mnemosyne_spine_assignments

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

With no annotations provided, the description carries the full behavioral burden. It compensates well: it states the operation is inspection ('Inspect', 'audit'), reveals ordering ('newest first'), clarifies that counts remain whole-vault when filtering by spine_type, and notes the taxonomy tree is optional. It does not explicitly assert non-mutating behavior, but the inspection framing and absence of side effects make it reasonably transparent.

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 sentences deliver the main output, the use cases, and the connection to mnemosyne_query with no wasted words. The first sentence front-loads the core behavior and key ordering detail; the second covers intended usage. The 'chronicle → spine' notation is compact but understandable in context.

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?

There is no output schema, so the description reasonably explains what is returned: assignments (newest first), whole-vault per-spine counts, and the optional taxonomy tree. It also clarifies that filtering by spine_type does not change the whole-vault counts. Combined with the 100% schema parameter coverage for a no-required-parameter tool, this is enough for an agent to call it 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 100%, so all five parameters are already documented with defaults and semantics. The description adds context by mentioning the optional taxonomy tree and the idea of discovering taxon ids for use in mnemosyne_query, but it does not add new meaning to the parameters beyond what the schema already provides. Baseline 3 applies.

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 opens with a specific verb and resource ('Inspect how Mnemosyne classified its memories: chronicle → spine assignments') and clearly enumerates the distinct outputs: newest-first assignments, whole-vault per-spine counts, and the optional global taxonomy tree. It also differentiates from the sibling mnemosyne_query by framing this as an audit/composition tool and mentions producing the taxon ids to pass into mnemosyne_query.

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 provides concrete trigger contexts: audit auto-classification quality, inspect a vault's composition at a glance, or discover taxon ids for use as a filter in another tool. It does not explicitly list when NOT to use this tool or name a sibling to switch to, but the use-case list is strong enough that an agent can infer appropriate versus inappropriate invocations.

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