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

Annotations already establish read-only, closed-world, non-destructive behavior, so the description adds real value on top: it discloses the auth requirement ('Needs tracker:read'), the ranking ('best match at the top'), the hard cap of 10, the exact returned fields, the linkStatus enum values, and the null semantics of fitScore. It stops short of describing what happens when nothing matches or how matching is weighted.

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?

Everything is packed into one front-loaded sentence that leads with the action and scope before the result fields. It is dense but nearly every clause carries information; readability suffers slightly from the long parenthetical and trailing field list.

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 no output schema and zero schema description coverage across three parameters, the description compensates well by enumerating return fields, disclosing the required scope, and documenting fitScore's null case. The remaining shortfall is that it never covers empty-result behavior or the character limits on q, which matters for a tool whose only required parameter is free text.

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 0%, so the description must carry parameter meaning. It does well for q by enumerating acceptable query content, and startupId's role is inferable from the fitScore explanation, but the 2–80 character bound on q and the purpose of limit (only its ceiling of 10 is mentioned) are not explained, leaving real gaps.

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 names a specific verb (search/open programs) and the resource (getfund catalog programs), and it enumerates the query dimensions (name, organiser, sector, stage, type, country) plus the returned fields. It does not explicitly contrast itself with the sibling getfund_programs, so an agent must infer which one to pick from name 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?

It tells the agent the kind of input that works ('a name, an organiser or a few words') and that results are best-match ordered and capped at 10, which implies exploratory lookup usage. However, it never states when to use this instead of getfund_programs or how to handle zero results, so the alternative-routing guidance is only implied.

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