Skip to main content
Contact Button exposes one shared Streamable HTTP endpoint:
Authenticate with the bearer token returned by agent onboarding. The preferred protocol revision is 2025-11-25; compatibility negotiation also accepts 2025-06-18 and 2025-03-26. Send the negotiated MCP-Protocol-Version header after initialization. Existing clients configured with https://app.contactbutton.com/mcp remain supported. Use the API-domain endpoint for new connections.

Why there is not one process per button

A button, page, or form is a logical resource—not a separately deployed server. The shared MCP gateway authenticates once, lists only accessible workspaces, and routes every tool call by workspace and resource UUID. This avoids thousands of idle servers, centralizes fixes and rate limits, and preserves a single authorization boundary. Each public profile can still feel like its own agent: it has a unique manifest, Agent Card, A2A tenant identifier, actions, and knowledge resources.

Capabilities

The first server exposes tools for listing workspaces/pages/buttons/forms/apps, creating pages/buttons/forms, reading manifests, and searching published knowledge. It also exposes published profiles as contactbutton://pages/{page_id}/manifest resources. Write tools are annotated as mutating and accept stable public IDs. Hosts should show users the tool invocation before execution.
The server validates browser Origin headers against MCP_ALLOWED_ORIGINS. Configure the exact trusted dashboard and MCP host origins; do not use * in production.