SiteGPT

Send a visitor message to a SiteGPT chatbot and get its answer — the data lane behind the inline chatbot preview's built-in chat. The first call (no threadId) creates a conversation and returns its threadId; pass that threadId on follow-ups to continue the same conversation. Messages are capped at 20000 characters (the endpoint's limit). On chatbots in human-support mode the message is delivered but answer is null — a human replies in the site widget. Uses POST /api/v2/chatbots/{chatbotId}/messages and POST /api/v2/chatbots/{chatbotId}/conversations/{threadId}/messages.

send_chat_message

Run read-only SiteGPT API v2 calls (GET only) using JavaScript code. Targets the SiteGPT API v2 (spec: https://sitegpt.ai/api/v2/openapi.json, docs: https://sitegpt.ai/docs/api-reference/v2/getting-started). First use 'search' to find the right endpoints. Requests run through an authenticated host-side bridge scoped to your OAuth grant. Write methods (POST, PUT, PATCH, DELETE) are rejected here — use the execute_write tool for those. Available in your code: interface RequestOptions { method: "GET"; path: string; query?: Record<string, string | number | boolean | undefined>; body?: unknown; contentType?: string; rawBody?: boolean; } // OpenAPI 3.x spec with $refs resolved inline. // The spec object follows the standard OpenAPI 3.x structure. interface OperationObject { summary?: string; description?: string; operationId?: string; tags?: string[]; parameters?: Array<{ name: string; in: "query" | "header" | "path" | "cookie"; required?: boolean; schema?: unknown; description?: string; }>; requestBody?: { required?: boolean; description?: string; content?: Record<string, { schema?: unknown }>; }; responses?: Record<string, { description?: string; content?: Record<string, { schema?: unknown }>; }>; security?: Array<Record<string, string[]>>; deprecated?: boolean; } interface PathItem { summary?: string; description?: string; get?: OperationObject; post?: OperationObject; put?: OperationObject; patch?: OperationObject; delete?: OperationObject; head?: OperationObject; options?: OperationObject; trace?: OperationObject; parameters?: OperationObject["parameters"]; } interface OpenApiSpec { openapi: string; info: { title: string; version: string; description?: string }; paths: Record<string, PathItem>; servers?: Array<{ url: string; description?: string }>; components?: Record<string, unknown>; tags?: Array<{ name: string; description?: string }>; } declare const codemode: { spec(): Promise<OpenApiSpec>; request(options: RequestOptions): Promise<unknown>; }; Your code must be an async arrow function that returns the result. Example: async () => { return await codemode.request({ method: "GET", path: "/your/endpoint" }); } SiteGPT API v2 is scoped by the bearer token used for this MCP connection. Use search first, then execute_read for lookups and execute_write for changes — /api/v2 paths only.

execute_read

Search the SiteGPT API v2 OpenAPI spec. Targets the SiteGPT API v2 (spec: https://sitegpt.ai/api/v2/openapi.json, docs: https://sitegpt.ai/docs/api-reference/v2/getting-started). codemode.spec() returns $refs resolved inline. This tool only reads the local spec catalog; it performs no API calls. Types: // OpenAPI 3.x spec with $refs resolved inline. // The spec object follows the standard OpenAPI 3.x structure. interface OperationObject { summary?: string; description?: string; operationId?: string; tags?: string[]; parameters?: Array<{ name: string; in: "query" | "header" | "path" | "cookie"; required?: boolean; schema?: unknown; description?: string; }>; requestBody?: { required?: boolean; description?: string; content?: Record<string, { schema?: unknown }>; }; responses?: Record<string, { description?: string; content?: Record<string, { schema?: unknown }>; }>; security?: Array<Record<string, string[]>>; deprecated?: boolean; } interface PathItem { summary?: string; description?: string; get?: OperationObject; post?: OperationObject; put?: OperationObject; patch?: OperationObject; delete?: OperationObject; head?: OperationObject; options?: OperationObject; trace?: OperationObject; parameters?: OperationObject["parameters"]; } interface OpenApiSpec { openapi: string; info: { title: string; version: string; description?: string }; paths: Record<string, PathItem>; servers?: Array<{ url: string; description?: string }>; components?: Record<string, unknown>; tags?: Array<{ name: string; description?: string }>; } declare const codemode: { spec(): Promise<OpenApiSpec>; }; Your code must be an async arrow function that returns the result. Examples: // List all paths async () => { const spec = await codemode.spec(); return Object.keys(spec.paths); } // Find endpoints by tag async () => { const spec = await codemode.spec(); const results = []; for (const [path, methods] of Object.entries(spec.paths)) { for (const [method, op] of Object.entries(methods)) { if (op.tags?.some(t => t.toLowerCase() === 'your_tag')) { results.push({ method: method.toUpperCase(), path, summary: op.summary }); } } } return results; }

search

Create, update or delete SiteGPT API v2 resources (POST, PUT, PATCH or DELETE only) using JavaScript code. Targets the SiteGPT API v2 (spec: https://sitegpt.ai/api/v2/openapi.json, docs: https://sitegpt.ai/docs/api-reference/v2/getting-started). First use 'search' to find the right endpoints and 'execute_read' for any lookups. Requests run through an authenticated host-side bridge scoped to your OAuth grant. GET is rejected here — use the execute_read tool to read data. GitHub knowledge-source connections cannot be created or updated through this tool because they carry an access token — direct users to the SiteGPT dashboard for GitHub setup; OAuth-based connectors (Notion, Google Drive, …) can be created here and finish authorization in the browser. Available in your code: interface RequestOptions { method: "POST" | "PUT" | "PATCH" | "DELETE"; path: string; query?: Record<string, string | number | boolean | undefined>; body?: unknown; contentType?: string; rawBody?: boolean; } // OpenAPI 3.x spec with $refs resolved inline. // The spec object follows the standard OpenAPI 3.x structure. interface OperationObject { summary?: string; description?: string; operationId?: string; tags?: string[]; parameters?: Array<{ name: string; in: "query" | "header" | "path" | "cookie"; required?: boolean; schema?: unknown; description?: string; }>; requestBody?: { required?: boolean; description?: string; content?: Record<string, { schema?: unknown }>; }; responses?: Record<string, { description?: string; content?: Record<string, { schema?: unknown }>; }>; security?: Array<Record<string, string[]>>; deprecated?: boolean; } interface PathItem { summary?: string; description?: string; get?: OperationObject; post?: OperationObject; put?: OperationObject; patch?: OperationObject; delete?: OperationObject; head?: OperationObject; options?: OperationObject; trace?: OperationObject; parameters?: OperationObject["parameters"]; } interface OpenApiSpec { openapi: string; info: { title: string; version: string; description?: string }; paths: Record<string, PathItem>; servers?: Array<{ url: string; description?: string }>; components?: Record<string, unknown>; tags?: Array<{ name: string; description?: string }>; } declare const codemode: { spec(): Promise<OpenApiSpec>; request(options: RequestOptions): Promise<unknown>; }; Your code must be an async arrow function that returns the result. Example: async () => { return await codemode.request({ method: "POST", path: "/your/endpoint", body: { name: "..." } }); } SiteGPT API v2 is scoped by the bearer token used for this MCP connection. Use search first, then execute_read for lookups and execute_write for changes — /api/v2 paths only.

execute_write

Render a live, interactive preview of a SiteGPT chatbot directly in the conversation (MCP Apps extension). Call it after creating or inspecting a chatbot, passing the chatbot id — an RFC-4122 UUID or a 15-20 digit numeric id — and optionally the chatbot title for the preview header. Returns { chatbotId, widgetUrl }; hosts that support MCP Apps render the actual chat widget from the ui://sitegpt/chatbot-preview resource, and any client can open widgetUrl in a browser instead. Performs no API calls and does not verify that the chatbot exists — use execute_read for lookups. Note: chatbots that restrict embedding via Allowed Domains (Settings > General) block the inline frame; the preview then switches to a built-in chat driven by the send_chat_message tool, and shows a fallback with the direct link when that fails too.

preview_chatbot

Update the chatbot widget appearance: title, welcome message, placeholder, tooltip, brand/launcher/link colors (#rrggbb), and launcher position. Only the provided fields change; the tool returns the full updated appearance. This changes the LIVE widget customers see. Uses PATCH /api/v2/chatbots/{chatbotId}/settings/appearance.

update_chatbot_appearance

Upload one file (base64-encoded, max 1500000 bytes decoded — about 1.5 MB; the MCP transport caps request bodies, larger files go through the dashboard) as chatbot training knowledge. Ingestion is queued asynchronously. Uses POST /api/v2/chatbots/{chatbotId}/knowledge/files.

upload_knowledge_file