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

Annotations already indicate the tool is not read-only, but the description adds meaningful behavioral context: agent_name is stamped on every write for traceability, and agents are advised to use tickets/roles to avoid collisions. This goes beyond the basic annotation flags and gives the agent important operational expectations. No contradiction with annotations.

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 four short, focused sentences: purpose, multi-agent context, coordination guidance, and traceability side effect. It is front-loaded and every sentence earns its place without fluff or 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 covers the essential context: what the tool does, why it matters (collision prevention), and a critical side effect (traceability). With an output schema present and detailed nested parameter schemas, the tool is adequately specified for an agent to use it correctly. Minor gaps exist (e.g., re-joining behavior, how to leave), but these are not critical for the core registration use case.

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 context signal reports 0% schema description coverage, likely because the top-level 'params' property is a wrapper with no description. However, the nested AgentJoinInput schema does provide detailed per-field descriptions (e.g., agent_name stability, role options). The tool description itself adds minimal parameter semantics, only mentioning agent_name's traceability effect, which is not a parameter explanation. With the nested schema carrying the load, the baseline stands at 3.

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 'Register as an active agent', a specific verb+resource pair that clearly defines the tool's purpose. It distinguishes itself from sibling tools like memory_init or memory_onboard by emphasizing active registration and multi-agent coordination. The additional note about agent_name being stamped on every write further clarifies its role in traceability.

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 gives clear context—multiple agents may share a platform and ticket claims/roles should be used to prevent collisions—but it does not explicitly state when to use this tool versus alternatives or when not to use it. The usage scenario is implied rather than directly articulated, so it stops short of full 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?

The annotations provide basic safety hints (readOnlyHint=false, destructiveHint=false, etc.), but the description adds valuable behavioral context by listing what the tool reads (README, git log, directory structure, package configs) and what it seeds (project context, tech stack, history, structure, warnings). It also discloses the return type. It could have mentioned whether it overwrites existing memory, but the act of 'bootstrapping' implies creation/writing, so the score is still high.

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 compact and well-structured. It opens with a one-sentence purpose, follows with two terse lines (Reads/Seeds), gives a clear usage note, and ends with the return type. Every sentence contributes meaningful information without redundancy or fluff.

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 bootstrap tool with many parameters and an output schema, the description covers the core behavior, when to use it, and what it returns. It lacks edge-case details such as behavior when .agent-mem/ already exists, whether the scan flags are defaulted true, or failure modes. However, it is sufficiently complete for an agent to invoke the tool correctly in the primary use case.

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?

Context indicates schema description coverage is 0%, so the description must compensate. It partially does by explaining that the tool reads README/git/config/structure (which maps to the scan_* flags) and seeds project context/tech stack/history/warnings (mapping to description, tech_stack, known_warnings, etc.). However, it does not mention the required agent_name parameter or explicitly connect the 'project description' to the description parameter. It gives a high-level conceptual mapping but lacks parameter-level detail.

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 bootstraps .agent-mem/ for an existing project by auto-scanning the codebase, which is a specific verb and resource. It explicitly distinguishes itself from the sibling tool memory_init with 'Use this instead of memory_init when joining an existing project for the first time,' making the purpose 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 gives explicit when-to-use guidance: 'when joining an existing project for the first time.' It also names the alternative tool to use instead (memory_init) and explains the benefit: 'the next agent gets full context without you manually typing everything.' This 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?

The annotations already declare destructiveHint=false, idempotentHint=true and openWorldHint=false, so safety and repeat-call behavior are covered. The description adds the permission model, which is real value beyond the annotations. It still omits whether the ticket can be recovered afterward, what happens to an existing claim, and whether cancelled tickets remain visible to list_tickets.

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 the action and then the constraint, with no filler. The only knock is that brevity here leans toward under-specification rather than efficiency.

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. But for a state-mutating ticket tool with three undocumented parameters and several overlapping siblings, the definition leaves the agent without the preconditions, parameter roles, or post-cancel state needed to invoke it confidently.

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 carries the full burden for all three parameters and does not meet it. It never mentions ticket_id, agent_name (is it the caller or the target of the action?), or whether reason is optional and recorded. The agent must infer all parameter meaning from bare 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?

The description states a specific verb and resource ("Cancel a ticket"), which is clear enough on its own. However, the sibling list contains memory_terminate_ticket, memory_submit_ticket, and memory_review_ticket, and the description does nothing to distinguish cancelling from terminating or submitting. An agent has to guess which of the ticket-lifecycle siblings to pick.

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 authorization clause ("Allowed: creator, claimer, or an active main/lead/reviewer agent") is a genuine prerequisite that tells the agent whether it is eligible to call the tool. But there is no guidance on when cancelling is the right action versus terminate_ticket or submit_ticket, and no stated preconditions such as ticket state.

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?

