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

The description explicitly discloses that the summary comes from a bounded relevance-ranked sample while still reporting the full matching count, which is important behavior beyond the annotations. It also adds a meaningful interpretive caveat that registration does not imply ownership, probability of success, or commercial value. No contradiction with the readOnly/openWorld/idempotent 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?

Two sentences with no filler: the first states the action and scope, the second adds a necessary caveat. The most important distinguishing behavior (bounded sample, full count) is front-loaded and clearly expressed.

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 gives enough context for an agent to understand what the tool returns: a portfolio summary grouped by key dimensions, based on a sample, plus the full matching count. It also covers the key interpretation limitation. It could be slightly stronger by clarifying parameter value formats and explicitly differentiating from similar sponsor-related siblings, but it is largely complete for a read-only summarization tool.

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 only 40%, so the description carries some responsibility for parameter meaning. It clarifies the sample behavior and grouping dimensions, but it does not explain valid values or formats for phase, status, or sample_size beyond what the property names already suggest. The sponsor and sponsor_match parameters are already documented in 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 opens with a specific verb and resource: 'Summarize a sponsor’s ClinicalTrials.gov portfolio' and names the exact grouping dimensions (phase, status, condition, intervention). It also distinguishes the tool from a generic search/list tool by describing the bounded relevance-ranked sample and the full matching count.

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 usage context is inferable: use it when you need a portfolio-level summary rather than individual trial results. However, it never explicitly says when to prefer this over sibling tools like ct_sponsor_trials, ct_compare_sponsors, or ct_sponsor_activity, nor does it name any exclusion conditions.

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