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

No annotations are supplied, so the description carries the full disclosure burden, and it does substantial work by listing the exact sections returned, including derived fields like how much of the partner's docs search and semantic_search cover. It does not say what happens for an unknown partner id, whether the result can be partial, or how large the payload is, which are the main remaining behavioral gaps.

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 content is front-loaded around a single framing sentence followed by the accepted-value list, and nearly every clause maps to something the tool returns. Slightly wasteful phrasing ('What an agent needs to build on a NEAR partner') and the length of the id enumeration cost it a point.

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 one parameter, no annotations, and no output schema, the description must explain the return shape, and it does so in detail. Missing only error/not-found behavior and any indication of response size or nesting for a tool that clearly aggregates many sources.

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 coverage is 100%, and the schema's own parameter description already states that id, name, contract account, or catalog slug are accepted, so the description's trailing sentence largely restates it. The one genuine addition beyond the schema is the explicit enumeration of valid partner ids, which helps the agent avoid guessing.

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 clear resource (a NEAR partner profile) and enumerates exactly what the response bundles: identity, mainnet contract accounts, GitHub, docs/llms.txt, doc-coverage stats, Catalog entry with TVL, and security incidents. It is specific enough that an agent can predict the payload, but it never names a sibling it is distinct from (e.g. find_project or get_contract_info), so full credit for sibling differentiation is not earned.

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 implied usage is clear from 'what an agent needs to build on a NEAR partner', and the trailing note clarifies the accepted key forms (contract account like "intents.near" or a catalog slug). However, there is no explicit when-to-use/when-not guidance and no alternative tool is named for cases where the agent only wants a single artifact such as contract info or a doc search.

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