Annotations already declare the write profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds real value beyond them: dual persistence (memory entry AND file) and an explicit rejection condition when the checkpoint path resolves outside the project — a guardrail the agent would otherwise only discover by failing.

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, each carrying distinct information (what, when, and a safety constraint), with the core action front-loaded. 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 needn't be explained, and the failure mode is covered. But for a structured, multi-field checkpoint payload with zero schema descriptions, the description leaves the agent guessing about what content to capture.

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 description says nothing about the five input fields (summary, blockers, agent_name, active_branch, remaining_tasks). For a checkpoint tool, guidance on what belongs in summary vs. remaining_tasks isn't inferable from bare titles alone.

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 action and artifact: saves a 'full state checkpoint' both as a memory entry and a standalone file. This distinguishes it somewhat from siblings like memory_write and memory_update_state, though it never names 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?

'Do every 10-15 min or before risky ops' gives an explicit cadence and trigger condition, which is unusually actionable. It stops short of naming alternatives (memory_update_state, memory_compact) or when-not-to-use cases.

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?

The description directly contradicts the idempotentHint annotation. It states that calling again on a claimed ticket advances to in_progress, meaning repeated calls have different effects, violating idempotency. No other behavioral details (e.g., error conditions, permissions) are provided.

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 concise (two sentences) and front-loaded with the action. It conveys the primary behavior and an important nuance (second call advances state) without unnecessary words or repetition.

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 having an output schema, the description is incomplete. The contradiction with idempotency is a critical gap, and the description does not clarify edge cases (e.g., what happens if the ticket is already in_progress). Missing parameter guidance also reduces completeness.

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 description provides no explanation for the parameters ticket_id and agent_name. The input schema only describes ticket_id as 'Ticket ID to claim', while agent_name has no description. With 0% schema description coverage from the tool description, the agent is left without guidance on what these parameters mean or how to format them.

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's purpose: claiming an open ticket, with a specific verb ('Claim') and resource ('ticket'). It also distinguishes itself from sibling ticket tools (create, cancel, submit, etc.) by detailing the state transition behavior. The added note about advancing to in_progress on a second call further clarifies the tool's unique role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool: claim an open ticket, and recall it on a claimed ticket to advance to in_progress, e.g., when spawning a subagent. However, it does not explicitly mention alternatives or when not to use it, so it lacks exclusionary 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?

The description discloses significant behavioral detail beyond the annotations: it splits memories into HOT/COLD, groups by session, compresses into digests, archives raw entries to archive.json, and keeps digest references. This provides rich context about side effects without contradicting the destructiveHint=false annotation.

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 purpose, uses a numbered 5-step breakdown, includes a token savings estimate, and lists environment variables. Every section contributes useful information with no filler or redundancy, making it appropriately sized for a multi-step operation.

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 the end-to-end process, archival behavior, environmental configuration, and token impact. It does not explain the relationship to memory_prepare_compaction or the auto-compaction threshold, but given the rich mechanism description and presence of an output schema, it is sufficiently 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?

The tool description does not mention force or agent_name, but the input schema provides clear descriptions for both properties ('Force compaction even if under threshold', 'Who is running the compaction'). The schema already covers parameter meaning, so the description adds no extra value; baseline 3 is appropriate.

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 'Compact old memories into compressed digests to save tokens,' a specific verb+resource+outcome statement. It clearly describes what the tool does, but it does not explicitly differentiate it from the sibling memory_prepare_compaction tool, so it falls just short of 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?

The description implies usage for saving tokens on old memories and explains the HOT/COLD split mechanism, but it never states explicit when-to-use/when-not-to-use conditions or mentions alternatives like memory_prepare_compaction. The context is useful but the guidance is mostly implied.

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?

Annotations already declare readOnlyHint and destructiveHint false. The description adds meaningful context about the env var source and that the tool returns a list of dirs and file names, which is beyond what annotations convey. No contradictions.

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 brief, front-loaded with the main verb phrase, and includes a clear Returns section. Every sentence adds value, with no redundant or filler content.

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 zero parameters, strong annotations, and a simple output type, the description fully covers the tool's behavior. It explains what the dirs are, how they are set, and what the return value is, making it self-contained.

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 has zero parameters, so the baseline is 4. The description adds no parameter-specific details (none needed) but does explain how the directories are configured via the AGENT_MEM_CONTEXT_DIRS environment variable, enriching understanding.

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

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

