TuringCorp

A decision model for the calls that don't have a right answer — over MCP.

Your agent has two defensible options and has to pick one. Send both here. You get back which one is preferred, how far apart they were judged, and why.

The confidence is what you route on. It is calibrated, not decorative: on both published benchmarks accuracy rises with the value — JudgeBench 99.6% in the 90%+ band down to 67.7% below 70%, and the harder ContextualJudgeBench 83.3% down to 55.4%. So an agent can act on a high value and escalate a low one instead of guessing. Full tables, sample sizes and method: api.turingcorp.net.

Two plans. Two drafts. Two diagnoses. Two vendors. The case where both are arguable is exactly where a single model's own opinion is least reliable — and where a second, independent judgement is worth a call.

Connect

Endpointhttps://mcp.turingcorp.net/mcp
Aliases/ and /mcp/ (same route)
TransportStreamable HTTP, stateless — no session, no handshake state. GET /mcp → 405 is normal.
Protocol2026-07-28 (modern — server/discover, no handshake) and legacy clients via the standard initialize handshake on the same route
Healthhttps://mcp.turingcorp.net/healthz
Discoverytools/list needs no credentials — scanners and clients can read the full tool list unauthenticated, by design.

Two ways in — and they are not the same

⚠️ The part that catches people out: being able to call the tool through a host does not mean you can reach the REST API. The host may never hand you the underlying Agent Pass, so a job-retrieval call you make on your own can come back 401. If your host declares the Tasks extension, retrieve through the tool surface instead (see Retrieving a result); if it does not, retrieval may simply not be reachable from where you are.

Add it to your client

The server is named TuringCorp — that is the name to enter below, and the one that appears in your client's server list. The tool you get once connected is decide (title Decider: pick the better of two options); the server name and the tool name are two different things.

You need an Agent Pass for every option below — get one at agent-pass.turingcorp.net. Discovery (tools/list) works without one; calling decide does not.

🔑 Where the pass lives matters. If your client can keep it out of the file, do that — VS Code's ${input:…}, Codex's bearer_token_env_var. A pass written in plain text inside mcp.json or any client config is readable by every agent and process that can read that file, and assistants do read their own config — one can print your pass straight into its output. Treat a client config as public within your machine.

Claude Code

claude mcp add --transport http TuringCorp https://mcp.turingcorp.net/mcp --header "Authorization: Bearer <your Agent Pass>"

Clients that read a JSON config — Cursor, Windsurf, Claude Desktop

{
  "mcpServers": {
    "TuringCorp": {
      "type": "http",
      "url": "https://mcp.turingcorp.net/mcp",
      "headers": { "Authorization": "Bearer <your Agent Pass>" }
    }
  }
}

Keep the "type": "http" line. Clients that read a url entry with no type treat it as a local stdio server and skip it — that is a configuration error, not a network one.

Cline

Cline needs a different type: "streamableHttp" (camelCase, no hyphen). Any other value, or omitting it, makes Cline fall back to SSE — which this server does not speak — and the connection then fails with 405. Cline keeps its servers in cline_mcp_settings.json: open the MCP Servers icon (stacked-server icon in the top toolbar) → Configure tab → Configure MCP Servers.

{
  "mcpServers": {
    "TuringCorp": {
      "type": "streamableHttp",
      "url": "https://mcp.turingcorp.net/mcp",
      "headers": { "Authorization": "Bearer <your Agent Pass>" },
      "disabled": false,
      "autoApprove": [],
      "timeout": 300
    }
  }
}

