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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds two things the annotations do not: the required scope (brain:read) and a preview of the returned structure (gaps with their questions, queue size, readiness flag). That is genuinely useful given no output schema exists, though it omits behavior on empty/missing startup and any error conditions.

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 sentence, front-loaded with the outcome, using a colon-list to enumerate the return payload efficiently. Minor cost: 'the brain gaps' is domain jargon that is only partially unpacked by the following clause, adding a small decoding burden for a first-time caller.

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 zero-required-parameter read tool with a clear safety annotation, this is close to adequate, and the absence of an output schema is partly offset by the payload preview. However, two undocumented parameters plus no statement about startupId scoping or default behavior leaves real gaps an agent needs to call it correctly.

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% for two parameters. The description never mentions startupId (which startup is being evaluated) or locale (which presumably controls the language of the founder questions, given the tr/en enum). With neither parameter explained in schema or description, an agent must guess how to scope the call and what locale changes.

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 the exact payload: unresolved brain gaps, the founder-facing question for each, queue size, and overall readiness. That is a concrete read operation an agent can distinguish from getfund_brain (raw brain content) and getfund_queue (queue contents). It stops short of explicitly differentiating from those siblings, so it is a 4 rather than a 5.

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?

Usage is only implied: the agent can infer it should call this to discover what the founder must still supply before the startup is ready. There is no explicit when-to-use statement, no exclusion of alternatives such as getfund_brain or getfund_application, and no mention of follow-up steps (e.g. getfund_write_brain_answers). The lone prerequisite, 'Needs brain:read', is helpful but is an access rule, not a routing rule.

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