The description opens with a specific verb and resource: 'List all configured external context/info directories and their files.' This clearly distinguishes the tool from siblings like memory_read or memory_search, which operate on content rather than listing directory locations.

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 purpose and configuration of context dirs, implying when to use the tool (to discover available external reference material). It doesn't explicitly name alternatives, but the unique scope provides sufficient context for correct 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds useful behavioral context: searches all configured AGENT_MEM_CONTEXT_DIRS and truncates output to max_chars. It doesn't cover error handling for missing files, but the safety profile is well-covered by annotations.

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?

Exactly three short sentences. Front-loaded with the primary purpose, followed by a usage hint and return type. No redundant wording—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?

With annotations covering safety, schema covering parameters, and the description stating return type and truncation, the tool is well-documented. The only minor gap is lack of error behavior (e.g., file not found), but this is not critical given the output schema likely covers return structure.

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 reported as 0%, but the schema itself provides clear descriptions for filename ('Filename or relative path...') and max_chars ('Max characters to return'). The tool description adds no additional parameter semantics, so baseline 3 applies, with schema doing the heavy lifting.

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 verb 'Read' and specific resource 'file from external context directories'. It also differentiates from siblings like memory_read by specifying 'external context directories' and mentions using memory_context_dirs for listing, reinforcing its distinct role.

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 explicit prerequisite: 'Use memory_context_dirs to list available files first.' This clarifies when to use the tool in a workflow. However, it does not explicitly contrast with alternative tools like memory_read or memory_search, so a small deduction.

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?

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the mutation profile is covered. The description adds real context beyond that — the ticket lands as a .md file in tickets/ as an open queue item — but says nothing about what happens on duplicate titles, whether the ticket must later be claimed/submitted, or any authorization requirement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences plus three short examples: the purpose is front-loaded and the bullets are scannable. The examples partly duplicate the assigned_to property description, so there is minor redundancy, but nothing is padded.

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 inner CreateTicketInput fields (scope, forbidden, required_fields, target_url) are self-documented in the schema. Still, for a 12-field creation tool whose top-level 'params' is undocumented, the description should at least say the single params object must satisfy CreateTicketInput; that gap keeps it at merely adequate.

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 reported at 0% because the single top-level 'params' wrapper is undocumented, and the description does nothing to explain that wrapper or the CreateTicketInput structure it must contain. The assignment examples restate what the nested assigned_to property already documents (stable agent name, e.g. 'cursor-coder'), so the description adds little beyond the inner 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?

States a specific verb and resource: 'Create a ticket requesting help from another agent', with the extra qualifier that it goes into the open queue in tickets/. That is enough to distinguish it from memory_claim_ticket / memory_submit_ticket behaviorally, but the description never names those siblings or explains the queue lifecycle, so an agent still has to infer the ordering from the tool names alone.

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 three worked examples show the intended assignment routing (assigned_to a specific agent vs. None for anyone), which implies when to use the tool. However, there is no explicit statement of when to create a ticket versus memory_write, memory_handoff, or the ticket siblings, and no prerequisites or exclusions are given.

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?

Annotations already declare readOnlyHint, destructiveHint=false, and idempotentHint=true. The description reinforces this by saying 'without changing files' and adds useful context about 'project-local' scope. No contradiction found; it provides additional behavioral context beyond annotations.

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 concise sentence with no filler. It front-loads the action ('Check') and packs in scope and non-destructive intent efficiently.

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 zero parameters, a full annotation set (read-only, non-destructive, idempotent), and an output schema, the description is sufficient for basic understanding. It clearly states what it does and that it is safe, though it could clarify the meaning of 'On Board' for an agent unfamiliar with the domain.

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 has zero parameters and schema coverage is trivially 100%, so the description carries no parameter burden. Baseline for 0 parameters is 4, and no further elaboration is needed.

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 checks 'project-local On Board setup' and specifies it does so 'without changing files', giving a specific verb, resource, and constraint. It distinguishes itself from write-oriented tools like memory_init, though the term 'On Board' is somewhat opaque and not differentiated from memory_status.

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 (use it to check setup without modifying files), but no explicit alternatives or when-not-to-use guidance is provided relative to sibling tools. The description does not name any other tool or exclusion scenarios.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is clear. The description adds useful behavioral context: it is token-aware, loads hot memories at full detail and warm digests as compressed history, and has workflow modes. No contradictions with annotations.

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 concise and well-structured. It starts with the critical 'CALL THIS FIRST' instruction, then a brief explanation of what it loads, and ends with mode options. Every sentence earns its place, with no wasted words.

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 that an output schema exists, the description needn't explain returns. It adequately covers the tool's workflow modes and the need to call it first. It lacks explicit differentiation from similar sibling tools (e.g., memory_onboard), but the first-call directive and mode variety provide enough context for correct 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 description adds meaning for the `mode` parameter by explaining each value ('brief' for handoff-first, 'normal' for onboarding, 'deep' for broad context, 'handoff-only' for fast transfer). However, it does not describe `focus_area` or `include_full_history`, and the top-level schema has no description (0% coverage). The mode explanation helps but doesn't fully compensate for undocumented 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?

