DevTune MCP

devtune_list_accuracy_claims

Read-onlyIdempotent

List one Accuracy claim list over the same window and filters as devtune_get_accuracy, most answers first: contradict (AI answers disagree with the site), site_conflict (the site disagrees with itself), not_on_site (the site does not say) or dismissed (contradictions and site conflicts the team dismissed). For contradictions grouped by the site sentence they conflict with, use devtune_list_accuracy_contradictions; a contradict or dismissed item's sentence_key names its row there. Each item is one claim group with the latest answer excerpt that had the outcome, the site page and any other page involved, and the team's active decision; answered is true when the team said whether a not-on-site claim is true or false. A locked page is one the customer has marked off-limits, so never suggest changing it. dismissed_count and answered_count count the window's dismissed and answered claims; dismissed_contradiction_count and dismissed_site_conflict_count split dismissed_count by kind. Pass next_cursor verbatim as cursor for the next page and keep the other arguments unchanged; it is null on the last page. An empty list means no claim had that outcome in the window.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "outcome": "<outcome>"
    },
    "name": "devtune_list_accuracy_claims"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Results per page.
`cursor`	No
`intent`	No
`window`	No
`outcome`	Yes
`pageSize`	No	The same setting as limit. Send either.
`platform`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedNov 10, 2026

removedInput schema / properties / pageSize / $ref
```
Removed value: -"#/properties/limit"
```
addedInput schema / properties / pageSize / maximum
```
Added value: +100
```
addedInput schema / properties / pageSize / minimum
```
Added value: +1
```
addedInput schema / properties / pageSize / type
```
Added value: +"integer"
```

addedInput schema / properties / window / anyOf

Added value: +[
+  {
+    "const": "30",
+    "type": "string"
+  },
+  {
+    "const": "90",
+    "type": "string"
+  },
+  {
+    "const": 30,
+    "type": "number"
+  },
+  {
+    "const": 90,
+    "type": "number"
+  }
+]

removedInput schema / properties / window / enum

Removed value: -[
-  "30",
-  "90",
-  30,
-  90
-]

removedInput schema / properties / window / type

Removed value: -[
-  "string",
-  "number"
-]

Changed3 schema fields changedOct 25, 2026
- removedInput schema / properties / limit / default
```
Removed value: -25
```
- addedInput schema / properties / limit / description
```
Added value: +"Results per page."
```
- addedInput schema / properties / pageSize
```
Added value: +{
+  "$ref": "#/properties/limit",
+  "description": "The same setting as limit. Send either."
+}
```
AddedOct 13, 2026

TDQS

A4.2/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description goes well beyond them: it describes the item shape (claim group, latest matching answer excerpt, site page and other page, active decision, answered flag), pagination contract (next_cursor verbatim as cursor, keep other args unchanged, null on last page), the meaning of an empty list, and the locked-page rule. This is substantive behavior an agent could not infer from 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the sibling routing are front-loaded in the first two sentences, and nearly every sentence carries real information. However, it is a single dense paragraph mixing usage, return shape, glossary terms, count-field semantics, and pagination, which makes it harder to scan than it needs to be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description fills the gap left by the absent output schema (item shape, counts, cursor semantics) and explains the enum, which is a lot for a 7-parameter tool. But two parameters (intent, platform) are undocumented in both schema and description, so an agent still has to guess what they do.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 29%, so the description must compensate. It does well for outcome (defines each enum value's meaning) and cursor (pass next_cursor verbatim, hold other args constant), and implies window via devtune_get_accuracy, but intent and platform are never explained and limit/pageSize redundancy is left to the schema. Coverage of the parameter surface is therefore partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List one Accuracy claim list') plus ordering ('most answers first') and enumerates the four outcome buckets with parenthetical definitions (contradict, site_conflict, not_on_site, dismissed). It also explicitly contrasts itself with devtune_list_accuracy_contradictions and ties its window/filters to devtune_get_accuracy, so an agent can distinguish it from the nearest siblings without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the alternative explicitly: 'For contradictions grouped by the site sentence they conflict with, use devtune_list_accuracy_contradictions', and notes it shares the window/filters of devtune_get_accuracy. It gives a clear routing rule but no explicit when-not-to-use case or guidance on how to pick among the four outcomes for a given question.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All DevTune MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?