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

Beyond readOnlyHint=true, it discloses that the response may be null (no agreement), that long text may be surfaced as a URL for the user to read themselves, and that accepting leaves a signature snapshot plus an organization audit record. It also warns that consent is bound to this specific versionId and that a newer version invalidates prior agreement — behavioral context the annotations cannot express.

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 the trigger condition, and every clause carries operational weight (precondition, null case, consent flow, audit, version binding, opt-out case). It is however one dense semicolon-chained block mixing languages and abbreviations, which costs some readability.

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 one-parameter read tool with no output schema, the description covers everything an agent needs: when to call, what null means, how long text may be returned, and the full downstream signing flow including version pinning and audit consequences.

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?

There is a single required parameter, slug, and schema description coverage is 100%, so the schema already carries its meaning; the description adds nothing about slug format or scoping. Baseline 3 per the high-coverage rule — the description's added value here is about return semantics ('null means no agreement'), not parameter meaning.

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?

States a specific verb+resource: fetch the full text of an activity's signup agreement, and pins the exact precondition (get_signup_activity reports the agreement as required-and-unaccepted, or activity_agreement_required is set). It also distinguishes its negative case — null means no agreement — so the agent will not confuse it with get_activity, get_signup_submission, or the various accept_* siblings.

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 explicit when-to-use (required and not accepted), when-not-needed (required=false, already signed or already registered), and the exact next step: show the text to the user and call submit_signup with agreement={versionId,accept:true} only after explicit consent. It also covers the retry path — on a version conflict, re-fetch and re-confirm — and forbids auto-accepting on the user's behalf.

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