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

No annotations, so the description carries the full burden. 'Retrieve' and 'local' imply a read-only, offline operation, but it never states there are no side effects, whether results can be empty, or how much is returned. Nothing is contradicted, but a mutation-free guarantee and result-shape hint 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?

Three short sentences with the core action first, the usage trigger second, and the parameter caveat last. No filler, nothing buried.

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 75% of parameters undocumented, the definition leaves real gaps: what 'compact memory' looks like on return, whether memory must first be written via amem_remember, and what platform/sessionId do. Adequate to attempt a call with just a query, but incomplete.

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 25% across four parameters. The description touches only workspace, and its wording ('named app memory, not only git repos') largely restates the schema's own 'Named workspace (not a git repo)'. The query, platform, and sessionId parameters are unexplained in both schema and description.

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: 'Retrieve compact local amem memory for a query.' Clear what it does and the local/compact nature. It does not differentiate from the obvious write counterpart amem_remember or from amem_graph, which also retrieves memory, so an agent must infer 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?

'Use before exploring files or calling a remote LLM with a large prompt' gives a concrete invocation context and implicitly a cost-saving rationale. It stops short of naming an alternative tool or stating when not to use it (e.g., when memory is stale or empty).

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. 'Dump stored facts' strongly implies a read-only operation and the scoping to a workspace or git repo is useful, but it says nothing about result size, truncation, ordering, or what happens when workspace is omitted (it is optional).

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 with no filler: capability first, usage trigger second, sibling routing third. Front-loaded and every clause carries information.

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

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

With two optional params and no output schema, the description adequately covers what the tool does and what categories of data come back. It falls short only on behavioral detail an agent might want (default workspace behavior, response volume), which is minor for a read-only dump.

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%: 'days' is documented in the schema but 'workspace' is bare. The description compensates by stating that the workspace may be a git repo, clarifying the accepted value domain of the undocumented parameter, though it never mentions the lookback/window at all.

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 ('Dump') plus the resource ('stored facts for a workspace or git repo') and enumerates what is returned: claims, components, flows, recent activity. It also names the sibling it is not (amem_context), so an agent can distinguish it without opening a 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 an explicit trigger ('Use when asked what amem remembers about a project') and an explicit alternative with the condition that selects it ('Prefer amem_context for a ranked packet for the current question'). Both the when and the when-not are present.

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 implies a read-only informational response by saying it returns a recipe/contract, and notes consistency across MCP hosts, but it does not explicitly state that no memory is modified or describe the response shape.

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

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

The description is three short sentences with no waste. It front-loads what is returned, then when to use it, then a useful consistency note.

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 zero-parameter guidance tool with no output schema, the description is nearly complete: it says what the tool provides and when to use it. A minor gap remains around what the returned contract looks like, but the core need is covered.

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

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

The tool has zero parameters, so parameter semantics are not applicable and the baseline is 4. The description correctly does not invent parameter details.

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 that the tool returns a generic amem remember contract and explicitly frames it as guidance for choosing between amem_context and amem_remember. That distinguishes it from the sibling tools, though the word 'contract' is slightly abstract and the tool's output form is only loosely implied.

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

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

It gives a direct condition for use ('Use if you are unsure whether to read or write memory') and names the two alternative tools at the decision point. This is explicit when-to-use guidance with alternatives identified.

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 substantial work: it discloses persistence/local-only scope, the privacy isolation guarantee of `private`, the effect of supersession ('stops being served'), and the shape of the response field `possiblySupersedes`. It omits permission/auth requirements, duplicate handling, and whether a failed supersede id is rejected.

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 tightly packed sentences, front-loaded with the core action, then the privacy rule, then the supersession workflow. No filler and every clause carries actionable information.

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

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

For a 5-parameter write tool with no annotations and no output schema, the description covers the action, the privacy dimension, the supersession path, and the one response field that requires follow-up action. The unexplained `anchors` and `workspace` parameters are the remaining gap.

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 20% (just `supersedes` is documented), and the description meaningfully compensates for `kind` and `supersedes` with the private-anchor rule and the replace-an-older-fact semantics. However, `anchors`, `workspace`, and `text` receive no explanation anywhere, leaving roughly half the parameters semantically opaque.

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?

