Skip to main content
Glama

devtune_get_agent_picks_actions

Read-onlyIdempotent

Read a page of the setup’s Agent Picks Actions (limit or pageSize, default and maximum 100), or the one actionId names whichever setup it belongs to, with rendered titles and descriptions, their loss rationale, baseline cell pick rate (every run that picked the tool, a stated pick included; re-tests compare the same rate) and Wilson 90% range (a measurement with scenarios pools that many cells: rate averages each cell’s rate, counting each once, and its range counts cells, so picks and runs are counts beside it, not its fraction), latest paid re-test status and credit accounting, and the measured Outcomes result with its method: v2 results decide each cell by the 90% interval on the difference from its baseline and show 90% ranges; v1 results, from re-tests started before v2, compare 95% ranges and show them. Report a result’s ranges at its method’s confidence, and say when results you compare used different methods. With actions.read, an Action with a current drafted fix carries agent_prompt, the fix as a Markdown prompt for a coding agent that names the locked pages it steers around; it publishes nothing. Reason Actions expose the actual fetch URL/status, classifier key or own-tool observation (own_url_failed, own_install_failed, own_tool_not_observed, own_tool_tried) and every covered cell, with aggregate evidence rather than a first-cell claim; observation Actions add observation_counts, a docs coverage result on own_tool_not_observed, the most common trails on own_tool_tried (what runs did with the own tool, in order, before picking another or building their own), the winners of each cell and failures on other sites by URL origin, while rates and re-tests stay on full-cell baselines. Pass pagination.nextCursor as cursor while pagination.hasMore; 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. Incomplete coverage is explicit. Shipping alone is unmeasured; only queued or running re-tests are still_measuring; no modelled wins. Re-tests are estimated and confirmed in the app. 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_actions"
  }
}

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.
actionIdNoRead one Action and its re-test result
pageSizeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
      +}
  2. 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"
      +}
  3. Added

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so this is bonus context: it discloses the exact-100-rows pagination trap where a full page reports more and the next page can be empty, an explicit 'incomplete coverage' signal, the still_measuring state rule, and that result ranges must be reported at their own method's confidence. It even states the drafted-fix prompt 'publishes nothing'. Density limits clarity but the disclosure burden is exceeded, not shirked.

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?

A single unstructured block with deeply nested parentheticals ('a measurement with scenarios pools that many cells: rate averages each cell's rate, counting each once, and its range counts cells...') that the reader must parse twice. Useful facts are present but buried mid-sentence with no bullets, headings, or ordering by importance, so valuable content is effectively discounted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

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

No output schema exists, so the description must carry return semantics, and it does attempt to — listing rendered titles, loss rationale, pick rate, Wilson range, re-test status, and the v1/v2 outcome method split. However, domain terms like 'baseline cell pick rate', 'Wilson 90% range', and the v1/v2 method decision rules are asserted rather than explained, leaving an agent unsure how to interpret or compare values it will actually receive.

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 description coverage is 83%, so the schema already documents limit/pageSize, cursor, offset deprecation, and the setup resolution errors. The description reinforces the 100 default/max and clarifies that actionId overrides setup scope across projects, but adds little semantic meaning the schema lacks. Baseline 3 applies.

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?

Opens with a specific verb and resource ('Read a page of the setup's Agent Picks Actions') and immediately distinguishes the two modes (paged list vs. single actionId lookup, which ignores setup). The purpose is unmistakable, though it is delivered in one ~150-word run-on sentence rather than front-loaded in a headline.

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?

Gives real operational rules: pass pagination.nextCursor as cursor while pagination.hasMore, next_offset is deprecated, and requires Agent Picks plus visibility.read. What it never does is route the agent between this and near-siblings like devtune_get_actions or devtune_get_agent_picks_cells, which a large catalog makes the more valuable guidance.

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