timeout is in seconds — leave it at 300 or higher. Cline has had a bug (#2296, closed 2025-06-23) where a request died after roughly a minute regardless of that setting. If a decide call is cut off at about 60 seconds, suspect that rather than the server — and retrieve by job_id instead of retrying, because a retry is a second paid call.

VS Code

Put this in .vscode/mcp.json in your project, or in the user-profile mcp.json. Note the key here is servers, not mcpServers:

{
  "servers": {
    "TuringCorp": {
      "type": "http",
      "url": "https://mcp.turingcorp.net/mcp",
      "headers": { "Authorization": "Bearer <your Agent Pass>" }
    }
  }
}

Codex — ChatGPT work mode and the Codex CLI

In the UI: Server name anything you like (TuringCorp), type Streamable HTTP (not Stdio — nothing runs on your machine), URL https://mcp.turingcorp.net/mcp. Leave the command, arguments and environment-variable fields empty; they belong to the Stdio type.

Then edit ~/.codex/config.toml — the UI has no field for the credential, and its default tool timeout is too short for this server:

[mcp_servers.TuringCorp]
url = "https://mcp.turingcorp.net/mcp"
http_headers = { Authorization = "Bearer <your Agent Pass>" }
tool_timeout_sec = 300

⚠️ tool_timeout_sec defaults to 60 seconds, which is far too short for this server. Leave it at the default and every call is cut off before the answer arrives. Set it to at least 180; 300 is safer.

To keep the pass out of the file, use bearer_token_env_var = "TURINGCORP_AGENT_PASS" instead of http_headers and export that variable — Codex prepends Bearer itself, so the variable holds the bare pass, not Bearer <pass>. With http_headers you write the whole value yourself.

TRAE (TraeCode)

Settings → MCP → Add → Manual, then paste the JSON below. TRAE's own docs lead with a stdio example (command + args) — that does not apply here: this is a remote server, so use url.

{
  "mcpServers": {
    "TuringCorp": {
      "url": "https://mcp.turingcorp.net/mcp",
      "headers": {
        "Authorization": "Bearer <your Agent Pass>",
        "RUN_MCP_TIMEOUT_MS": "300000"
      }
    }
  }
}

⚠️ TRAE sets its tool-call timeout through the headers block, and its documented value is 60000 ms. 60 s is far too short for this server, so leave it there and every call is cut off before the answer arrives. Raise RUN_MCP_TIMEOUT_MS — 300000 is 5 minutes.

For a project-scoped server, put the same JSON in .trae/mcp.json and switch on 启用项目级 MCP (Settings → MCP) first.

Platforms that ask for a header name and a token — Coze (扣子) and similar

These platforms send the token value verbatim and will not add an auth scheme for you, so the value has to carry it: header name Authorization, value Bearer <your Agent Pass> — including the word Bearer and the space after it. On Coze: 扩展 → MCP → 添加自定义 MCP, or 资源库 → 添加 → 插件 with 类型 set to MCP. Plugin URL https://mcp.turingcorp.net/mcp; 授权方式 = Service token / API key; 位置 = Header; Parameter name = Authorization.

Clients that only speak stdio

Bridge to this remote server with mcp-remote. The credential must go in through --header — mcp-remote does not read a AUTHORIZATION environment variable, so a config that only sets one connects, lists tools, and then fails on the first call with 401. Note the missing space after Authorization:: some clients mangle spaces inside args.

{
  "mcpServers": {
    "TuringCorp": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.turingcorp.net/mcp", "--header", "Authorization:${AGENT_PASS}"],
      "env": { "AGENT_PASS": "Bearer <your Agent Pass>" }
    }
  }
}

To check what went wrong, run npx -y mcp-remote@latest https://mcp.turingcorp.net/mcp on its own: it connects and lists tools, then fails on the first call with 401 — discovery is open, execution is not.

Making a decision: decide

TitleDecider: pick the better of two options
Inputtask, optionA, optionB — all required
OutputbetterOption ("option_A"|"option_B"), confidence (e.g. "76.7%"), reason, job_id
AnnotationsreadOnlyHint: true · openWorldHint: false · idempotentHint: false
TimeoutReserve 180–300 seconds — a decision is a long call. The timeout is a client/host setting, not a tool parameter: there is nothing to pass in the call. A 60s default cuts it off before the answer arrives; if that happens, do not call again — retrieve it with get_result.

Retrieving a result: get_result

Inputjob_id — optional
OutputWith an id: that job's status and, once it succeeded, the same decision body the original call returned. With no id: the job ids this credential created in the last 7 days.
AnnotationsreadOnlyHint: true · idempotentHint: true — read-only and free: it starts no new work and costs nothing
CredentialNone of your own. The host attaches the Agent Pass, exactly as it does for decide — an agent never handles the pass

This is the recovery path when a call is cut off by a client timeout, and the reason you can leave your client's timeout alone: do not re-call decide (a retry is a new paid call) — call get_result with no argument to find the id, then again with it.

A successful call returns the decision inline. betterOption, confidence, reason and job_id all arrive in the same tool result — there is nothing to poll and nothing to fetch afterwards. The job_id is only for the case where the call never came back (timeout, dropped connection, client gave up waiting).

confidence is this service's own judgement of how far apart the two options were — a reference for your decision-making, not an instruction, not a result, and not a prediction of how the choice turns out. Higher means the chosen option stood out more clearly against the other one.

Choose your own threshold for your own use case. For high-stakes or irreversible decisions, apply your own review policy. Observed accuracy by range, and how it was measured, is published at api.turingcorp.net.

idempotentHint: false is an honest declaration: a retried call is a new call. So rather than retrying blindly, record the id the call returns (that is the job id) — a job you have already paid for can be collected afterwards with the same Agent Pass, for 7 days. See Retrieving a result.

