Skip to main content
Glama

devtune_get_agent_picks_cells

Read-onlyIdempotent

Read per-model cells for 1 to 8 distinct project-owned tests from test history. Returns coverage, the shared loss verdict and own-led status with each cell’s decision_method, the rule that decided them (v2: a clear difference at 90%; v1, also when missing: raw counts, a top rival or built its own with no own majority is a loss; no_provider never wins a loss and unmatched-code guesses are left out), fallback guesses and none/unclassified/other-tool run counts, plus per-tool picks, pick rates and Wilson ranges, with stated_picks, installs and the install rate and range beside each pick rate (null for built_its_own and no_provider). Each test’s 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. Each test includes status. Non-completed tests retain coverage only: tools are unmeasured and measurement counts, rates, ranges and verdicts are null. Each test includes judging_key and comparison_key for its classifier version, stated-pick policy, category, resolved own tool, sorted distinct competitor keys and recorded requests, request ending, job line and job signals. With no recorded request metadata, the key still covers category_id and resolved tool roles. Use equal complete keys for pairwise deltas. Retain each test’s measured trend points and break lines at judging changes. projects_added and projects_removed list the test apps (id, slug, name, framework) the test added and removed against the full test before it: show them as an event on the trend without breaking the line; cells still compare per test app. requests_changed lists each request (intent, before, after) the test reworded, left out (after null) or asked again (before null) against that test, and ending_changed the request ending before and after (null when unchanged): show each as an event on the trend without breaking the line; cells across either have different comparison keys. Each test includes outcome_counts_available; its outcome counts are null when completed run detail is unavailable. Each test and cell also includes runs_without_trail, the completed runs that recorded no trail event (null where trail coverage cannot be determined, as for a cloned public test; never read null as 0). Each cell includes discovery: completed_runs, reached_runs (the trail searched for, fetched or installed the own tool: its docs, package or registry entry), unavailable_runs (no trail to decide from, left out of the rate), and rate with rate_low and rate_high, the Wilson 90% range. Report it beside the pick rate: a loss with a low discovery rate means agents never found the tool; a high one means they found it and still chose another. discovery is null when the test has no discovery measurement (finished before it was recorded, no own tool, or not completed): say it is unavailable, never 0. Model-side web search and fetch bypass the sandbox, so not reached means not seen in the sandbox. Unmeasured tools have measured false and null rates. Completed counts and displayed rates include fallback guesses; loss verdicts exclude them. Each cell tool also includes found, the cell’s Found in with the same fields as discovery, for every tool the test recorded: report it with its counts beside the pick rate, never as a pick. found is null for built_its_own, no_provider, a tool the test did not record and a test with no Found in measurement: report Unmeasured, never 0. Each test includes integration (null until it completes, and null when not computed for every install; an empty tools list only when nothing was installed): per installed tool, and per agent when the test ran more than one, how often install runs (stated picks excluded) had an observed package version, matched the registry latest pinned at queue time, used a deprecated version, requested vendor docs and ran the package’s commands. Each rate has numerator, denominator and unknown; report all three, never treat unknown as no, and report no_snapshot as no pinned registry data rather than a version verdict. Malformed and unavailable observations are counted, not included. Requires Agent Picks and visibility.read.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "test_ids": "<test_ids>"
    },
    "name": "devtune_get_agent_picks_cells"
  }
}

Input Schema

NameRequiredDescriptionDefault
test_idsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior5/5

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

Annotations already declare a safe read (readOnlyHint, idempotentHint, non-destructive, closed-world), and the description adds substantial context beyond them: required scope (Agent Picks plus visibility.read), rich null semantics (null is never 0 for install rate, discovery, found, runs_without_trail), and why nulls occur (no_installable_tool, pre-measurement tests, cloned public tests). It also discloses a real caveat: model-side web search bypasses the sandbox, so 'not reached' means 'not seen in the sandbox'.

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 undifferentiated wall of output-field documentation roughly ten times the length of what the tool-selection decision requires, with no headings or bullets. Critical invocation information (the permission requirement, the cell-vs-test distinction) is buried at the very end and mid-paragraph, and much of the text is per-field reporting advice that belongs in an output schema rather than a tool description.

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 takes on the full burden of explaining returns and discharges it exhaustively: cell fields, verdict rules, discovery and found measurements, integration counters, and null-vs-zero semantics. Missing only edge behavior (invalid or non-owned test_ids, batching or error cases), which for a read-only tool is a minor gap.

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 0% for the single test_ids parameter, so the description must compensate, and it does: it states the inputs are 'distinct project-owned tests' and are drawn 'from test history', adding ownership and distinctness constraints beyond the bare uuid/minItems/maxItems in the schema. It does not say what happens for unknown or non-owned ids, which keeps it below 5.

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 and resource: 'Read per-model cells for 1 to 8 distinct project-owned tests from test history.' The 'distinct project-owned' qualifier and the 1-8 bound distinguish it from a single-test reader like devtune_get_agent_picks_test. However, no sibling is named, so an agent must infer the boundary with get_agent_picks_test, get_agent_picks_summary and get_agent_picks_history on its own.

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?

'Requires Agent Picks and visibility.read' at the very end gives a prerequisite, and 'Use equal complete keys for pairwise deltas' is a real usage rule. But there is no explicit when-to-use-this-vs-sibling guidance despite many adjacent Agent Picks readers in the sibling list, so the agent must guess whether to call this, get_agent_picks_test, or get_agent_picks_summary.

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