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

No annotations are provided, so the description carries the full behavioral disclosure burden. It only mentions the return value (handoff id), omitting side effects, persistence/visibility, permissions, error behavior, or limits for this 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?

Two tight sentences front-load the core action and target agent concept. No wasted words, though the return-value sentence is somewhat redundant given the output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Full schema coverage and an output schema mean parameters and return values are covered elsewhere. For a write tool with no annotations, however, the description leaves gaps around behavioral side effects and sibling routing, making it only minimally complete.

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

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

Schema description coverage is 100%, so each parameter is already documented. The description repeats the 'to' semantics ('agent label ... * for any agent') but adds no additional meaning beyond what the schema provides, making the baseline 3 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?

States a specific verb ('Leave a task') and resource ('handoff') with the target agent concept, so the action is clear. It distinguishes the tool from siblings like handoff_take or handoff_done only implicitly, without naming 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 for delegating work to another agent by label, which is helpful context. However, it gives no explicit when-to-use versus handoff_take, handoff_list, or handoff_done, and no exclusions or prerequisites.

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

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

With no annotations, the description carries the full behavioral burden, yet it only restates what the schema already says ('id of the handoff you took', optional note). It does not disclose whether the state change is reversible, whether it requires ownership/permission, whether it is idempotent, or what effect it has on handoff_list results. For a mutation tool with zero annotation coverage this is a real gap.

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

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

A single, front-loaded sentence that states the action, the target, and the optional input with no wasted words. Nothing is buried and nothing is redundant.

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 output schema means return values need not be described, and both parameters are covered. However, for a no-annotation mutation tool the description omits prerequisites (must have been taken), failure modes, and post-completion effects, leaving it only minimally 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 100% and both parameters ('id', 'note' with its 4 KiB limit) are documented in the schema. The description adds no syntax, format, or constraint detail beyond that, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('mark a handoff ... as done') and scopes it to 'a handoff you took', which cleanly separates it from handoff_take, handoff_create, and handoff_list. It stops short of explicitly naming those siblings, so it lands at a clear-but-undifferentiated 4.

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?

'a handoff you took' implies the precondition that handoff_take must have run first, and 'with an optional note on what you did' clarifies the typical follow-up action. There is no explicit when-not guidance, no mention of the alternative of leaving a handoff open, and no statement of what happens if the handoff was never taken.

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, so the safety profile is covered. The description adds useful behavioral context the annotations do not: the default is open handoffs, the scope is this project unless all_projects, and it covers handoffs addressed to any agent. It does not describe result shape or ordering, which is partly excused by the output 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?

Two sentences, zero filler, with the primary scope constraint front-loaded before the mine alternative. Every clause carries information the agent needs.

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 read-only list tool with a full output schema and 100% parameter coverage, the description supplies the defaults (open state, current project) that matter for correct invocation. Only result ordering/pagination behavior is unstated, a minor gap given the 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 coverage is 100%, so all three parameters are already documented in the schema, including the meaning of mine and the allowed state values. The description reinforces the mine/state defaults but adds no syntax or format detail beyond what the schema provides; baseline 3 applies.

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

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

States a specific verb (List) and resource (handoffs) with explicit scope: this project, addressed to you or any agent. It also clarifies the default filter (open) and the alternate mode (mine), so an agent can tell what it returns. It stops short of explicitly naming the mutation siblings (handoff_create/take/done) it should not be confused with, but the read verb makes that distinction self-evident.

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?

"open ones unless state says otherwise" and "mine lists the ones you created instead" imply when the tool applies and how to flip behavior, but there is no explicit when-to-use/when-not framing or reference to the sibling tools (e.g. use handoff_take to claim one). Usage is inferable rather than stated.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the exclusive-take semantics ('Only one agent can take a handoff') and the 'open' state precondition, plus that the result is the full content. It omits what happens on conflict (error vs. silent failure), whether the handoff's state changes, and any authorization requirements.

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

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

Two short sentences, zero filler, with the action and the exclusivity constraint front-loaded. Nothing needs trimming.

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 spelled out, and the single parameter is fully documented. The description covers purpose, precondition, and the key concurrency rule, leaving only edge-case behavior (already-taken, permissions) unaddressed.

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

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

