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

With no annotations, the description carries the full behavioral-disclosure burden. It usefully states that contradictions accelerate the contradicted memory's decay and that superseded or archived evidence stops counting, but it omits authentication requirements, idempotency, reversibility of added evidence, and expected response behavior. The decay/counting effects are valuable, but the disclosure is not complete.

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

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

The description is front-loaded with the core action and then efficiently covers relation semantics and behavioral effects. Every sentence adds useful information, with no filler or redundant restatement of the tool name. It is appropriately sized for a multi-relation evidence tool.

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

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

For a 7-parameter tool with no annotations and no output schema, the description covers the core relation semantics and important decay behavior. It still leaves out authentication handling, agent identity expectations, confidence defaults, and what a successful call returns or changes. It is adequate but not fully complete for the tool's complexity.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters, including relation direction and source requirements. The description reinforces the relation semantics and clarifies that evidence_id points from evidence to memory, but it largely repeats schema-level information rather than adding substantial new parameter meaning. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Record evidence for a memory.' It also explains the three relation modes, so an agent can understand what the tool does without opening the schema. It does not explicitly differentiate this tool from sibling tools such as get_memory_evidence or review_memory, which keeps it from a 5.

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

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

The description gives relation-specific usage: supports/contradicts link two memories, while sourced_from records external provenance via source. However, it does not say when to choose add_evidence over related sibling tools like get_memory_evidence, review_memory, or save_memory. Usage is implied by the relation modes but not fully guided.

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

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

With no annotations, the description carries the full burden; it does usefully disclose the exact side effect (access_count and last_read_at updated). It omits idempotency, behavior for unknown memory IDs, and whether the counters feed ranking, decay, or promotion logic – meaningful gaps for a mutation 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?

Two short sentences, both earning their place, with the action front-loaded and the side effect second. No filler, though there is no structure beyond the two sentences.

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-annotation mutation with no output schema, the definition covers the action and its effects but leaves out return value, error behavior for invalid IDs, and any prerequisite linking to an actual read. Adequate but with clear 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 (including api_key authentication and agent_id) are already documented in the schema; baseline 3 applies. The description only restates that memory_ids accepts one or more values, adding no new semantics such as deduplication or batching limits.

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+resource ('Confirm that one or more memories have been read') and immediately names the mutated state ('Updates access_count and last_read_at'). It does not differentiate itself from plausible siblings like review_memory or search_memory, which also touch the read/evidence lifecycle.

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: an agent can infer it should call this after actually reading memories, but the description never says when to call it, when not to, or whether search_memory / review_memory already implies the same bookkeeping. No alternatives are named.

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 not meet it: it never says whether deletion is permanent, irreversible, or soft, whether related evidence is cascaded, or whether agent-level permissions are checked. 'Delete' signals mutation, but an agent gets no confirmation of consequences before an irreversible call.

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 zero wasted words. It is efficient, though the terseness edges toward under-specification rather than genuine clarity.

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

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

For a destructive, unannotated tool with no output schema, the description should disclose return behavior and irreversibility. It supplies neither, so an agent cannot judge risk or expected result from the definition alone.

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 memory_id, agent_id, and api_key are already documented in the schema. The description only restates the memory_id requirement and adds no semantics about authentication behavior or what an auto-filled agent_id implies.

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?

A specific verb (delete) and resource (memory) with the key identifier named, so the agent knows exactly what the tool acts on. However, it does nothing to distinguish itself from the semantically overlapping sibling forget_memory, leaving the agent to guess which one performs the deletion.

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

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

No statement of when to use this versus forget_memory, run_decay, or run_dedup, all of which remove or alter memories. There are also no stated preconditions such as required confirmation via confirm_read.

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 disclosure itself and does well: it explains the LLM-to-rule fallback and that it surfaces via fallback_used/fallback_reason, notes that saving is optional, and flags invalid occurred_at as a hard error. It still omits auth expectations and the response shape beyond 'extracted items.'

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 action, then mode behavior, then return/save semantics. Dense but every clause carries information, though the long parenthetical in the second sentence is somewhat heavy.

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 seven-parameter tool with no output schema, the description covers the key decision (which mode), the failure path, and whether memories are persisted. Auth requirements are left thinly covered relative to the surrounding complexity.

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

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

