list_batches
List batch analyses by name with readable status and progress.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| status | No |
List batch analyses by name with readable status and progress.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| status | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds only that results include 'readable status and progress', which hints at return content but says nothing about pagination behavior implied by limit/cursor, result ordering, or what happens at end of pages.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single short sentence with no wasted clauses, so it is concise. However, the brevity comes at the cost of specification, leaving the misleading 'by name' as the most prominent claim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paginated listing tool with an opaque cursor and a status filter, none of which the schema documents, the description is not complete enough to call it correctly. There is no output schema to fill the gap either, so return shape and paging semantics are entirely undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for all three parameters, so the description carries the full burden and provides nothing about limit, cursor, or status. Worse, 'by name' points at a filter that does not exist while the real filter (status) and paging (limit/cursor) go unmentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'List' and resource 'batch analyses' identify the operation, but the qualifier 'by name' has no corresponding parameter in the schema and misleads about what filtering is possible. No distinction is drawn from siblings such as get_batch or export_batch, so an agent cannot confidently separate listing from fetching a single batch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this versus get_batch, export_batch, or get_analysis, all of which appear in the sibling list and touch the same resource. The reader must infer that this is the enumeration entry point from the verb 'List' alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.