The hosted MCP endpoint

The endpoint

POST https://mcp.meetext.xyz/mcp/products/{product_slug}
authorization: Bearer <per-environment token>
content-type: application/json
accept: application/json, text/event-stream

One endpoint per product, speaking JSON-RPC 2.0 over HTTP, the MCP Streamable HTTP transport. The slug is the one you chose when the product was created and does not change.

Every customer of that product calls the same URL. What differs is the token, and the token is what decides which capabilities are listed and whose credentials execute them.

Authentication

A bearer token resolves to exactly one customer environment. From that environment Meetext derives the current deployment, its frozen package, and the credentials to execute with.

• A missing or unknown token returns 401 with a www-authenticate challenge.
• A token valid for a different product returns 401 as well, with the same message. Whether the product exists is not leaked.
• Tokens are stored as digests. Rotate one with POST /v1/environments/{environment_id}/mcp-token/rotate.

Two customers of the same product can never see each other's tools or reach each other's credentials, because neither of those is looked up from the request. Both come from the environment the token resolved to.

Protocol versions

Three versions are supported. The client sends the one it wants in initialize, and Meetext echoes it back when it is supported. A version Meetext does not know is answered with the current default rather than an error, so an older client still gets a working session.

Methods

Anything else returns a JSON-RPC -32601 method not found. Notifications, messages with no id, are accepted and answered with nothing, as the specification requires.

{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "tools/call",
  "params": {
    "name": "search_campaigns",
    "arguments": { "query": "spring launch", "limit": 10 }
  }
}

Arguments are validated against the capability's own schema before anything reaches your backend. A call that fails validation is refused at Meetext and never forwarded.

Failures are results, not errors

This is the part clients get wrong. A capability that fails comes back as a successful JSON-RPC result whose payload carries isError: true. It is not a JSON-RPC error object.

{
  "jsonrpc": "2.0",
  "id": 4,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "search_campaigns acts on behalf of a specific user, but no verified user identity was supplied by the destination"
      }
    ],
    "isError": true
  }
}

The reason is the model. A tool failure is information the model can act on: it can ask the user for the missing detail, retry with different arguments, or explain what happened. A JSON-RPC error is a transport level fault, and most clients handle it by discarding the body and reporting that the connector is broken.

JSON-RPC errors are reserved for protocol faults:

Transport details

• Batching. A JSON array of messages is accepted and answered with an array of replies.
• Body limit. Requests above 2 MB are rejected with 413.
• Origin validation. Browser requests carrying an Origin header are checked against an allow list and rejected with 403 otherwise. Without that, a page on any site the customer visits could drive the endpoint using a token their browser holds. Server to server clients send no origin and are unaffected.
• Discovery. Under OAuth mode the 401 challenge names where protected resource metadata lives, per RFC 9728. Under static token mode it deliberately does not, because advertising a flow that cannot complete costs a client a failed setup and teaches it nothing true.

What happens when a deployment is not healthy

Tool calls execute in the healthy and degraded states. In every other state, tools/call returns a result with isError whose text explains the state in the reader's terms: waiting on authorization, disconnected, still validating.

tools/list keeps working throughout. The tools are a property of the package, not of the current state, and a client that cannot list tools has no way to tell a user what is temporarily unavailable.

See Deployments for how those states are reached, and the security model for what is recorded about each execution.