Schema coverage is 100%, so all seven parameters are already documented in the schema, including the mode semantics the description repeats. The description adds little meaning 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?

States a specific verb and resource: 'Extract structured memories from conversation text,' which separates it from sibling persistence tools like save_memory and search_memory. It doesn't explicitly name those siblings as alternatives, so it falls 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?

Gives clear selection guidance between the two modes: 'rule' is the default keyword-based path, while 'llm' is for semantic understanding of full context. It also explains when assistant_text helps. It stops short of saying when not to use the tool versus siblings such as save_memory or search_memory.

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

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

No annotations exist, so the description carries the full burden and does: irreversible, purges memory_history snapshots and orphaned compliance rows, leaves only a content-hash audit entry, gated by per-agent API-key auth with no separate admin tier. It also warns that Priority::Must rows are silently excluded unless overridden — exactly the destructive semantics an agent must know before calling.

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 dense paragraph that front-loads the destructive action, then scope, then the dry_run safety workflow, then the auth and exclusion caveats. Every sentence conveys a constraint an agent would otherwise have to guess; nothing is repeated from the schema verbatim.

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 12-parameter destructive tool with no annotations and no output schema, the description covers irreversibility, retention behavior, auth, defaults, and exclusion rules — everything needed to invoke it safely. Return-value detail is unnecessary given the tool's audit-log framing and the dry_run preview path.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds operational meaning beyond the field docs: the preview-then-execute pattern for dry_run, the memory_id-vs-criteria precedence, and the allow_must gate. Only the reason/agent_id/api_key parameters get no narrative treatment, keeping it short of a 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?

States a specific verb and resource ('Permanently erase ... one memory by id or a bulk set matched by criteria') and enumerates the criteria dimensions inline, so the scope is unambiguous. It explicitly contrasts with the sibling delete_memory, letting an agent distinguish the two without opening either 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 when-to-use rules: single id vs bulk criteria, the two-call dry_run workflow ('call once to preview, then again with dry_run=false'), and the Priority::Must exclusion plus the allow_must override. It also names the alternative (delete_memory) and the condition that would select it.

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

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

No annotations exist, so the description carries the full burden. It does disclose the return content (follow/violation rates for MUST memories) and implies a read-only operation, but says nothing about permissions, pagination behavior from the limit parameter, or how the aggregate differs in shape from a session report.

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 purpose before the mode-selection rule, with no filler. It could be slightly tighter by folding the return-content clause into the first sentence, but nothing is wasted.

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

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

With no annotations and no output schema, the description should ideally explain the read-only nature, the shape of the two report modes, and the role of limit. It covers purpose and mode selection adequately but leaves the pagination parameter and the aggregate-vs-session output distinction unexplained.

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%; agent_id and inject_session_id are documented in the schema, while limit has no description anywhere. The description reinforces the inject_session_id semantics but adds nothing for limit or for how agent_id interacts with the aggregate mode, so it does not compensate for the gap.

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

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

The description names a specific verb+resource (get compliance report) and scopes it to injection sessions, adding that it shows follow/violation rates for MUST memories. That is clear enough to act on, but it never distinguishes itself from the sibling 'report_compliance' or 'get_effectiveness_report', which an agent could easily confuse with this tool.

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 genuine decision rule between the two modes: supply inject_session_id for a single session, omit it for an aggregate. However, there is no guidance on when to reach for this tool versus report_compliance or get_effectiveness_report, so sibling selection is left to inference.

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 that judgments are computed automatically from record_outcome and are separate from manual compliance, but it omits read-only confirmation, permissions, pagination/ordering, time range, and response structure.

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 gives the verb, resource, rate categories, source, and contrast. Every clause adds selection-relevant information and there is no 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?

The core computation and rate categories are covered, which is the key need for this report. However, with no annotations and no output schema, the description leaves gaps around read-only behavior, parameter effects, time scope, and response shape.

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%: agent_id is described in the schema, but limit is not. The description mentions neither parameter and does not compensate for the undocumented limit or clarify filtering behavior, so parameter meaning relies almost entirely on the schema.

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

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

