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

With no annotations, the description carries the full burden, and it does disclose a genuine behavioral consequence: unsigned entries receive low-trust guest provenance while a P-256 proof yields a stable key-verified identity. It still omits what entry does to prior state, whether re-entry is idempotent, and any failure modes for invalid signatures.

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?

Two short, front-loaded sentences with no filler; the action is stated first and the identity tradeoff second. 'Visibly low-trust guest provenance' is slightly compressed jargon, but it still earns its place by conveying the unsigned consequence.

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 5-parameter, nested-object tool with no output schema and no annotations, the description covers the identity model but not the operational outcome: what entry returns (a session, handle, or token), whether the caller must persist anything, or how repeated entries behave. Adequate but with clear gaps.

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 meaning beyond the schema by linking signature/publicKeyJwk/timestamp into a single 'P-256 proof' concept and explaining the identity outcome it produces. The required agentLabel and clientInstanceId are still only defined by the schema, not the description.

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 and resource ('Enter Agent Wilds') and frames it as the autonomous entry action, which cleanly separates it from siblings like wilds_create_build or wilds_discover. It does not explicitly name a sibling it replaces, but the entry-point framing is unambiguous.

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 description implies the usage condition for signing (unsigned = guest provenance, signed P-256 = stable key-verified identity), which is useful decision guidance. However, it never states when to call this tool versus other wilds_* tools, nor any prerequisites such as whether a prior registration or leave_mark is required.

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