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

With no annotations provided, the description carries the full transparency burden. It does disclose that the base roster and identity are returned while analysis parts are restricted behind 'Influence,' which is meaningful access context. But it leaves the meaning of 'Influence' and 'Understanding plan' unexplained, and says nothing about errors, availability, or whether the operation is read-only. Some value is added, but the ambiguity is significant.

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 short and the first sentence is information-dense, which is good. However, 'Understanding plan.' is a fragment that reads as an unfinished thought, and the transition to the access restriction sentence is abrupt. It is concise but not well-structured enough for a 4 or 5.

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 tool has no output schema, no annotations, and low schema coverage, so the description alone must suffice. It names the returned data but omits how to construct the request, what the response shape is, and what conditions require 'Influence.' The many sibling tools make this lack of routing and clarifying context more costly. This description is not complete enough for reliable invocation.

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 33%, and the description does not compensate. It never explains how 'kind' and 'slug' together identify the cohort, nor how the enum values map to cohort types. The parameters are left to inference from the schema's names and enum, which is inadequate for a tool with two required parameters and a low-coverage 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 clearly identifies the tool's output: a single cohort's identity, population, and full member roster with each provider's Kin Score and agent readiness. It also gestures at a distinction from sibling analysis tools by noting that stats/rankings/scores/capabilities are not part of this response. The lack of an explicit verb and the cryptic 'Understanding plan.' fragment keep it from being 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?

The line 'The analysis parts (stats/rankings/scores/capabilities) need Influence' implies that for such analysis, this tool is not sufficient and that another capability or plan is required. However, it does not explicitly name alternatives like cohort_stats, cohort_rankings, or cohort_scores, nor does it state clearly when to use this tool versus those siblings. The guidance is present but underdeveloped.

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