Opens with a specific verb+resource ('Store a durable local fact in amem') and immediately scopes it as local-only. It also names the sibling tool (amem_supersede) reserved for retiring memories, so an agent can distinguish the two without opening schemas.

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 three concrete selection rules: use kind/anchor `private` for personal non-work facts, pass old claim ids in `supersedes` when the fact replaces an older one, and route look-alikes surfaced in `possiblySupersedes` to amem_supersede. The alternative tool and the condition that selects it are stated explicitly.

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 must carry the behavior, and it does disclose useful details beyond the signature: items carry a kind, and workspaces have a stable slug (MCP id) that can differ from the display name — a genuine gotcha that prevents lookup errors. It stops short of stating read-only semantics, result size, or pagination, so a 4 rather than a 5.

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: purpose first, then item structure, then the usage trigger. Every sentence supplies information an agent needs (taxonomy, the slug/display-name caveat, routing cue) with no filler.

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

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

There is no output schema, so the description has to sketch the return shape, and it does name kind and the workspace slug/display-name distinction. It does not enumerate the full item fields or say whether results are paginated or ordered, which leaves a small gap for a no-annotation 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% and the single 'kind' parameter already documents all/git/workspace, so the baseline is 3. The description references the git/workspace taxonomy but adds no filtering semantics — e.g. whether 'all' is the default or how slug matching works — beyond what the schema states.

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

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

The description opens with a specific verb and resource ('List what amem is monitoring') and then defines the item taxonomy (kind git or workspace), which no sibling tool offers. The final clause scopes it to projects/workspaces/repos, so an agent can separate it from amem_status or amem_stats without inspecting another 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?

'Use when asked which projects, workspaces, or repos amem knows about' gives a clear triggering condition. It does not name a when-not case or an explicit alternative (e.g. amem_status for health vs this for inventory), so it falls short of a 5.

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

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

With no annotations, the description carries the behavioral burden and does disclose the key traits: it is 'cheap', returns only an index of names and descriptions, and is meant to precede a view call. It does not mention pagination, ordering, or auth, but for a simple read-only list tool the disclosed cost and return shape are the critical behavioral facts.

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 with zero waste. The purpose and return shape are front-loaded, followed by the recommended follow-up and the sibling distinction, all in an efficient 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?

No output schema exists, so the description must explain return values, and it does ('index of names and descriptions only'). It also covers cost and next steps. Minor gaps remain: no mention of ordering, result count, or behavior for an empty index, but these are small for a lightweight list 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 coverage is 100%, so the single optional 'query' parameter is fully described in the input schema. The description itself never mentions the query parameter or how it ranks results, so it adds no meaning beyond the schema. 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?

States a specific verb ('List') and resource ('stored skills'), defines them as 'procedures the agent learned', and specifies the return as 'an index of names and descriptions only'. It explicitly distinguishes itself from amem_skill_view (load one) and amem_context (small durable facts), so an agent can pick it without opening another 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 explicit sequencing: 'call this first, then amem_skill_view to load the one you need'. It also names an alternative for a different need ('use amem_context for small durable facts'), leaving no ambiguity about when to use this tool 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 exist, so the description bears the full burden. It usefully discloses accepted input shapes (full SKILL.md vs. description-plus-body) and the 'non-trivial' admission bar. It omits the behaviors that matter most for a write tool: what happens if `name` already exists (overwrite, error, or needs amem_supersede), whether the skill is immediately visible to amem_skill_view/list, and any size or rate limits.

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 scope, then the trigger, then the input convention. Nothing is redundant and every sentence carries distinct information.

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

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

