DevTune MCP

devtune_list_accuracy_contradictions

Read-onlyIdempotent

List Accuracy's contradictions once per site sentence they conflict with, over the same window and filters as devtune_get_accuracy, most answers first: what the tab's contradictions table shows. Each row is one sentence on the brand's own site (site_page, with whether it is locked now) that AI answers contradict in wording_count different wordings (claim groups, listed in group_ids), with answers (an answer stating two wordings counts under each), platforms, last seen, dismissed_wording_count for wordings the team dismissed, an example wording with its latest contradicting answer, and the open action correcting it. other_page is a set-aside page, such as a dated blog post, that says what the AI said. A row whose wordings were all dismissed is not listed. A locked page is one the customer has marked off-limits, so never suggest changing it. Pass next_cursor verbatim as cursor for the next page and keep the other arguments unchanged; it is null on the last page. A contradiction whose check quoted no sentence from the site has no row; devtune_get_accuracy counts those in unquoted_contradictions. An empty list therefore means no contradiction names a site sentence in the window, not that nothing was contradicted: check unquoted_contradictions there before saying so.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "devtune_list_accuracy_contradictions"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Results per page.
`cursor`	No
`intent`	No
`window`	No
`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.3/5.0

Behavior5/5

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

Annotations already declare a safe, idempotent read, yet the description adds substantial context beyond them: rows with all wordings dismissed are omitted, locked pages must never be suggested for change, other_page is a set-aside page, and an empty list has a very specific non-obvious meaning. It also explains pagination behavior (cursor null on last page, keep other args unchanged).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The opening sentence is a dense run-on that packs purpose, granularity, ordering, and tab mapping into one clause chain, and several later sentences are similarly overloaded. Everything earns its place given there is no output schema, but the information could be restructured into scannable sentences without loss.

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

Completeness5/5

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

With no output schema, the description correctly assumes the burden of describing return structure and does so field by field: site_page and lock state, wording_count, group_ids, answers (counted under each), platforms, last seen, dismissed_wording_count, example wording plus latest contradicting answer, and the open action. Nothing structural is left for the agent to guess.

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 coverage is only 33%, so the description must carry weight; it does well on cursor (pass next_cursor verbatim, null on last page) and gestures at "the same window and filters as devtune_get_accuracy" for window/platform. But limit, pageSize, intent, and platform are never explained in prose, leaving half the parameters relying on thin or absent schema text.

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 Accuracy's contradictions") plus a precise granularity ("once per site sentence they conflict with") and ordering ("most answers first"). It explicitly ties the window/filters to devtune_get_accuracy and to "the tab's contradictions table," so an agent can distinguish it from the singular devtune_get_accuracy_contradiction without opening any 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?

Gives a concrete routing rule: when the list is empty, check unquoted_contradictions on devtune_get_accuracy before concluding nothing was contradicted. It also gives paging instructions for cursor reuse. It does not point to devtune_get_accuracy_contradiction for per-row drill-down, so it falls short of full when/when-not coverage.

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?