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

No annotations exist, so the description carries the full load and does disclose the non-obvious behavior: omitting note auto-captures the transcript, and bookmarks are never auto-pruned (a durability guarantee). It does not state what is returned on success or how duplicate labels are handled, leaving a small gap for a mutation with zero annotation coverage.

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 identity and the resume-point framing, then requirements, then behavior, then triggers — a sensible order. It is dense but every clause carries information; only the phrasing is slightly em-dash heavy rather than wasteful.

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 two-parameter tool with no annotations and no output schema, the description covers purpose, required/optional inputs, the conditional behavior of note, durability, and when to call it. The remaining gap is return-value/error behavior, which is modest given the tool's simplicity.

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

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

Schema coverage is only 50% (label is undocumented in schema), and the description compensates by labeling it "short name" and marking it required. The most valuable addition is the note-omission semantics, which materially changes what the call does and is not fully conveyed by the schema text 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 verb and resource — "drop a named session bookmark — a resume point" — and immediately clarifies the abstract concept with a concrete gloss. It also implicitly separates itself from amp_handoff by noting bookmarks surface in the next session's handoff, so an agent can distinguish it from the sibling tools without opening any schema.

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

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

Gives concrete triggering conditions: user says "bookmark this" / "mark this point", before a risky change, or when the context window is filling up. That is clear positive guidance, but no explicit when-not or named-alternative routing (e.g. vs amp_handoff or amp_resume) is offered.

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 does not say whether generating a handoff persists anything (writes a file, mutates state) or merely returns text, nor whether the operation is idempotent, what permissions it needs, or how large the output is. For an operation named 'handoff' whose side effects matter, this is a significant 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?

Two short sentences, front-loaded with the action, with the format/default detail following. No wasted words, though the brevity edges toward under-specification rather than pure 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?

No output schema, no annotations, and no description of what the handoff document contains, where it goes, or what the agent receives back. For a tool whose entire value is the artifact it produces, the description leaves the agent unable to predict or verify the result.

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

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

Schema coverage is 0%, but the single parameter is an enum whose allowed values are visible in the schema. The description adds real value by specifying the default (markdown), which the schema does not declare. It does not explain any behavioral difference between markdown and json output beyond the surface 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?

States a specific verb and resource: 'generate the handoff document for the next AI session.' The purpose is clear and distinct from siblings like amp_resume or amp_read, though it never explicitly names or contrasts those siblings.

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

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

The phrase 'for the next AI session' implies this is called at the end of a session, giving implied usage context. However, there are no explicit when-to-use/when-not rules and no mention of alternatives such as amp_resume, leaving the agent to infer the trigger condition.

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 exist, so the description carries the full burden. 'Get' implies a read-only operation and the score range/letter grade hints at the return payload, but it says nothing about what 'health' measures, whether it requires an active session, cost, or what happens when no session exists.

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 with the resource and the return format front-loaded; no filler and nothing repeated from structured fields.

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

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

With no output schema, the description usefully discloses the return format (0-100 score, A-F grade). It is nearly complete for a zero-parameter read tool; the remaining gap is that 'session health' itself is never defined.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline for a parameterless tool is 4.

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 ('get') and a specific resource ('session health score'), and even names the return shape (0-100 plus an A-F grade). That is enough for an agent to tell it apart from siblings like amp_read, amp_search, or infernoflow_status, though it never explicitly contrasts with those 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?

There is no statement of when to call this rather than infernoflow_status or amp_read, no preconditions, and no exclusions. The agent must infer usage purely from the tool name.

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 disclosure burden. It conveys read semantics through the verb "read" but says nothing about what is returned (fields, ordering), default behavior with no filters, or the 200-entry cap enforced by the schema — real gaps for a memory-retrieval 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?

A single front-loaded sentence with no filler or repetition. It is efficient, though the brevity comes at the cost of substance rather than being paired with useful detail.

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?

Four parameters, zero schema descriptions, no annotations, and no output schema means the description is the only source of semantics — and it supplies almost none. An agent cannot confidently choose filter values or predict results from this definition.

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

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

Schema description coverage is 0% across all four parameters, so the description must compensate and does not. It never explains what "file" scopes to, whether "query" is substring or semantic matching, how "query" differs from "file", or what "limit" defaults to — the enum of seven memory types is likewise never mentioned.

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

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

The description names a specific verb (read) and resource (session memory entries), so an agent can tell it retrieves rather than mutates. However it does not distinguish this from the sibling amp_search, which by name also retrieves memory entries — the read/search boundary is left to inference.

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?

"With optional filters" implies a retrieval use case but never says when to prefer this over amp_search, amp_resume, or amp_bookmark, nor when filtering is unnecessary. No prerequisites, no exclusion 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?

With no annotations, the description carries the full burden and does well: it enumerates exactly what comes back, including uncommitted changes and memory-store identity, which the agent could not infer elsewhere. It stops short of stating read-only safety, cost, or volume limits, which matters for an unannotated tool.

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

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

Front-loaded with the core value ('where were we?' in one call), followed by the payload list, then usage timing, then the single optional parameter. No filler sentences and nothing repeated from structured fields.

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

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

For a one-optional-param, no-output-schema, no-annotation tool, the description covers purpose, timing, and payload contents sufficiently to invoke it correctly. Gaps are secondary: no indication of result size, truncation, or what happens when no resume point exists.

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

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

