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

Beyond the readOnlyHint, the description adds critical data interpretation: annual award amounts are obligations per fiscal year, not revenue, cash received, or guaranteed future funding. This prevents misinterpretation of returned data and explains cumulative reported funding, which is valuable context not provided by annotations.

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 two sentences, each earning its place: the first lists the tool's function and deliverables, the second clarifies a critical data nuance. Information is front-loaded with no redundancy, making it highly efficient.

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?

With only one parameter, read-only annotations, and no output schema, the description sufficiently covers the tool's purpose, data elements, and interpretive caveat. It does not describe the exact return format, but for a simple historical look-up this is acceptable.

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 provides a clear description and examples for core_project_num (e.g., R43GM128494 or UG1HD078437), achieving 100% coverage. The tool description does not add further parameter-specific guidance, so the schema carries the burden and the baseline of 3 is appropriate.

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 states the action ('Build the annual NIH award history'), the scope ('for one core project number'), and the contents (award, direct/indirect cost, budget dates, application type, cumulative reported funding). This distinguishes it from broader sibling tools like nih_funding_concentration or search_grants.

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 description implies usage for a single project's annual history and clarifies the meaning of award amounts, but it does not explicitly mention when to prefer this tool over alternatives or provide exclusions. A direct reference to sibling tools for multi-project or summary queries would strengthen this dimension.

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