A decision model for the calls that don't have a right answer. The better option, with a reason.
Scored across 2 tools
The two tools have completely distinct purposes: 'decide' initiates a decision-making process, while 'get_result' retrieves results from previous calls. There is no overlap or ambiguity between them.
Both names are verb-based, but 'decide' is a single verb while 'get_result' follows the verb_noun pattern. This is a minor inconsistency, but the names are clear and predictable given the server's narrow scope.
With only two tools, the count is minimal but appropriate for the server's focused purpose of decision-making with result retrieval. The scope is narrow, so two tools fully cover the intended functionality.
The tool surface covers the core workflow: making a decision and retrieving its result (including listing available job IDs). No obvious gaps exist for the stated purpose, though a cancel or status-check tool could be imagined but is not essential.
Use this when you must choose between two concrete options and both are defensible - two plans, two drafts, two diagnoses, two vendors - and you have no objective way to pick. Not for: more than two options; anything an objective rule settles (a spec, a test, a price, a document); factual lookup; paths that must answer in seconds; high-stakes irreversible calls without review. Fill it in: state task neutrally, without leaning toward either side; give one concrete plan per option - never bundle alternatives into a single one ("go indoors or postpone"); keep the two sides comparable in length. Returns the decision inline: betterOption ("option_A" or "option_B"), confidence (e.g. "76.7%"), reason and job_id, all in the same tool result. There is nothing to poll and nothing to fetch afterwards. Reserve 180-300 seconds: this is a long call, and the timeout is a client/host setting, not a parameter you pass. If the call is cut off, do NOT call again - a retry is a new paid call. Retrieve it instead with the get_result tool (same job_id): read-only, free, and no credential of your own needed; with no job_id it lists the ids for your credential. A host that declares the io.modelcontextprotocol/tasks extension can use tasks/get instead. The confidence is the point: it is calibrated, not decorative. On both published benchmarks accuracy rises with it - JudgeBench 99.6% in the 90%+ band down to 67.7% below 70%; the harder ContextualJudgeBench 83.3% down to 55.4% - so route on it: act on a high value, review or escalate a low one, instead of trusting a bare pick. Tables, sample sizes and method: https://api.turingcorp.net Judged by an independent panel, not by a model grading its own output. Read it as a reference, not an instruction, a result, or a prediction; set your own threshold, and apply your own review policy for high-stakes or irreversible decisions. Auth: Agent Pass as Authorization: Bearer <pass> (issued at https://agent-pass.turingcorp.net, valid 7 days; each decision is a paid call). On invalid_credential, sign in there and re-roll. Errors: a credential problem is rejected before the call - HTTP 401 with WWW-Authenticate; a business failure (e.g. insufficient balance) comes back as a tool result with isError true plus a second JSON block {error, http_status, action_url, message}, where http_status is the upstream status (the tool call itself is HTTP 200).
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | The decision to make, stated neutrally and without a preferred answer. | |
| optionA | Yes | First candidate and the case for it. | |
| optionB | Yes | Second candidate and the case for it. |
| Name | Required | Description |
|---|---|---|
| job_id | No | Identifier of this decision, also usable to retrieve the stored result for 7 days with the get_result tool. Keep it: if the call times out, retrieve the result with get_result instead of calling again, which would be a new paid call. |
| reason | Yes | Why the chosen option was preferred. |
| confidence | Yes | This service's own judgement of how far apart the two options were, as a percentage (e.g. "76.7%"). A reference for your own decision-making - not an instruction, not a result. Observed accuracy by range is published at https://api.turingcorp.net |
| betterOption | Yes | Which option was preferred, using the same values as the REST API. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that this is a paid, long-running call, that retries are new paid calls, that results return inline with no polling, and that errors come back in a specific format. It also explains confidence calibration and independent judging. The readOnlyHint=true annotation is not contradicted; the tool does not mutate state even though it is paid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but every section earns its place: use cases, exclusions, input formatting, return behavior, timing, retry policy, authentication, and error handling. It is front-loaded with the primary use case and structured logically, though slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers everything an agent needs to call it correctly: when to use it, how to format inputs, what to expect in the result, how long it takes, what to do on interruption, how to authenticate, how to interpret errors, and how to use the confidence score. The output schema covers return values, so the description need not restate them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all three parameters with 100% coverage. The description adds meaningful semantic guidance beyond the schema: state the task neutrally, give one concrete plan per option, avoid bundling alternatives, and keep both sides comparable in length.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with an explicit use case: choosing between two concrete, defensible options. It names the resource (two options) and the verb (decide/pick), and explicitly lists exclusions (more than two options, objective rules, factual lookup, time-sensitive paths), clearly distinguishing it from siblings like get_result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use and when-not-to-use guidance, including concrete examples and exclusions. It also names alternatives (get_result, tasks/get) and gives specific operational constraints like the 180-300 second duration and the no-retry rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this to retrieve the result of an earlier TuringCorp tool call by its job_id - for example a call that was cut off by a client timeout, or one whose id you were given. Retrieval is read-only and free: it starts no new work and costs nothing, so it is always safe to retry. With job_id: that call's status, and once it has finished the same payload the call would have returned inline. Without job_id: the ids available to your credential (7 days). If a call was cut off, retrieve it here instead of calling again - a retry is a new paid call. A job that is not yours and a job that does not exist are answered identically, on purpose. If your client declares the io.modelcontextprotocol/tasks extension, tasks/get reaches the same job.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | No | Identifier returned by an earlier TuringCorp call (also usable at GET /v1/jobs?job_id=<id>). Omit it to list the ids available to your credential. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false. The description enriches this by stating that retrieval 'starts no new work and costs nothing, so it is always safe to retry', explains that a job not yours and a nonexistent job are answered identically (a deliberate privacy feature), and notes the 7-day availability window. All this adds significant behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: it leads with the core purpose, then flows through the two modes, usage guidance, privacy behavior, and an extension note. Every sentence conveys a distinct, valuable piece of information without redundancy. The length is justified given the tool's dual-mode nature and the nuances it covers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with optional input and no output schema, the description thoroughly covers what the agent needs to know: what is returned with and without job_id, the behavior for missing/unauthorized jobs, the 7-day retention, the safety of retries, and the alternative via tasks/get. Nothing material is left unexplained, making it complete for correct invocation and expectation setting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a complete description of the `job_id` parameter, including its purpose and the behavior of omitting it. The tool description essentially repeats the schema's information without adding new semantic depth beyond saying the same thing. Since schema coverage is 100%, the baseline of 3 is appropriate; the description does not introduce any additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states what the tool does: retrieve the result of an earlier TuringCorp call by job_id. It explicitly covers both invocation modes (with and without job_id) and clearly distinguishes this retrieval action from other potential operations (e.g., 'decide' sibling). The verb 'retrieve' and resource 'result' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'If a call was cut off, retrieve it here instead of calling again - a retry is a new paid call.' It also clarifies the no-job_id case for listing available ids and mentions an alternative (tasks/get) for the same job. This gives clear context for when to select this tool over a fresh call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
decide1 field changedOutput schema / properties / job_id / descriptionPrevious value: -"Identifier of this decision, also usable to retrieve the stored result for 7 days (GET /v1/jobs?job_id=<id> with the same credential). Keep it: if the call times out, retrieve the result instead of calling again, which would be a new paid call."New value: +"Identifier of this decision, also usable to retrieve the stored result for 7 days with the get_result tool. Keep it: if the call times out, retrieve the result with get_result instead of calling again, which would be a new paid call."get_resultdecide9 fields changedInput schema / properties / optionAAdded value: +{
+ "description": "First candidate and the case for it.",
+ "type": "string"
+}Input schema / properties / optionBAdded value: +{
+ "description": "Second candidate and the case for it.",
+ "type": "string"
+}Input schema / properties / option_aRemoved value: -{
- "description": "First candidate and the case for it.",
- "type": "string"
-}Input schema / properties / option_bRemoved value: -{
- "description": "Second candidate and the case for it.",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "task",
- "option_a",
- "option_b"
-]New value: +[
+ "task",
+ "optionA",
+ "optionB"
+]Output schema / properties / betterOptionAdded value: +{
+ "description": "Which option was preferred, using the same values as the REST API.",
+ "enum": [
+ "option_A",
+ "option_B"
+ ],
+ "type": "string"
+}Output schema / properties / better_optionRemoved value: -{
- "description": "Which option was preferred.",
- "enum": [
- "A",
- "B"
- ],
- "type": "string"
-}Output schema / properties / confidence / descriptionPrevious value: -"This service's own judgement of how far apart the two options were, as a percentage (e.g. \"83.3%\"). A reference for your own decision-making - not an instruction, not a result. Observed accuracy by range is published at https://api.turingcorp.net"New value: +"This service's own judgement of how far apart the two options were, as a percentage (e.g. \"76.7%\"). A reference for your own decision-making - not an instruction, not a result. Observed accuracy by range is published at https://api.turingcorp.net"Output schema / requiredPrevious value: -[
- "better_option",
- "confidence",
- "reason"
-]New value: +[
+ "betterOption",
+ "confidence",
+ "reason"
+]decide1 field changedOutput schema / properties / job_idAdded value: +{
+ "description": "Identifier of this decision, also usable to retrieve the stored result for 7 days (GET /v1/jobs?job_id=<id> with the same credential). Keep it: if the call times out, retrieve the result instead of calling again, which would be a new paid call.",
+ "type": "string"
+}decideThe deciding place: argue the call, decide, keep the reasons, get the work back as finished files.
Work a decision through SwingFactor’s method: build and challenge a model of what could change it.
Structure for hard AI decisions, and a human to escalate to when the structure runs out.
The decision layer for AI agents: act, escalate or refuse, and every decision comes back signed.
Add one secure layer between your agents and this server.
