memory_graph_review

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

With no annotations, the description carries full burden. It discloses side effects for each action: 'writes the relation edge', 'dismisses the pair', 'deletes an over-extraction artifact', 'fold a near-duplicate into its twin'. It also specifies return behavior ('per-action dict; {error} on bad input') and mentions batch triage with proposal_ids. While it does not discuss permissions or reversibility, the level of disclosure is above average for a multi-action 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?

The description is appropriately sized for a tool with 10 distinct actions. It front-loads the purpose in one sentence, then uses a clean bulleted list to enumerate actions, each on a single line with clear wording. The 'Returns' line at the end is concise. No filler or repetition; every sentence earns its place, making it easy to scan.

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 complexity (10 actions, 9 parameters) and the presence of an output schema (noted in context), the description covers the main behaviors and parameter requirements. It explains the propose format, slot pair keys, batch triage, and returns. It does not detail all edge cases or error handling, but the output schema likely covers return structures. The description is sufficient for an agent to understand what each action does and how to invoke them.

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 several parameters: 'scope' filters in list, 'proposals' format with a full object shape, 'store' with key format for slot pairs, 'proposal_ids' for batch triage, and 'relation' implied in the relate action. It does not explicitly define 'src', 'dst', 'proposal_id', or 'store' meaning beyond action context, but the action list gives enough inference. This is better than most zero-coverage tools but not exhaustive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear statement of purpose: 'Work the graph review queue — deep-dream proposals that need a verdict before they touch the graph.' It distinguishes itself from sibling tools by focusing on review/verdict actions (accept/reject/dismiss/relate) rather than creating or reading entities directly. The action list makes the resource and its scope 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?

The description makes the tool's context explicit ('review queue') and lists specific actions for different verdict types. It clearly implies that this is the tool for triaging proposals and link/slot pairs. However, it does not explicitly name alternatives or state when not to use it (e.g., for direct graph manipulation use memory_graph_relate). The lack of explicit exclusions prevents a 5, but the context is strong.

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