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

With no annotations, the description carries full burden. It discloses the permanent destructive nature ('PERMANENTLY delete'), the full scope ('ALL memory for ALL projects'), and the mandatory safety confirmation requirements (confirm=true and the exact phrase). This is thorough for a high-risk operation.

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?

A single, front-loaded sentence with no filler. It conveys the essential safety warning first, then the parameter requirements. 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?

For a destructive tool with only two parameters and no output schema, the description fully covers the necessary context: scope, permanence, and required safeguards. It allows an agent to safely invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description reinforces the parameter requirements but does not add meaning beyond the schema's own descriptions. It simply restates that confirm must be true and confirmPhrase must be 'delete everything', which is already 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 description clearly states the action ('PERMANENTLY delete') and resource ('ALL memory for ALL projects'), which distinguishes it from the sibling tool delete_project_memory that likely targets a single project. The scope is explicit and 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 implies when to use this tool (when needing to wipe all memory across projects) by highlighting 'ALL projects'. It does not explicitly name alternatives like delete_project_memory, but the scope differentiation is clear enough for an agent to infer the boundary.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains the purpose and intended content, but does not disclose side effects such as whether the handoff overwrites prior ones, whether an active session is required, or how the handoff is stored/retrieved. This leaves moderate gaps beyond what is obvious from the action itself.

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, front-loaded with the action and timing, then listing the required content. Every word earns its place; there is no redundancy or 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 tool has 10 parameters and no output schema, the description provides a solid overview of purpose and main content but omits important behavioral details such as persistence semantics, overwrite behavior, and the significance of optional parameters like sessionId or workspacePath. It is adequate but has clear gaps for a tool of this complexity.

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 only 40%, but the description compensates by naming five key fields to include (completed, remaining, known problems, changed files, next action), which maps to schema parameters. Combined with the schema's own descriptions for task, nextAction, agentId, and workspacePath, most parameters gain meaning. A few params (notes, sessionId) remain unexplained, but the description adds significant value.

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

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

The description states a specific verb ('Create'), a resource ('structured handoff'), and a clear timing ('BEFORE ending or pausing work'). It also includes the purpose ('so the next agent can continue seamlessly'), which distinguishes it from sibling tools like get_latest_handoff (read operation) or save_memory (memory storage).

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

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

The description explicitly identifies when to use the tool: 'BEFORE ending or pausing work.' It provides clear context for invocation, though it does not explicitly name alternatives or when not to use it. This fits 'clear context, no exclusions' rather than reaching a full 5.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It explicitly warns of permanence ('PERMANENTLY delete'), scope ('all stored memory'), and the safety requirement ('Requires confirm=true'), which are important for a destructive operation. It does not mention potential side effects on workspacePath or specific auth needs, but the key risks are covered.

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

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

The description is a single sentence that front-loads the destructive nature ('PERMANENTLY delete') and includes the critical requirement. There is no wasted wording.

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 destructive delete tool with two parameters, no output schema, and no annotations, the description covers the essential aspects: action, scope, permanence, and confirmation. It lacks alternatives to differentiate from clear_memory, and does not mention return value, but the core context 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?

Schema coverage is 100%, so the baseline is 3. The description does not add product-specific meaning beyond the schema; it only restates the confirm requirement. The workspacePath parameter's purpose and default are clear from the schema itself.

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 specifies the action ('PERMANENTLY delete'), the resource ('all stored memory for the current project'), and the required confirmation parameter. This distinguishes it from sibling tools like get_memory or save_memory, though it does not explicitly differentiate from clear_memory.

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 versus alternatives such as clear_memory or other deletion tools. The description only states the confirmation requirement, not the context or exclusions for using it.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the core action and statuses but omits side effects, reversibility, or what happens to the session after finishing. The description adds little beyond the schema.

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

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

The description is one sentence with no filler. The essential information (action, statuses, summary requirement) is front-loaded and concise.

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?

This is a mutation tool with no annotations and no output schema. The description is under-specified: it doesn't clarify when to use finish_session versus save_session_digest, whether finishing affects the current task, or what state the session enters. These gaps could mislead an agent.

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 50%, and the description adds the requirement for a 'short summary' and restates the status enum. It does not clarify the distinction between interrupted and abandoned, nor explain sessionId or workspacePath beyond 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 description states a specific action ('Mark a session as finished') on a clear resource (session), and enumerates valid statuses. This differentiates it from sibling tools like start_session and save_session_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?

Usage is implied: finish a session with a status and summary. However, there are no explicit when-to-use instructions, alternatives, or exclusions. The statuses provide some context but don't fully clarify when each status should be chosen.

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

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

No annotations are provided, so the description carries full burden. The verb 'Returns' implies a read-only operation, but it does not explicitly state safety, how relevance is determined, or any edge-case behavior. Adds some context about output but lacks depth.

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

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