The description clearly states the tool's purpose: 'Token-aware briefing with workflow modes.' It specifies what it loads (hot memories + warm digests) and its role as a first-call onboarding/briefing tool. While it doesn't explicitly differentiate from sibling tools like memory_onboard or memory_bootstrap, the specific resource ('briefing') and modes make the purpose clear.

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 gives explicit when-to-use guidance with 'CALL THIS FIRST' and describes scenarios for each mode (handoff-first, default onboarding, broad context, fast task transfer). It doesn't mention exclusions or alternative tools, but the strong first-call directive and mode-specific contexts are sufficient.

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?

Annotations indicate this is a mutating operation but not destructive. The description adds that the handoff is visible to the next agent, which is useful behavioral context. However, it doesn't reveal whether the handoff overwrites previous ones or how it integrates with other memory tools, leaving some ambiguity.

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 two crisp sentences, immediately stating the tool's purpose and mandatory usage. No wasted words; front-loaded with the most critical 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?

Despite having an output schema, the description doesn't explain how to craft an effective handoff or what happens to existing handoff data. For a tool marked 'ALWAYS call', more guidance on content and side effects is needed to ensure correct usage.

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 description provides no information about the required fields (agent_name, summary, next_steps) or optional ones. The agent must infer parameter meaning from names alone, which is insufficient for a nested 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 tool facilitates a formal handoff and emphasizes its mandatory use before leaving, making its purpose obvious. It doesn't explicitly name sibling alternatives, but the 'ALWAYS call before leaving' positioning distinguishes it from general memory write 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?

The description provides explicit when-to-use guidance ('ALWAYS call before leaving') and notes that the next agent sees it first, establishing priority. It lacks explicit exclusions or alternative recommendations, 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?

The description adds the key behavioral fact that it initializes .agent-mem/ in the project root and reinforces idempotency with 'Safe to re-call'. Annotations already convey idempotentHint=true and destructiveHint=false, so the description aligns but doesn't significantly extend beyond them, lacking details like overwrite behavior or prerequisites.

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 three short sentences, front-loaded with the primary action. Each sentence adds value—purpose, when to call, and re-call safety—with no wasted words.

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 tool is simple, has an output schema, and strong annotations. The description sufficiently covers purpose and usage, and the schema covers parameters. It lacks some context about what .agent-mem is used for, but that doesn't hinder invocation, so it's nearly 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?

The description contains zero information about the required 'description' parameter or the optional 'tech_stack' parameter. With schema description coverage at 0%, the description fails to compensate, leaving parameter meaning entirely to the input schema's own field 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 uses the specific verb 'Initialize' and identifies the exact resource '.agent-mem/' in the project root. This clearly distinguishes it from sibling read/write/search tools and establishes a unique purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance with 'Call once per project' and 'Safe to re-call', covering when to call and idempotency. It does not name alternatives, but no close alternative exists for initialization, so this is adequate.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is well covered. The description adds the behavior of showing relationships but does not provide additional context such as the default exclusion of archived memories or pagination behavior, which are useful but not disclosed in the description.

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, front-loaded sentence that states the action and resource without extraneous words. It is efficient and easy to parse.

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 tool is a read-only relationship viewer with an output schema and strong annotations, so the description does not need to explain return values. However, it omits important behavioral context like the default archive exclusion and the availability of filters, which the agent must discover from the schema. This makes the description somewhat incomplete for a standalone tool summary.

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 description names the entity types (ticket, file, agent, tag) that map to filter parameters, but it does not explain parameter roles, mention the include_archive flag, or describe the limit default. With 0% schema description coverage (the description itself does not describe any parameters), the description fails to compensate, though the input schema provides detailed descriptions for each parameter.

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 the specific verb 'Show' and clearly identifies the resource: relationships across memory entries involving tickets, files, agents, and tags. This distinguishes it from sibling tools like memory_read or memory_search, which focus on content retrieval rather than relationship mapping.

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 implies the tool should be used when needing to understand interconnections between tickets, files, agents, and tags, but it does not explicitly state when to prefer this over alternatives like memory_search or memory_read, nor does it mention exclusions or typical use cases.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the default status filter behavior and the include_closed option, which are behavioral details beyond the annotations. No contradiction with annotations.

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 convey the purpose and a key usage hint. The first sentence is front-loaded with the core action. No filler or 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 list tool with good annotation coverage and an output schema, the description covers the essential behavioral details: default filtering and how to include history. It doesn't discuss pagination or ordering, but these are likely in the output schema. Overall, the description is adequate for this 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?