For a four-parameter write tool with no annotations and no output schema, the description covers purpose and input shape but leaves the collision/update semantics and post-save visibility unaddressed — both of which an agent needs in order to call this correctly, especially with amem_supersede sitting among the siblings.

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, but the description genuinely adds meaning the schema does not: it explains that `content` may be either a complete SKILL.md or a markdown body to be wrapped, and that `description` plus body is an accepted alternative to a full document. That clarifies the relationship between the two nullable fields rather than restating them.

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

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

Specific verb ('Save') plus a well-qualified resource ('a non-trivial multi-step procedure ... as a reusable skill'), which cleanly separates it from amem_skill_view and amem_skill_list. It does not, however, distinguish itself from amem_remember, the sibling an agent is most likely to confuse it with when deciding whether a piece of knowledge is a 'skill' or a '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?

Gives explicit, concrete trigger conditions: 'after solving something worth repeating — a workflow, a dead end you found the way past, or a correction the user gave you.' These are actionable and better than most. It stops short of exclusions — nothing says when NOT to save (e.g. one-off facts, trivial steps) or to prefer amem_remember instead.

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. 'Load' implies a read, and the prerequisite sentence discloses ordering, but nothing is said about behavior for an unknown skill name, payload size of a 'full body', or any side effects. Adequate but not rich.

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, both load-bearing: the first defines what is fetched, the second constrains when. Front-loaded with the action and zero 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 no-output-schema read tool with fully documented params, the definition covers what is returned (full skill body or inner file) and the ordering constraint. It leaves out failure behavior and whether repeated loads are cheap, which are the only notable gaps.

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

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

Schema coverage is 100%, so all three parameters are already documented. The description adds only the relational nuance that 'file' is a supporting file inside the named skill; it adds no new guidance on 'sessionId' 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?

States a specific verb and resource with scope: 'Load the full body of one skill by name, or a supporting file inside it,' which distinguishes it from amem_skill_list and amem_skill_save. It does not name those siblings explicitly beyond the prerequisite mention, so it falls just short of a 5.

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

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