Single sentence with no filler, front-loads the primary action, and is appropriately sized for the tool's simplicity.

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 getter with one optional parameter, the description provides a high-level summary of the return value. However, it does not specify the exact data structure (e.g., array vs object) or field details, which is a minor gap given no 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?

Schema description covers the single optional parameter workspacePath with 100% coverage, so the description need not provide parameter details. The description does not mention the parameter, and baseline 3 applies due to high schema 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?

Description uses specific verb 'Returns' and clearly identifies the resource: 'most relevant open task for the project, plus other open tasks.' This distinguishes it from sibling tools like get_project_context and get_decisions.

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 explicit guidance on when to use this tool versus alternatives. The description implies usage for retrieving the current task, but does not mention exclusions or alternative tools, leaving the agent to infer context.

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

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

No annotations are provided, so the description carries the burden. It discloses that results are sorted newest first, which is a behavioral trait, but it does not explicitly confirm read-only semantics, permissions, or output format. 'List' implies read-only, which adds some clarity, but more detail would be expected.

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?

A single sentence, front-loaded with the action and object. Every word earns its place, with no redundant or vague phrasing.

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 tool with two optional parameters and no output schema, the description adequately covers what the tool does. It implies the return of a list of decisions, though it does not describe the structure or mention the activeOnly filter (which is in the schema). Given the low complexity, this is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (both activeOnly and workspacePath are documented in the schema). The description itself adds no parameter-level detail, so it does not exceed the baseline of relying on 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 description uses a specific verb ('List'), names the resource ('recorded decisions'), and adds ordering ('newest first'). This clearly distinguishes it from write tools like record_decision and other memory tools, 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 does not provide explicit guidance on when to use this tool versus alternatives such as record_decision or get_memory. It merely says 'for the project' without mentioning exclusions or alternative scenarios. The agent is left to infer usage from context.

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

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

With no annotations, the description carries the full burden, but it only states that the tool retrieves the most recent handoff. It does not disclose whether this is read-only, how the history flag affects behavior, or what happens if no handoff exists. This is minimal 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 short sentence and is not verbose, but it essentially restates the title ('Get latest handoff' vs 'Retrieve the most recent handoff'), adding no new information and thus not fully earning 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?

For a simple tool with no output schema and no annotations, the description is underdeveloped. It does not explain the significance of the history flag, the default workspace path behavior, or how this differs from similar retrieval tools, leaving the agent with insufficient context to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and both parameters (history, workspacePath) are already described in the schema. The description adds no additional meaning about the 'project' context or how the parameters affect the result, so it meets the baseline without compensating further.

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 action ('Retrieve') and resource ('the most recent handoff'), clearly distinguishing it from sibling tools like create_handoff and get_project_context. It precisely states the tool's function without ambiguity.

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 this tool versus alternatives such as create_handoff or get_project_context. It lacks any context about scenarios, prerequisites, 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?

No annotations are provided, so the description carries the full transparency burden. It only says 'Retrieve' without confirming that the operation is read-only or non-destructive, nor does it describe behavior such as return when not found or any side effects. Adding details like 'read-only' or 'does not modify' would improve 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 sentence of 7 words, with no filler. It is front-loaded with the core action and achieves maximum 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?

Although the tool is simple, the description lacks context about return values (no output schema) and the workspacePath parameter's effect. Given multiple sibling tools, a bit more context on how this fits the workflow would improve 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?

Schema description coverage is 100%, with memoryId and workspacePath both described. The description adds no extra meaning beyond the schema, so 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?

Description clearly states the tool retrieves a single memory by its id, with a specific verb and resource. It distinguishes itself from search_memory (which likely queries) and save_memory (which writes).

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 'by id' implies usage when memoryId is known, but no explicit when-to-use or when-not-to-use guidance is given. Alternatives like search_memory are not mentioned, leaving the usage context implicit.

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

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

No annotations are present, so the description must disclose behavior itself. It communicates a read-only action via 'Returns' and adds a performance trait via 'Lighter than initialize_project_context.' Missing are edge cases like behavior when no context is stored or dependencies on workspacePath.

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, front-loaded with an action and resource, and includes a useful comparative note. Every word earns its place, with 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?

Given the tool's simplicity (one optional param, no output schema, no annotations), the description covers the key aspects: what is returned and a comparison with a sibling. It could mention what happens when no stored context exists, but overall it is appropriately complete for the complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the single optional parameter workspacePath fully described. The description adds no parameter-specific information but does not need to, as the schema already provides equal value.

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

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

The description uses a specific verb ('Returns') and identifies the exact resource ('stored compact project context') along with its fields (name, technology, current task, status, summary, last agent). It also distinguishes from a sibling tool by noting it is 'Lighter than initialize_project_context'.

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

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

