SiteGPT
Manage SiteGPT chatbots and account resources through the SiteGPT API v2: search the spec, run reads and writes, preview chatbots, and view analytics.
От сообщества: Добавлен пользователем или импортирован; проверьте владельца перед подключениемРаботаетБез входаГлобальныйБесплатноМожет изменять данные
Что умеет
- Search: 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
- Execute Read: 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
- Execute Write: 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
Какие данные видит
Нужен ли аккаунт
Не нужен: сервер работает без входа
Manage SiteGPT chatbots and account resources through the SiteGPT API v2: search the spec, run reads and writes, preview chatbots, and view analytics.
Список инструментов сервера (17)
Технические названия из tools/list. Нужны только разработчикам.
| search | 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; } |
| execute_read | 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_write | 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. |
| preview_chatbot | 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. |
| send_chat_message | 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. |
| get_onboarding_status | Get the live status of an agent-first onboarding workspace: workspace and claim state, the setup checklist (knowledge crawl/training, persona, starters, …), the browser onboarding page URL, and the POST-only claim API endpoint (claimUrl is for agents/CLI clients — never a page to open in a browser). The onboarding-progress view polls this while pages crawl and train. Requires the temporary onboarding token issued by the onboarding start endpoint. Uses GET /api/v2/onboarding/workspaces/{workspaceId}. |
| get_chatbot_appearance | Read the chatbot widget appearance (colors, launcher position and shape, title, welcome message, placeholder, tooltip) plus its starter questions, for the inline appearance card. Uses GET /api/v2/chatbots/{chatbotId}/settings/appearance and GET /api/v2/chatbots/{chatbotId}/starters. |
| update_chatbot_appearance | 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. |
| list_conversations | List a chatbot conversation inbox with filters (open/resolved status, escalated-only) and cursor pagination, projected to compact rows with a last-message snippet. Renders as the inline conversations inbox. Uses GET /api/v2/chatbots/{chatbotId}/conversations. |
| get_conversation | Read one conversation with its transcript (visitor questions and chatbot/system answers, capped at 2000 characters per message). Renders as the transcript panel of the inline conversations inbox. Uses GET /api/v2/chatbots/{chatbotId}/conversations/{threadId}. |
| get_chatbot_analytics | Get chatbot analytics for the inline analytics card: message counts and feedback split, training/knowledge state (from the chatbot dashboard endpoint) plus account-wide quota usage and a 12-month message-volume history (from the usage endpoint). Uses GET /api/v2/chatbots/{chatbotId}/dashboard and GET /api/v2/usage. |
| list_leads | List the leads a chatbot collected (name, email, phone, received time, starred/archived flags) with search, status filter, and cursor pagination. Renders as the inline leads browser. Uses GET /api/v2/chatbots/{chatbotId}/leads. |
| list_escalations | List the open conversations that are escalated to a human and waiting — the queue behind the inline escalations view — with cursor pagination for queues longer than one page. Read-only: replying to escalated visitors happens in the SiteGPT dashboard inbox (API v2 has no agent-reply endpoint yet). Uses GET /api/v2/chatbots/{chatbotId}/conversations with escalated=true and status=open. |
| list_knowledge_sources | List a chatbot connector data sources (Notion, Google Drive, Confluence, …) with their sync state, plus document counts by ingestion status. Renders as the inline knowledge view. Uses GET /api/v2/chatbots/{chatbotId}/knowledge/sources and GET /api/v2/chatbots/{chatbotId}/documents/stats. |
| create_knowledge_source | Create a new OAuth knowledge source connection (Notion, Google Drive, Dropbox, OneDrive, Box, SharePoint, or Confluence) and get the browser authorization URL to finish connecting it. Confluence additionally requires the site domain (e.g. your-team.atlassian.net). GitHub is not available here — its connections carry an access token and must be set up in the SiteGPT dashboard. Uses POST /api/v2/chatbots/{chatbotId}/knowledge/sources. |
| authorize_knowledge_source | Get a fresh browser authorization URL for an existing knowledge source connection (for example one still pending OAuth). Uses POST /api/v2/chatbots/{chatbotId}/knowledge/sources/{connectionId}/authorize. |
| upload_knowledge_file | 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. |