DevTune MCP

devtune_list_accuracy_decisions

Read-onlyIdempotent

List the Accuracy Reviewed list: the decisions the team made on claims, newest first, with the claim, the kind of finding, the choice, who decided and when, whether it is still active or was undone, and its action: action_role is where the decision stands on its action now: created when the action is built from it, attached when it is added to an action built from another claim, and null when it has none (undoing the decision an action was built from rebuilds it from the next claim, whose role becomes created). For a site conflict, chosen_url is the page the team kept and changed_url the page to change. For a not-on-site claim, choice true means the team marked it true and created an "Add to your site" action, true_no_action that they marked it true without an action (no_action_reason nothing_to_add), and false that they marked it false. Pass next_cursor verbatim as cursor for the next page; it is null on the last page. An empty list means no claim has been reviewed.

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_decisions"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Results per page.
`cursor`	No
`pageSize`	No	The same setting as limit. Send either.

Schema Changelog

Changes observed during successful MCP inspections.

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

A3.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description still adds real context: newest-first ordering, null-cursor meaning the last page, and an empty list meaning no claim has been reviewed. It also explains field-level state semantics such as action_role transitions and no_action_reason values.

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?

Purpose is front-loaded, but the remainder is one dense run-on chain of field definitions with nested clauses. With no output schema the content largely earns its place, yet the packing into a single paragraph hurts scanability and could be broken up.

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

Completeness4/5

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

With no output schema available, the description carries most of the return-value burden and does so thoroughly (claim, finding kind, choice, decider, timestamp, active/undone, action_role, URL pairing, choice enum meanings). Minor gap: the default page size and behavior when limit is omitted is unstated.

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

Parameters4/5

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

Schema coverage is 67%: limit and pageSize are documented, cursor is not. The description compensates for the undocumented parameter by specifying 'Pass next_cursor verbatim as cursor for the next page; it is null on the last page,' which resolves the next_cursor/cursor naming gap and warns against transforming the value.

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

Purpose4/5

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

States a concrete verb and resource ('List the Accuracy Reviewed list: the decisions the team made on claims') and fixes the ordering (newest first) plus the returned fields. It is clearly distinguishable from devtune_list_accuracy_claims and devtune_get_accuracy by being the reviewed-decisions list, though it never names a sibling explicitly.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: an agent can infer 'call this to see reviewed decisions,' and there is pagination guidance ('Pass next_cursor verbatim as cursor for the next page'). But there is no explicit when-to-use vs when-to-use-a-sibling guidance against the many adjacent accuracy tools.

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?