Provides clear context by contrasting with initialize_project_context, implying use for a lightweight retrieval rather than full initialization. However, it does not explicitly state exclusions or how it relates to other context siblings like get_current_task or get_memory.

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

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

With no annotations provided, the description fully carries the transparency burden. It discloses several important behaviors: auto-registration, project detection via git remote/.agent-memory.json/path, returning a briefing and protocol, conditional user prompt about unfinished work, and silent background memory bookkeeping. It does not explicitly state whether the tool modifies files or if any destructive actions occur, but 'auto-registers' implies a state change, which is adequately transparent for an initialization tool.

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

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

The description is four sentences long and information-dense, with no wasted words. It is slightly longer than necessary but each sentence carries essential guidance (when to call, what it does, when to ask the user, how to handle memory commands). The critical 'call first' instruction is front-loaded, which is well-structured.

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 moderate complexity, no output schema, and no annotations, the description covers the essential context: behavior, return value (briefing + protocol), and usage pattern. It does not describe error cases or the exact structure of the briefing, but those are not strictly required for the agent to invoke the tool correctly. The description is sufficient for an agent to know when and how to call it.

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 100%, and the schema descriptions for focus, agentId, and workspacePath are already clear. The tool description itself does not add additional parameter-level meaning beyond what the schema provides. According to the rubric, this lands at the baseline score of 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 states a specific verb ('initialize'), the resource ('project context'), and the exact behavior: detect the current project, auto-register it, and return a briefing plus an AGENT PROTOCOL. It clearly distinguishes itself from sibling tools like get_project_context (which retrieves existing context) and save_memory (which stores specific memories) by positioning itself as the session-start entry point.

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 is explicit about when to use it: 'Call this FIRST, automatically, at the start of EVERY chat/session — without the user asking.' It also provides a clear exclusion: memory bookkeeping (save_memory, create_handoff, finish_session) must happen silently and never be left to the user. This leaves no ambiguity about the tool's role versus its siblings.

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

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

No annotations are provided, so the description must carry the full burden of disclosing behavioral traits. It only adds 'Decisions stay relevant for a long time', which hints at long-term persistence but omits details about overwrites, idempotency, return values, or required session/workspace context. This is minimal behavioral disclosure for a write operation.

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 with no filler. It is front-loaded with the primary action and then adds a note on long-term relevance. Every word contributes to understanding the tool's core purpose.

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 has 8 parameters, no output schema, no annotations, and multiple sibling tools, the description is too sparse. It does not explain return behavior, when to use over save_memory, or the meaning of several parameters. This makes it incomplete for an agent deciding whether and how to invoke the 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 only 38%, so the description must compensate. It explains rationale and rejected alternatives but does not address confidence, importance, agentId, sessionId, or workspacePath semantics. The required content is obvious from the tool name, but other parameters remain unclear, making the description insufficient for the low schema 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 uses the specific verb 'Record' with the resource 'important project decision', clearly distinguishing it from sibling tools like save_memory or get_decisions. It also mentions optional components (rationale, rejected alternatives), making the scope unambiguous.

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

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

The description gives clear context: record important project decisions with rationale and alternatives. It does not explicitly discuss when not to use or name alternatives like save_memory, but the purpose is distinct enough to imply appropriate usage. A score of 4 reflects the clear context without formal 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?

No annotations are provided, so the description must carry the full behavioral burden. It adds useful curation guidance but fails to disclose critical traits like whether saving is idempotent, whether it updates or creates when an id is provided, or what the side effects are. This is a significant gap for a write operation.

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 purpose and then a valuable usage/exclusion note. Every word earns its place; 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?

With no annotations and an output schema absent, the description provides a clear scope and use cases but misses behavioral details like update semantics, interaction with other memory tools (e.g., get_memory, search_memory), and lifecycle. It is adequate but has notable gaps for a tool this complex.

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 80%, so most parameters (id, type, content, etc.) are already documented. The tool description adds minimal parameter context beyond the concept of 'curated' and 'distilled' content, which aligns with the schema but does not go further. 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 clearly states 'Save a curated memory for the current project' with a specific verb and resource. It lists the categories it applies to (decisions, requirements, architecture, etc.) and explicitly excludes raw conversation text, distinguishing it from sibling memory 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 via the list of memory types and a clear exclusion ('Do NOT save raw conversation text'). However, it does not name alternative tools for specific scenarios (e.g., record_decision for decisions), so it falls just short of explicit alternative naming.

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

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