Schema coverage is 0%, so the description must compensate, and it does: 'file' is described as optional and as a ranking hint ('rank entries about that file first') rather than a hard filter — semantics the bare string/maxLength schema cannot convey. It doesn't specify accepted path formats or matching behavior.

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

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

The description states a specific resource and scope: it returns the latest resume point, open dead ends, recent decisions/notes, uncommitted changes, and the active memory store. The 'in one call' framing implicitly distinguishes it from granular siblings like amp_read and amp_search, though no sibling is named outright.

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?

'Call it at the start of work in a session' gives a clear triggering condition, and the dead-ends note ('don't repeat them') tells the agent how to act on the output. There is no explicit when-not or named alternative (e.g., versus amp_search for targeted lookups).

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 exist, so the description carries the full burden, yet it discloses nothing beyond 'search': not what a match covers (title, body, tags), whether results are ranked or capped, case sensitivity, or whether full entry bodies are returned. For a tool with zero annotation coverage this is a substantial 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?

Two short front-loaded sentences with no padding, and the core purpose leads. The terseness comes at the cost of substance rather than being padded, so it is efficient but slightly under-specified.

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

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

With no annotations, no output schema, and 0% schema description coverage, the description should compensate with match semantics, result limits, and the meaning of the type enum — none of which are present. The tool is simple, but what an agent needs to call it well is still missing.

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

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

Schema coverage is 0%, and the description only restates the parameter surface: 'keyword' maps to query and 'optional type filter' maps to the type enum. It adds that type is optional, but never explains what the seven enum values (gotcha, decision, attempt, note, detection, pattern, preference) mean or what text query matches against.

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 (entries) qualified by 'by keyword', so an agent knows this is a keyword lookup rather than a direct fetch. It never distinguishes itself from amp_read or amp_resume, so the sibling differentiation needed for a 5 is absent.

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 only usage hint is that the type filter is optional; there is no statement of when to search versus using amp_read/amp_resume, no prerequisite or scope conditions, and no exclusions. An agent must infer the routing decision entirely on its own.

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 adds valuable context by explaining that 'detail' is stored in a sidecar and loaded on demand without bloating the always-on memory index. However, it does not state whether entries are immutable, whether writes require confirmation, or what the response looks like.

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 tight sentences with zero waste. The core purpose is front-loaded, followed by required/optional parameters and then the most important behavioral nuance about 'detail', in a logical order.

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

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

For a six-parameter write tool with no annotations and no output schema, the description covers the core logging behavior and the sidecar storage model. It remains incomplete regarding the 'type' enum semantics, the meaning of 'file' and 'line', and any return or confirmation behavior.

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

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

Schema coverage is only 17%, so the description must compensate. It lists all parameters at a high level and gives strong semantics for 'msg' (one sentence) and 'detail' (rich multi-paragraph body stored in sidecar), but it does not explain the meaning of 'file', 'line', 'tags', or the 'type' enum values.

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: 'log a new entry'. This clearly identifies a write/logging operation, distinguishing it implicitly from read/search siblings like amp_read and amp_search. It does not explicitly differentiate itself from write-adjacent siblings such as amp_bookmark or amp_handoff.

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

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

Usage is implied by 'log a new entry' and the required/optional parameter breakdown. The description adds useful guidance on when to use 'detail' versus 'msg', but offers no explicit when-to-use conditions, exclusions, or comparison to sibling tools.

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

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

No annotations are provided, so the description carries the full disclosure burden. 'Detect' implies a read, but it never states whether this is read-only, whether revalidation mutates memory state, what the cost/scope is, or what the response looks like — all critical for a tool with zero annotation coverage.

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?

One front-loaded sentence with no wasted clauses. The trailing '— useful when...' clause is somewhat jargon-heavy but does add a usage hint rather than padding.

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

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

For a one-parameter detection tool with a well-documented schema, the definition is largely sufficient. But with no output schema, the description should hint at what 'affected capabilities' results look like, and it doesn't, leaving the return shape opaque.

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 single parameter is fully documented with type, default, and max. The description adds nothing about sinceCommits, so the baseline 3 applies — the schema does 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?

The description states a specific verb (detect) and resource (capabilities affected by recent code changes), which is more than a name restatement. However, it doesn't distinguish this from any sibling tool, and 'capabilities' is left undefined, so an agent can't fully tell what domain it operates in.

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?

'useful when memory needs branch-aware revalidation' gives an implied usage context but no explicit when-to-use/when-not, no prerequisites, and no alternatives among the siblings. The agent must infer the trigger condition from vague jargon.

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 disclosure burden. "Show" weakly implies a read-only operation, but nothing confirms it, and there is no mention of cost, auth requirements, or whether the summary is cached/live — meaningful gaps for a memory-and-health dashboard 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?

A single eight-word sentence with no filler, and the core purpose is front-loaded. It is arguably under-specified rather than bloated, but it wastes nothing.

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

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

No output schema and no annotations, so the description is the only source of information about what comes back. It never says what "at a glance" contains — memory counts, contract violations, pass/fail state — leaving the agent unable to predict the return value before calling.

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

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

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-level information 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?

Names a verb ("Show") and two resources ("project memory" and "contract health"), so the general domain is graspable. But "contract health" is unexplained jargon, and nothing distinguishes this from siblings like amp_health or infernoflow_git_drift, which sound like they surface overlapping health signals.

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 statement of when to call this versus amp_health, infernoflow_git_drift, or amp_resume. The agent is left to infer usage entirely from the tool name.

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