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

Annotations already declare readOnlyHint=true, and the description adds genuinely useful behavior: public organizations can be read anonymously, the terms body is capped at ~20k characters and should only be fetched on demand, and pending applications must not be duplicated. However, for a compound read whose return shape matters, it discloses field-level quirks only piecemeal (currentTerms.bodyLength, myMembership.id) and says nothing about pagination, ordering, or error modes.

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?

Front-loaded with what is read, then policy and sequencing, so an agent can act after the first clause. The remaining semicolon-chained caveats are individually useful but crammed into one dense block with no structure or emphasis, making them easy to skim past.

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, the description carries the burden of describing what comes back and does so at a useful level — terms summary vs body, membership id semantics, application state. It is slightly thin on the shape of the eligibility/policy fields an agent must interpret when deciding whether the user can apply, but nothing essential for correct invocation is missing.

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%, so the baseline is 3, but the description adds real meaning: includeTermsBody=true is the only way to get the full agreement text and should be used only when reading it to the user for confirmation, while the default false returns a summary flagged by bodyLength. It also disambiguates a returned identifier (myMembership.id is a membershipId, not a userId), which the schema cannot express.

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?

Opens with a specific verb+resource: reads an organization's identity/visibility/join policy/terms summary/topics plus the caller's own membership and application state, and the title frames it as "view an organization (including whether I can apply)". It implicitly separates itself from discovery/update siblings (discover_organizations, update_organization) and routes downstream actions to apply_to_organization and submit_signup, though it never names an alternative to use instead of this read.

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?

Gives concrete when-to-use rules: consult this when activity_members_only to determine whether the user can apply, and only pass includeTermsBody=true when the terms body must be read aloud for confirmation. It also states an explicit when-not / sequencing constraint — after the user consents go to apply_to_organization and then submit_signup, and do not resubmit while an application is PENDING.

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