Read all retained research results. Returns the complete owner-scoped retained result prefix up to a consistent manifest sequence.
Read all retained research results. Returns the complete owner-scoped retained result prefix up to a consistent manifest sequence. Before a valid report or structured result exists, returns ready=false with partial=true and any retained evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Research job ID |
Changes observed during successful MCP inspections.
v1.17.12Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose meaningful behavior: results are owner-scoped, capped at a 'consistent manifest sequence', and the not-ready state returns ready=false with partial=true plus retained evidence. It still omits auth/permission requirements, size limits, or whether repeated calls are stable snapshots.
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?
Three sentences, front-loaded with the core action, and each sentence adds a distinct fact (scope, boundary, fallback state). It is slightly jargon-heavy ('retained result prefix', 'consistent manifest sequence') for an agent without prior context, but there is no filler.
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 single-parameter tool with no annotations and no output schema, the description covers the essential return semantics, including the partial/not-ready case. The main gaps are how to poll (interval/termination) and whether the prefix is paginated, which are minor for this shape.
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 coverage is 100% and the sole job_id parameter is documented in the schema as 'Research job ID', so the schema does the heavy lifting. The description adds the owner-scoping notion but no syntax, format, or sourcing guidance for obtaining a job_id.
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 gives a specific verb and resource ('Read all retained research results') and clarifies the resource is owner-scoped and sequence-bounded, so the agent knows what it fetches. However, it never distinguishes itself from the many sibling research_* tools (research_status, research_events, research_sources), so an agent cannot tell which one to call from purpose alone.
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?
Usage is only implied: the note that it returns ready=false/partial=true before a valid result exists signals this can be polled during a running job, but no alternative (e.g. research_status for progress, research_events for streaming) is named and no when-not-to-call condition is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.