States a specific verb and resource: 'Get automatic effectiveness judgments for injected memories', and enumerates the four rate categories. It explicitly contrasts with manual report_compliance, so an agent can distinguish it from siblings like get_compliance_report and report_compliance.

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 establishes clear usage context: automatic effectiveness derived from record_outcome, independent of manual report_compliance. It does not spell out explicit when-not conditions or directly route the agent to get_compliance_report for manual checks, 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 still discloses the key behavioral fact that this is a read-only grounding operation returning raw trace rows plus an evidence profile. It does not cover what happens when evidence has been pruned or is absent, ordering/limits of the returned chain, or that authentication may be required.

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

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

Two sentences, front-loaded with what is returned, followed by why it matters. No filler, no repetition of the tool name or schema details.

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?

It names the returned artifacts (L0 trace rows, evidence profile), which compensates for the missing output schema. However, for a read tool with zero annotation coverage, gaps around emptiness/pruning behavior and result size remain unexplored.

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 memory_id and its meaning are already documented; the description restates the L0 trace expansion but adds no format, ID-shape, or error semantics. Baseline 3 applies when the schema carries the parameter burden.

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: retrieving the raw-evidence chain (L0 trace rows) and evidence profile for a given memory. The 'distilled from' framing makes the retrieval direction clear, so it is distinguishable from write-side siblings like add_evidence, though no sibling is named explicitly.

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

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

The phrase 'Read-only grounding: lets an agent quote the original session text and name its sources' implies the use case (citation/provenance checks), but there is no explicit when-not guidance and no alternative tool named for related needs such as review_memory or add_evidence.

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 the heading-to-skill mapping, that sections without steps are skipped, and that imports default into the review inbox unless approve=true. It omits auth requirements, idempotency/dedup behavior, and what is returned, which prevents 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?

Four tight sentences: purpose first, then parsing rules, then the default review-inbox behavior. Every sentence carries information and 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 mutation tool with no annotations and no output schema, the description covers the core mechanics (what is created, what is skipped, default review state) adequately. It leaves gaps around authentication expectations and duplicate handling, but the schema covers parameter-level detail.

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 six parameters are already documented in the schema; the description mostly restates the markdown and approve semantics. It adds a little framing about heading structure but no syntax detail beyond what the schema provides, 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 ('Import') and resource ('skills from a Markdown SOP document') plus the parsing rule, so an agent can tell this apart from single-item tools like save_memory. It does not explicitly name a sibling or alternative, which keeps it from 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 only implied by 'from a Markdown SOP document' — there is no explicit when-to-use/when-not guidance and no mention of alternatives such as save_memory or extract_memories. The approve=true note is behavioral, not a usage 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?

With no annotations, the description carries the burden and does well: it discloses the two-stage classification (rule floor plus optional LLM judge), the write side effect (records an episode like record_outcome), and the non-error 'skipped' outcome with three concrete skip conditions. It omits permission/auth requirements (an api_key parameter exists) and any duplicate/idempotency behavior, which keeps it short of 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?

The differentiator (evidence instead of transcript) is front-loaded in the first clause, and the skip semantics land at the end where they matter. It is dense and slightly overloaded with the 'rule-floor-plus-optional-LLM-judge ... as the Claude Code Stop hook's outcome --infer' clause, but no sentence is 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 an 8-parameter, no-annotation, no-output-schema tool, the description covers what an agent needs: when to choose it, how evidence is constructed, what classification runs, that recording happens, and that 'skipped' is not a failure. Return-shape detail is unnecessary since the key return value (status 'skipped') is stated inline.

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 the baseline is 3. The description still adds value by telling the caller what to put in `evidence` (pre-computed friction counts and terminal state) and by naming `judge_context`-style judge behavior, clarifying that the judge is optional and only the rule floor runs when no context is supplied.

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 pair (classify and record) on a specific resource (task outcome) and immediately scopes the input source: host-provided evidence rather than raw transcript text. It explicitly positions itself against record_outcome ('records exactly like record_outcome') and against the Claude Code Stop hook path, so an agent can distinguish it from siblings 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 a clear selection condition — use this for hosts whose event model doesn't produce a Claude-Code-shaped JSONL transcript (e.g. dsh/Cordis session events). It references the alternative paths (transcript-based Stop hook, record_outcome) but never states the inverse rule explicitly, e.g. 'if you do have a transcript, use record_outcome instead.' Clear context, no formal exclusion.

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 it does disclose one genuinely useful behavioral trait: the results are sorted by created_at ascending (oldest first). However, it says nothing about permissions/authentication (the api_key param implies auth is needed), pagination behavior, whether limit truncates silently, or whether this is purely read-only.

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

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

