Get Research Report

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

With no annotations and no output schema, the description carries the full disclosure burden and does substantial work: it names the returned fields and calls out that company reports conditionally include target price, previous target price, and publication-date stock price. It omits error/not-found behavior and any auth or rate-limit context, which is the main residual gap.

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 tight sentences, front-loaded with the operation and its return shape, ending with the sourcing prerequisite. No filler and no repetition of schema content.

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 two-parameter read tool with no annotations or output schema, the description adequately covers inputs' origin and the conditional return fields. It stops short of covering failure modes (unknown nid, invalid category) or whether the summary is truncated, which would round it out.

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 100% and the category enum is fully spelled out in the schema, so the description needn't repeat it. The description adds only the provenance hint that both parameters come from search_research, and implicitly signals that category=company changes the response shape — useful but marginal against a complete 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?

States a specific verb and resource ('Get one research report') and immediately enumerates the payload: summary text, pdfUrl, detailUrl, plus company-specific pricing fields. This clearly distinguishes it from search_research, which is named as the discovery counterpart.

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 closing sentence 'Take category and nid from search_research results' tells the agent this is the second step in a flow and where the required keys come from. It doesn't state exclusions or failure behavior, but the intended usage context is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.