Though the top-level schema coverage is 0%, the nested schema provides descriptions for 'status', 'assigned_to', and 'include_closed'. The description adds meaning to 'include_closed' by explaining it is for history, and clarifies the implicit default for status. This goes beyond the schema's basic filter labels.

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 'List tickets' clearly, with a specific verb and resource. It also specifies the default scope ('open/in_progress/in_review'), which distinguishes it from other ticket operations like create or claim.

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 clear context that listing defaults to active statuses and that 'include_closed' is for historical tickets. It does not explicitly exclude alternatives like search, but the default behavior is well described.

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?

The description discloses that the tool performs 'join' and 'collision-check', which imply state mutation and potential validation failures. However, it does not specify whether it writes persistent state, what a collision entails, or any side effects beyond showing context. Since annotations are all false (readOnlyHint=false, etc.), the description carries the burden, and it provides only partial 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?

The description is a single, compact sentence that is front-loaded with the core purpose. It contains no redundant words and efficiently communicates the tool's role. Every word 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?

The description is too sparse for a tool with many optional parameters and an output schema. It does not mention the different briefing modes, the role of ticket_id, or what the output briefing contains. While the schema handles parameter details, the description should better tie the workflow together, especially given the large number of sibling 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?

The description covers 0% of the schema parameters (per context signals) and provides no insight into how parameters like mode, agent_name, or token_budget affect behavior. Although the schema itself has rich parameter descriptions, the tool description fails to add any contextual meaning or usage examples, so it does not compensate for the low coverage.

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 identifies this as a session entrypoint with specific actions: join, collision-check, and show context. It distinguishes from siblings like memory_agent_join by being a combined/compact operation, though it doesn't explicitly name alternatives. The verb 'join' and resource 'session' make the core purpose clear.

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 phrase 'session entrypoint' implies this is for starting or onboarding a session, but there is no explicit guidance on when to use this versus siblings like memory_agent_join, memory_get_briefing, or memory_init. It does not state any exclusions or alternative conditions, leaving the usage context to be inferred.

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?

Annotations declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safe read-only nature is already communicated. The description adds value by detailing that output is a string with token counts and that the intended usage is to summarize before compacting, which gives the agent a clearer picture of expected 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 somewhat lengthy due to the workflow and style guidance, but it is well-organized and front-loaded with the primary purpose. The workflow list makes it scannable, and each sentence contributes useful information, so it earns a 4 rather than a lower 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?

The description covers the return type, the full workflow, and important context about how digest content should be written (compressed English, verbatim code/paths/IDs). With no parameters and safe annotations, this is sufficient for the agent to use the tool effectively.

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 has no parameters and the input schema is empty, so there are no parameter descriptions needed. The baseline for zero-parameter tools is 4, and the description does not attempt to explain any (non-existent) 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?

The description explicitly states that the tool 'Returns cold entries grouped by agent session' and frames it as a preparation step for summarization and compaction. This distinguishes it from sibling tools like memory_compact, which performs the actual archival, by indicating this is the read step before writing a digest.

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 provides a numbered workflow: call memory_prepare_compaction, summarize, call memory_write for the digest, then call memory_compact. This makes it clear when to use this tool as the initiation of a compaction sequence, though it does not explicitly list scenarios where it should not be used.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that filtering is supported and highlights agent_name filtering, but it doesn't disclose other behavioral traits such as default limit, response format, or search vs read semantics.

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 two short sentences, front-loaded with the core purpose and a specific usage tip. Every word earns its place with 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?

Given the schema has six nested parameters and an output schema exists, the description is minimal but covers the primary read operation. However, it lacks details on filtering semantics, defaults, and how it compares to search tools, making it only moderately 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?

With schema description coverage at 0%, the description only compensates for one parameter (agent_name) and ignores the other six parameters (tag, limit, memory_type, pinned_only, since_minutes, response_format). It adds little meaning beyond what the schema already shows.

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 reads memories with filtering capability, using specific verb 'Read' and resource 'memories'. It provides a concrete use case (filter by agent_name) that distinguishes it from related tools, though it does not explicitly name alternatives.

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 implies usage by suggesting a specific scenario (trace who wrote what), but it does not explicitly say when to use this tool versus other memory tools like memory_search or memory_get_briefing. No exclusions or alternative references are given.

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?

