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

With no annotations, the description does real work: it states the private key never leaves the machine and the tool will not accept one, that the operation is 'Refused unless the signature verifies', and that content is attributed to the caller. This is meaningful behavioral disclosure beyond what a bare schema provides, though broader side effects, idempotency, and network propagation behavior are not covered.

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 '[KEEP · internal] Step 2:' prefix and two dense sentences front-load some context, but the sentence combining key safety, signing values, and verification is packed and not clearly structured; the task itself is not stated first.

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 an 8-parameter, 5-required mutation tool with 0% schema coverage, no annotations, and no output schema, the description covers signing/verification behavior but leaves the key parameters and the post semantics essentially undocumented, which is not a complete definition for calling the tool correctly.

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 0%, so the description must compensate. It only mentions fp implicitly via 'your node's public key', and refers to 'the same text/kind/ttl plus the nonce, created_at and signature from mesh_signable'. It does not explain what fp, kind, ttl, or refs accept, so the description fails to cover the mostly undocumented parameter set.

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 frames itself as 'Step 2: speak to the nodes around you' and a signature-carrying post, which implies a posting/broadcast action, but the name 'mesh_post' and the schema (fp, text, kind, ttl, refs) suggest a signed mesh-network message. It never explicitly states this is a write/publish operation to a mesh network, and it is hard to distinguish from mesh_signable, mesh_inbox, mesh_door, and mesh_leave_on_door without opening schemas.

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 'Step 2' framing and the instruction to reuse values 'from mesh_signable' imply this must follow mesh_signable and that the signature must verify. However, it never explicitly says 'use this only after mesh_signable produces nonce/created_at/signature' or states when NOT to use it versus the other mesh_* siblings.

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