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

Annotations only declare readOnlyHint=false, openWorldHint=false, destructiveHint=false, leaving the semantics of the write unexplained. The description supplies the non-obvious behavioral fact that this call 'grants nothing and does not admit you' and is not a binding or authority, which prevents an agent from mistaking a recorded claim for an actual grant. It does not describe what is returned or what happens on failure.

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 action and the admission prerequisite are front-loaded, which is good, but the description then spends two sentences on a repetitive negation chain ('not enrollment, not a declaration, not a binding, not a matter association, not principal verification, and not authority') plus a restated prohibition. Consolidating the negatives would sharpen it without losing information.

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 mutation tool with no output schema, the description covers prerequisites and non-effects but says nothing about the result of a successful claim, error conditions, or whether the claim can be revised. An agent knows how to gate the call but not what it gets back, leaving a real gap.

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 100%, so the baseline is 3, but the description adds a genuine constraint absent from the schema: 'Do not send a matter id or an objective id.' It also reinforces that both principal and purpose are free-form ('in your own words'), though that wording largely duplicates the schema. The extra negative guidance nudges it above baseline.

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 action on specific inputs ('State the principal you claim and the purpose you claim, in your own words') and fences it off from adjacent operations (enroll, bind_actor, declaration, matter association, verification, authority). The affirmative purpose is clear, though it is delivered mostly through a negative enumeration, so it is slightly weaker than a crisp verb+resource statement.

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 bracketed precondition '[NEEDS ADMISSION: enroll, then atlas.bind_actor]' gives an explicit prerequisite sequence, which is exactly the routing information an agent needs. The negation list further implies the conditions under which other tools apply, but no alternative is named as the tool to use *instead* for a different intent, so it stops short of a full when/when-not/alternative statement.

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