get_reportThe finished report: summary over every page, a slice of the per-page results (offset and limit, default 1000 a call; nextOffset points at the next slice), and the plain-text report over that slice. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | ||
| limit | No | Page results to return (default 1000, at most 5000). | |
| offset | No | Index of the first page result to return (default 0). | |
| jobToken | Yes | The jobToken returned when the job was created. |
Changes observed during successful MCP inspections.
Input schema / properties / limitAdded value: +{
+ "description": "Page results to return (default 1000, at most 5000).",
+ "maximum": 9007199254740991,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / offsetAdded value: +{
+ "description": "Index of the first page result to return (default 0).",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose pagination behavior via offset, limit, and nextOffset, plus the returned report structure. It does not disclose error behavior, job-state requirements, or whether the operation is read-only, and the standalone 'Free.' is ambiguous.
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?
The description is compact and front-loads the main purpose. The final 'Free.' is extraneous and ambiguous, which prevents a perfect score, but the rest of the text is dense and informative.
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?
The description covers the response structure and pagination, which is essential for calling this tool. However, with no output schema and no annotations, it omits job-completion preconditions, error handling, and how this tool fits into the comparison workflow, making it adequate but incomplete for a no-annotation context.
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?
The schema already documents limit, offset, and jobToken, but the description adds meaningful pagination context: the default 1000-per-call slice and that nextOffset points to the next slice. This clarifies the relationship between offset, limit, and the returned data beyond the schema.
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 description clearly identifies the tool as returning a completed report with summary, per-page slices, and plain-text content. It lacks an explicit verb like 'retrieve' and does not explicitly distinguish itself from get_comparison, but the resource and scope are unambiguous.
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?
The word 'finished' implies the report is only available after a job completes, providing a weak contextual hint. However, there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives like get_comparison or start_comparison.
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.