MCP server

An agent that can call a model can also call a model that has been checked, and can run the dashboard too: read stats and receipts, change settings, mint keys, top up credits. One endpoint, the same engine and the same rules as the app.

Endpoint

JSON-RPC 2.0 over a single POST. Authentication is a Bearer API key, the same one the REST surface takes.

endpoint

https://www.llm11.com/api/mcp

Connect a client

Most MCP clients take a URL and a header map. This is the shape Claude Code and Cursor use.

mcp config

{
  "mcpServers": {
    "llm11": {
      "type": "http",
      "url": "https://www.llm11.com/api/mcp",
      "headers": { "Authorization": "Bearer YOUR_LLM11_KEY" }
    }
  }
}

Run the dashboard from an agent

Everything the dashboard shows is a read tool and everything it lets you change is a write tool. Project tools act on the project the key belongs to; pass projectId to act on another project in the same workspace. Call whoami first to see what the credential can do.

Write tools need a live API key. A sandbox key and a workload identity token can read and call verify_request, but are refused on anything that changes settings, spend, keys or trust, so a token holder cannot widen who else is trusted. Key values and provider keys are never readable: a new key is shown once, and the workspace owner is emailed when one is made.

Read

whoami: Who this credential is: its project and workspace, the workspace's credit balance, whether it is a live key, a sandbox key or a workload identity, and whether it can make changes. Call this first.
list_projects: Every project in this workspace, with its routing pool, verification policy and retention settings.
get_project: One project's settings: routing pool, verification policy, content retention and which provider keys are stored (fingerprints only).
get_stats: The overview page for a project: request counts, spend, savings against the declared baseline, latency, a daily series and breakdowns by task and model.
list_requests: The receipt browser: a project's requests, newest first, each with verdict, models, cost and savings. Filter by verdict or task type; page with `nextCursor`.
get_request: One request's full receipt, with the verification checks that ran on it.
get_billing: The workspace's credit balance, whether it has a billing account, and the credit packs that can be bought (face value, and what is charged including the fee).
get_ledger: The workspace's credit ledger: top-ups and debits, newest first.
list_models: The live model catalogue with prices, the routing packs (llm11-fast, -balanced, -smart) resolved against it right now, and which lab is answering. Use it to choose a pack or a custom pool.
list_api_keys: A project's active API keys: name, prefix, sandbox flag and last use. The key values themselves are never readable.
list_provider_credentials: Which provider keys (bring your own key) a project has stored: provider, fingerprint and timestamps. The key is never returned.
list_workload_identities: A project's active workload identity rules, each with the audience a token must carry.

Write

create_project: Create a project in this workspace. It starts with the default routing pool and no keys; mint one with create_api_key.
update_project: Change a project's settings: name, routing pool (a pack id, or `custom` with `poolModels`), verification policy, and whether prompt text is retained and for how many days (max 90). Send only what changes; `policy` is replaced whole.
create_api_key: Mint an API key for a project. The raw value is returned once and cannot be read again, so store it straight away. The workspace owner is emailed that a key was made. A sandbox key is low-trust: it can call the API but not make changes.
revoke_api_key: Revoke an API key by id. It stops working immediately. Revoking the key you are calling with is allowed.
set_provider_key: Store or rotate a project's own provider key (bring your own key). It is checked with the provider, encrypted, and never returned; only a fingerprint is shown. Requests pinned to that provider's models then skip routing and credit billing.
remove_provider_key: Delete a project's stored provider key.
create_workload_identity: Trust an OIDC issuer for a project: workloads presenting a token from it call /v1/* with no API key. A rule must name a subject pattern (trailing * allowed) or a claim. Returns the rule's audience, which the workload must request its token for. The issuer's discovery document and keys are fetched now, so a typo fails here.
revoke_workload_identity: Revoke a workload identity rule by id. Tokens for it stop working immediately.
create_credit_checkout: Open a Stripe checkout to top up the workspace's credits. Returns a payment link for a person to open and pay; nothing is charged until they do. faceCents is one of 500, 2500, 10000, 50000.
open_billing_portal: A Stripe billing portal link for the workspace (receipts, payment methods). Needs a past purchase.

Creating a workspace and signing in stay in the app, since they need a person. Buying credits returns a Stripe link for someone to open; nothing is charged until they pay.

The tool: `verify_request`

Takes messages and an optional context. Triages, routes, verifies, escalates on failure, and returns the final answer as text with the receipt attached under _meta.

tools/call

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "verify_request",
    "arguments": {
      "messages": [
        { "role": "user", "content": "Does this clause allow early termination?" }
      ],
      "context": "8.2 Either party may terminate on 90 days written notice."
    }
  }
}

isError comes back true when the verdict is a failure, so a well-behaved agent can notice a suspect answer without parsing the receipt. Agents that do read the receipt get the full breakdown of which checks ran and what each one found.

Why route an agent through this

An agent loop makes many calls per task and most of them are small: decide the next step, classify an intermediate result, extract a field. Those are exactly the calls a cheaper model handles well and exactly the ones where a wrong answer propagates silently into every later step, because nothing in the loop is checking. Routing them through here means each step is checked at a cost proportional to what it was worth, and the trail of receipts explains where a run went wrong afterwards.

Other machine-readable surfaces

/api/v1/openapi.json for the full REST schema.
/llms.txt for a plain-language summary an assistant can read.
/pricing.json for the plan table as data, generated from the same constant the pricing page renders from.