mnemosyne_agent_collisions

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

With no annotations provided, the description carries the full burden and does it well. It discloses that answers come from transcript files on disk, that Mnemosyne OS and a token are not required, and that each recorded directory is resolved to the working tree to avoid false collisions. It also explicitly explains the meaning of a clean answer, the miss of agents with external transcripts, and separate 'unplaceable' handling, which is remarkably 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?

The description is dense and each sentence carries intent: scoping, when to call, why, internal resolution logic, and limitations. It is slightly long but every clause supports efficient use of the tool, so it counts as well-structured rather than bloated.

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 tool with no output schema and no annotations, it does a strong job of covering the context and semantics of the result: what counts as a collision, what a 'clean answer' means, and why false negatives may happen. It never spells out the exact response shape, but the behavioral caveats and safety-guided intent are well documented. Minor gap remains in explicit return shape.

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?

The schema coverage is 100%, and the property's own description already explains the normalization and the `git rev-parse` recommendation. The overall tool description does not add parameter-specific guidance beyond this, but it also does not need to because the schema is very clear. Baseline is 3 for high coverage with no additional parameter detail in the text.

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 first sentence states the tool's specific purpose: detecting whether two agent sessions live in the same git working tree and branch, from any installed harness. It also says it's the call to make before git add, commit, or rebase, which gives clear identity. However, it never names sibling alternatives to differentiate itself, so it stops short of the strongest version of this criterion.

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 explicitly states when to call the tool: before `git add -A`, before commit, and before rebase, with the shared-index rationale. It also gives important exclusions and caveats, such as 'a clean answer says only that nothing was found in what is readable' and that unreadable transcripts are not considered. It does not explicitly describe when to choose a sibling tool, but the usage context is clear and substantial.

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