Two sentences, front-loaded with the core purpose, with the sort-order detail appended where it is most useful. No filler or restatement of the tool name.

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

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

For a tool with no annotations and no output schema, the description covers what is listed and in what order but omits the review workflow that gives the tool meaning, plus filtering/paging semantics. It is adequate to call the tool, but a thin basis for using it correctly in a multi-step flow.

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 limit, api_key, agent_id, and namespace are all documented in the schema itself. The description adds no parameter-level meaning (e.g., that namespace narrows the inbox or how limit interacts with sort order), 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 pairs a specific verb (list) with a precisely scoped resource (memories pending human review) and further clarifies 'not been reviewed yet', making the operation unambiguous. It does not explicitly contrast itself with siblings like search_memory or review_memory, which is the only thing separating it from 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?

There is no guidance on when to call this versus search_memory (which also returns memories) or when to follow up with review_memory. The sentence 'Shows memories that have not been reviewed yet' defines the contents rather than prescribing usage, so the agent must infer the review-workflow context itself.

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 it does disclose a non-obvious downstream effect: failures with a cause are 'reflected into lessons that get injected into similar future tasks.' It also enumerates the allowed status values. It omits auth expectations, idempotency/duplicate behavior, and what a call returns, leaving real gaps for an 11-parameter write 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?

Three tight sentences, front-loaded with the action and followed by the trigger and the consequence. Every sentence carries information; there is 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?

Purpose and the key side effect are covered, and the schema fully documents all 11 parameters. However, with no output schema and no annotations, the description should say what a successful call returns and whether there are authentication or de-duplication considerations — especially since api_key and session_id parameters imply behavioral constraints that go unmentioned.

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 schema already documents all parameters in detail. The description adds a little meaning by implying that the 'cause' field is what triggers lesson reflection and that status is constrained to three values, but this largely restates the schema descriptions. 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 and resource ('Record the outcome of a task') and names the memory type (episodic memory). It is distinguishable in practice from siblings like save_memory or infer_outcome, but it never explicitly contrasts itself with them, so it falls short of the top mark.

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 clear trigger: 'Call this after finishing a task.' It explains the payoff (past successes and failures inform future sessions) but offers no when-not guidance or explicit alternative (e.g., infer_outcome), so it is clear context without exclusions.

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

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

No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about side effects, whether reports can be amended or resubmitted, whether partial reporting (a subset of injected memories) is allowed, or what the call returns. The only behavioral clue is the implicit prerequisite of a prior session_start, mostly conveyed by the schema rather than the description.

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

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

Two short sentences, purpose front-loaded, zero filler. Nothing to trim and 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?

For a 2-parameter, 100%-covered schema the description is minimally sufficient, but with no output schema and no annotations it leaves open what the report produces and whether/how the session's compliance state changes as a result. An agent knows what to send but not what to expect back or whether a repeat call is safe.

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%: inject_session_id's origin and the status values (followed/violated/unknown) are fully documented in the schema. The description adds only a gloss ('one per memory' is implied by 'which injected memories'), 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?

States a specific verb+resource: report compliance for a previous injection session, and clarifies the payload is 'which injected memories you followed or violated'. An agent can distinguish it from the read-side sibling get_compliance_report by the verb alone, but the description never names that sibling or otherwise explicitly contrasts 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?

'Call this to indicate which injected memories you followed or violated' implies the trigger condition (after memories have been injected), and the schema notes inject_session_id comes from a prior session_start call. However, it gives no explicit when-not guidance, no mention of how often to report, and does not name get_compliance_report as the read alternative.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It usefully states that approved memories get higher priority in future injections, but it omits important traits such as permissions/auth requirements, whether reject deletes or just excludes the memory, and what edit requires.

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

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

