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

Annotations already declare this read-only/idempotent, and the description adds meaningful behavior: compact output by default, full metadata when 'limit' is raised, no identifier/score/eligibility changes, and source rights staying attached. This goes beyond the annotations and helps an agent understand outputs and non-effects.

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 compact and front-loaded, with no filler. The first sentence states the core purpose and the second statement adds key behavioral constraints. It is slightly dense with proprietary names, but every clause earns its place.

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?

Given there is no output schema and no parameter-level help, the description is only partially complete. It clarifies output verbosity and safety, but it does not explain the offset pagination parameter, the exact meaning of 'full metadata', or how the topic enum maps to the listed data sources. It is adequate for a simple read-only call, but leaves meaningful gaps.

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 compensate, but it only explains the limit parameter ('set limit for full metadata'). The topic parameter is only indirectly alluded to via the named data sources, and offset is completely unexplained. Two of three parameters remain under-specified.

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 states a specific action—connecting institution research to multiple named data sources (Palimpsest, Seiche, Undertow, NarcoScope)—which gives the tool a clear core purpose. However, 'connect' is somewhat abstract and it does not explicitly distinguish this tool from the sibling evidence_* and institution-focused tools nearby.

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 when to use it: when institution research needs to be linked with source, funding, liquidity, or global data context. It also gives a partial exclusionary note ('No institution identifiers, scores or eligibility changes'), but it never names alternative tools or clearly states when to choose a sibling instead.

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