MCP servers

Connect a Model Context Protocol server you run, or a third party's, and its tools appear to the model exactly like a built-in one.

MCP (Model Context Protocol) is an open standard for a server that exposes tools to a model. Register one here, name it on a chat completion, and its tools are fetched, translated into the same shape as a function tool, and executed on your behalf when the model calls them — you never see the protocol.

What this costs
Metered per call your server receives through Larsa. Pricing is set by your platform operator and may not be published yet — check Pricing.
A registered server sees the arguments the model sends it
When the model calls one of its tools, Larsa sends your server the arguments the model filled in — which can include text drawn straight from the conversation. Register only a server you trust with that. Any headers you configure, such as an API key your server expects, are sent on every call and are never echoed back by a later read.

The transport

One JSON-RPC 2.0 request per call, over streamable HTTP — the single-URL transport, not stdio and not the older two-endpoint SSE transport. When you register a server, Larsa calls tools/list immediately to publish its schema; when the model uses one of its tools, Larsa calls tools/call. There is no separate initialize handshake before either — point url at a server that answers those two methods directly.

Registering a server

POST/v1/mcp/servers
ParameterTypeDescription
label
Required
string[A-Za-z0-9_-]{1,40}. Becomes the prefix on every one of this server's tool names, so two servers offering search never collide.
url
Required
stringYour server's streamable-HTTP endpoint.
headers
Optional
objectSent with every request to your server — an API key it expects, for instance.
Response
{
  "label": "docs-lookup",
  "registered": true,
  "reachable": true,
  "tools": ["mcp__docs-lookup__search", "mcp__docs-lookup__fetch"]
}

Registration succeeds even when the server cannot be reached at that moment — reachable is false and an error explains why, rather than the whole call failing. Larsa tries tools/list again the next time you use it.

Listing its tools

GET/v1/mcp/{label}/tools
Response
{
  "object": "list",
  "data": [{
    "type": "function",
    "function": {
      "name": "mcp__docs-lookup__search",
      "description": "…",
      "parameters": { "type": "object", "properties": { "query": {"type": "string"} } }
    }
  }]
}

Register and list, together

# Register the server.
curl https://api.console.larsa.larsima.com/v1/mcp/servers \
  -H "Authorization: Bearer $LARSA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "label": "docs-lookup",
    "url": "https://tools.example.com/mcp",
    "headers": {"Authorization": "Bearer example-server-key"}
  }'

# List the servers on this account.
curl https://api.console.larsa.larsima.com/v1/mcp/servers \
  -H "Authorization: Bearer $LARSA_API_KEY"

Using it from a chat completion

tools
[{
  "type": "mcp",
  "server_label": "docs-lookup",
  "allowed_tools": ["search"]
}]
allowed_tools is optional and matches the server's own short names, unprefixed — leave it out to offer every tool the server has. An unreachable server at request time simply loses its tools for that call rather than failing the request; only larsa-auto runs MCP tools.
curl https://api.console.larsa.larsima.com/v1/chat/completions \
  -H "Authorization: Bearer $LARSA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "larsa-auto",
    "messages": [{"role": "user", "content":
      "Use docs-lookup to find our internal deployment guide for the staging environment."}],
    "tools": [{"type": "mcp", "server_label": "docs-lookup",
      "allowed_tools": ["search"]}]
  }'

Removing a server

DELETE/v1/mcp/servers/{label}

The same request shape as everywhere else on this page, just DELETE and no body. Every request naming this server_label afterward simply gets none of its tools.

Navigate Open esc Close