Explicit gating condition: 'Call this only after amem_skill_list (or the "Relevant skills" section of an amem context packet) shows a skill worth following.' That tells the agent both the prerequisite and the qualifying signal. No explicit when-not case (e.g., don't call for skills already loaded in context) is given.

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

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

With no annotations, the description carries the full disclosure burden; it does convey that this is a local metrics lookup (read-only by implication) and what metrics are reported. It does not state that it is non-mutating explicitly, what the response shape looks like (no output schema exists), how "estimated" savings are computed, or whether results are cached/paginated. Adequate but thin 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?

Two tight sentences: what it returns and its scoping are front-loaded, then the trigger condition. No filler, no repetition of the tool name, no wasted clauses.

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 3-parameter, all-optional stats tool with no annotations and no output schema, the description covers purpose and scope adequately but leaves the return structure unexplained — a meaningful omission for a metrics tool where the agent must know what fields come back. It also sidesteps the near-duplicate sibling entirely.

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 67%: `days` and `scope` are documented in the schema, while `workspace` has no description anywhere. The prose reinforces scope semantics ("one workspace/repo or everything") and implies a time window with "usage over time", but adds no format or default detail beyond the schema. Matches the baseline-3 expectation at this coverage level.

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 resource (usage and savings stats) and enumerates the metrics returned — local lookup time, estimated tokens/ms saved, hit rate — plus the scope dimension (one workspace/repo vs everything). An agent can tell this is an analytics read tool. The gap: the sibling `amem_usage_report` is nearly synonymous and the description does nothing to separate the two.

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 second sentence gives a concrete trigger ("asked how much amem helped, how often it hit, or usage over time"), which is real when-to-use guidance. However, no exclusions or prerequisites are stated, and given a sibling named `amem_usage_report`, an agent has no basis for choosing between them — that overlap is left entirely unresolved.

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?

Since no annotations were provided, the description must carry the full burden. It clearly implies a read-only behavior ('Binding, policy, and counts'). However, it does not disclose non-functional behaviors like rate limits, latency, or the expected structure of the 'full monitored inventory,' keeping it at a satisfactory but not stellar score.

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 definition is extremely concise. It uses only two sentences, and every phrase serves a high-value purpose: defining content and defining scope/behavior.

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

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

Despite having no output schema, the description provides all the necessary context regarding what the tool retrieves (bindings, policies, inventory) and how its behavior changes based on the input parameters. It is highly complete for its functional purpose.

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

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

With 0% schema description coverage, the description is vital. It explains the semantic significance of the 'workspace' parameter—that it controls the scope (single repo vs. machine-wide)—which is crucial context for tool invocation.

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

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

The description explicitly defines the resource and the data it returns ('Binding, policy, and counts,' 'full monitored inventory'). It clearly distinguishes the tool's function from a generic data retrieval operation.

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 a clear conditional usage guideline: omitting the 'workspace' parameter switches the scope from a specific repository to a machine-wide overview, effectively guiding the agent on how to use it for different levels of detail.

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 bears the full burden and does disclose the most important behavioral trait: supersession is non-destructive ('kept for history, not served'). It leaves out permission requirements, idempotency, and what happens to unknown ids, but the core semantics are front and center.

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 tight sentence with the outcome ('stop appearing in context') front-loaded, followed by the mechanism and the optional parameter hint. Nothing is padded.

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

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

For a three-parameter mutation tool with no annotations and no output schema, the description covers the what and the effect but is silent on workspace scoping, error behavior for unknown ids, and whether the operation is reversible beyond 'kept for history'.

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 33%, so the description must compensate. It clarifies 'by' (which the schema already documents) and implicitly explains that 'ids' are the claims being retired, but says nothing about the 'workspace' parameter or the array/list format of ids.

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?

Uses a specific verb and resource ('retire outdated claims', 'marks them superseded'), and immediately distinguishes the operation from deletion by noting the records are 'kept for history, not served'. An agent can tell this apart from amem_remember and from a hypothetical hard-delete sibling.

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

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

States the triggering condition clearly: claims are 'outdated' and should 'stop appearing in context'. It does not name an alternative tool or state when not to use it (e.g., what to do instead if a claim was simply wrong rather than replaced).

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 behavioral load. It discloses the default status (backlog) and that tasks are persisted on a project Kanban, but says nothing about return value, deduplication, permissions, or what anchors/workspace do.

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 placement, then the usage condition, then the alternative. 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?

For a simple create tool this covers purpose and routing well, but with no annotations, no output schema, and 40% parameter coverage, it leaves an agent guessing about anchors, workspace, and what a successful call returns. Minimum viable, not 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 only 40%: body and status are described in the schema, while title, anchors, and workspace are undocumented everywhere. The description adds one useful default (status defaults to backlog) but does not compensate for the undocumented anchors and workspace parameters.

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

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

States a specific verb and resource ('Create a deferred agent task on the project Kanban') plus the default placement ('backlog'). It explicitly distinguishes itself from the sibling amem_remember by naming where durable facts belong.

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 a use condition ('work that should not get lost in chat') and names the alternative routing ('Durable facts still go through amem_remember'). An agent can decide between the two without opening either schema.

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 burden for a mutation tool. It does not state whether the operation is idempotent, what happens if the task is already done, what permissions are required, or what the response contains.

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

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

The description is a single front-loaded sentence with no wasted words. It is concise, though it is under-specified rather than dense with useful information.

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

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

For a mutation tool with no annotations, no output schema, and zero parameter description coverage, the description is too sparse. It communicates the core action but omits side effects, return behavior, parameter formats, and any safety or permission context.

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

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

Schema description coverage is 0%, so both parameters are undocumented in the schema. The description does not explain the expected format of `id` or clarify the role of the optional `workspace` parameter, leaving the agent to infer both.

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: marking a deferred agent task as done on the Kanban board. It is clear enough to distinguish this from sibling tools like task_add or task_list, though it does not explicitly name how it differs from task_update.

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 'deferred agent task' hints at when the tool applies, but there is no explicit guidance about when to use this versus amem_task_update, amem_task_list, or amem_task_add. No exclusions or preconditions are 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, and it does disclose one real default: done tasks are excluded unless requested. However, it says nothing about result ordering, pagination/limits, or what a task record contains, and read-only status is only implied by the verb 'List'.

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, and the core purpose plus the default-behavior caveat are front-loaded before any elaboration.

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?

There is no output schema, no annotations, and only partial parameter coverage, so the description still leaves gaps around returned fields, ordering, and result size. It is adequate to select the tool but thin for calling it correctly on a workspace with many tasks.

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 33%, so the description should compensate more than it does. It adds meaning for include_done by stating the default excludes done tasks, and implies workspace scoping, but the status parameter's semantics and the workspace format are left entirely to the bare 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 opens with a specific verb and resource: 'List deferred agent tasks (Kanban) for a workspace/repo'. It also explicitly separates this tool's data domain from amem_remember, so an agent can tell it apart from the fact-storage sibling without opening the 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?

It gives a clear usage condition ('Use for work to do later') and names the alternative for the other case ('not durable facts (use amem_remember for those)'). It does not explicitly say when to prefer this over task_add/task_update/task_complete, but the list-vs-mutate distinction is largely self-evident.

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 burden for a mutation tool. It discloses the mutable fields and allowed status values, but says nothing about permissions, whether updates are partial, reversibility, side effects of status changes, or what is returned.

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 definition is a single front-loaded sentence with no filler. It efficiently lists the main update targets and the allowed Kanban status values.

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

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

Given a six-parameter mutation tool with no annotations, no output schema, and no parameter descriptions in the schema, the description is too thin. It should clarify the required id, workspace scoping, and partial-update behavior to be complete enough for reliable invocation.

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

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

Schema description coverage is 0%, and the description only names some of the six parameters. It mentions title, notes (likely body), anchors, and status, but omits the required id and the workspace parameter; the "notes" wording also does not directly match the schema's "body" field.

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

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

The description uses a specific verb and resource ("Update a task") and enumerates the mutable fields: title, notes, anchors, and Kanban status. It is clear what the tool does, though it does not explicitly differentiate itself from the sibling amem_task_complete despite overlapping with moving a task to "done".

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

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

The description implies usage by listing the fields that can be updated and the allowed status values, but it gives no explicit when-to-use guidance or exclusions. In particular, it does not say when to use this tool versus amem_task_complete for completing a task, leaving the 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 burden and does well: it discloses that amem computes the saving server-side from real file sizes, so the agent should not estimate, and that paths not in the packet are ignored. It does not state whether this is a write/attestation that persists, what happens on a repeat call, or what the tool returns, which is a meaningful residual gap for an unattested mutation.

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 purpose and the timing constraint in the first two sentences, with the anti-estimation warning early. It is somewhat padded — the closing reassurance and the restated parameter names duplicate schema fields — but nothing is confusing or out of 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 four-parameter tool with no output schema and no annotations, the description covers the critical decision points: when to call, what to report, what not to compute, and the omission default. The main missing piece is the return value — with no output schema, an agent cannot know whether it gets back a saving figure or an acknowledgement.

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 75%, so the schema already documents most fields; the description adds real semantic value by clarifying that anchors_opened means anchors you ended up opening anyway rather than a token estimate, and by explaining the intent of answered. event_id and workspace are left entirely to the schema, so it is not a full 5.

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 — report what you did with the last amem context packet — and frames the outcome (its savings estimate becomes a measurement). That framing alone distinguishes it from retrieval siblings like amem_context or amem_stats, which produce the packet or aggregate numbers rather than attest usage.

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?

Timing is explicit: "Call this once after you have finished acting on a packet," and there is a clear prohibition ("Do NOT estimate tokens"). It also pre-empts a likely withholding behavior by saying reporting that you opened everything is expected. It does not name a sibling alternative or say when not to call it at all (e.g., if no packet was ever issued), which keeps it below a 5.

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