Annotations only give generic flags (readOnly=false, destructive=false, idempotent=false); the description supplies the real state machine: file moves, attempt-scoped archive directories, spec marked 'rejected', canonical ticket reopened as 'open'. It even explains why the tool is non-idempotent (each attempt gets its own directory, no overwrite), which reconciles the idempotentHint=false with destructiveHint=false. It omits role/permission requirements and any validation of the ticket's current state.

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 outcome and the two branches, and the trailing note about per-attempt directories is non-redundant information. The layout is a bit ragged and 'then reopens the canonical ticket + index as open' plus the parenthetical could be tightened, but nothing is wasted.

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 described, and the annotations cover the safety profile. The remaining gap is the guard conditions around invocation (ticket state, reviewer role, what happens if fix_instructions is omitted on reject), which matter for a state-transition tool but are not covered.

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 reads as 0% at the top level (single nested 'params' object), so the description must carry weight. It adds some meaning by tying ticket_id to path construction and indicating that fix instructions are persisted into <ticket_id>-rejected.md, but it never explains verdict, agent_name, review_notes, or allow_self_review semantics, leaving that to the nested 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?

States a specific verb+resource ('Review a submitted ticket') and immediately enumerates the two outcomes with their destination paths (closed/ vs rejected/), which is far more than a restatement of the name. It is clearly distinct from submit_ticket/claim_ticket/cancel_ticket by the verdict-routing it performs, though it never names those siblings 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?

The approve/reject branches make the two modes of use clear and imply this runs after a submission exists, but there is no explicit 'call this when X, not when Y', no prerequisites (ticket must be in submitted state), and no pointer to alternatives such as terminate_ticket or cancel_ticket.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral detail of 'local relevance ranking', which gives some context about how results are ordered, but it does not elaborate on what 'local' means or disclose potential quirks like pagination or timeouts.

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, concise sentence with no filler words. It is appropriately sized for a simple search tool, though it could add a brief mention of alternatives without losing conciseness.

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 tool is simple, has an output schema, and annotations cover safety, so completeness is partly derived from those structured fields. However, with no parameter descriptions and no usage guidance relative to sibling tools, the description leaves meaningful gaps for an AI agent trying to decide when to use this 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 description coverage is 0%, so the description must compensate for undocumented parameters. It conveys that a query is used for searching but does not explain the 'limit' parameter or its default/maximum values. The phrase 'local relevance ranking' offers a hint at result ordering but is insufficient for fully understanding parameter semantics.

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's verb ('Search') and resource ('all memories'), with a qualifier ('local relevance ranking') that hints at its scope. It implicitly distinguishes from sibling tools like memory_search_vector and memory_search_archive by emphasizing 'all memories', but does not explicitly call out those alternatives.

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 implies this tool should be used for broad searches across all memories, but it does not provide explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, despite the presence of sibling search tools such as memory_search_vector and memory_search_archive.

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?

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, covering the safety profile. The description adds behavioral context that the archive is compacted and contains details compressed out of hot memory, implying results may be less complete. This adds value beyond annotations without contradiction.

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 two sentences long, front-loaded with the main action ('Search the cold archive') followed by a clear usage note. Every word earns its place; there is no fluff or repetition.

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 read-only search tool with one required parameter and an output schema present, the description is complete. It explains what the archive is, when to use the tool, and the safety profile is covered by annotations. No significant gaps remain.

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 input schema has 0% description coverage, and the description does not mention the query or limit parameters. It does not compensate for the missing parameter documentation. The parameter names are self-explanatory, but the description provides no additional semantics about how searching works or what limit controls.

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's function: 'Search the cold archive (compacted entries)'. It uses a specific verb (Search) and resource (cold archive), and explicitly distinguishes itself from hot memory search by mentioning 'compressed out of the hot memory'. This differentiates it from sibling tools like memory_search.

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 gives explicit usage guidance: 'Use when you need old details that were compressed out of the hot memory.' This clearly indicates when to use the tool, though it does not name alternatives directly. However, the contrast between cold archive and hot memory implies the alternative (search hot memory) sufficiently.

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?

Annotations already declare this as read-only, idempotent, and non-destructive. The description adds that the vector backend is disabled by default and that JSON remains canonical, which hints at fallback behavior but does not state what happens when disabled. This provides some context beyond annotations but lacks richness.

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 concise, with two short sentences and the core purpose front-loaded. The second sentence about JSON canonical adds a caveat but is somewhat cryptic. It is not padded, though the ambiguity slightly reduces its effectiveness.

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 sibling search tools and a disabled-by-default backend, the description should clarify when vector search is useful and what happens when disabled. It does not explain return behavior or fallback, and the ambiguous 'JSON remains canonical' leaves key operational context missing. The available output schema and annotations do not cover these 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%, and the description provides no information about the query, limit, or backend parameters. The schema itself offers only a brief description for backend, so the description fails to compensate, leaving parameter semantics almost entirely to the structural names in the 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 phrase 'vector-style search' clearly identifies a search operation on memories, and the title 'Vector-style Search Memories' reinforces the resource. However, it does not explicitly differentiate from sibling tools like memory_search or memory_search_archive, though 'vector-style' implies a specialized variant.

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 is provided on when to use this tool over the sibling memory_search or memory_search_archive. The phrases 'Optional' and 'Disabled by default' hint at availability but do not offer selection criteria or exclusions.

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?

