Skip to main content
Glama

devtune_list_visibility_response_history

Read-onlyIdempotent

Page every still-present execution, including pending, running, failed and rate-limited records, in a fixed 30/90-day started-at window. Default 50, maximum 100 per page. Keep filters unchanged with nextCursor. Read each execution with devtune_get_visibility_response for retained public answer evidence. This live operational listing is not a visibility denominator or a snapshot; retention and statuses can change during traversal. Enterprise platforms require existing entitlement.

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

Input Schema

NameRequiredDescriptionDefault
limitNoThe same setting as pageSize. Send either.
cursorNo
statusNo
pageSizeNoResults per page.
platformNo
promptIdNo
windowDaysNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • removedInput schema / properties / limit / $ref
      Removed value: -"#/properties/pageSize"
    • addedInput schema / properties / limit / maximum
      Added value: +100
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • addedInput schema / properties / limit / type
      Added value: +"integer"
    • addedInput schema / properties / promptId / 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})$"
    • addedInput schema / properties / windowDays / anyOf
      Added value: +[
      +  {
      +    "const": 30,
      +    "type": "number"
      +  },
      +  {
      +    "const": 90,
      +    "type": "number"
      +  }
      +]
    • removedInput schema / properties / windowDays / enum
      Removed value: -[
      -  30,
      -  90
      -]
    • removedInput schema / properties / windowDays / type
      Removed value: -"number"
  2. Changed2 schema fields changed
    • addedInput schema / properties / limit
      Added value: +{
      +  "$ref": "#/properties/pageSize",
      +  "description": "The same setting as pageSize. Send either."
      +}
    • addedInput schema / properties / pageSize / description
      Added value: +"Results per page."
  3. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower; the description still adds real behavior: the data is live operational state, retention and statuses can shift mid-traversal, and enterprise platforms need pre-existing entitlement. That last point is an access prerequisite the agent could not get from structured fields. Missing only the response/item shape, which it partly offloads to the get tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Five short, front-loaded sentences with no filler — scope first, then paging rules, then the follow-up tool, then the caveat. Slightly dense with stacked caveats, but every clause carries information an agent needs before calling.

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?

For a 7-parameter listing tool with no output schema and thin parameter descriptions, the definition supplies the operationally important context: windowing, page bounds, cursor-stability, data volatility, and entitlement. The remaining gap is item-shape and the unaddressed promptId/platform filters, which keeps it short of full coverage.

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 only 29%, so the description has to carry weight, and it does cover the pagination contract (cursor keeps filters unchanged, 50 default / 100 max) and the meaning of the 30/90-day window. But promptId, platform, and the limit/pageSize alias are left to the schema despite low coverage, so it does not fully compensate.

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?

"Page every still-present execution" gives a specific verb plus resource, and the scope is narrowed to a fixed 30/90-day started-at window with enumerated statuses. The line distinguishing it from a "visibility denominator or a snapshot" separates it conceptually from the sibling listing tool, though it never names that sibling outright.

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?

It usefully routes the agent forward by naming devtune_get_visibility_response as the per-execution read, and warns that filters must stay fixed across nextCursor paging. However, there is no explicit when-not or the condition under which an agent should prefer the snapshot-oriented sibling listing instead — that has to be inferred from the denial of being a denominator.

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