Two error conventions, on purpose. A credential problem is decided before the call runs, so it is a real HTTP status (401) with a JSON-RPC error body — branch on the HTTP status. A business failure ends as an ordinary MCP tool result (isError: true), which the protocol carries as HTTP 200 — branch on isError and the JSON block, not on the HTTP status. The http_status inside that block is the upstream status (e.g. 402), not the tool call's.

Every call returns a job_id. Keep it. A decision is a long call, and if the call times out or the connection drops, that id is how you get the result — see Retrieving a result. Calling decide again is a new call.

When not to use it

How to fill the three arguments

{
  "task": "Which version of the delivery-slip email do I send to a client we want to keep?",
  "optionA": "Short and direct: the integration took longer than planned, delivery moves to the 24th, everything else is unchanged.",
  "optionB": "Warmer and longer: thank them for the kickoff, explain that dependencies took more time, offer to walk through the details."
}

Long calls: the Tasks extension

A decision is a long call — longer than many clients wait. If your client declares the io.modelcontextprotocol/tasks extension, decide returns a task handle you can poll instead of holding one connection open:

{"resultType":"task","taskId":"<id>","status":"working","ttlMs":604800000,"pollIntervalMs":2000}

Poll tasks/get with {"taskId":"<id>"}: the status moves to completed (carrying the same payload a synchronous call returns) or failed. The handle is valid for 7 days, so a result you already paid for can be collected later rather than paid for twice. tasks/cancel only acknowledges the request — it is cooperative and does not guarantee the work stops. Clients that do not declare the extension see no change at all.

An invalid or expired pass on tasks/get is HTTP 401 with invalid_token; a task id that is not yours is reported as No such task.; any other failure is retryable.

Retrieving a result

⚠️ Who can retrieve — and why get_result exists. Retrieval needs the Agent Pass, and inside an MCP host the agent usually does not have it: the host stores it and attaches it for you. So the way you retrieve is the get_result tool — the host supplies the credential, you never handle the pass. That is deliberate: a pass put into a tool argument would end up in prompts, transcripts and client logs. (A host that declares the io.modelcontextprotocol/tasks extension can also poll tasks/get; most clients do not declare it yet, which is precisely why get_result exists.) The practical answer is still not to need retrieval — reserve 180–300 seconds so the call finishes inline.

The job_id field of a result is the job id. Use the same Agent Pass (operator/host):

You have the job idget_result with {"job_id":"<job id>"} — inside an MCP host this is the path that works, because the host supplies the credential you do not have. Outside a host (you own the pass): tasks/get with {"taskId":"<job id>"} (Tasks clients), or GET https://api.turingcorp.net/v1/jobs?job_id=<job id> on the API host, not on this MCP endpoint
You did not keep itget_result with no argument lists the job ids this credential created in the last 7 days; then fetch one as above. The list carries the job id, the product and created_at (the Unix second the call was started, not when it finished) — to see what a job was, fetch it by id
Nothing yetAn empty list is not an error, and there is no job_id=0 placeholder: {"object":"list","window_seconds":604800,"data":[]}. Asking for 0 returns 404 No such job.

Retrieval returns the job's status and, once it succeeded, the stored result — the same body the call itself would have returned. A job that is not yours, or older than 7 days, is reported as unavailable.

Authentication

Send an Agent Pass: Authorization: Bearer <pass>. Get one at agent-pass.turingcorp.net — self-service signup with email verification, then top up. A pass is valid for 7 days and can be re-rolled; if a call is refused as an invalid credential, sign in again and re-roll it.

No credentialHTTP 401 + WWW-Authenticate: Bearer realm="turingcorp-mcp"
Expired / invalid passHTTP 401 — invalid_credential in the body, with a re-login URL
Insufficient balanceHTTP 200 tool result with isError: true + a JSON block: {"error":"insufficient_balance","http_status":"402","action_url":"…/topup"}
Over quota / rate limitedentry limiter → HTTP 429 + Retry-After (before the call runs); an upstream business denial → tool result, as above

Entry rate limit: 120 requests / 60 s / client IP. This is flood damping, not a quota — the real per-key quota is enforced separately. The counter is approximate: it is kept per edge location and is eventually consistent, so a brief overshoot is possible.

Pricing

$0.50 per decision — launch offer $0.25 for the first month.

What this is not


Machine-readable views of this same page: /llms.txt · /index.md · /.well-known/mcp/server-card.json. Facts are generated from one source, so they cannot drift between the human page and the agent-facing files.