MemAI

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

With no annotations present, the description carries the full burden and mostly succeeds: it discloses the additive (non-moving) effect, that every read scoped to the domain will return the memory, that duplicate/redundant paths are dropped, and the shape of the response. It omits auth requirements and failure modes, but the core behavioral semantics are unusually well 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?

Front-loads the core action in sentence one, which is good, but the middle paragraph leans on metaphor ('cuts across the tree', 'the echo is what actually holds') that adds ambiguity rather than precision for a simple two-parameter tool.

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, but the description compensates by specifying the return object (`uid`, `also`). Behavior, usage, and result shape are all covered; only parameter-level detail for `uid` is thin.

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 conveys the meaning of `domain` (a path, subject to redundancy dedup) but says nothing about `uid` beyond the response echo, so one of two parameters stays undocumented.

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?

States a specific verb ('Cross-list') and resource ('an existing memory') plus the target ('one more domain path'), and contrasts against a sibling behavior by saying 'without moving it -- use the dashboard's re-home for that.' This distinguishes it from move_to_project/unfile_domain, though it does not name them directly.

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?

Gives a clear triggering scenario: a memory was filed where it lives and later turns out to belong to a cross-cutting subject. It also implicitly sets the boundary that the memory is not relocated. No explicit 'do not use when' or named alternative sibling, so not a 5.

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

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

No annotations are provided, so the description carries the full burden. While it mentions storage type, cross-listing behavior, and review scheduling, it lacks crucial mutation details: no indication of required permissions, whether the operation is idempotent, side effects, or what the response contains. It also doesn't clarify if creating an anti-pattern affects other domains or requires specific context.

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 somewhat verbose with multiple paragraphs and references to other tools ('see note()' three times), which may require additional lookups. However, it is structured logically and front-loads the core purpose. Some sentences could be more direct.

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 mutation tool with 10 parameters, no annotations, no output schema, and 0% schema coverage, the description leaves significant gaps. It doesn't explain what happens on creation (e.g., where it's stored, how it's indexed), doesn't cover all required parameters, and relies heavily on external references (note()), which may not be available to the agent. It also omits error handling or constraints.

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 0% for 10 parameters (4 required). The description only partially compensates: explains meaning of 'also', 'review_after', 'source_ref', 'title' (with constraints), and 'tags' (with retrieval impact). It leaves 'pattern', 'why_wrong', 'instead', 'domain', and 'session' completely undefined in both schema and description, making it difficult to correctly populate required fields.

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?

States a specific verb+resource: 'Record a mistake/temptation to avoid repeating, and the correct approach.' This clearly distinguishes it from the sibling note() tool by focusing on anti-patterns. However, it doesn't explicitly contrast the distinction with other memory types in the first sentence.

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?

Implies usage context ('to avoid repeating') and mentions related tools (pulse, pending, note) without explicitly stating when to use anti_pattern vs note or other memory types. The reference to 'see note()' suggests differences but doesn't fully clarify selection criteria.

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

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

