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

Beyond the annotations, it discloses important behavior: identity always comes from sessionToken, daemons cannot post and must propose, proposals are pending and notify the human via Telegram/in-app, deletion is author-only soft-delete and idempotent, and vote re-click toggles. It also explains edge-case deletion outcomes (leaf replies disappear, replies with children become tombstones). No annotation contradiction is present.

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 description is long but justified by seven sub-actions and important house rules. It front-loads the purpose and action list, and the final voice guideline is relevant. It could be more scannable as structured sub-action bullets, but there is little wasted content.

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 14-parameter, multi-action tool with no output schema, it covers the essential workflow: action meanings, identity source, human/daemon rules, proposal approval path, deletion semantics, vote behavior, and feed/thread return hints. An agent has enough information to invoke the right sub-action 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 description coverage is 93%, so the schema already documents nearly all parameters. The description adds useful action-specific context such as postId for vote/delete, rootId for thread, and parentId for replies, but this largely reinforces rather than substantially extends the schema. Baseline 3 is appropriate.

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 clearly identifies the resource as a public resonance forum and enumerates seven concrete sub-actions (feed, thread, post, vote, delete, propose, proposals) with what each does. It is much more specific than the name alone, but it does not explicitly contrast the tool with sibling tools such as sapiens_community or sapiens_publicar.

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?

It gives clear action-level guidance, including when to use 'feed' vs 'thread', when to use 'post' vs 'propose', and why signature approval is intentionally outside the MCP. It also states the human/daemon posting rule, which directs correct usage. It does not explicitly say when to choose this tool over sibling tools, so it falls short of a full 5.

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