The description adds no behavioral detail beyond the annotations, which already indicate read-only, idempotent, and non-destructive behavior. It does not mention return format, pagination, or any 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 extremely short ('Quick status dashboard'), but it is under-specified rather than appropriately concise. It is a noun fragment that lacks the details needed to understand the 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?

Given the tool's simple nature, the description is not complete enough. It leaves 'status' undefined and does not clarify what the dashboard contains, despite the presence of an output schema.

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 are zero parameters, and the schema is empty, so the description has nothing to explain. The baseline for a parameterless tool is 4, and nothing in the description detracts from that.

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 'Quick status dashboard' conveys only that the tool provides some kind of status overview, but it fails to specify what status is shown or what action the tool performs. This does not distinguish it from sibling tools like memory_get_briefing or memory_doctor, both of which could plausibly be status-related.

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 guidance on when to use this tool versus alternatives. The description gives no context about conditions, exclusions, or preferred use cases, leaving an agent to guess.

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?

The description discloses the concrete actions (creating a report in tickets/review/ and moving the ticket to review status), which is useful since annotations are all false. However, it omits the key default behavior of auto-handing off unless stay_active is true, a significant side effect.

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's a short, front-loaded description with no redundant content. Every sentence contributes to understanding the tool's function and workflow.

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 six nested parameters and no explanation of its required inputs, the description is incomplete. It doesn't mention that ticket_id, agent_name, and summary are required, nor the stay_active auto-handoff 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 description coverage is 0% per context signals, and the description makes no mention of any parameter names, meanings, or required fields. The schema itself provides some descriptions, but the tool description adds no parameter guidance.

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 'Submit completed work on a ticket for review,' which is a specific verb+resource+outcome. It also explains it creates a submission report and moves the ticket to review status, distinguishing it from sibling tools like memory_create_ticket or memory_review_ticket.

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 clearly situates when to use: after work is completed, to hand off for review by another agent. It doesn't explicitly mention when not to use or compare to alternatives, but the context is clear enough.

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?

Beyond destructiveHint=true, the description adds that this is 'forceful' and allowed 'at any stage', plus the auth constraint 'Creator or active main/reviewer only', which are useful behavioral disclosures. It does not contradict the annotations.

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 concise, front-loaded sentences with no filler. The first states purpose, the second adds the permission constraint, earning a perfect 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?

Given a destructive tool with 3 parameters and zero schema descriptions, the description is too brief; it omits the 'reason' parameter and does not clarify what 'active main/reviewer' means, relying on domain knowledge. It is minimally adequate but leaves 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 coverage is 0% and the description does not explain the 'agent_name', 'ticket_id', or 'reason' parameters. The only hint is the permission phrase which relates to 'agent_name', but it does not explicitly map parameters or clarify the 'reason' field.

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 the specific verb 'terminate' with resource 'ticket' and qualifies with 'forcefully' and 'at any stage', clearly distinguishing from the sibling 'memory_cancel_ticket'. It states exactly what the tool does.

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?

States the permission restriction 'Creator or active main/reviewer only' and implies this is for forceful termination at any stage, but does not explicitly name when to use this versus 'memory_cancel_ticket' or mention alternatives.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds behavior beyond the annotations by stating the tool makes a compaction recommendation and lists the specific token estimate categories (hot memories, digests, archive, briefing output), providing useful 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 two concise sentences, front-loaded with the main action. It avoids redundancy and every sentence provides distinct value—the second sentence details what the breakdown includes.

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 (no params), the existing output schema, and annotations covering safety, the description provides sufficient context. It mentions the categories of token estimates and the recommendation function, making the tool's purpose and output clear without needing further elaboration.

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 has zero parameters, so the description carries no parameter burden. Per the baseline for 0 params, a score of 4 is appropriate.

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 ('Show') and resource ('token usage breakdown') and adds an additional behavior ('recommend compaction if needed'). This clearly distinguishes it from sibling tools like memory_compact (which performs compaction) and memory_status (which likely provides general status).

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 implies when to use the tool (when token usage needs assessment or compaction may be needed) but does not explicitly state when to use it over alternatives like memory_status or memory_compact. No exclusions or alternative tool references are provided.

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?