No annotations are provided, so the description carries the burden. It discloses storage type ('type=checkpoint'), the cost model (every session pays for what's parked here), and how it's retrieved by pulse(). It does not detail permissions or deletion behavior.

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 front-loaded with the core purpose, but grows long with detailed guidance on title, also, and tags. While each section is purposeful, it borders on verbose and mixes tool description with field-level instruction that could be in the schema.

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?

Given no annotations, no output schema, and 9 parameters with 0% schema coverage, the description provides critical context on usage, storage, and retrieval. It is nearly complete for an agent to invoke correctly, though it could say more about the impact of session or domain fields.

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 0% for 9 parameters, so the description compensates substantially: it documents the purpose of title, also, and tags, and lists the intent/established/pursuing/open_questions fields. Uncovered parameters like domain, session, and the required core fields lack detailed semantics beyond naming.

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 states a specific action and resource: 'Snapshot current working state' with parenthetical fields. It distinguishes from siblings via explicit references to pulse(), note(), and link_memories(), but does not directly name why this differs from handoff or reasoning.

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?

Provides clear routing guidance: use checkpoint for bearing, put timeless detail into note(), cite facts by [[uid]], and understand it's read via pulse(). It does not provide explicit when-not-to-use versus handoff, but strong context relative to its primary consumer.

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

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

With no annotations, the description carries the behavioral load and does so well: it discloses the matching method, that each pair is tagged with its `method`, that same-domain/session checkpoint pairs are excluded, and that checkpoint pairs rank below durable pairs. It explicitly clarifies this is not an automatic merge, which is the key safety-relevant behavior. It stops short of describing scoring/threshold effects or result volume.

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 content is front-loaded: what it surfaces, then what it excludes, then what it is not. Sentences are dense but each carries distinct information. There is mild redundancy in the closing paragraph, but no filler.

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?

An output schema exists, so return values need not be explained, and the description covers the non-obvious essentials: exclusions, ranking, non-mutating behavior, and next steps. The remaining gap is the un-documented tunable parameters (threshold/limit/type), which an agent needs in order to call it well.

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 0% for four parameters, so the description must carry parameter meaning and only partly does. It explains `domain` well (scans a path and everything nested under it, with a rationale for why that is usually desired), but `type`, `limit`, and `threshold` (the key similarity cutoff at 0.6) are left entirely undefined.

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 states a specific verb+resource (surface likely-duplicate/contradictory memory pairs) and immediately narrows the mechanism (lexical overlap over near-identical text). It differentiates itself from what an agent might reach for instead by declaring that paraphrased takes on one subject do not surface here, which separates it from semantic search/recall siblings.

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 a clear when-it-fires / when-it-does-not condition (lexical overlap only; different-words pairs excluded) and routes the agent to the right follow-ups (link_memories / edit_memory / forget). It does not explicitly compare against sibling scan tools like optimize_scan or get_relations, so the alternative-selection guidance is implied rather than complete.

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

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

With no annotations, the description carries the full burden and delivers: validation constraints (exactly one 'start', all nodes reachable, cycles allowed), atomicity ('nothing written at all' on error), server-side position computation, and the cross-linking semantics of 'also'. This is unusually rich behavioral disclosure for a mutation tool.

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?

Front-loads purpose before the schema examples, and each block (nodes/edges, key rules, also semantics) earns its place for a complex tool. Some sentences lean editorial ('one more wall of prose', 'not a mistake'), which adds length without operational value.

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 11-parameter tool with no output schema and no annotations, the description covers validation, return shape ({uid} vs {ok:False,errors}), and the linking model well. It falls short only on the auxiliary metadata params (kind, tags, session, summary) that an agent still has to guess at.

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, and it does substantial work: node fields (key/label/shape/note), the key character rules, the shape enum (start|step|decision|io|end), edge from/to/label, and the meaning of 'also', 'domain', 'review_after' and 'source_ref'. However 'kind', 'tags', 'session', 'summary' and 'title' remain entirely undocumented, so it does not fully close the gap.

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?

States a specific verb and resource ('Document what a routine does, start to end, as a graph') and pins the storage type ('type=\'diagram\''). It explicitly distinguishes itself from siblings note() and checkpoint(), so an agent can select it without opening any schema.

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?

Gives an explicit when-to-use rule: 'For a PROCESS, not a fact: note() records what is true, checkpoint() where the work stands, this one how a routine runs.' It names the alternatives and the discriminating condition, leaving nothing to inference.

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

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

With no annotations, the description carries the full behavioral burden and does add non-obvious value: it discloses upsert/idempotent semantics ('calling again with the same endpoints updates the label instead of adding a second edge'), which is exactly the kind of trait an agent needs. It does not cover permissions, error behavior, or the return shape.

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 tight and front-loaded: the primary action comes first, followed by the label semantics and the idempotency note. Every sentence earns its place with no redundancy.

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 mutation tool with no annotations, no output schema, and 0% schema coverage across five parameters, the definition covers the core workflow and idempotency but omits 'uid', endpoint semantics, and any error/return context. It is adequate but leaves real gaps for an agent invoking 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 0%, so the description must compensate. It explains 'label' well (condition on a decision branch, with examples) and implicitly covers from/to via 'two steps' and delete via 'remove it', but 'uid' is never mentioned and endpoints are not named explicitly, leaving part of the 5-parameter surface undocumented.

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 names specific verbs and resource: wire two diagram steps together, relabel the wire, or remove it. It clearly frames this as an edge-mutation tool. However, it does not differentiate itself from the sibling 'diagram_link', which an agent might plausibly confuse with 'diagram_edge'.

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?

Usage is implied by the three operations listed (wire, relabel, remove), and the 'calling again with the same endpoints' note hints at repeated invocation. But there is no explicit when-to-use vs alternatives guidance (e.g. vs diagram_link or diagram_node), and no prerequisites are stated.

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

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

With no annotations, the description carries the full burden and does disclose non-obvious behavior: the jump is 'stored once and read from both ends,' the reverse edge already exists, get_diagram reports it on both diagrams, and a jump can be deleted from the receiving end. It stops short of describing permissions, side-effect profile for the delete flag, or reversibility guarantees.

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?

Purpose is front-loaded in the first sentence, and the sibling-contrast and behavioral notes are ordered usefully. Slightly verbose with inline code formatting and parenthetical asides, but no sentence is purely filler.

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 six-parameter mutation-style operation with no annotations and no output schema, the description covers purpose, usage, and some behavior, but leaves label and peer_uid semantics and the delete flag's exact effect under-specified, so an agent still has gaps before invoking 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 0%, so the description must compensate and only partly does: it clarifies that leaving peer_node empty targets the whole diagram and that uid/node_key denote 'this diagram's side,' plus implicit delete semantics. It never explains label or peer_uid, leaving several of the six parameters undocumented.

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?

States a specific verb and resource ('Continue one step of a flow into ANOTHER flow') and immediately differentiates itself from the sibling diagram_link by contrasting what each one represents. An agent can distinguish the two without opening either schema.

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?

Names the alternative (diagram_link) with an explicit contrast of meaning, and gives concrete when-to-use cases: a sub-process hand-off, an error path owned by another flow, or a variant of the same job. Nothing is left to inference about routing between the two link tools.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does add the useful reciprocal-visibility fact (get_memory on the linked memory reports referencing diagrams), but it never explains what the `delete` flag does, whether re-linking the same node_key overwrites or duplicates, or what permissions are required for this mutation.

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?

Purpose is front-loaded in the first line, but the middle paragraph ('What turns a diagram into an index of its domain...') is abstract rationale rather than operational information and dilutes an otherwise compact description. It is not bloated, but it spends words on philosophy instead of on the undocumented delete/relation_type parameters.

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?

With no annotations, no output schema, and 0% schema description coverage, the description is the only source of behavioral truth, and it leaves the destructive `delete` flag, the relation_type vocabulary, and overwrite/permission behavior unaddressed. It covers the conceptual model well but not enough for an agent to call a 5-parameter mutation tool safely.

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 0% across 5 parameters, and the description supplies no parameter-level detail beyond an implicit mapping of 'step' to node_key and 'another memory' to target_uid. `delete` (a destructive toggle) and `relation_type` (with its 'explains' default) are completely undocumented anywhere the agent can see.

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?

States a specific verb+resource: 'Attach another memory to one specific step of a diagram.' The second sentence clarifies the granularity (per-step, not per-diagram) and explicitly routes whole-diagram links to the sibling link_memories(), so an agent can distinguish it from that tool without reading either schema.

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 names the alternative ('for an edge to the diagram as a whole use link_memories() instead') and the condition that selects it, which is exactly the kind of routing guidance agents need. It stops short of any prerequisites, ordering constraints, or guidance on when NOT to link a given memory.

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

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

With no annotations, the description carries the full burden and discloses important behavior: only passed arguments are touched, note="" clears a note, delete=True removes the step plus its edges and memory links, and unattached steps are allowed. It does not cover error conditions or whether deletion is reversible, but the mutation semantics are well described.

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?

Front-loads the core action, then efficiently layers in patch semantics, delete behavior, and the intentional relaxation of whole-graph rules. No wasted sentences.

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?

Given no annotations, no output schema, and 0% schema description coverage, the description covers purpose and key mutation behaviors but is incomplete for a 6-parameter tool. It omits meaning for most parameters and does not address error or return behavior.

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% across 6 parameters, so the description must compensate. It clarifies 'note' and 'delete' semantics but leaves 'key', 'uid', 'label', and 'shape' unexplained, leaving the agent without definitions for most parameters.

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?

States a specific verb set (add, patch, remove) and resource (one step of a diagram), and distinguishes itself from diagram() by noting that whole-graph rules are relaxed here while diagram() enforces them. The edge mention also implicitly separates it from diagram_edge.

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?

Explains that whole-graph rules are intentionally relaxed so a flow can be built across multiple calls, and contrasts with diagram() which enforces them. However, it does not explicitly state when to use this versus diagram_edge or when not to use this tool.

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

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

With no annotations, the description carries the full burden and does well: it discloses that manual adjustments are discarded, that positions live in the shared store (so all readers see the same picture), and that a layered arrangement is rebuilt. It omits whether the operation is reversible, what permissions are needed, or what the response returns.

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 action is front-loaded in the first sentence, followed by supporting rationale about storage and consequence. Three sentences with little waste, though the middle sentence about store-vs-viewer could be tightened.

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 single-parameter mutation with no output schema and no annotations, the description conveys the key effect (destroys manual positions, rebuilds layout) and the shared-store semantics. The only real gap is that what 'uid' refers to is left to inference.

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 0% and the sole parameter 'uid' is undocumented in both schema and description. The phrase 'a diagram's' weakly implies uid identifies the target diagram, but the description does not compensate for the coverage gap.

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 states a specific verb and resource: 'Recompute a diagram's stored node positions from scratch.' An agent immediately knows this rewrites layout data rather than editing nodes or edges. It does not, however, name or contrast itself with any sibling (diagram_node, diagram_edge, get_diagram), so it stops short of full differentiation.

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 a clear use case -- 'the fix for a diagram dragged into a mess' -- which tells the agent when this tool is appropriate. There is no explicit when-not guidance or named alternative, but the trigger condition is concrete enough for selection.

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

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

With no annotations provided, the description carries the full burden and delivers: previous versions are preserved, source_ref/tags/title are each settable alone, empty strings leave stored values untouched (clearing is a dashboard edit), passing neither new_content nor source_ref is an error rather than a no-op, title is capped at 120 chars, tags are indexed, and diagram/task content rewrites are refused because they would be silently overwritten. This is unusually rich behavioral disclosure.

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 purpose is front-loaded and each paragraph maps to a parameter or refusal case, so the length is largely earned by 7 params at 0% schema coverage. It does repeat stock phrases ('Settable on its own' three times, 'a dashboard edit' twice) that could be consolidated, adding mild redundancy.

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 7-parameter mutation tool with no annotations and no output schema, the description covers every meaningful parameter, the append-vs-replace decision, empty-string and error semantics, and the refusal cases for generated content. Nothing an agent needs in order 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 0%, so the description must compensate fully, and it does: it gives meaning to mode ('append' vs replace), new_content, source_ref (the field note() writes and later passes check against, plus empty-string semantics), title (what a list shows, search weight, 120-char cap), tags (comma-separated, REPLACES the set, indexed, empty leaves alone), and note (the write-time reference field). Only uid is left undescribed, which is acceptable as the identity key.

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 opening sentence names a specific verb (correct) and resource (a memory's content or source reference) and adds the defining trait that distinguishes it from delete-only siblings: the previous version is kept. An agent can immediately tell this apart from forget (delete), note (create), or purge_memory without opening any schema.

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 explicit when-to-use guidance per mode ('append' when a memory gains a fact rather than being wrong), names the alternative approach it replaces (read, restate, resend) and why it is worse, and spells out per-field standalone usage for source_ref, title, and tags. It also names the cases where this tool must NOT be used (diagrams, tasks) and routes them to diagram_node/diagram_edge instead.

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

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

With no annotations, the description carries the full burden and does well: it discloses soft-delete semantics (content kept, excluded from default search/list), records a reason as an audit entry without mutating content, and notes the side effect that archiving an open task cancels it. It omits whether archiving is reversible and any permission/auth requirements.

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?

Three tight sentences with the parenthetical clarification front-loaded right after the verb. No filler; every clause conveys a distinct behavioral fact.

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 soft-delete mutation with no annotations and no output schema, the description covers the core behavior and one side effect. However it leaves reversibility, the meaning of `superseded_by`, and usage routing to siblings unaddressed, so it is only minimally complete.

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% across 3 parameters, so the description must compensate. It explains `reason` (recorded as a status-change audit entry, without touching content) but says nothing about `uid` or the cryptic `superseded_by`, leaving the most ambiguous parameter entirely undefined.

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 gives a specific verb+resource and immediately clarifies the non-obvious name 'forget' as 'Archive a memory (soft delete)'. It distinguishes soft-delete semantics from a hard delete by noting content is kept. It stops short of naming the actual sibling alternative (purge_memory) explicitly.

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 describes what happens when the tool runs but never states when to choose it over alternatives like purge_memory, edit_memory, or set_confidence. There are no prerequisites or exclusions given, leaving the agent to infer selection from the behavior alone.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that both SVG formats write markup to a file and return only a path plus a thin index ('the payload is deliberately too small to draw from'), that mermaid DISCARDS the user's arrangement, and that `next_step` tells the caller what to do with the path. That is exactly the kind of non-obvious behavioral context annotations would otherwise provide.

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 key routing rule (which format for show vs. reasoning) is front-loaded in the first sentence, and the rest is organized as a compact format inventory followed by return behavior. Slightly verbose with parentheticals, but every sentence carries information.

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 2-param, no-output-schema, no-annotation read tool, the description covers format semantics, the actual return shape (file path + thin index + next_step), and defers detail to help(command='get_diagram'). Only the meaning of `uid` is left unaddressed.

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% and there are no enums, so the description must define the format values — which it does thoroughly, including round-trippability and side effects per value. The `uid` parameter receives no explanation at all, leaving one of two params undocumented.

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 opening 'Read a diagram back' gives a specific verb (read) plus resource (diagram), and the format list immediately differentiates this from write-oriented siblings like diagram_node, diagram_edge, and diagram_relayout. An agent can tell what it retrieves and in what shapes without opening anything else.

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?

Guidance is explicit per format: 'svg-interactive' is 'the one to SHOW', 'json' is 'the one to reason over', 'mermaid' is portable but re-lays out, 'text' is the prose projection. It stops short of naming when to prefer a sibling (e.g. `diagram` or `diagram_jump`) instead of calling this tool.

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

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

With no annotations, the description carries the full burden and does so: it enumerates the returned mode values, explains what each mode means, and discloses a non-obvious behavioral rule — that a non-conforming domain is adjusted rather than rejected and the writer's result carries a domain_adjusted note. That is exactly the kind of cross-tool consequence an agent cannot infer elsewhere.

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?

Three tight sentences: purpose first, return shape second, write-time consequence third, then the usage cue. Every sentence adds information; none restates the name or schema.

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?

No parameters, no output schema, and the description fills that gap by specifying the return payload and the semantics of each value, plus how it interacts with writes. Nothing needed to call this 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond the schema. Baseline for a 0-param tool 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?

States a specific verb and resource: 'Report the store's domain-casing policy.' It is immediately distinguishable from the sibling set_domain_case, which mutates rather than reads. An agent can classify the tool without opening anything else.

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?

Gives explicit usage context: 'Read this before coining a new domain so its casing matches what will be stored.' That is a clear when-to-use trigger, though it never names the counterpart set_domain_case or states when not to call it.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it does disclose substantial conditional behavior: a diagram returns mermaid source, per-node links and jumps, while other memories return referenced_by_diagrams, and tasks return a task block with goal, state, items and comments. That return-shape variance by memory type is genuinely useful context an agent cannot get elsewhere. It omits operational traits such as whether the call is read-only, permission requirements, and what happens when the uid is unknown.

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 summary sentence is front-loaded and the per-type detail follows in a logical order. The middle sentence is dense and slightly awkward ('the flows that point a step at it'), but every clause conveys distinct return-shape information rather than padding. Well sized for the amount of conditional behavior being described.

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?

With no output schema, the description must describe returns, and it does so thoroughly across the diagram, generic-memory, and task cases. The remaining gaps — uid semantics, not-found behavior, and read-only/permission expectations with no annotations present — are the main things an agent would still be guessing at.

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?

There is a single required parameter, uid, and the schema provides 0% description coverage for it. The description never explains what a uid is, its format, or where an agent obtains one (e.g., from search or list_recent results). The only implicit signal is that it identifies 'a single memory,' which is thin for the one input the tool requires.

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 opening sentence gives a specific verb and resource — 'Fetch a single memory's full record' — which cleanly separates it from bulk siblings like search, list_by_domain, and list_recent. It also enumerates what 'full record' contains (edit history, relations), so the agent knows the depth of the fetch. It stops short of naming a specific alternative sibling to disambiguate against, which keeps it from a 5.

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?

Usage is implied rather than stated: the agent can infer 'call this when you already have a uid and need the complete record,' and the 'without a second lookup' phrasing hints at avoiding follow-up calls. There is no explicit when-to-use/when-not guidance and no routing to alternatives such as search or get_relations for partial lookups. Adequate but leaves the agent to infer the decision boundary.

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

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It accurately states that the tool lists both incoming and outgoing relations, implying a read-only operation. However, it omits potential details like pagination or ordering, but for a simple list tool this is adequate.

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 a single sentence of 8 words with no filler or redundancy. It is front-loaded with the action and resource, making it easy to parse quickly.

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?

Given the tool's simplicity (one parameter), and the existence of an output schema documenting return values, the description sufficiently covers its purpose. It clearly states what is listed (incoming and outgoing relations) and for which memory, meeting completeness needs.

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 0%, so the description must compensate. It indicates that 'uid' is the unique identifier of a memory, adding basic context. However, it does not specify the expected format of the UID (e.g., UUID or string pattern), leaving some ambiguity.

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 uses a specific verb 'list' and specifies the resource 'relations (incoming and outgoing) for a memory'. It clearly distinguishes from siblings like 'get_memory' (gets a single memory) and 'link_memories' (creates relations).

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 states it lists all relations for a memory, but provides no guidance on when to use it over alternatives like 'search' or 'list_by_domain'. No explicit when-not-to-use or prerequisites are mentioned.

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

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

With no annotations, the description carries the burden and does well: it discloses that the no-arg mode also reports which tools this process did not load (MEMAI_TOOLS), and explains the docstring-vs-schema tradeoff. It doesn't state auth or rate-limit behavior, but for a read-only help tool that gap is minor.

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?

Front-loaded with the core purpose, then the two modes. Mostly earning its place, though the parenthetical about schema cost being 'paid for on every request' is a bit of editorializing that could be trimmed without losing meaning.

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 single-optional-param help tool with no output schema and no annotations, the description covers both invocation modes and what each returns, which is what an agent needs to call it correctly. It stops short of describing the exact docstring format, but that is not essential to invocation.

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% (the 'command' param has no schema description), so the description must compensate. It does: command='<name>' selects a specific tool's signature and full documentation, versus an empty/omitted value returning the full list. The syntax format is given, though the exact accepted name set is not enumerated.

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?

States a specific verb and resource: 'Explain the memai tools, read directly from their code docstrings.' It is unmistakably the meta/help tool and cannot be confused with any sibling like search or recall.

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 explicitly branches usage by input: 'Without arguments' returns the full tool list, and 'With command=<name>' returns that tool's signature and full docs. The conditions that select each mode are named directly, leaving nothing to inference.

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

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

With no annotations, the description carries the full behavior burden and does well: it discloses validation rules (unknown uid, self-edge, duplicate edge with same relation_type) and the exact failure shape {"ok": False, "errors": [...]}. It does not mention permissions, transactionality, or whether an edge is reversible/deletable, so a small gap remains.

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 core action is front-loaded in one sentence, followed by the relation_type convention and the error contract. The 'what splitting a body into several memories costs' passage is motivational rather than operational, but it earns its place by justifying the tool's existence.

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 4-parameter mutation tool with no annotations, no output schema, and 0% schema description coverage, the description covers the error contract and relation_type but leaves the 'note' parameter and uid semantics unexplained. Usable, but not complete enough to fully compensate for the missing structured metadata.

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 and only partly does. It documents relation_type as free text with example values, and from_uid/to_uid are implied as memory uids by context, but the optional 'note' parameter is never mentioned and no uid format is specified.

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 a specific verb and resource: 'Create a queryable edge between two memories.' It also names the downstream consumer, get_relations(), which implicitly separates it from sibling graph tools like diagram_link. It stops short of explicitly contrasting with diagram_edge/diagram_link, so it is clear but not fully sibling-differentiating.

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 explains the condition that motivates the tool: a [[uid]] inside prose is only a reference, whereas an edge is what get_relations() and the graph can see. That gives clear context for when to reach for it, but there is no explicit when-not or named alternative (e.g., when to prefer diagram_link instead).

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

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

With no annotations, the description carries the full burden and does so richly: default status is 'active', closing a task archives its memory (so archived status surfaces completed/cancelled tasks), results are snippet-truncated, and get_memory(uid) is required for the full record. It also defines est_tokens semantics at both row and top level.

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?

Front-loads the core purpose and keeps every paragraph earning its place; the path-matching and return-format details are non-obvious and necessary. It is dense and fairly long, but there is little fat to cut.

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?

Despite no output schema, the description specifies the return shape ({"results": [...], "est_tokens": N}), the truncation behavior, and the escape hatch to get full records. For a filtered-list tool this is complete enough to call 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, and it does: 'domain' path matching (outermost-segment matching, subdomain inclusion, retry as a run of segments inside a path, ambiguity covering both branches), 'subtree' semantics, and 'status' values are all explained. 'type' is shown by example and 'limit' is the only parameter left unaddressed.

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 ('List memories for a domain and its subdomains, most recent first') and immediately distinguishes itself from siblings: it is a fallback to 'search' and a complement to 'list_domains()'. An agent can tell what this tool does and where it sits in the family without opening any schema.

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 frames itself as the 'Fallback when search misses' and points to list_domains() to discover paths first. It also explains the subtree=False case. It stops short of stating hard when-not-to-use conditions, but the routing context is clear and actionable.

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

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

With no annotations, the description carries the full behavioral burden and does so richly. It discloses ordering by most recent activity, implicit levels, cross-listed counts (also and subtree_also), and casing policy enforcement. For a zero-param read/list tool, this is substantial transparency.

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?

Front-loaded with the main purpose in the first sentence, then proceeds through usage and output semantics. It is long and explains return fields despite an output schema existing, so some content is verbose, but the structure is logical and the extra detail is mostly useful.

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?

Given a zero-param list tool with an output schema and no annotations, the description is complete. It covers purpose, discovery context, return-field meanings, cross-listing behavior, and the related casing-policy tool, leaving no major ambiguity for invocation.

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 tool takes zero parameters, so there is no parameter schema for the description to clarify. Baseline for zero params is 4, and the description appropriately focuses on output semantics instead.

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?

States a specific verb and resource: 'List the domain tree: every path with its counts and latest activity.' It also frames the tool as warm-up discovery for surfacing domain paths in use, which distinguishes it from guessing or searching for a domain. The core purpose is unambiguous.

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?

Gives clear usage context: warm-up discovery, reading subtree to pick a scope worth warming up, and calling get_domain_case() before coining a new domain. It does not explicitly name when-not-to-use or compare against sibling tools like list_by_domain, but the intended context is clear.

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

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

With no annotations, the description carries the full burden and does meaningful work: it explains the active-project switching semantics, that running servers follow on the next call, that write results name their landing project, and that pulse() names the read project. It omits whether the list itself is read-only or paginated, but discloses the key behavioral context.

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 first sentence is well front-loaded and states the core purpose, but the paragraph then expands into cross-tool narrative (pulse(), write results, case matching) that is tangential to a zero-argument list tool, adding length without directly serving invocation.

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 no-parameter, no-output-schema list tool, the description supplies the field names returned (`name`, `memories`, `active`) and the semantics of the active project, which is enough to call and interpret it. It stops short of stating pagination or ordering behavior.

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?

Zero parameters, so the baseline is 4. The description usefully adds case-insensitive name matching semantics that apply wherever a tool takes a project name, which is relevant context even though no parameter exists here.

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?

States a specific resource (projects in this home) and clarifies the scope that no parameter controls. It does not explicitly differentiate from the sibling list_domains, which lists a different resource type, but the resource is stated clearly.

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?

Usage is implied by describing what the tool returns and how the active project is switched (admin dashboard). There is no explicit when-to-use or when-not-to-use guidance, and no named alternatives like list_domains or move_to_project.

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

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

With no annotations, the description carries the full burden and does well: it discloses that content is snippet-truncated per result, explains that est_tokens on a result estimates the full-record cost while the top-level est_tokens is the sum, and directs the agent to get_memory for complete records. It omits ordering guarantees, pagination, and auth requirements.

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?

Front-loaded with the core purpose, then domain-resolution nuance, then return-shape details. Every sentence carries information, though the est_tokens explanation is dense enough to require careful reading.

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?

No output schema exists, but the description supplies the return shape and truncation behavior, and it addresses three of four parameters. Only the `limit` parameter remains undocumented, which is a minor gap for a list tool with zero required arguments.

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 0%, so the description must compensate. It adds real meaning for type/domain filtering and especially subtree (domain covers subdomains; subtree=False narrows to the exact path), but the `limit` parameter is never mentioned and no accepted `type` values are given.

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?

States a specific verb and resource (list the most recent active memories) with a clear scope (optionally filtered by type/domain). It references the sibling list_by_domain for domain semantics, giving partial sibling differentiation, though it never contrasts itself against search or recall.

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?

Usage is implied by the name and the 'optionally filtered' clause, and it routes the agent to get_memory(uid) for full records. However, it never states when to prefer this over search, recall, or list_by_domain, so the agent must infer the selection.

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

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

With no annotations, the description carries the full burden and delivers: the purge is irreversible short of the backup, a backup is written, conflicts (uids target already holds) stay put, and 'outside' edge artifacts (relations, diagram links/jumps, superseded_by marks, [[uid]] references) are dropped. This is precisely the destructive, lossy behavior an agent must know.

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?

Front-loaded with the core action, then parameters, then the dry_run workflow. Slightly dense with parentheticals and backticks, but every clause carries operational weight and nothing is filler.

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 5-param destructive move with no annotations and no output schema, the description is close to complete: it covers scope, loss, backup, conflicts, target discovery, and the safe dry-run-first workflow. It doesn't explicitly describe the shape of the dry_run report fields beyond naming conflicts and outside, which is a minor gap.

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 0%, so the description must compensate and does: uids is comma-separated, domain is a path whose subdomains and archived rows go too, either or both may be given, dry_run's default and meaning are spelled out, and create makes a missing target. Meaningful semantics far beyond the bare schema titles.

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?

States a specific verb+resource: carry memories from the active project into another and remove them here. It goes beyond a simple rename by describing exactly what travels and what is purged, and names the sibling list_projects() as the way to discover targets.

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?

Explicit when-to-use and a strong workflow rule: dry_run defaults to reporting-only, read the report with the user, then widen the slice or accept the loss BEFORE calling again with dry_run=False. It also explains the create flag for non-existent targets. This is genuine when/how guidance, not inference.

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

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

With no annotations, the description carries the full burden and does so richly: retrieval is by relevance not recency, title outweighs all other fields in search, tags weigh second only to the body, a [[uid]] in the body does NOT create a graph edge until link_memories() is called, redundant `also` paths are silently dropped, and review_after drives pulse()'s scope.stale and optimize_scan. These are non-obvious side effects and ranking behaviors an agent could not infer from the schema.

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?

Front-loaded with purpose, then a compact read-path line, then per-parameter blocks in schema order. Every sentence carries information, but the prose is long and occasionally discursive (e.g. the extended title rationale), which is defensible given 0% schema coverage but not maximally tight.

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 write tool with no annotations and no output schema, the description covers purpose, read paths, graph-edge semantics, and 7 of 8 parameters. Gaps remain: the `session` parameter is never explained, and the description does not state what the call returns (e.g. the echoed redundant-path behavior is mentioned but not the response 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?

Schema description coverage is 0% with 8 parameters, so the description must compensate and largely does: it explains title (120-char cap, why repeating the type is useless), content (one fact, multi-subject bodies should be split), domain vs also (lives-on vs cuts-across, ancestor dedup), tags (BM25 synonym surfacing), review_after (date or span syntax), and source_ref. Only `session` goes undocumented.

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?

States a specific verb and resource up front ('Save a general long-term memory (fact, decision, finding)') and pins the storage type ('Stored as type=note'), which is exactly what distinguishes it from the sibling type-specific savers (task, anti_pattern, reasoning). An agent can tell what this writes without opening the schema.

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?

Names the read-side alternatives explicitly (recall(), search(type='note'), pending(type='note')) and gives a conditional rule for review_after ('Leave it empty for anything that does not go stale'). It stops short of saying when to prefer a different save tool (task/anti_pattern/checkpoint) or when not to use note at all, so it is clear context rather than full routing.

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

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

Despite no annotations, the description fully discloses read-only nature, the counts, note, and safety-backup path, and the workflow division. Could be 5 but lacks explicit mention of no side effects beyond read.

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 paragraphs with front-loaded purpose and concise supplementary context. Slightly wordy but every sentence adds value; no redundancy.

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?

The description fully covers purpose, usage timing, output contents, and relationship to sibling tool, leaving no gaps for this simple list tool with no parameters.

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?

With zero parameters and 100% schema coverage, baseline is 4. The description adds value by explaining the output fields (counts, note, backup path) which enriches understanding beyond the empty schema.

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 states the verb 'List' and the resource 'optimization runs', and distinguishes itself from optimize_stage by specifying it's a read-only companion for post-staging review.

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 says 'after staging, use this to see whether the user has applied/rejected your suggestions in the admin dashboard' and clarifies that applying/rejecting stays in the dashboard, effectively guiding when and when not to use.

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

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

With no annotations, the description carries the full behavioral burden and does so heavily: it explains that the listing is slim, that pages can end early at an internal size budget, and that `truncated` signals continued paging. It explains hint semantics like due/source_ref and repeats a critical safety rule about verification before destructive proposals. Missing is the pagination/size mechanics spelled out precisely, but the safety and truncation behaviors are well disclosed.

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?

It is front-loaded with the purpose and step-1 framing, which is good, but the description is long and repetitive across paragraphs, with a mid-text all-caps warning and repeated emphasis. Some sentences earn their place; others (the recalls/stats paragraph) are defensive and could be tightened.

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 7-parameter read tool with no output schema and no annotations, the description covers purpose, workflow placement, hint semantics, and a critical verification rule. However, because there is no output schema, the definition does not fully specify the returned listing shape or all parameter behaviors, and it explicitly offloads detail to the help tool. That deferral leaves the standalone definition incomplete.

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 0%, so the description must compensate. It only meaningfully explains `since` (delta scans), `full` (whole bodies), and `truncated`/offset/count paging. Parameters `type`, `domain`, `limit`, `offset`, and `include_archived` are barely or not addressed, and the description defers to help(command='optimize_scan') for the rest. This leaves several param semantics implicit.

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 states a specific verb and resource: dump the memory corpus compactly for a curation pass. It positions itself as step 1 of a named workflow and names the sibling (optimize_stage) to use next. It is distinguishable from dedup_scan and other read siblings, though the 'dump' framing is slightly informal.

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 explicit context: use as step 1 of the optimization workflow, then stage with optimize_stage. It also warns not to treat low recall counts as archiving signals. It lacks explicit when-not-to-use guidance relative to siblings like search or get_memory, but the workflow framing is unusually clear.

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

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

With no annotations, the description carries the full burden and does so richly: it discloses that nothing is applied, that the dashboard backs up before the first apply and can undo, that destructive kinds require a non-empty `verified`, that invalid suggestions are skipped and reported in `errors`, and that an over-long `note` raises and stages nothing. This is exactly the mutation/safety context an agent needs.

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?

Front-loaded with purpose and workflow position, then the suggestion contract, then failure modes. The kind enumeration is long but each entry carries unique information the schema does not, so little is wasted; density is high but 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 mutation tool with no annotations and no output schema, the description still supplies the return shape ({run_id, staged, errors}), the skip-and-report error semantics, the destructive-verification requirement, and a pointer to help(command='optimize_stage') for deeper kind documentation. Nothing an agent needs to call 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 0%, so the description must compensate and it does: it fully documents the shape of each suggestion (kind, target_uid, payload, rationale, verified), enumerates every kind with its payload fields, explains target_uid derivation for link/merge/distill, and gives `note`'s 250-character cap and raise behavior.

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?

States a specific verb and resource — staging curation suggestions for human review — and immediately positions itself as 'Step 2 of the "optimize my memories" workflow', which separates it from the scan/apply siblings. An agent knows this stages rather than applies without opening the schema.

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?

Clearly states the context (step 2 of the optimize workflow) and an explicit when-not: 'NOT applied here: the user reviews and applies or rejects each one in the admin dashboard.' It does not name the specific sibling to run first (e.g. optimize_scan), leaving sequencing to inference, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden. It declares read-only behavior and lists all returned fields (run header, suggestion details including decision status), giving good insight into what the tool provides without side effects.

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 front-loaded with the core purpose in the first sentence. The second sentence is informative but slightly verbose listing fields; could be more concise. No wasted words overall.

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?

Given one parameter and no output schema, the description is adequate. It explains what the tool returns. However, it lacks context on how run_id is obtained, error handling for invalid IDs, and doesn't mention pagination or large runs, leaving some gaps.

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 only parameter, 'run_id', has no description in the schema (0% coverage). The tool description does not explain what run_id represents or how to obtain it (e.g., from optimize_runs), leaving the agent with minimal guidance beyond the integer type.

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 states the specific verb 'inspect' and the resource 'optimization run'. It distinguishes itself from siblings like 'optimize_runs' (lists runs) and 'optimize_scan' (scans) by focusing on a single run's details.

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 indicates this tool is for inspecting a single run in detail, providing context on its scope. However, it lacks explicit when-to-use vs alternatives, such as when you would use 'optimize_scan' instead.

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

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

With no annotations, the description carries the full burden and does well: it defines 'pending' semantics, specifies output shapes for both modes, describes pagination ('next_offset' absent on last page), states limit range (1-50), and notes that invalid types produce an error. It does not explicitly state read-only nature or side effects, but the query nature is clear.

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 long, but given the absence of schema descriptions and output schema, most content is necessary. It is front-loaded with the core purpose, though the paragraph style could be more structurally organized (e.g., bullet points).

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 5 undocumented parameters, no annotations, and no output schema, the description is quite complete: it covers output formats, parameter meanings, scope rules, pagination, and error behavior. The main missing piece is explicit guidance on when to use this tool versus sibling listing tools.

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 fully. It explains every parameter: type (empty vs. with type), limit (1-50), domain (covers subdomains and cross-listing, empty means whole project), offset (pagination via next_offset), and pinned (narrows to pins, accepts checkpoint/reasoning). This is thorough and leaves no ambiguity.

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?

States a specific purpose: counting open items per category or listing headers for one category. It is clear what the tool does, but does not explicitly differentiate itself from siblings like search, list_by_domain, or list_recent.

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?

Provides follow-up guidance ('Open a header with get_memory(uid)'), but gives no guidance on when to choose this tool over alternatives such as search or list_by_domain. The agent must infer appropriate usage contexts.

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

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

With no annotations, the description carries the full burden and largely meets it: it discloses the ordering rule (created_at DESC, never similarity) and why, that the checkpoint is returned in full with relations attached, token cost via est_tokens, and that fields like stale/also appear only when non-zero. It never states auth/permission requirements or whether the call mutates anything, which is the remaining gap.

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?

Front-loaded with the one-sentence purpose and the return-shape list, then organized field by field, so it is scannable despite its length. It is verbose for a one-parameter tool and repeats constructions like 'present only when non-zero' across pinned, stale, and also, which costs it the top score.

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 must define the return payload -- and it enumerates every field (project, latest_checkpoint, pending, pinned, read_next, scope with by_type/subdomains/stale/also) and how to interpret each. Nothing an agent needs to consume the response 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 coverage is 0% and the single `domain` param is undocumented in the schema, so the description must compensate -- and it does in depth: domain warms up a path and everything under it, deep-only names are resolved to their branches with scope.paths reporting the result, and ambiguous names resolve to ALL branches.

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 concrete verb-plus-resource framing ('Session warm-up: the latest checkpoint, what is pending, and what to read next') and immediately distinguishes itself from siblings by stating a pulse 'lists no memories besides the checkpoint' while pending/get_memory/search/list_by_domain do the listing. An agent can tell exactly what this returns versus neighboring tools.

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?

Gives an explicit session-start trigger, then routes the agent onward: 'open tasks first, then pending(domain, type=...) for each other category, before acting,' with read_next codifying the sequence. It also names the alternatives and their division of labor (pending = headers, get_memory(uid) = the record, search/list_by_domain = contents).

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

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

No annotations are provided, so the description carries full burden. It discloses the destructive irreversible nature, the exact deletion scope, and the confirm_phrase requirement. However, it does not mention authorization needs or response format.

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 a few sentences long, each adding value. It is well-structured with a warning and guidelines, though slightly verbose. Every sentence earns its place.

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?

Given no output schema, no annotations, and only 2 parameters, the description is fairly complete. It covers purpose, usage, and parameter semantics. Missing information about return values or permissions, but still adequate for a simple tool.

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%, but the description adds critical meaning: it explains that confirm_phrase must exactly equal 'DELETE <uid>' and must come from the user's own message, and that uid identifies the memory. This partially compensates for the lack of schema descriptions.

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 states the tool permanently deletes a memory along with its edit history and relations, using specific verbs and resources. It distinguishes itself from the sibling 'forget' tool by highlighting irreversibility.

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 advises using 'forget' instead unless permanent removal is requested, and gives a strict guardrail for the confirm_phrase parameter, preventing the agent from constructing the confirmation string itself.

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

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

With no annotations, the description carries the full burden and does much of it: it discloses the storage type ('type=reasoning'), the retrieval mechanism ('BM25 over content and tags'), and search-ranking behavior ('a title ... outweighs every other field in search'). It omits auth/permission needs, error behavior, and any body-size limits, so it falls short of full behavioral disclosure.

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 purpose and the note() routing are front-loaded, and the required-field explanations are laid out in sequence. It is on the long side — the title paragraph in particular runs several sentences — but nearly every sentence carries field-level or retrieval information rather than filler.

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 12-parameter, 6-required mutation tool with no annotations and no output schema, the description supplies purpose, storage semantics, retrieval behavior, and field meanings. The gaps are domain and session semantics, and nothing about failure or permission behavior, but the core calling information an agent needs is present.

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 and largely does: it gives explicit semantics for all six required fields (title, hypothesis, reasoning, result, revised_belief, next_time) plus tags, and delegates also/review_after/source_ref to note(). domain and session, however, are never explained anywhere, leaving two of twelve parameters undocumented.

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?

States a specific verb and resource ('Record an analysis worth keeping: what was thought, and what it settled') and immediately distinguishes itself from the closest sibling: 'For the PROCESS, not the fact it produced -- note() takes the fact.' An agent can route between reasoning() and note() without opening either schema.

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?

Names the alternative (note()) and the condition that selects it, plus the cardinality rule ('ONE analysis per memory: a second hypothesis tested in the same session is its own reasoning()'). It also tells the agent how to retrieve these later (filter search/list_* with type='reasoning'), which is explicit when-to-use guidance.

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

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

With no annotations, the description carries the full burden and does so: it names the retrieval mechanism (BM25 scoped to type='note', relevance-ranked), the return shape ({"results": [...], "est_tokens": N}), the truncation behavior of snippets, the meaning of both the per-result and top-level est_tokens, and the domain path-resolution semantics. That is substantially more than the structured fields provide.

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?

Front-loaded with the core purpose and routing, then return format, then parameter notes. Mostly earns its length, though phrases like 'which is what you want for timeless facts/rules/decisions' are editorial filler.

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?

No output schema and no annotations, so the description must supply everything, and it covers returns, truncation, token cost, and the follow-up tool for full records. The only gap is the unexplained `limit` parameter, which is minor given the tool's simplicity.

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 gives real meaning for `domain` (scopes to a path plus everything nested, resolves bare deep segments like search()) but says nothing about `limit` (default 10) or `query` syntax, leaving two of three parameters undocumented.

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?

States a specific verb and resource ('recall long-term knowledge saved with note()') and immediately distinguishes itself from siblings search(type='note') and pending(type='note'). An agent can tell exactly what this tool is for without opening any schema.

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: use this (or search(type='note')) to bring notes back by relevance, use pending(type='note') for newest, and use get_memory(uid) when the truncated snippet isn't enough. When-to-use and alternatives are both named.

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

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

With no annotations, the description carries the entire burden and does so well: it discloses default active-only filtering, snippet truncation with a pointer to get_memory(uid), the meaning of succeeded_by/collapsed/confidence='contradicted' result annotations, that nothing boosts a type in ranking, and that a deep-end domain filter is resolved to parent branches. This is behavior an agent could not infer from the schema.

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?

Front-loaded with the one-line definition, and organized into topical paragraphs. Some of the query-construction prose is repetitive ('Twenty terms beat ten', 'common words score near zero and cost nothing') and could be tightened, but it is dense with substance rather than filler.

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?

No output schema exists, yet the description documents the return shape ('results' + est_tokens), per-result est_tokens semantics, snippet truncation, and the in-result annotations that drive follow-up actions. For a search tool with four params and type/domain filtering, nothing essential appears 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 0%, so the description is the only source, and it fully compensates: query (unbounded, more terms rank higher, ranking semantics), type (enumerated values with per-type meaning and an error condition), domain (path-prefix scoping plus deep-end path resolution), and limit (raise it to see collapsed duplicates). All four parameters gain real meaning.

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?

States a specific verb, resource and mechanism: 'Keyword search over memory content+tags+domain: FTS5 BM25.' It also distinguishes itself from the sibling recall() by naming what recall() cannot do (never surfaces a diagram). An agent can tell exactly what this tool is and how it differs.

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?

Explicit routing: use recall() for note()-stored knowledge, but use search() to reach diagrams; use type='diagram' to sweep documented flows; use domain='acme/x100' to scope to a module and its routines. It also gives clear guidance on query construction ('SPEND TERMS FREELY') and when to raise limit. When-to-use and when-to-use-something-else are both covered.

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

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

No annotations provided; description does not disclose behavioral traits such as whether the mutation is destructive, permissions required, or error handling. The tool modifies a memory, but side effects are not mentioned.

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?

Single sentence, direct and to the point, no redundant information. Efficiently conveys the core action.

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 simple mutation tool with no output schema or annotations, the description covers the basic purpose and allowed values. However, it lacks details on return value, error conditions, and behavioral context, leaving gaps.

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 0%, so description must compensate. Description lists the three confidence values, aiding understanding of the 'confidence' parameter, but does not explain the 'uid' parameter (e.g., it identifies a memory). Provides partial semantic value.

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?

Description clearly states the tool 'Set a memory's confidence' and lists the three allowed values (unverified, confirmed, contradicted). This distinguishes it from sibling tools like edit_memory or forget.

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?

No guidance on when to use this tool versus alternatives. Does not mention prerequisites (e.g., memory must exist) or scenarios where it is appropriate.

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

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

With no annotations, the description carries full burden and does so: it discloses the forward-only scope ('only governs new writes'), the separate remediation path, the collision-preview behavior of that path, and the return value. This is rich behavioral context rarely seen.

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?

Front-loaded with the verb, then modes, then the critical caveat. Slightly longer than minimal but every clause carries new information about scope or remediation.

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 one-parameter mutation tool with no annotations and no output schema, the description supplies everything an agent needs: valid values, effect semantics, scope limitation, and 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?

Schema coverage is 0% and no enum is defined in the schema, so the description must define the parameter. It does precisely: lists all three legal values and explains the effect of each, compensating fully for the schema gap.

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?

States a specific verb and resource ('Set the store's domain-casing policy') and enumerates the exact policy values. Clearly distinguishable from siblings like get_domain_case or list_domains.

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?

Explains what each mode does and, critically, the boundary condition: this only governs new writes, and existing domains require a separate admin action. It does not explicitly name a sibling alternative, but the constraint is clear.

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

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

With no annotations, the description carries the full burden and does well: it discloses storage ('type=task'), the auto-archive lifecycle ('archives itself once every item is done or dropped'), and generation of stable item keys (i1, i2) consumed by task_item(). It omits any mention of permissions, failure modes, or whether the task is visible to other sessions.

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?

Front-loaded with purpose and lifecycle, then parameter-by-parameter detail in short labeled blocks. A few asides (the repeated 'See note()', the remark about the type name not being auto-added) add length, but each carries actionable guidance rather than filler.

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 7-parameter write tool with no annotations and no output schema, the description covers the creation semantics, limits, key generation, and lifecycle well. The two gaps are the undocumented domain and session parameters, which an agent would have to guess at.

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, and it documents five of seven parameters with real semantics: title (one line, ≤120 chars), goal, items (one per line, ≤50 items of ≤300 chars, keyed i1...), also (comma-separated cross-cutting domains), and tags (synonyms not in the body, with a rationale). It leaves domain and session entirely unexplained.

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?

States a specific verb+resource and scope: 'Open a task: a goal and a checklist, kept until its items are closed.' It also names the sibling tools that operate on the created task (task_item, task_add, task_comment, pending), so an agent can distinguish it from those without opening a schema.

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 follow-up work: 'Work it with task_item(), grow it with task_add() and discuss it with task_comment(); ... pending() lists the open ones.' This tells the agent both when to use this tool and which alternatives to use for the adjacent operations.

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

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

With no annotations, the description carries the full burden and it does disclose two meaningful behaviors: items are appended rather than replacing (one per line) and a closed task reopens — an important side effect. It still omits permissions, ordering, and whether duplicate items are deduplicated, so it is partial rather than complete.

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 tight, front-loaded sentences with no filler; the primary action leads and the return value follows. Slightly terse terms like 'keys' and 'progress' go undefined, which costs a point but the structure is efficient.

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?

The description covers input format, the reopen side effect, and return values in place of a missing output schema, which is decent for a two-parameter tool. It still leaves the uid parameter and any sibling differentiation unaddressed.

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 clarifies the 'items' parameter format ('one per line,' implying a newline-separated string), which the bare schema does not, but leaves 'uid' entirely unexplained.

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?

States a specific verb+resource: 'Append items to a task,' and adds the notable qualifier that a closed task reopens. It is clear what the tool does, but it does nothing to distinguish itself from siblings like task, task_item, or task_comment.

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?

There is no when-to-use guidance or reference to alternatives. An agent choosing between task_add, task_item, and task_comment gets no routing help, only a description of mechanics once the tool is already selected.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that a comment never edits task content (purely additive), but says nothing about permissions, whether comments are editable/removable, or how they are returned.

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 short sentences, front-loaded with purpose and scoping. The second sentence carries a slightly editorial tone but still earns its place by justifying the tool's distinct value.

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 3-param mutation-free tool with no annotations and no output schema, the description covers intent and the `item` selector but omits return behavior and any constraints on comment content or targets. Adequate but with clear gaps.

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 0%, so the description must compensate. It meaningfully explains the optional `item` parameter's role as a key targeting a checklist item, but `uid` and `body` semantics are left to name inference.

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?

States a specific verb (comment) and resource (a task or one of its items), and clarifies the `item` selector. It is distinguishable from the sibling `task_item`/`task` tools, though it doesn't explicitly name them.

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?

Implies when to use it — capture rationale the checklist can't hold, like why an item is blocked or what a review said. But there is no explicit when-not guidance or named alternative, so the routing is left to inference.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the archival side effect of closing the last open item, the reopen-on-reopen behavior, and atomicity ('An unknown uid refuses the whole call, and nothing is written'). It omits permission/auth requirements and any return-shape detail beyond 'archived in the result'.

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?

Front-loaded with the core action, then a compact per-parameter glossary that maps cleanly to the schema properties. Each sentence carries information; the only mild redundancy is restating 'They apply together, or not at all' after the unknown-uid atomicity note.

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 5-parameter, unannotated, no-output-schema mutation tool the description is strong on state/comment/related semantics and side effects, but leaves the required uid parameter undefined and gives no sense of the returned payload beyond the 'archived' flag.

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 thoroughly explains item (key format, examples i3/3), state (enum-like values), comment, and related (comma-separated uids, failure semantics). But the required parameter uid is never defined anywhere, leaving a required field undocumented.

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?

States a specific verb and resource: 'Update one item of a task' and enumerates the three updatable facets (state, comment, related). An agent can tell it apart from task_add and task, though it never explicitly names or routes to the sibling task_comment, which overlaps with the comment facet.

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?

Provides a hard precondition ('Give at least one of state, comment and related') and describes the archival/reopen consequences of state transitions. However, it never states when to prefer this tool over task_comment or task_add, so selection guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full burden and mostly succeeds: neighbour selection is by time only, archived records are excluded from the neighbourhood, output is snippet-truncated with est_tokens, and lists are ordered oldest-first with the anchor excluded. It does not mention permissions, error behaviour when query matches nothing, or limits, which keeps it short of a 5.

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?

Purpose is front-loaded and the returns block earns its place given no output schema, but the prose is leisurely and repeats the anchor/neighbour distinction in several forms ("Neighbours are picked by time alone," then "domain and type narrow the NEIGHBOURHOOD, not the anchor"). Reduce without losing meaning.

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 6-parameter tool with no annotations and no output schema, the description covers the return shape (anchored_by, anchor, before, after), ordering, anchor inclusion/exclusion, filtering scope, archiving defaults, and truncation. Nothing an agent needs to call 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 0%, so the description must compensate and largely does: it defines before/after counts and ordering, the uid/query precedence, and clarifies that domain/type filter the neighbourhood rather than the anchor (including path-prefix, cross-listing, and bare-segment resolution). The `type` parameter's accepted values are never enumerated, leaving a gap.

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?

States a specific resource (the records created immediately around one anchor memory, in creation order) and explicitly separates itself from search: "not what mentions this record, but what was being written when it was." An agent can distinguish this from search/recall/list_recent without opening a schema.

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?

Names the condition that selects this tool versus search (semantic neighbours vs temporal neighbours), specifies the uid-vs-query requirement and precedence ("Give both and uid wins"), and routes to get_memory for full content. Alternatives and exclusions are explicit.

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

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

No annotations are provided, so the description carries the full burden. It discloses the exact-path matching semantics ('acme' vs 'acme/x100' are separate scopes) and the return shape, which is meaningful behavioral context. It doesn't state reversibility or permission requirements, keeping it just short of 5.

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?

Three short sentences, front-loaded with the action, then the scoping caveat, then the return shape. No filler.

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 2-param mutation with no annotations and no output schema, the description covers effect, matching semantics, scope examples, and return shape. Missing only permission/reversibility notes, which is a minor gap.

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 0%, so the description must compensate. It clarifies that 'domain' is matched on exact path and gives a concrete example distinguishing scopes, which adds real meaning beyond the bare 'uid'/'domain' schema titles.

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?

States a specific verb ('Drop') and resource ('cross-listings' / membership), and explicitly distinguishes from its inverse concept by saying it 'Does not touch where it is filed.' This separates it from move_to_project and link_memories.

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?

Clear context: removes a cross-listing without affecting primary filing. The 'Does not touch where it is filed' clause implicitly signals when-not-to-use (for moving, use move_to_project), but no sibling tool is named explicitly.

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