DevTune MCP

devtune_get_agent_picks_history

Read-onlyIdempotent

Read 100 paid tests, newest first, or only the test test_id names, with completion coverage and the project tool’s pick rate (rate, every run that picked it, a stated pick included) and, beside it, stated_picks, installs and install_rate, from rollups, each with Wilson 95% likely ranges. install_rate_hidden_reason is no_installable_tool when none of the test’s tools has a package, config name or import pattern to install (a hosted dashboard): every install_rate is then null, not 0; report the pick rate alone and say why. directional=true marks partial matrices, cell re-runs, re-tests, starter tests and tests with fewer than three runs per cell. Keep those off full-test trends. Action and re-test baseline selectors exclude them. type is how the test was run: full, quick, custom or retest. settled_micros is what it has charged so far (1 credit = 1000000 micros), final once it ends. baseline_eligible marks completed full tests in the current category, by the test-level rule that chooses the tests loss Actions, re-test baselines and full-test trends read; coverage does not change it, and a re-test also needs every planned run of its losing cell completed. It is false without a setup. The previous qualifying full test is the next baseline_eligible test by completed_at. open_loss_actions counts the loss Actions the test created that are still suggested or accepted. action_id is the Action a re-test measures, null otherwise. Follow next_offset until null for earlier tests. Unfinished tests have no rate. Requires Agent Picks and visibility.read.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`offset`	No
`test_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

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

TDQS

B3.2/5.0

Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive, but the description adds real behavioral context: the auth requirement ('Requires Agent Picks and visibility.read'), pagination behavior ('Follow next_offset until null'), and the no_installable_tool fallback where install_rate is null rather than 0. That is genuine value 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.

Conciseness2/5

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

The description is a single long run-on paragraph dense with jargon, Wilson ranges, directional flags, micros, and baseline rules. Much of it explains output fields rather than helping select or invoke the tool, and it is not front-loaded beyond the first clause, making it hard to parse.

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 carries the full return-value burden and does so thoroughly, explaining pick rate, installs, install_rate_hidden_reason, directional, settled_micros, baseline_eligible, open_loss_actions and action_id. Combined with the disclosed auth requirement and pagination, it is complete enough to use, though the density works against clarity.

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 0% for both params, so the description must compensate. It does so partially: 'only the test test_id names' implies test_id selects a single test, and 'Follow next_offset until null' explains the offset's pagination role. It stops short of stating what offset counts or the default page size.

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?

The opening states a clear verb+resource: reading the history of paid tests (newest first, or a single test by test_id). It distinguishes the list vs single-test-id modes. However, it never distinguishes itself from close siblings like devtune_get_agent_picks_test or devtune_list_agent_picks_runs, so an agent still has to infer which to pick.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance or when-not/exclusion, and no routing to alternatives among the many agent-picks siblings. The only 'guidance' is interpretive (keep directional tests off full-test trends), which is about reading results, not about when to call this tool.

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?