Skip to main content
Glama

devtune_get_agent_picks_run

Read-onlyIdempotent

Inspect one project-owned Agent Picks run with test_id and run_id from the run list. Returns status, stage and live model activity (cell_agreed=true: cancelled before it started because its cell’s first 4 runs agreed, not needed rather than an error, with has_error false), typed context, classified pick and an ordered page of retained observations by seq then id. Follow evidence.pagination.next_cursor until has_more is false; request and job are null with request_withheld and job_withheld distinguishing withheld snapshots from absent ones, null pick means no recorded classification, optional pick.statement_index locates the deciding sentence without exposing its quote or consistency fingerprint, pick.classifier_accuracy is how often the classifier version that judged the run was right on a labelled test set, not on production runs: precision per outcome kind, the unclassified rate and stated-pick recall, each as rate with count of of; it is null for a version with no labelled figures or a job test judged by Jev, and a precision kind is null when never reported on the set, pick.category_precision is how often that version was right in the run’s category on a hand-labelled sample of DevTune’s own published test runs, not on your runs: precision per outcome kind (installed, built_its_own, no_provider, none) as rate with count of of, where rate is null when of is below minimum_reported, too few to state a rate; it is null for a category or version with no labelled sample, other_tools is empty with other_tools_withheld marking withheld runtime names, pick.overlapping_tools names the test’s tools an ambiguous run used (tool_key, display_name; empty otherwise) and pick.custom_job says whether the test is the project’s own job and still its setup, where saying which tool runs inside the other (signals.yieldsTo, saved with devtune_save_agent_picks_job) decides such runs in later tests, and not_retained means no event rows are retained, including before a running run records them. Commands, error text, raw provider prompts and Storage artifacts are withheld; URLs show only their HTTP origin. Arbitrary request/job/search/file text is withheld; text_withheld marks search and file details. Packages must match the configured tool catalog and packages_withheld marks omitted names. integration.packages[].registry reports the queue-time registry snapshot for each observed package: latest_version, comparison, version-specific npm deprecated, comparison_reason, deprecation_reason, source and captured_at. Scheduled project tests and DevTune board tests capture registry metadata; new on-demand tests, free starter tests and Action re-tests do not capture it and registry comparison/deprecation remain unknown with no_snapshot. Previously retained snapshots are preserved. A comparison of differs does not mean outdated. Missing snapshots, wildcard names, unavailable or unsupported registries, malformed responses, redirects, timeouts, not_found lookups, unknown gem lookup spelling (lookup_identity_unknown), capture limits, missing observed versions and versions absent from captured metadata remain explicit unknowns; non-npm deprecation data is unsupported, and yanked does not mean deprecated. Installer output and archive downloads remain distinct evidence. Observations do not prove causes or a working integration. Requires Agent Picks and visibility.read. Cannot change or start a run.

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_id": "<test_id>",
      "run_id": "<run_id>"
    },
    "name": "devtune_get_agent_picks_run"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoResults per page.
cursorNo
run_idYes
test_idYes
pageSizeNoThe same setting as limit. Send either.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • removedInput schema / properties / limit / default
      Removed value: -50
    • addedInput schema / properties / limit / description
      Added value: +"Results per page."
    • addedInput schema / properties / pageSize
      Added value: +{
      +  "$ref": "#/properties/limit",
      +  "description": "The same setting as limit. Send either."
      +}
  2. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context the annotations cannot: which fields are withheld (commands, error text, raw prompts, Storage artifacts), null-vs-absent semantics, retention behavior before events record, and required permissions. The main weakness is that these facts are scattered through dense parentheticals rather than surfaced as operating rules.

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 purpose is front-loaded, but the body is an unstructured ~600-word wall of nested parentheses covering registry snapshots, classifier accuracy, and deprecation caveats. Much of that is output documentation that lacks an output schema to live in, yet the density makes it hard for an agent to extract the operative instructions.

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, the description compensates exhaustively: return shape, pagination loop termination, withheld-vs-absent nulls, unknown states, and permission requirements are all covered, and it clearly marks that observations are not causal proof.

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 coverage is only 40%, so the description should carry more weight than it does; it mentions following 'evidence.pagination.next_cursor until has_more is false', which implies how the cursor parameter is used, but never explains the limit/cursor inputs or that pageSize is an alias for limit.

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 first sentence gives a specific verb and resource ('Inspect one project-owned Agent Picks run') plus the identifiers needed, and the phrase 'from the run list' implicitly points at devtune_list_agent_picks_runs as the source of test_id/run_id, separating it from the list and trace siblings.

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 entry condition (ids come from the run list), prerequisites ('Requires Agent Picks and visibility.read') and an explicit exclusion ('Cannot change or start a run'), but never names the alternative tool to use for adjacent needs such as execution trace or history.

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