DevTune MCP

devtune_get_agent_picks_starter_test

Read-onlyIdempotent

Read the project's Agent Picks starter test as it runs, run by run. test is the project's latest starter test, or null when it has none (then runs and tools are empty). test.status is queued, running, completed, failed or cancelled; planned_runs counts the runs it queued and completed_runs those with status completed. A failed or cancelled test keeps its runs, so report what its completed runs picked and that the rest did not finish. Each run gives the request it was given (intent add = build it, recommend = recommend one, hosted = hosted service, and request the text), its agent and model, its status, and sandbox_attempts, the sandboxes it started. outcome is null until the run is classified, then installed (tool_key names the tool), built_its_own (the agent wrote its own), no_provider (wired in a hosted service without naming a provider), other_tool (other_tools lists the packages and hosts it added that no tool in the test names), none or unclassified. tools lists the tools the test ran with and gives the display name for each tool_key; it is null for a test queued before tests recorded their tools, so do not report which tools such a test compared. stage is sandbox, setup, agent or judging while running, otherwise null, including older runs. During agent, model_calls reports proxy-recorded calls across attempts; null means no meter was recorded. These are live per-run results, not rates: for install rates with their likely ranges, read devtune_get_agent_picks_summary. It shows the latest completed non-directional own test first, otherwise the latest completed directional own test, including a starter. A starter never displaces a full own result or feeds loss Actions, re-test baselines or trends.

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

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 13, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover read-only/idempotent safety, but the description adds substantive behavior: a failed or cancelled test keeps its runs, null tools means a legacy test that recorded no tools, stage is null when not running including older runs, and model_calls null means no meter. It explains what to report from partial failures, which goes well 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.

Conciseness3/5

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

It is one dense block that enumerates field after field (request modes, outcome values, stage values, model_calls), which is essentially an output schema rendered as prose. Front-loading is decent, but the run-on sentences and parenthetical asides make 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.

Completeness5/5

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

There is no output schema, so the description carries the full burden and meets it: it defines test/status lifecycle, planned vs completed runs, per-run request, agent, model, sandbox_attempts, outcome variants including other_tool, the tools list and its null case, stage values, and model_calls. An agent can interpret every field without opening anything else.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description instead spends its words on return semantics, which is appropriate for a parameterless read.

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 specific verb and resource: 'Read the project's Agent Picks starter test as it runs, run by run', and clarifies that 'test' is the latest starter test or null. It differentiates from devtune_get_agent_picks_summary at the end, but never explains how it differs from close siblings like devtune_get_agent_picks_test, devtune_get_agent_picks_run, or devtune_list_agent_picks_runs.

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?

Explicitly routes the agent elsewhere for a different question: 'for install rates with their likely ranges, read devtune_get_agent_picks_summary'. Also gives a conditional reporting instruction ('do not report which tools such a test compared'). It lacks a clear statement of when this tool is preferred over devtune_get_agent_picks_test or devtune_list_agent_picks_runs, which share the same domain.

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?