One parameter with 100% schema description coverage, so the baseline is 3. The phrase 'by its id' merely restates the schema field and adds no format, sourcing, or validity detail beyond it.

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 (take) and resource (handoff), scoped by id, and clarifies the ownership scope ('addressed to you or to any agent'). It does not name or contrast with siblings such as handoff_list or handoff_done, which would have made it a 5.

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

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

Usage is implied: you need an id, presumably from handoff_list, and the handoff must be open. There is no explicit when-to-use vs. when-not guidance, no mention of alternatives, and no statement of what to do if the handoff is already taken.

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 idempotentHint=false, so the safety profile is covered. The description adds one useful piece of behavioral context — 'in full' implies untruncated retrieval, unlike a search summary — but says nothing about what happens when the id is absent or invalid, which is the main failure mode for an id lookup.

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 short sentence, front-loaded with the verb and resource, with no filler or redundancy. Every word contributes to identifying the 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?

An output schema exists, so return-value explanation is unnecessary, and the single required parameter is fully documented. The only real gap is the absence of routing guidance against memory_search, which is minor for such a simple tool.

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

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

Schema description coverage is 100% for the single 'id' parameter, so the schema already carries the parameter documentation. The description's 'by its id' merely restates it without adding format, range, or sourcing guidance, which is the baseline-3 case for a fully documented 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 gives a specific verb ('Read'), resource ('one saved note'), and scope ('in full by its id'), which distinguishes it implicitly from the sibling memory_search (query-based retrieval vs single-item retrieval). It stops short of naming the alternative, so it is clear but not fully sibling-differentiated.

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 only implied: the phrase 'by its id' signals you must already have an id, which hints that this is the follow-up to a memory_search result. There is no explicit statement of when to use this versus memory_search, nor any exclusion or prerequisite.

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, so safety is covered. The description adds that results are ranked 'best matches first' and returns ids/titles/snippets, but the latter duplicates the existing output schema; no note on result limits or empty-result 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?

Two short sentences, purpose and scope front-loaded, with zero filler 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?

With an output schema present and annotations covering the safety profile, the description needn't explain return fields; it covers purpose, scope and ranking. The only real gap is the absence of routing guidance against the sibling memory_read/write tools.

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

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

Schema description coverage is 100% with all three parameters documented, so the schema carries the load. The description's 'for this project' only loosely reinforces the all_projects default and adds no syntax or format 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?

States a specific verb (Search) and resource (notes agents have saved for this project), plus what it returns. It is clear on its own but never names the adjacent siblings memory_read/memory_write, so an agent must infer the search-vs-read distinction.

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 scope phrase 'for this project' implies when the tool applies, and the all_projects parameter implies the broader variant, but there is no explicit when-to-use, when-not, or named alternative. Usage is inferable rather than stated.

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

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

No annotations, so the description carries the full burden. It does disclose two useful behaviors: the return value (the note's id) and the supersession semantics ('pass supersedes to replace an older note'). It says nothing about permissions, durability, deduplication, or whether superseding makes the old note unreadable.

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

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

Three short sentences, front-loaded with the action and purpose, then the return value, then the one non-obvious parameter behavior. 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?

Output schema exists and the description still confirms the id return, and all four parameters are schema-documented. Adequate for a write tool, though lifecycle details (what superseding does to the old note, whether notes persist) remain unstated.

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 every parameter is already documented (body size cap, tag charset, supersedes meaning). The description only restates the supersedes intent, adding no format or constraint detail beyond the schema, so baseline 3 applies.

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

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

Specific verb+resource ('Save a note') plus the kinds of content the note holds (decision, finding, convention) and the destination (other agents on this project). It reads clearly as the write counterpart to memory_read/memory_search, but it never names a sibling to sharpen the boundary.

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

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

Gives practical when-to-use context by enumerating the note categories (decision, finding, convention) and implying a shared, cross-agent audience. It stops short of explicit alternatives or exclusions, e.g. when to prefer handoff_create or how it relates to memory_read.

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