Skip to main content
Glama

devtune_get_agent_picks_summary

Read-onlyIdempotent

Read Agent Picks: which tool coding agents (Claude Code, Codex, OpenCode, Pi) installed when asked to add one in the project's category, from install-verified test runs. test is the project's latest completed non-directional own test. If none exists, show its latest completed directional own test, including a starter, Quick, Custom subset or cell re-run, with test.directional=true. Only when neither exists use the category's public test: the copy cloned into the project (kind cloned), else the latest public test. Directional tests never displace a non-directional own result and never feed loss Actions, re-test baselines or full-test trends. test.scope is public for either, so say when the numbers are the public test. Re-tests are never shown. runs counts completed runs, and every rate uses completed runs only. coverage says how many of the planned runs (matching the filters) completed, failed (ran without completing) or were not run (the test reached its budget before they started): when completed is below planned, say so with the numbers, e.g. 418 of 432 runs completed. incomplete_cells lists each environment, question, agent and model cell where fewer runs completed than were planned; a cell with completed 0 was not measured, so report it as not measured, never as a 0% rate. Each tools item's rate is its pick rate: picks (every run that picked it, including a stated pick, where the agent named it as its choice without writing it into the code) over runs summed across the test's cells, with rate_low and rate_high, the Wilson 95% likely range: report the range with the rate, and do not call two tools different when their ranges overlap. The pick rate is the headline. Beside it, stated_picks counts the stated picks, installs = picks - stated_picks the runs that wrote the tool into the code, and install_rate with install_rate_low and install_rate_high its install rate and range; never report the install rate instead of the pick rate. built_its_own and no_provider name no tool, so their installs and install rates are null. 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. outcome says what each item counts: installed (tool_key names the tool), built_its_own (the agent wrote its own instead of installing a tool) or no_provider (the agent wired in a hosted service, such as a database or mail server URL the user fills in, without naming a provider); the last two have tool_key null. Report built_its_own and no_provider separately, never as one figure, and never count either as a tool's loss to the other. is_own marks the project's own tool and is_competitor its competitors; both always list, at zero picks when no agent picked them. frameworks gives each framework's runs and top picks (framework null is an empty project); agents gives each agent and model's rates for the same tools, in the same order. environments gives each test environment (slug, name, framework) with its runs and picked tools, its rates per agent (models summed), and cells: one per question the test asked (intent add = build it, recommend = recommend one, hosted = hosted service, asked only where the category has a hosted option) and agent, each with its coverage; each group lists the tools picked there plus the project's own tool. A cell or environment where no run completed has runs 0 and no tools. Pass agent and/or intent to narrow every number to those runs; filters echoes what was applied. own_tool_key, competitor_tool_keys, enabled_environment_ids, enabled_frameworks, enabled_agents and enabled_agent_models are the project's setup; an empty list means it is not chosen yet. status no_settings means no category or job is chosen yet and no_test that no test has finished, so there are no rates to report. job is set when the project tests its own job instead of a public category: job.job is the work agents are asked to do, job.requests the requests its tests give them, job.tools the tools it compares (is_own marks the project's) with the packages, config names, import patterns and domains that name each one in a run, and job.building_blocks what decides built_its_own and no_provider; an agent drafted them and the customer confirmed them. When a test is shown, job.job, job.requests, job.tools and job.building_blocks are as that test recorded them when it was queued, so they describe the numbers even after the job is edited. A job has no public test, so its numbers are always the project's own, and category is then the job's own (slug job-, name the job line). A job test's run that added a package or hosted service no confirmed tool names counts in every rate's denominator but in no tool's picks. Pass test_id (from devtune_get_agent_picks_history) to read one completed test in the project's current category instead of the shown one; a re-test, unfinished test or another project's test is not found. open_loss_actions counts the project's loss Actions still suggested or accepted, whatever the filters.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agentNoOnly runs by this coding agent.
intentNoOnly runs of this question: add (build it), recommend (recommend one) or hosted (hosted service).
test_idNoRead this completed test, from the history, instead of the shown one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / test_id
      Added value: +{
      +  "description": "Read this completed test, from the history, instead of the shown one.",
      +  "format": "uuid",
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / agent / enum
      Previous value: -[
      -  "claude_code",
      -  "codex",
      -  "cursor"
      -]New value: +[
      +  "claude_code",
      +  "codex",
      +  "cursor",
      +  "pi",
      +  "opencode"
      +]
  3. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint, so the safety profile is covered. The description still adds real behavioral context beyond that: status no_settings/no_test states, the rule that re-tests are never shown, and that 'a re-test, unfinished test or another project's test is not found'. That error/edge-case disclosure is genuine value on top of 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?

Roughly 600 words delivered as a single unstructured paragraph. Although no output schema exists so much return-field explanation is unavoidable, the content is not grouped or front-loaded, and dense sentences repeat concepts repeatedly, making the critical usage rules hard to extract.

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 this description carries the full burden of describing the response and it does so exhaustively: rate/rate_low/high (Wilson), stated_picks, installs, install_rate and its hidden reason, built_its_own, no_provider, outcome, is_own, frameworks, agents, environments, cells, coverage, incomplete_cells, status, job, and open_loss_actions are all explained.

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 100%, so the baseline is 3. The description goes further by clarifying filter effect ('Pass agent and/or intent to narrow every number to those runs; filters echoes what was applied') and the intended source and scope of test_id, adding semantics the schema alone does not convey.

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 sentence gives a specific verb, resource and scope: 'Read Agent Picks: which tool coding agents ... installed when asked to add one in the project's category, from install-verified test runs.' An agent immediately knows the domain. However, it never contrasts itself with the very similar siblings devtune_get_agent_picks_test and devtune_get_agent_picks_cells, so differentiation relies on inference.

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?

The description routes to devtune_get_agent_picks_history for the test_id parameter and lays out the data-selection precedence (own non-directional > own directional > cloned public > latest public). But it gives no explicit when-to-use/when-not guidance relative to the other agent-picks siblings, leaving the choice among them mostly implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources