Skip to main content
Glama

devtune_get_agent_picks_history

Read-onlyIdempotent

Read a page of the setup’s paid tests, newest first (limit or pageSize, default and maximum 100), or only the test test_id names, whichever setup it belongs to, with completion coverage and the project tool’s pick rate (rate, every run that picked it, a stated pick included, each scenario’s rate averaged over the test’s scenarios, which scenarios counts) and, beside it, stated_picks, installs and install_rate, from rollups, each with Wilson 90% likely ranges over the scenarios. picks and installs are run counts, not the rate’s fraction. rate_directional is true when the rate rests on fewer than 10 scenarios (one scenario: fewer than 10 runs): say the rate is directional. It is separate from directional, which marks how the test was run. 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. trend_eligible marks completed full tests in the current category. judging_key identifies classifier version plus stated-pick policy (absent, empty or unreadable policy means rules). Null means judging is unavailable. baseline_eligible additionally requires the latest full test’s known judging key. judging_changed marks a boundary from the preceding full test before pagination. Retain historical points but visibly break the line at every judging change, including a return to an earlier policy. projects_added and projects_removed list the test apps (id, slug, name, framework) the test added and removed against that test, empty for a directional test or re-test: show them as an event on the trend without breaking the line. requests_changed lists each request (intent, before, after) it 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): events on the trend, never breaks. A recognition edit on a setup of confirmed tools changes judging_key, so it breaks the line. Compare equal non-null judging keys only; intervening tests with different judging do not make two matching tests ineligible. 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. Pass pagination.nextCursor as cursor while pagination.hasMore for earlier tests; next_offset is deprecated. A page of exactly 100 rows reports more even when it is the last, so the following page can be empty. Unfinished tests have no rate. Requires Agent Picks and visibility.read.

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

Input Schema

NameRequiredDescriptionDefault
limitNoResults per page (1-100). Defaults to 100.
setupNoThe Agent Picks setup to use: its id or its category slug. Optional while the project has one setup. With several, omitting it is refused as agent_picks_setup_required, and a setup the project does not have as agent_picks_setup_not_found; both list the project setups in details.setups (id, category_slug, category_name). The response echoes the setup used as setup {id, category_slug}.
cursorNopagination.nextCursor from the previous page, unchanged. Keep the other arguments the same; omit it for the first page.
offsetNoDeprecated: pass cursor instead. Zero-based result offset.
test_idNo
pageSizeNoResults per page (1-100). Defaults to 100.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • addedInput schema / properties / offset / maximum
      Added value: +9007199254740991
    • removedInput schema / properties / pageSize / $ref
      Removed value: -"#/properties/limit"
    • addedInput schema / properties / pageSize / description
      Added value: +"Results per page (1-100). Defaults to 100."
    • addedInput schema / properties / pageSize / maximum
      Added value: +100
    • addedInput schema / properties / pageSize / minimum
      Added value: +1
    • addedInput schema / properties / pageSize / type
      Added value: +"integer"
    • addedInput schema / properties / test_id / pattern
      Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
  2. Changed1 schema field changed
    • addedInput schema / properties / setup
      Added value: +{
      +  "description": "The Agent Picks setup to use: its id or its category slug. Optional while the project has one setup. With several, omitting it is refused as agent_picks_setup_required, and a setup the project does not have as agent_picks_setup_not_found; both list the project setups in details.setups (id, category_slug, category_name). The response echoes the setup used as setup {id, category_slug}.",
      +  "maxLength": 200,
      +  "minLength": 1,
      +  "type": "string"
      +}
  3. Changed4 schema fields changed
    • addedInput schema / properties / cursor
      Added value: +{
      +  "description": "pagination.nextCursor from the previous page, unchanged. Keep the other arguments the same; omit it for the first page.",
      +  "maxLength": 1024,
      +  "type": "string"
      +}
    • addedInput schema / properties / limit
      Added value: +{
      +  "description": "Results per page (1-100). Defaults to 100.",
      +  "maximum": 100,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / offset / description
      Added value: +"Deprecated: pass cursor instead. Zero-based result offset."
    • addedInput schema / properties / pageSize
      Added value: +{
      +  "$ref": "#/properties/limit"
      +}
  4. Changed1 schema field changed
    • addedInput schema / properties / test_id
      Added value: +{
      +  "format": "uuid",
      +  "type": "string"
      +}
  5. Added

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already cover the read-only, idempotent, non-destructive profile, but the description adds real behavioral context: the required permission scope, named error codes (agent_picks_setup_required, agent_picks_setup_not_found) with their details.setups payload, the quirk that a 100-row page reports hasMore even when last, and that unfinished tests have no rate. Most remaining text documents return-field semantics rather than call behavior, which weakens it slightly, but the operational disclosures go 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.

Conciseness2/5

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

The description is a single sprawling paragraph of run-on clauses covering rate math, directional flags, judging keys, event lists and pagination in no discernible hierarchy. Individual statements carry information, but the lack of structure and the dense parenthetical chains ('rate, every run that picked it, a stated pick included, each scenario's rate averaged over the test's scenarios') make it hard to scan. Front-loading exists only in the first clause.

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 burden of explaining the return payload, and it does so extensively: rate, install_rate, Wilson ranges, rate_directional, install_rate_hidden_reason, judging_key, baseline_eligible, trend events and pagination behavior are all covered. For a complex six-parameter history tool this is close to complete, though the density leaves some field relationships ambiguous.

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 83%, and the schema already documents limit, pageSize, cursor, offset and setup thoroughly. The description adds genuine meaning only for test_id, which has no schema description ('only the test test_id names, whichever setup it belongs to'), and restates the default/maximum of 100. That is marginal added value over the schema, consistent with the baseline 3.

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 clause gives a specific verb and resource: 'Read a page of the setup's paid tests, newest first.' That is clearly distinguishable from a single-test getter. However, it never names or routes against siblings such as devtune_get_agent_picks_test or devtune_get_agent_picks_summary, so the agent must infer the boundary from the name alone.

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?

Usage is implied rather than stated: 'Pass pagination.nextCursor as cursor while pagination.hasMore for earlier tests; next_offset is deprecated' and 'Requires Agent Picks and visibility.read' give operational prerequisites. There is no explicit when-to-use-this-vs-alternatives guidance, e.g. when to use history rather than the summary or single-test tools.

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