Annotations already indicate non-destructive and idempotent behavior, and the description adds context by clarifying that unpinning does not delete the memory and preserves the audit record. This goes beyond the annotations by specifying what side effects (or lack thereof) occur, though it doesn't cover aspects like permissions or error handling.

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, front-loaded sentence with no filler. Every word contributes to meaning, efficiently conveying the action and its non-destructive nature.

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 the core action and its audit-preserving attribute, but lacks any parameter guidance. Given the tool's simplicity and the presence of an output schema and annotations, it is minimally adequate, yet incomplete for fully autonomous invocation without additional context.

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 for parameter explanations. However, it does not mention agent_name, memory_id, or reason at all, leaving the agent to infer their meanings from names alone. This is a significant 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 uses a specific verb 'Unpin' and resource 'memory', and clearly distinguishes itself from deletion by stating 'without deleting it, preserving the audit record.' This makes its purpose unambiguous and differentiates it from sibling tools like memory_write or memory_update_state.

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 implies usage when one wants to unpin a memory while retaining the audit record, but it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. No sibling tool is referenced, so the guidance is only implicit and thus limited.

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?

Annotations already indicate non-read-only, idempotent, and non-destructive behavior. The description adds the behavioral detail that updates are 'Stamped with agent_name', which is useful context. However, it does not explain the stamping mechanism or what happens to existing values, so it adds only partial value beyond annotations.

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 entire description is two short sentences with no filler. It front-loads the action and resource, and each word contributes meaning. This is a model of conciseness.

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?

While an output schema exists and the tool is relatively simple, the description is too sparse to be fully contextual. It lacks guidance on usage, parameter behavior, and the exact meaning of 'stamped'. The presence of many sibling memory tools also demands clearer differentiation, which is absent.

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 description provides virtually no parameter information. It mentions 'agent_name' in the context of stamping but does not clarify the roles of 'key' or 'value'. The agent is left to infer parameter semantics from names alone.

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 'Update' and identifies the resource as 'shared key-value state', making the tool's primary function clear. It adds 'Stamped with agent_name' providing extra specificity. However, it does not explicitly distinguish this from sibling tools like memory_write, which could also be used for writing state.

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 is provided about when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or exclusions. The description simply states what it does, leaving the agent without context for tool 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?

The description reveals non-obvious behaviors beyond annotations: 'Returns instantly if events piled up', 'One wake drains the whole queue', 'You never wake on your own actions', and 'cursor is stored per agent'. These are valuable and not in the readOnly/destructive hints.

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 compact, front-loaded with the purpose, and each subsequent sentence adds a distinct behavioral fact. No verbosity or repetition.

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 complexity (6 parameters) and the presence of an output schema, the description covers the core lifecycle, queue-draining behavior, and re-arming. Parameter details are left to the schema, which is appropriate.

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?

Context signals report 0% schema description coverage, and the description does not explain parameters like kinds, timeout_s, long_wait, or only_mine. It only hints at agent_name via 'per agent', so it fails to compensate for the low coverage.

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 'Park until another agent acts, then return everything pending' – a specific verb and resource. 'The listening half of On Board' clearly distinguishes it from sibling tools like memory_write or memory_create_ticket.

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 frames when to use: 'Instead of a human relaying messages, an agent blocks here until a peer creates a ticket...' and gives direct re-arm instructions: 'Re-arm by calling it again.' This is clear contextual placement.

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?

Annotations indicate a non-read-only, non-idempotent operation, but the description adds no context about side effects such as entry persistence, compaction implications, pinning behavior, or retraction linkage. The single sentence does not extend beyond the basic write action.

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, concise sentence of eight words. It is front-loaded and free of fluff, making it easy to parse, though its brevity is a double-edged sword.

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 tool has a complex schema, multiple related memory operations, and significant behavioral nuances (e.g., priority auto-pinning, retraction). The description offers almost no context about these behaviors or how they affect the agent's decision to use this tool, making it incomplete for the complexity involved.

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 description only highlights agent_name, while the required parameters memory_type, title, and content are not mentioned at all. Although the nested schema contains descriptions for these fields, the top-level parameter coverage is 0%, and the description does little to compensate by summarizing the expected input format.

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 'Write' with a clear resource 'memory entry' and adds the distinctive 'stamped with your agent_name' detail. This effectively distinguishes the tool from siblings like memory_read, memory_search, and memory_compact.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use memory_write versus alternative tools. It does not mention exclusions, prerequisites, or preferred scenarios, leaving the agent to infer usage from the tool name alone.

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