MCP requirements

Purpose

An MCP server should help an assistant add CanWeChat to a customer website and verify inbound webhooks — using public docs and the Widget JS/HTTP contract. It is not a remote control for the CanWeChat inbox.

Scope

In scope: install snippet guidance, Widget JS API usage, domain-lock reminders, webhook signature verification examples, links to human dashboard steps.

Out of scope: session-authenticated dashboard HTTP (list/reply conversations, configure integrations, rotate webhook secrets, billing, team). Those stay in the product UI. Do not proxy them through MCP.

Required tools

get_llms_index — fetch or return https://canwechat.dev/llms.txt.

get_public_openapi — fetch or return https://canwechat.dev/openapi.json (widget paths only).

get_install_guide — return the install steps and script tag template (site key supplied by the user from /app/install).

get_widget_js_api — summarize CanWeChat.open / identify / send / events from /docs/widget.

get_webhook_verify_example — return HMAC verification guidance from /docs/webhooks for the customer’s backend language when known.

build_install_snippet — given a public site key from the user, return the exact script tag (no network call to CanWeChat admin APIs).

Resources

Expose read-only resources for: /llms.txt, /openapi.json, /docs/agents, /docs/install, /docs/widget, /docs/webhooks, /docs/mcp. MIME text/plain or application/json as appropriate.

Prompts

install_canwechat — walk script install → identify → remind human to lock domains and pick a reply channel in the dashboard.

integrate_webhooks — walk HMAC verification on the customer backend using the relay secret from the dashboard.

Safety

Never ask the model to call CanWeChat dashboard session APIs. Never echo Slack/Discord/Telegram tokens or webhook signing secrets into tool results or transcripts. Treat site keys as public but still avoid logging them unnecessarily.

Acceptance

A compliant MCP server can: (1) produce a correct install snippet from a user-provided site key, (2) point at Widget API usage for identify/open, (3) supply webhook verification guidance, (4) serve openapi.json / llms.txt as resources, (5) refuse tools that would operate the inbox or write integration credentials via internal APIs.