The description is two short sentences with no wasted words. The core purpose and available actions are front-loaded, followed by a useful behavioral consequence.

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 schema covers all parameters and there is no output schema to explain. Still, for a review/mutation tool with no annotations, the description is a bit thin: it does not clarify the effects of reject or edit, or authentication expectations beyond what the schema says.

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 the schema already documents all six parameters. The description aligns with the action values and mentions editing content, but adds little beyond the schema, especially about conditional fields like edited_content and edited_instruction when action is edit.

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 ('Review a pending memory') and enumerates the three supported actions. It is clear on its own, but it does not explicitly distinguish this tool from nearby siblings such as list_inbox, delete_memory, or save_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?

The phrase 'pending memory' implies the usage context, and the actions approve/reject/edit clarify the review workflow. However, it gives no explicit guidance on when to choose this over alternatives or when not to use it.

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

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

With no annotations at all, the description carries the full behavioral burden, and it does disclose the key trait: this tool archives (i.e. removes from active use) memories below a threshold, which is destructive-adjacent. It also discloses the MUST exemption. However, it omits whether the operation is reversible, whether it is global or scoped to the calling agent, and what happens to the api_key-only authentication path.

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 followed by the effects and the exception. Zero filler and 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?

For a maintenance mutation with no annotations and no output schema, the description should say more about scope and results. The threshold is referenced but never defined or made configurable, and it is unclear whether the response reports how many memories were decayed or archived. The core effect and the MUST carve-out are covered, but an agent cannot predict the blast radius.

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 both parameters already document themselves in the schema. The description adds nothing about api_key or agent_id, nor whether the cycle is scoped by the requesting agent. Baseline 3 is appropriate when the schema does all the work.

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 ("Run memory decay cycle") immediately followed by the concrete effects: decay_score reduction, archival below threshold, and a durable exemption for MUST memories. An agent can distinguish this from delete_memory or forget_memory because the effect is scoring-based and selective rather than direct deletion. It stops short of naming those siblings explicitly, so it is clear but not fully 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?

The description says what happens but never when to invoke it — no cadence, no prerequisites, and no statement of when to prefer run_dedup, run_promote, or forget_memory instead. The agent is left to infer that this is periodic maintenance. The absence of any exclusion is notable given that three maintenance-cycle siblings exist.

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. It usefully implies a read-only scan that only reports (no mutation) and discloses the Jaccard text-similarity basis, which signals that only lexical near-duplicates are caught. However, it never explicitly states that nothing is merged or deleted, nor how results are shaped or how expensive a full-namespace scan is.

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

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

Two short sentences, front-loaded with the action and trailed by the detection method; every clause carries information and there is 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?

With no output schema and no annotations, the description should say more about what 'findings' contain (duplicate pairs, scores, memory IDs) and whether remediation is a separate step. As written it is adequate to invoke the tool but leaves the result shape and follow-up workflow unspecified.

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 api_key, agent_id, and namespace are all documented in the schema. The description adds no extra meaning about scope (e.g., what a null namespace means for scan cost) or about authentication expectations, so it sits at the baseline.

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 ('scan for duplicate memories') plus the output act ('report findings'), and names the detection method (Jaccard text similarity). It is distinguishable from siblings like search_memory or delete_memory, though it never explicitly contrasts itself with them.

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 when-to-use guidance: nothing says whether this should run before delete_memory/forget_memory cleanup, how often to run it, or that it is a prerequisite step rather than a cleanup action. The agent must infer the workflow role entirely.

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 it does disclose one genuinely important side effect: source memories are archived to L0 after promotion. It does not say whether that archival is reversible, what permissions or API key scope are required for a mutating batch job, how long it takes, or whether it is idempotent — all relevant for a pipeline that rewrites memory tiers.

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, no filler: the first states the pipeline and its two stages, the second states the consequential side effect. The most important information (what it does, what it archives) is front-loaded.

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 five-parameter, no-output-schema, no-annotation tool, the description covers the pipeline mechanics and the archival behavior. But it omits the return value (e.g., counts consolidated/promoted), any preconditions such as needing sufficient memory volume, and whether namespace is currently ignored despite being a parameter — gaps an agent would want closed before invoking a mutation pipeline.

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 of the five parameters (min_l1, min_l2, api_key, agent_id, namespace) is already documented with defaults. The description adds tier context (L1/L2/L3) that helps interpret min_l1 and min_l2 but does not explain the namespace caveat or auth behavior beyond what the schema says. 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 gives a specific verb ('Run') plus a named pipeline and then decomposes it into two concrete transformations (L1→L2 consolidation, L2→L3 promotion). This makes it clearly distinct from siblings like run_decay or run_dedup in effect, though it never explicitly names those siblings as 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?

