DevTune MCP

devtune_get_agent_picks_test

Read-onlyIdempotent

Read the project's latest paid Agent Picks test, or the paid test or re-test test_id names, with its status, estimate in credits, reserved_micros, settled_micros, refunded_micros, released_at and complete per-run table from its rollup. Pass test_id (from devtune_quote_agent_picks_test or devtune_start_agent_picks_test) to follow one test through cancellation and settlement after another starts; one that is not the project's paid test is not found. One credit is 1000000 micros. Failed runs and runs cancelled before they start are not charged; a run cancelled after it starts pays its recorded spend. cell_agreed=true marks a run cancelled before it started because its cell's first 4 runs picked the same thing: not needed, not an error or missing coverage, and not charged. Unused credits return when the test ends. Unknown spend on a completed run or a run cancelled after it starts charges the greater of recorded cost and the run's reservation share, capped by the remaining reservation. directional=true marks a partial matrix, a cell re-run, or fewer than three runs per cell, excluded from loss Actions, re-test baselines and full-test trends. Install rates are in devtune_get_agent_picks_summary for the latest completed non-directional own test, else the latest completed directional own test, else public results. Start tests with devtune_start_agent_picks_test.

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

Input Schema

Name	Required	Description	Default
`setup`	No	The Agent Picks setup to use: its id or its category slug. Optional while the project has one setup. With several, omitting it is refused as agent_picks_setup_required, and a setup the project does not have as agent_picks_setup_not_found; both list the project setups in details.setups (id, category_slug, category_name). The response echoes the setup used as setup {id, category_slug}.
`test_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026

addedInput schema / properties / setup

Added value: +{
+  "description": "The Agent Picks setup to use: its id or its category slug. Optional while the project has one setup. With several, omitting it is refused as agent_picks_setup_required, and a setup the project does not have as agent_picks_setup_not_found; both list the project setups in details.setups (id, category_slug, category_name). The response echoes the setup used as setup {id, category_slug}.",
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}

Changed1 schema field changedOct 25, 2026
- addedInput schema / properties / test_id
```
Added value: +{
+  "format": "uuid",
+  "type": "string"
+}
```
AddedOct 14, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Far beyond the annotations, the description discloses billing semantics (1 credit = 1000000 micros, failed runs and pre-start cancellations not charged, post-start cancellation pays recorded spend, unknown spend charged at max(recorded cost, reservation share) capped by remaining reservation), credit return on test end, cell_agreed=true meaning, directional=true exclusion from loss Actions/baselines/trends, and not-found behavior for a non-paid test_id.

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 well front-loaded, but the rest is one dense run-on paragraph mixing billing edge cases, cell_agreed, directional, and cross-tool routing with no headings or bullets. Nearly every sentence carries useful information, yet the structure makes it hard to scan.

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, the description does list the returned fields and per-run table, plus the billing edge cases an agent would need to interpret them. The shape of the per-run table is only described as 'complete ... from its rollup', which is thin for a tool whose output the agent must reason about.

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 50%: the setup parameter is heavily documented in the schema (errors, details.setups, echo) while test_id has none. The description compensates by explaining where test_id comes from (quote or start tools) and that a test_id that is not the project's paid test returns not found, which the schema does not say.

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?

The description opens with a specific verb and resource: read the project's latest paid Agent Picks test, or the paid/re-test test_id names, and it enumerates the returned fields (status, estimate, reserved_micros, settled_micros, refunded_micros, released_at, per-run rollup table). It is clearly differentiated from devtune_get_agent_picks_summary (install rates) and from the start/quote tools.

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?

It states the concrete when-to-use case: pass test_id to follow a test through cancellation and settlement after another starts, and redirects to devtune_start_agent_picks_test for starting tests and to devtune_get_agent_picks_summary for install rates. It doesn't state a hard exclusion, but the alternatives are explicit enough that an agent can route correctly.

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?