The MCP endpoint

The MCP endpoint is how tool-using assistants (claude.ai connectors, ChatGPT and other MCP clients) talk to a practice:

POST /api/a2a/{public-token}/mcp

Transport is Streamable HTTP, stateless, JSON responses only. The token rides in the URL because several assistant platforms cannot set custom headers when users add a connector.

Live demo connector, ready to paste into any MCP client:

https://founderexecute.com/api/a2a/a2a_4adce6dd8c149abd94d885bbe7a32323cfc9745edfa53b8e/mcp

One tool: reception_message

The connected assistant sees exactly one tool:

{
  "name": "reception_message",
  "inputSchema": {
    "message": "string — your message to the receptionist, plain text",
    "conversation_id": "uuid, optional — from the previous result; omit only on the first message"
  }
}

Every call returns:

{
  "reply": "Thursday I have 14:30 or 16:00 with Ms Weber. Which suits?",
  "conversation_id": "0d7c…",
  "status": "ok"
}

The conversation contract

1. The assistant sends messages, the reception answers, and the assistant must echo conversation_id back every turn. That id is the whole session state; there are no server sessions.
2. When the reception needs to verify the patient, status becomes "awaiting_input": the patient has just received a 6-digit SMS code, the assistant asks its user for it and relays it verbatim.
3. Before anything is final the reception reads the booking back and asks for confirmation.
4. If a conversation has expired, the next reply carries "conversation_reset": true and a fresh id. The assistant briefly restates the request and carries on.

These rules ship to the assistant in the MCP instructions field, so well-behaved clients follow them without custom work on your side.

Limits

Per token: 30 requests per minute, plus a daily conversation cap counted in the database. Enough for real patients, boring for loops.

The same conversation over A2A

Agents that speak the A2A protocol instead POST JSON-RPC to /api/a2a/{public-token}: message/send with text parts and an optional contextId (same continuity idea), and tasks/get to re-read the last task. Responses are A2A task objects whose state is completed or input-required (the SMS step). Streaming is not offered on either transport.