get_research_brief

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

No annotations are supplied, so the description carries the full behavioral burden and does not meet it. It reveals nothing about failure behavior when a brief is absent, permissions, or what the read returns.

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?

A single short sentence with the resource front-loaded and no wasted wording. Brevity here borders on under-specification rather than verbosity, but nothing is padded.

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 simple 1-parameter read tool with no output schema and no annotations, the description should at least say what the brief read yields and whether an existing brief is required. Neither is covered, leaving the agent to guess or fail.

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?

One required parameter at 0% schema description coverage, so the description must compensate; saying "for a seed" does map seed_id to a seed identifier. It adds no format, source, or validation detail beyond that minimal mapping.

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 (Read) and resource (research brief) scoped to a seed, which is enough to tell it apart from the sibling build_research_brief by the read-vs-build verb. It stops short of explicitly naming that sibling or stating what the brief contains.

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?

No when-to-use or when-not guidance. In particular it never says whether the brief must first be created with build_research_brief, or what happens if none exists yet — the single most important decision an agent faces with this pair of tools.

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