Let your vendor bots use your bot's phone

• Texts and calls only reach people who contacted the number first, or whom you added as contacts. Anyone who replied STOP stays blocked. See Calls and texts in threads.
• Email is always a draft. send_email waits for your OK before anything is sent.
• The daily text limit and carrier registration apply. If a tool is refused, the vendor bot gets one plain sentence saying why.
• Every message says where it came from: “Sent by Claude via Gizzi”. Calls open with that same line in their brief.

​

Connect

1. In Allternit, open the vendor bot and look under Use the phone. See Vendor bots on your bot’s phone.
2. The vendor bot uses the phone and mailbox of the bot that directs it. If exactly one of your bots has a phone number, that is the one. With more than one, a developer sets it with the connector API below until the app offers a picker.
3. Copy the connector address, which looks like https://mcp.allternit.com/mcp/bots/<vendor bot id>.
4. Add it where the vendor lets you:
   • Claude: Settings → Connectors → Add custom connector. Paste the address and sign in to Allternit when asked.
   • ChatGPT: turn on developer mode, then add the address as a connector and sign in to Allternit when asked.
   • Grok: Grok has no custom connectors, so Gizzi relays instead: ask Gizzi to pass the message to your bot.

​

What the vendor bot can do

​

For developers

• Public edge, cloud-api (cmd/allternit-cloud-api/src/routes/mcp_edge.rs), at api.allternit.com and mcp.allternit.com. Both hosts use the same paths, with no prefix change. This is what Claude and ChatGPT call. It also serves the agents server (POST /mcp/server, POST /mcp) and the .well-known documents below. The edge answers server/discover itself after checking the token, so a client learns versions, capabilities and instructions without waking the computer; every other method is forwarded. GET on a connector path answers 405 with Allow: POST after the token is checked.
• Runtime, allternit-api (cmd/allternit-api/src/mcp_vendor_bots.rs, next to the agents server in mcp_agents.rs), for a signed-in session on the computer itself. The edge never sends the OAuth token here.

1. It verifies the Clerk token (signature, issuer, expiry) and then the sign-in model described under OAuth below: either a token for this connector with aud and its own scope, or a Clerk token with scope profile whose OAuth client you approved for this connector. Nothing is forwarded until all of that passes.
2. It lists the token owner’s paired runtimes (connected ones first, then most recently seen) and calls POST /webhooks/mcp-edge/bots/:vendorBotId on the first. The call goes over the signed runtime relay (x-allternit-runtime-sig, x-allternit-runtime-ts, x-allternit-owner = the verified user, x-allternit-mcp-client = the OAuth client), and the relay wakes a sleeping computer. The runtime accepts only that signature, and only as the owner it is paired as; its own owner checks, revoked-client check and audit run unchanged.
3. A runtime that doesn’t hold the bot answers 404 {"error":"not_found"} and the next runtime is tried. The runtime that answered is remembered for 10 minutes. If none holds the bot the caller gets the same 404 as for someone else’s bot id, so there is no way to probe for bot ids. The agents server uses only the best runtime.
4. The whole attempt, including waking a computer, has a 25 second budget. When it is exceeded, or every candidate is offline or still waking, the answer is HTTP 200 with a JSON-RPC error carrying the caller’s request id: {"jsonrpc":"2.0","id":<id>,"error":{"code":-32000,"message":"Your Allternit computer is offline; it will be woken — try again in a minute."}}.
5. A revoked connection comes back 401 with the WWW-Authenticate challenge (the edge adds it, because the relay drops runtime headers).

{
  "resource": "https://mcp.allternit.com/mcp/bots/<id>",
  "authorization_servers": ["https://allternit.com/__clerk"],
  "scopes_supported": ["profile"],
  "bearer_methods_supported": ["header"],
  "resource_name": "Allternit vendor bot"
}

{ "error": "approval_required", "client": "<client id>", "target": "bot:<id>", "approve_url": "https://ai.allternit.com/mcp/approve?client=…&target=bot:<id>", "message": "The owner has not approved this app (…) for this connector. Approve it here, then retry: …" }

• send_text is a message in the phone:<botE164>:<to> thread, sent by the sms transport to the cloud’s POST /api/v1/channels/sms/send. The cloud enforces opt-out, consent, registration state and the daily cap (ALLTERNIT_SMS_DAILY_CAP).
• start_call calls POST /api/v1/phone/calls/outbound; 403 no_consent becomes a tool error.
• send_email is send_email_for_user, which always queues a mailflare approval.
• post_message calls the runtime’s channel-start path (channel_start::VendorStarter, registered at boot), so each platform’s rules, the bot’s channel policy and approvals apply. A refusal comes back as one plain sentence. See Starting conversations.
• ask_bot is agent_send to the directing bot, so its approval flow applies.