Usage is implied by the accumulation thresholds ('consolidates atomic L1 memories', default min_l1=3), so an agent can infer it should be run after memories have built up. However, there is no explicit when-to-use / when-not-to-use statement and no guidance relative to run_dedup or extract_memories, which also operate on the memory tiers.

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 discloses that saves are persistent, that embeddings are generated automatically, that near-duplicates cause a merge or skip rather than an insert, and it names the three possible statuses in the response. It stops short of saying what happens to the existing memory's prior content on a merge (append vs. overwrite) and says nothing about auth or 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?

Front-loaded with the action, then definition, then the non-obvious delta-write behavior, which is the right order. The definitional sentence about what memories are is slightly padded, but every sentence carries real 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 16-parameter mutation tool with no annotations and no output schema, the description covers the highest-risk behavior (silent dedup/merge instead of insert) and even documents the response status values an agent would otherwise not know. Remaining gaps, such as interaction between namespace/visibility and the merge scope, are noted but minor given full schema coverage.

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 the schema already documents all 16 parameters including force_insert. The description only restates the force_insert bypass and the embedding behavior, adding little syntactic or semantic detail beyond what the schema fields already say.

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 ('Save a new memory') and immediately defines what a memory is (preference, fact, episode, skill), which disambiguates it from generic storage. It never names a sibling, so there's no explicit contrast with extract_memories or review_memory, leaving the agent to 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?

The description gives clear guidance on the force_insert escape hatch and explains that dedup is on by default, which is genuinely useful for deciding how to call it. It gives no guidance on when to save via this tool versus extracting memories in bulk or reviewing them, so sibling routing is only implied.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the default mode and the embeddings dependency ('hybrid' when embeddings are available), but omits auth requirements, result ordering, and what happens when embeddings are unavailable.

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 compact, front-loaded sentences with no filler. Slight ambiguity: the mode property text says 'keyword' (default) while the top-level default and description say hybrid.

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 10-parameter search tool with no output schema and no annotations, the description covers the core mode behavior but leaves auth requirements and result-shaping options (min_score, expand_relations, filters) entirely to the schema. Adequate but minimal.

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 the schema already documents all 10 parameters, including mode, top_k, min_score, filters, and expand_relations. The description reinforces mode semantics with implementation detail (RRF) but adds no parameter information beyond the schema; 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 and resource ('Search user memories') and enumerates the three search modes with their mechanics (text match, vector similarity, RRF combination). An agent can tell this is a retrieval tool, though it doesn't explicitly contrast itself with siblings like get_memory_evidence or review_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?

The mode semantics imply when each mode is useful, and the default behavior is stated, but there is no explicit when-to-use guidance relative to alternatives or when a caller should switch modes. Usage is inferable rather than directed.

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 it does disclose useful behavior: identity-scoped filtering, the MUST/REF output format, and overflow summarization. It omits whether starting a session persists server-side state, whether it is idempotent, and what happens if a session already exists — meaningful gaps for a state-initializing 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?

Three tight sentences: purpose first, return shape second, overflow/fallback behavior third. Nothing is redundant and the most decision-relevant information is front-loaded.

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 and no annotations, and the description compensates well by explaining the return format and overflow handling for a 5-parameter tool. It falls short only on side effects and authentication/session-state behavior, which an agent would still want before invoking.

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 five parameters are already documented in the schema, setting the baseline at 3. The description adds only the notion that results are filtered by agent identity, which loosely maps to agent_id/agent_type but gives no additional semantics for project, context_hint, or api_key.

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 ('Start a new session') and immediately clarifies what it returns: memories filtered by agent identity, rendered as MUST/REF instructions. It also distinguishes itself from the sibling search_memory tool by explaining that overflow items only appear as summaries with a pointer to that tool.

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 call this at the beginning of a conversation — and the overflow sentence routes the agent to search_memory for details, which is a partial alternative hint. But there is no explicit statement of when to call it versus alternatives, no prerequisites (e.g., api_key need), and no exclusions.

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