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

Annotations only say this is a non-read-only, non-destructive write. The description adds real behavioral context beyond them: the deprecated direction parameter, that the server 'refuses a contradiction' between a per-edge override and the label, and that sourceEntryId/targetEntryId ordering is semantically load-bearing. It also discloses cardinality consequences ('keep each to one link').

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 critical rule ('The label decides everything') is front-loaded, and the closing routing advice is well-placed. The 16-label enumeration is long and partially duplicates the enum already in the schema, but each entry adds source/target type semantics the enum cannot express, so the length is mostly justified.

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 write tool with an output schema, the description covers what matters: which parameter determines edge shape, direction ordering, the deprecated field, the valid label matrix via a sibling tool, and when to prefer an alternative API. Nothing an agent needs to invoke it correctly is missing.

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 only 17%, so the description carries the load — and it does, defining the 'from'/'to' roles of sourceEntryId and targetEntryId and the source/target types implied by each of the 16 labels. The gap is color and campaignId, which are never explained in either the schema or the description; color in particular is a free-form field with no stated effect.

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?

Opens with a specific verb+resource: 'Create a relationship between two mnemon entries.' It is immediately distinguishable from delete_mnemon_relationship and list_mnemon_relationships, and the follow-on sentence pins down that the edge's kind and reading are derived from the label rather than from caller input.

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?

Explicitly routes the agent away from this tool where an alternative exists: 'for faction membership prefer memberNpcEntryIds / affiliationEntryIds on the NPC itself; for a quest's giver, location and parent prefer giverId / locationId / parentQuestId'. It also states the one case with no alternative ('SESSION_* labels are the only way to set them') and points to describe_mnemon_types for the full matrix.

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