With no annotations, the description carries the burden of disclosure. It reveals that the digest is 'stored compactly (max 4000 chars)' and 'automatically injected into the next chat's briefing', which are key behavioral traits. It also instructs to call silently and to produce a narrative, but does not mention persistence details, overwrite behavior, authentication, or failure modes.

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 sentences, front-loaded with the core purpose, and every sentence provides essential information: what it does, when to call, storage behavior, and content style. 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 4-parameter tool with no output schema, the description is quite complete. It explains the purpose, timing, content requirements, storage size, and downstream use (next session briefing). Minor gaps include lack of information about return values or error handling, but these are not critical given the tool's nature.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are already documented. The description adds meaningful context beyond the schema, such as the required content ('what was discussed, decided, built, changed'), the max 4000 chars, and the instruction to write a distilled narrative rather than a raw transcript. This helps the agent construct the 'digest' parameter appropriately.

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 and resource: 'Compress and store a detailed digest of the ENTIRE current conversation'. It clearly defines the scope (from first message to now) and differentiates from siblings like save_memory or create_handoff by emphasizing the full-conversation digest and its automatic injection into the next session's briefing.

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

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

The description explicitly states when to call: 'Call this silently BEFORE ending or pausing any chat.' It also provides guidance on what to write ('Do NOT save raw transcripts — write a distilled, detailed narrative'). However, it does not explicitly mention alternatives or when not to use it vs sibling tools like save_memory.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It does state that results are ranked and scored, which is useful. However, it does not explicitly confirm that the operation is read-only and non-destructive, nor does it mention any side effects or prerequisites. For a search tool, this is a moderate but incomplete disclosure.

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

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

The description is two concise sentences, front-loaded with the main purpose. Every phrase adds value: the keyword search scope, the memory categories searched, and the ranked result output. No redundancy or 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 tool has 5 parameters, no output schema, and no annotations, the description provides a reasonable overall picture but lacks critical context. It does not mention how to refine searches (using types, minImportance, workspacePath), nor does it clarify what 'scores' represent or whether results are restricted to the current workspace. The description is adequate but incomplete for full autonomous use.

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 60% (query, types, workspacePath are described; limit and minImportance are not). The tool description adds no parameter-level detail beyond the schema, failing to compensate for the parameters lacking descriptions. The meaning of limit and minImportance is left entirely to their names, which may not be self-explanatory.

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 a specific verb ('keyword search') and defines the exact scope (memories, tasks, decisions, handoffs, session summaries, project context), distinguishing it from sibling tools like get_memory or get_decisions. The addition of 'returns ranked results with scores' clarifies the search nature.

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 is used for searching across memory types, but it does not explicitly state when to use it vs alternatives like get_memory (direct retrieval) or get_project_context. No exclusions or alternative tool mentions are provided, leaving the agent to infer usage.

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

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

With no annotations, the description carries the full burden. It communicates that a session begins and is tracked, and implies persistence until finish_session, but does not disclose side effects, idempotency, prerequisites (e.g., whether a project context must already exist), or behavior when a session is already active. Basic transparency is present, but richer details are missing.

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, front-loaded with the core action, and every word earns its place. It avoids redundancy and clearly communicates the essential purpose and usage in a compact form.

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, low-complexity tool with fully documented schema and no output schema, the description is nearly sufficient. It explains what the tool does and when to use it, though it could add a brief note on prerequisites or idempotency. Given the simplicity, this is a minor gap rather than a major omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%; all three optional parameters (agentId, agentName, workspacePath) have clear descriptions in the schema. The tool description adds no additional semantic value to the parameters, so 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 clearly states the tool's purpose with a specific verb ('Start tracking') and resource ('an agent working session for the project'). It also distinguishes itself from the sibling tool 'finish_session' by explicitly saying 'call finish_session when done', making the opposite action 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?

Provides explicit when-to-use guidance ('Call when beginning work') and names the complementary tool to use at the end ('call finish_session when done'). This gives the agent clear direction on the session lifecycle and the primary alternative.

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

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

With no annotations, the description carries the full burden. It discloses the create-vs-update behavior based on taskId presence and lists valid statuses, but does not explain update semantics (merge vs replace), error handling, permissions, or return values. This is moderate, better than a bare mutation tool but not fully transparent.

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

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

The description is short and front-loaded with the core action, but the second sentence listing statuses is redundant with the schema enum. Still, it is efficient and lacks 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 an 8-parameter mutation tool with no output schema or annotations, the description covers the basic create/update distinction but omits expected behavior such as merge semantics, return values, and permission requirements. It is adequate for selecting the tool but not fully complete for invoking it correctly with all parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 38%, and the description does not compensate. It repeats field names (title, description, priority, relatedFiles) without explaining their meaning, and the status list duplicates the schema enum. For example, it doesn't clarify the meaning of priority's numeric range or the content of relatedFiles.

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

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

The description states a specific action: 'Create a task (omit taskId) or update an existing one' and lists the updatable fields. It is unambiguous and clearly distinguishes from read-only siblings like get_current_task and memory 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 explicitly says when to use the tool (create or update) and how to differentiate via taskId. However, it does not explicitly mention alternatives or exclusions, such as using get_current_task for read-only access, so it stops short of a full usage guide.

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