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

Annotations already signal that the operation is non-read-only, non-idempotent, and non-destructive. The description adds a useful behavioral fact: the tool performs no LLM processing itself. However, it does not disclose return behavior, overwrite/conflict semantics, or side effects beyond archiving, so the added transparency is modest.

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 exactly two sentences with no fluff. The primary action is front-loaded, and the second sentence communicates the critical caller-responsibility constraint. It avoids repeating schema content.

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 description plus the rich input schema adequately cover the 8 parameters, including nuanced ones like project_id and session_key, and state the key prerequisite. It does not explicitly connect archival to recall/list_episodes or describe the return value, but those are not essential for correctly selecting and invoking the tool.

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

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

Schema description coverage is 100%, so the baseline is 3 even without parameter details in the tool description. The phrase 'pre-computed summary, keywords, and resolved status' reinforces that these values must be prepared by the caller, but it does not add meaningfully to the already-detailed schema descriptions.

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 ('Archive') and resource ('conversation episode') and states the payload: pre-computed summary, keywords, and resolved status. It is clear about what the tool does and that it creates/stores an archived episode, but it does not explicitly contrast it with sibling tools like store, update_memory, or list_episodes, so it stops 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?

'All LLM processing is performed by the caller' is an explicit prerequisite: the agent should only call this tool after summarization, keyword extraction, and resolved-status determination have already happened. It does not name alternatives or state when not to use it, so it lacks the explicit exclusion guidance needed for 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?

Annotations only say the operation is not read-only, not idempotent, and not destructive. The description adds meaningful behavioral detail: it samples memory pairs, places the threshold above the null mean, uses no labels, and adapts to model and corpus. It stops short of explicitly stating whether the calibration result is persisted or how it affects future recalls, but the added algorithm-level transparency is strong.

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 dense but well-structured: purpose first, then method details. Every sentence adds meaningful information, though the method explanations are slightly verbose and overlap with the schema descriptions.

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 description covers the algorithm and method choices well, but it does not state what the calibration changes in persisted state, whether there are prerequisites (e.g., existing memories), or what the return value is. Given the absence of an output schema and the mutating nature of the tool, these gaps leave the description slightly 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 100%, so the baseline is 3. The description goes beyond the schema by explaining the statistical rationale for each method, including when percentile is robust (anisotropic models like bge-m3) and how separation falls back to nearest-neighbour. This helps an agent choose sensible parameter values.

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

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

The description clearly states a specific action ('Auto-calibrate') on a specific resource ('the vector search threshold'), grounded in a concrete statistical basis (the null cosine distribution). It also distinguishes the different calibration methods, making the tool's intent unambiguous.

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

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

The description explains how the tool works and the method options, but it does not say when to use this tool versus alternatives like set_recall_precision or get_recall_precision. It gives no explicit usage conditions, prerequisites, or exclusion criteria.

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?

Beyond the readOnlyHint=false annotation, the description discloses many behavioral traits: lossy/irreversible repairs, report-only file-integrity findings, per-run caps, the remaining convergence signal, unknown-check rejection, and the removal of the old healthy boolean. This is exactly the side-effect and edge-case disclosure an agent needs.

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 long but dense and front-loaded: the core purpose and check list come first, followed by repair caveats and status semantics. Each sentence carries distinct information; the historical note about the removed healthy boolean is useful but adds length that could be trimmed in a more tightly structured definition.

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 output schema and only one annotation, the description covers behavior, return signals (status, issues, severity_summary, checks_run, remaining, storage stats), version nuances, and parameter usage. An agent has enough information to invoke it correctly and interpret results, including convergence behavior.

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

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

Schema coverage is 100% (all parameters described), but the description adds meaning beyond the schema: it explains that fix=true is agent-scoped, lossy/irreversible, and capped, and that checks rejects unknown names rather than silently doing nothing. It does not add details for agent_id or session_key beyond their schema descriptions, so a 4 is earned rather than 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?

The description opens with a specific verb and resource — 'Check memory database health' — and enumerates 29 named check categories, making the scope unusually concrete. However, it never names or contrasts sibling tools such as deep_check, so it stops short of explicit sibling differentiation.

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 clear operational guidance: use checks to run a subset, set fix=true to auto-repair, and re-run until remaining stops decreasing. It does not explicitly state when to prefer this tool over alternatives like deep_check, but the context strongly implies a health/safety-check role.

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?

The description extensively discloses behavior beyond the minimal readOnlyHint:false annotation: the once-per-process background check, 24h cache, no network/disk on bare calls, exact state meanings, restart requirement, no automatic updates, install-method constraints, and independence from pause_persistence. This is exemplary transparency for a tool with side-effecting capabilities.

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 content is dense and every major point is relevant, but it is delivered as one long monolithic paragraph with no bullets or headings, making it harder to parse. It is somewhat longer than necessary, with minor repetitions around 'never automatic' and 'only if you ask'.

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

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

With no output schema, the description fully covers the return contract: state values, reason, install command, exit_code, and output truncation. It also addresses edge cases such as detached HEAD, uvx cache behavior, and the CPERSONA_UPDATE_CHECK disable path, so an agent has everything needed to invoke the tool correctly.

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

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

Schema coverage is 100%, but the description adds substantial meaning: refresh has a 3s budget and failure yields state=unknown; apply returns exit_code and last 40 lines, never uses a shell, and is restricted to pip/checkout installs. The description enriches both boolean parameters well beyond their schema definitions.

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 precise verb and resource: 'Report whether a newer release of this server exists' and explicitly scopes the install capability as opt-in. It clearly separates check, refresh, and apply behaviors, making the tool's purpose unambiguous even among many siblings.

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

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

The description gives clear context for when a bare call, refresh=true, and apply=true are appropriate, and explicitly states when apply is refused (checkout at tag, uvx). It does not explicitly name alternative sibling tools, but the usage boundaries are otherwise detailed enough for an agent to decide correctly.

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?

The description goes well beyond the readOnlyHint=false annotation by disclosing exactly which checks are repaired by fix=true, which are report-only, and that fix is accepted but ignored for those. It also surfaces the default dry-run preview behavior and the judgment call nature of the analysis.

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 dense but every sentence carries a distinct responsibility: scope, issue taxonomy, fix behavior, routing, and check selection. The core capability is front-loaded 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?

For a tool of this complexity, it covers the input contract, per-check fix behavior, and downstream actions, which is strong. It does not describe the shape or content of the report returned (and there is no output schema), so an agent must assume the issue categories are the output vocabulary.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds value by grouping checks into fixable vs report-only and by explaining that fix is not a global repair switch. It confirms how checks selects specific checks, though it does not add detail beyond the schema for session_key or agent_id.

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 ('Deep heuristic analysis') and a well-scoped resource (memory data quality), then enumerates the six concrete issue categories it detects. This clearly distinguishes it from sibling health/update tools even without reading their 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?

It gives actionable guidance on how to use the fix flag and which checks to select, and routes report-only outcomes to the correct follow-up tools (merge_memories, delete_memory, calibrate_threshold, update_profile). It does not explicitly contrast deep_check with check_health or other diagnostic siblings, so an explicit when/not-when boundary is missing.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds meaningful context beyond these flags by specifying exactly what data domains get destroyed (memories, profiles, episodes) and that it is scoped to a single agent, clarifying the blast radius.

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

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

The description is two sentences with no filler. The core action and scope are front-loaded, and the usage context is given in the second sentence. Every word earns its place.

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

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

Given the simple two-parameter schema and annotations that already cover destructive/idempotent behavior, the description sufficiently explains the tool's purpose and scope. Minor omissions like return values or preconditions are not critical for this kind of cleanup operation. The note about being used by the kernel adds adequate 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?

Both parameters (agent_id and session_key) have detailed descriptions in the input schema, including the nuanced behavior of session_key as a partition hint rather than a data filter. The tool description itself adds no param information beyond what the schema provides, so a baseline of 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 uses the specific verb 'Delete' and names the exact resource: ALL data (memories, profiles, episodes) for a specific agent. It clearly distinguishes this from sibling memory-manipulation tools by emphasizing it purges everything for one agent during 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?

The description explicitly states when to use this tool: 'Used by kernel during agent deletion.' It does not provide explicit alternatives or when-not-to-use guidance, but the context of a cleanup/teardown operation is unambiguous enough for an agent to decide.

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

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

Annotations already indicate destructive and non-read-only behavior, and idempotentHint=true is present. The description adds value beyond the annotations by revealing that ownership is enforced when agent_id is provided, which is key behavioral context for callers. It does not contradict the annotations.

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, no filler, and the core action is front-loaded. Every word earns its place by clarifying scope or the ownership condition.

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 single-ID deletion tool, the description covers the core operation and the ownership nuance. The destructive nature is already communicated by annotations, and no output schema exists, so return-value details are not required. It could mention the alternative of archiving, but that is not necessary for correct 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 100%, so the schema already documents episode_id, agent_id, and session_key. The description largely restates what the schema says: delete by ID and ownership enforcement for agent_id. It does not add meaningful parameter-level detail beyond the schema.

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

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

The description states a specific verb and resource: 'Delete a single episode by ID.' It clearly scopes the operation to one episode, distinguishing it from broader deletion tools like delete_agent_data or archiving tools like archive_episode. The ownership enforcement sentence adds further precision about the operation's conditions.

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 a clear usage context: use when you need to delete exactly one episode by its ID. It also notes an important condition around agent_id and ownership verification, but it does not explicitly name alternatives or explain when not to use this tool versus archive_episode or delete_agent_data.

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

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

Annotations already establish destructive and read-only behavior, so the description adds value by explaining ownership enforcement when agent_id is provided. It does not contradict the annotations.

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 concise, front-loaded sentences with no filler. The core action is stated first and the ownership caveat follows.

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 single-item deletion tool, the description plus annotations and full schema coverage are largely sufficient. It could additionally clarify not_found behavior or relationship to bulk deletion tools, but these are minor 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 description coverage is 100%, so parameters are already fully documented. The description does not add meaningful parameter details beyond what the schema provides.

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 (Delete), a specific resource (memory), and a precise scope (single memory by ID). This clearly distinguishes it from sibling tools such as delete_episode and delete_agent_data.

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 use case is implied: use this when deleting one memory by its ID. However, it does not explicitly mention when_not_to use it or name alternatives like delete_agent_data for broader deletion, leaving some routing to the agent's 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?

The description describes an export operation, which is typically non-destructive. However, annotations set destructiveHint to true, implying the tool may have destructive side effects (e.g., file overwrite). The description does not disclose this, contradicting the annotations.

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, straightforward sentence with no wasted words. It is front-loaded with the action and purpose.

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

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

The description mentions the data types exported (memories, episodes, profiles) and the format (JSONL), but does not address potential side effects like file overwriting despite the destructiveHint annotation. Given no output schema, more detail on the return value or behavior would improve completeness.

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

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

The input schema covers all three parameters (agent_id, output_path, include_embeddings) with descriptions. The tool description does not add additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool exports memories, episodes, and profiles to a JSONL file for backup or portability. It uses a specific verb and resource, and distinguishes from siblings like import_memories.

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 context for when to use the tool (backup or portability) but does not explicitly state when not to use it or mention alternatives. Sibling list makes the purpose clear enough.

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?

Goes far beyond the readOnlyHint annotation by disclosing two independent bounds (20 refs and 40,000 chars), the deferred return field and budget_chars, the never-cut behavior, the special case of a single row exceeding the budget, and the ownership check via agent_id that results in missing. This level of behavioral detail is exceptional.

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 dense and every sentence provides meaningful detail about limits, edge cases, and the deferred mechanism. It is longer than average, but the complexity of the tool justifies the length; the version reference '2.5.4a2' adds specificity without being redundant.

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

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

Given the multi-bound behavior, deferred refs, budget semantics, and the absence of an output schema, the description covers all critical runtime behavior, edge cases, and the ownership check result. The agent receives everything needed to invoke the tool correctly and interpret results.

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

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

Schema description coverage is 100% and both refs and agent_id are already well-described in the schema. The description adds contextual behavior (deferred, missing) but does not add new parameter-level semantics, so the baseline of 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 opens with 'Fetch full, untrimmed content for recall preview refs', which clearly specifies the action, resource, and scope. It also distinguishes this tool from the preview-tier recall flow by positioning it as the targeted expansion path, differentiating it from sibling tools like recall and recall_with_context.

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

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

Explicitly states when to use the tool ('Use after a preview-tier recall to expand only the rows that matter') and names the alternative approach ('instead of opting the whole recall out with full_content=true'). Also gives operational guidance about re-fetching deferred refs in a second call.

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?

The description not only aligns with the readOnlyHint annotation but adds significant context: the context is edited on the filesystem (~/.cpersona/operating-context.toml), never via MCP. This discloses the source of truth and mutation path, which annotations alone do not provide.

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 concise sentences, front-loaded with the core purpose, followed by mode details and behavioral note. No wasted words. Structure is logical: what, how, important 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?

Given one optional parameter, no output schema, and full annotations, the description covers all necessary aspects: return types (preview tier components, full section body), usage modes, and behavioral constraints (read-only, filesystem editing). It is sufficient for an AI agent to correctly invoke this 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% with a description for the 'section' parameter. The description adds value by explaining the default behavior (preview tier) and that the section is from 'doctrine_sections'. It clarifies the parameter's effect beyond the schema's own 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?

The description clearly states the tool reads the 'server-served operating context' with a specific version (v2.5.1). It identifies the resource and its nature as 'operator-owned doctrine'. This is specific and distinct from sibling tools like 'get_profile' or 'get_contents'.

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

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

The description explicitly states the two modes: without arguments returns the preview tier, and with a 'section' argument returns the full body. It mentions read-only and that editing is done via filesystem, not MCP. While it doesn't contrast with siblings, it provides clear usage context.

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

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

Description aligns with readOnlyHint by stating 'Get', but adds no further behavioral details such as error handling for missing agents, return format, or scope of the profile.

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

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

Single sentence, concise and front-loaded. Could include more detail without being overly long, but the brevity aids readability.

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?

Adequate for a simple 1-parameter tool with no output schema. However, lack of return value description may leave the agent uncertain about the output format.

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% with a clear description for 'agent_id'. The tool description does not add any additional meaning beyond the schema, so baseline score 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 'Get the current profile for an agent' clearly states the action (get) and resource (profile) with specifier 'for an agent'. It distinguishes from sibling 'update_profile' but is slightly redundant with the tool name.

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

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

No guidance on when to use this tool vs alternatives, no prerequisites or limitations mentioned. The only implicit guidance is from the readOnlyHint annotation.

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

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

Annotations already declare readOnlyHint=true, so the description's addition of 'pending tasks, retry config' provides some context. However, it could be more transparent about the return format or any other behavioral traits.

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 of 13 words. Every word is purposeful and concise.

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

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

For a simple, parameterless tool with readOnlyHint annotation, the description is fairly complete. It could benefit from specifying the output structure, but given no output schema, it's adequate.

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

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

The input schema has zero parameters, so baseline is 4. The description does not add parameter details, which is acceptable since there are none.

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

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

The description clearly states a specific verb 'Get' and resource 'background task queue status', and mentions what is included (pending tasks, retry config). This distinguishes it from sibling tools like check_health or list_episodes.

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

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

The description implies usage for checking queue status but provides no explicit guidance on when to use it versus alternatives, nor when not to use it. No sibling comparisons mentioned.

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

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

Annotations already declare readOnlyHint=true. The description goes further by stating it never recalibrates or persists, and details the returned fields (beta, precision level, override flags). This adds behavioral context beyond the annotation, though it doesn't cover all edge cases.

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 paragraph that front-loads the main purpose and then provides additional details. It is reasonably concise, though some sentences could be tightened. Every sentence adds value.

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

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

Given the simple input (1 param, no output schema), the description thoroughly explains the return value and its relationship to the global default and override behavior. It is complete for a read-only tool of this complexity.

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

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

The schema covers the single required parameter (agent_id) with a description. The tool description does not add meaning beyond that, but since schema coverage is 100%, a baseline of 3 is appropriate.

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

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

The description clearly states the tool reads an agent's effective recall precision, identifies it as the read-back companion to set_recall_precision, and specifies it is read-only. This distinguishes it from its sibling and provides a specific verb-resource combination.

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 explains when to use this tool (as a read-back companion to set_recall_precision, for UI loading before editing) and implies it should be used before writing. However, it does not explicitly mention alternatives or when not to use it, though the sibling set tool is clearly the counterpart.

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

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

Annotations only carry readOnlyHint=true, so the description bears the full burden — and it delivers massively: cost profile (O(database), two whole-database reads), the guarantee that findings are NOT filtered by agent_id/project_id, the cap semantics ('capped_kinds names every kind that had more (observed, not inferred from count == limit)'), the check_crashed fallback instead of failing the pull, and identity_shared behavior. The 'Read-only, never repairs' statement is consistent with readOnlyHint=true.

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 unusually long, but every sentence carries distinct operational information — cost, filtering, caps, crash handling, transport identity — and the core purpose is front-loaded in the first sentence. It is information-dense rather than padded; a slight trim would be possible, but nothing is wasted given the tool's genuinely complex 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?

With no output schema present, the description must document return semantics itself — and it names the essential fields (kind, severity with its value meanings, health_severity, check_crashed, findings, capped_kinds, total, per_kind_limit, summary, identity_shared, _meta.server_version). Combined with parameter semantics, cost, and filtering behavior, an agent has everything it needs to call this correctly on a complex 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 already 100%, but the description adds substantial meaning beyond the schema: per_kind_limit's interaction with capped_kinds and the honesty caveat that total/counts describe only the returned set, session_key being 'a partition hint, not a filter' with identity_shared implications, and include_summary being described as a prose restatement you can skip to avoid paying for it. This goes well beyond the baseline 3 for fully-covered schemas.

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 ('Pull the storage-integrity findings on demand') and immediately distinguishes itself from the sibling check_health ('instead of reading them off check_health'). The 'Same detector as check_health(fix=false) over the WHOLE database' line precisely situates it among siblings, so an agent cannot confuse it with check_health, deep_check, or the other tools.

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

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

Explicitly states when to use it vs the alternative: it is a pull contract meant to be invoked 'once a session', budgeted by call frequency, versus check_health for scoped repair ('scope a repair with check_health(agent_id=...)'). It also gives concrete invocation guidance like 'pass include_summary=false to skip paying for it' and explains why no cheap subset exists — leaving nothing 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?

The description adds useful behavioral detail beyond annotations by specifying deduplication keys (msg_id/content for memories, summary for episodes). However, destructiveHint is true and the description does not disclose what destructive effect may occur, such as overwriting existing records, which leaves an important behavioral gap.

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

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

The description is two sentences with no filler: the first states the operation and scope, and the second adds essential idempotency and deduplication semantics. Information is front-loaded and every sentence earns its place.

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

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

For a mutating tool with destructiveHint, the description is reasonably complete but missing return-value behavior and clarification of the destructive/overwrite effect. The schema and annotations cover parameters and high-level safety, but the description does not fully bridge those 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 description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond saying the source is a JSONL file; it does not elaborate on dry_run, session_key, or target_agent_id, though the schema already captures those.

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), the resource (a JSONL file), and the data kinds (memories, episodes, and profiles). This clearly differentiates it from siblings like export_memories, store, or merge_memories.

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 tool's intended use as a bulk importer from a JSONL file is implied, and the idempotency note suggests it is safe for repeated imports. However, it does not explicitly say when to use this instead of alternatives such as store or merge_memories, nor does it state exclusions or prerequisites.

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

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

The annotation readOnlyHint=true is complemented by a detailed exposition of response-size budget, degradation semantics, truncation markers, and conditional budget_chars. The description also discloses special-case behavior (literal '@auto' resolution, no warning). This is transparent about the tool's behavior beyond the schema.

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

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

The description is technically dense but effective numerically; the leading sentence furnishes the purpose ('dashboard display') and the exotic details (budget, ref) are packed after. A slight con: it jumps into bug/history references (bug-255, v2.4.7) that might confuse a simple agent, but the structure 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?

Without an output schema, the description compensates by explaining the response layout (summary/keywords truncation, budget_chars presence, ref expansion). It also cross-references get_contents and export_data for full data, so the agent knows how to recover details. The complexity of the tool is well 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?

All three parameters have schema descriptions, but the tool description adds significant semantic depth, particularly for project_id: explaining the '@auto' sentinel, resolution edge cases, and referring to list_memories for same semantics. This goes well beyond the generic schema 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 the verb 'list' with a specific resource ('archived episodes for an agent') and qualifies the scope ('for dashboard display'). It distinguishes itself from list_memories and mentions export_data for full keyword data. However, it doesn't explicitly name sibling alternatives for the list function; it clarifies what it is not for related tools.

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

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

The description provides clear when-to-use context (dashboard display) and directs the agent to alternative tools for expansion (get_contents) and full data (export_data). Yet it still lacks a formal exclusion framework (e.g., 'use export_data when full keywords are needed') in the imperative; but the info about ref and keywords hint is 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?

Even with readOnlyHint=true, the description goes far beyond that annotation to explain the honored content budget, newest-first ordering, row-degradation mechanics, preview cap, suffix fields, ref expansion behavior, and budget_chars presence. It also covers edge cases like all-agent listings and preview-cap-0 disabling trimming. This is exemplary behavioral disclosure — the agent is fully informed about response size limits, truncation, and associated fields without having to guess.

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 long and dense, but it front-loads the core purpose in the first sentence, then structures the rest around the bug-255 behavior and its consequences. The detail is necessary for a tool with no output schema, and the organization (budget → degradation → edge cases) makes it navigable. It could arguably be trimmed, but the density is justified by the complexity of the response contract.

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, this description carries the full burden of explaining the response shape — and it does so thoroughly: rows, degradation conditions, truncation fields, ref expansion, budget_chars, and the scaling ceiling. It also covers the all-agents pairing nuance and the preview-cap edge case. The description is complete enough for an agent to correctly interpret and invoke the tool, including handling the 'ref' expansion via get_contents.

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 input schema already provides 100% coverage for all three parameters (limit, agent_id, project_id), each with descriptive text — project_id's is especially detailed. The tool description adds zero parameter-level information; it focuses entirely on response behavior. Per the rubric, with schema coverage >80%, a baseline of 3 is appropriate, and no extra value is added here.

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 clear verb-object pair — 'List recent memories for an agent' — and adds the dashboard-display context, making the tool's primary function unmistakable. While it doesn't name sibling tools, the distinction from recall/store/get_contents is evident from 'list recent' versus retrieval/storage actions. The purpose is specific and unambiguous.

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

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

The description states a clear use case: 'for dashboard display,' which implicitly signals this is for lightweight listing rather than full recall. It does not explicitly name alternatives or exclusionary conditions (e.g., 'use recall for full content'), but the dashboard-display context implies a preference for this tool over more memory-heavy operations. The guidance is adequate but could be stronger with an explicit 'use this when…' statement.

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?

The description adds behavioral context beyond the annotations by explaining that locking prevents deletion and editing. It also clarifies the conditional ownership enforcement tied to agent_id, which is not captured in the readOnlyHint, idempotentHint, or destructiveHint flags. No contradiction with annotations exists.

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

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

The description is two short sentences with no filler. It front-loads the primary purpose and immediately follows with the key ownership condition, making it efficient and easy to parse.

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 locking tool with a single required parameter, the description covers the core behavior and the important ownership nuance. No output schema exists, but little is needed because the tool's effect is straightforwardly described.

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, and the description adds value by clarifying that ownership is only enforced when agent_id is provided. This is a meaningful semantic qualifier beyond the schema's generic 'Agent ID for ownership verification' phrasing.

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 ('Lock') and resource ('a memory') and clearly states the intended effect: preventing deletion and editing. It is distinguishable from sibling tools like unlock_memory and delete_memory, so there is no ambiguity about what this tool does.

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 the tool is used when a memory must be protected from deletion or editing, but it does not explicitly state when to choose this over alternatives or when not to use it. The ownership note ('Ownership enforced when agent_id provided') gives conditional usage context, but no direct comparison to siblings is provided.

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

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

Annotations already mark the tool as non-read-only, idempotent, and destructive. The description adds useful behavioral context beyond those flags: atomicity, lack of intermediate files, and the deduplication behavior for strategy 'skip' by msg_id and summary. It does not contradict the annotations.

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 focused sentences, each adding distinct value: the operation and scope, the atomic/one-shot nature, and the deduplication rule. No fluff or repetition of schema content.

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

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

Given the 6-parameter schema and destructive annotations, the description plus schema provide enough for an agent to select and invoke the tool correctly. It could go slightly further by describing what the call returns, especially since there is no output schema, but that is a minor gap for a mutating merge operation.

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 fully documents all six parameters. The description adds minor value by detailing how the 'skip' strategy deduplicates, but it does not need to compensate for missing parameter documentation.

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 operation ('Merge memories, episodes, and profiles from one agent into another') and the exact resource scope. The phrase 'Atomic one-shot equivalent of export→import without intermediate files' strongly distinguishes it from sibling tools like export_memories and import_memories.

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 clearly implies when to use this tool: when a single atomic merge between agents is desired, avoiding the multi-step export→import flow. It does not explicitly give exclusion criteria or name alternatives, but the contrast with export/import is enough to guide selection among related 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?

Annotations only provide readOnlyHint=false, which is minimal. The description compensates fully by disclosing that the operation is non-destructive (only the channel column changes), idempotent (re-running is a no-op), that dry_run avoids mutation, and that globalize_unrecoverable moves unmatched rows to the global channel. It also explains the unrecoverable bucket behavior. No contradiction with annotations.

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 dense and long, but every clause contributes necessary operational detail: the transformation rule, the session_id format, non-destructiveness, idempotency, dry_run behavior, and the globalize option. It is front-loaded with the core purpose. A more structured list might improve readability, but the content is warranted.

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 migration tool with no output schema, the description covers all essential context: what gets rewritten, the exact session_id format, default behavior, the unrecoverable case, and the optional globalize behavior. An agent can correctly decide whether to call this tool and how to set the parameters without additional information.

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 adds value beyond the schema by explaining what dry_run=true reports (recoverable count, channels, unrecoverable bucket) and what globalize_unrecoverable does to the unrecoverable bucket. This goes beyond the simple boolean descriptions in the schema.

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

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

The description states a specific action: 'Re-channel bridge-type memories to their concrete channel', naming the resource (bridge-type memories) and the transformation (rewriting channel from session_id). It clearly distinguishes this migration utility from the sibling memory tools, which operate on individual memories or recall rather than performing a schema migration.

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 operational guidance: dry_run=true is the default and reports without mutating, while globalize_unrecoverable=true is an opt-in escalation. It also clarifies idempotency and non-destructive behavior. It does not explicitly name alternative tools or exclusion conditions, but there is no obvious sibling alternative for this migration, and the flag semantics effectively tell the agent when to use which mode.

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 only idempotentHint=true and readOnlyHint=false as annotations, the description carries the full burden of behavioral disclosure and exceeds it: it explains the no-op response shape, the authoritative `persisted: false` signal, blanked id keys, wildcard versus key-scoped pause semantics, the keyless shared bucket fallback, and the migrate_channel_axis exception. No contradiction with the annotations exists.

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

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

The description is long, but every sentence earns its place given the nontrivial semantics of scoped pausing. The critical behavior is front-loaded, with response signatures, scope rules, and edge cases presented in logical order. No filler or repeated schema content is present.

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 must explain the response shape—and it does, including `persisted: false`, `dry_run: true`, the reason field, the 'no-persist' id, and nulled id keys. It also covers TTL defaults, scoped/global behavior, resume requirements, and server boundaries, making it complete for an agent to correctly invoke and interpret the tool.

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

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

Although the schema already documents both parameters, the description adds meaning beyond the structured fields. For session_key, it clarifies that '*' is global, non-wildcard keys are partition hints rather than credentials, pauses do not stack or clear each other, and omitting the key shares a process-level bucket. For ttl_seconds, it reinforces the default and upper bound while explaining the automatic resume behavior.

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

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

The description opens with a specific verb and resource: 'Pause write operations on this MCP server for an opt-in TTL window.' It clearly names the affected write tools and distinguishes the behavior from resume_persistence and persistence_status by explicitly stating that only resume_persistence can end the pause early.

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

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

The description provides explicit use cases: 'Use for benchmarking, AB testing, or ephemeral exploration where memory contamination must be avoided.' It also gives cross-tool guidance by telling the agent to call cscheduler's pause_persistence if both servers should be paused, and clarifies which operations are not affected.

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

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

Annotations already declare `readOnlyHint: true`, lowering the burden. The description still adds valuable behavioral nuance: the status is scoped to a bucket selected by `session_key`, not the whole server, and in streamable-HTTP deployments a keyless caller may see `paused: true` caused by another session. This meaningfully goes beyond the annotation.

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?

Although the description is longer than typical, every sentence earns its place: the main question is front-loaded, and the subsequent sentences clarify non-obvious scope semantics. No filler or redundant restatement of the tool name or schema exists.

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 present, the description supplies the needed outcome expectations: paused state, TTL remaining in seconds, and scope. It also covers the one optional parameter and the tricky multi-session semantics. Nothing needed to call and interpret this tool correctly is missing.

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

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

The schema already documents `session_key` as an opaque partition hint with 100% coverage, so baseline is 3. The description adds extra meaning by connecting the parameter to response scope, explaining that omitting it shares a bucket with other keyless callers, and clarifying that it is not authentication or a data filter.

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: 'Report whether persistence is currently paused and the TTL remaining (in seconds).' It clearly distinguishes itself from broader server-wide status by emphasizing the returned `scope` is tied to a session key, so it is not ambiguous against sibling status or mutating tools.

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

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

The description gives clear usage context: it explains what happens when `session_key` is provided vs omitted, and warns that `paused: false` does not mean no other session is paused. It stops short of explicitly naming alternative tools or saying 'use this when X, not when Y,' but the inclusion criteria are strongly 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?

Beyond the readOnlyHint annotation, the description discloses substantial behavioral details: content is returned as a preview tier by default, full_content is budgeted at 200k chars, rows past the budget degrade, match_reason and gate_fallback appear conditionally, and unscored rows omit match_reason. It also exposes edge cases with bug IDs and version markers, giving an agent a genuinely accurate model of the tool's behavior.

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

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

The description is long and dense, but every sentence carries operational weight: purpose, preview behavior, budget semantics, match_reason encoding, and gate_fallback handling. It is front-loaded with the core purpose and then structured into logical behavioral blocks, though some version-specific details add reading load.

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 minimal annotations, the description carries the full burden of explaining return behavior. It covers result tiers, budget degradation, per-row match_reason structure, and the gate_fallback failure mode. For a tool this complex, the description is unusually complete for invocation and interpretation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful extra context for full_content, including the 200k-char budget and the full_content_budget_chars response field, which is not present in the schema description. This additional semantic detail justifies a score above 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?

The description opens with 'Recall relevant memories using multi-strategy search (vector + FTS5 + keyword)', giving a clear verb, resource, and method. It does not explicitly distinguish itself from the sibling tool recall_with_context, but its scope and mechanism are clearly stated.

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 useful guidance on when to use get_contents vs full_content for expanding message content, and explains the default preview-tier behavior. However, it never explicitly addresses when to choose this tool over recall_with_context or other sibling recall-related tools, leaving that comparison 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 readOnlyHint=true already covering the safety profile, the description adds substantial behavioral detail beyond annotations: deduplication, chronological ordering, preview-tiering, external_context filtering semantics, role-based merging, context_filter_only behavior, and gate_fallback low-confidence signaling. This is rich context that an agent needs to interpret the response correctly.

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 dense and long but almost every sentence earns its place given the absence of an output schema and the tool's intricate return semantics. It front-loads the core purpose before diving into caveats. It could be tightened with bullet points, but the structure is effective for the complexity.

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 10 parameters, no output schema, and several non-obvious response behaviors, the description covers dedup, ordering, preview tiers, filtering semantics, context_filter_only, and gate_fallback. It also cross-references sibling tools and known caveats like bug-211, making it about as complete as an agent needs for correct invocation and interpretation.

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 meaning beyond the schema: it explains how external_context entries filter the recall and which roles are merged into messages, and it clarifies the full_content response-budget implication. This goes beyond simply restating parameter descriptions.

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-resource pair: 'Recall memories and merge with external conversation context.' It further clarifies the value-add—deduplication, chronological sorting, and a unified list—and explicitly distinguishes itself from 'separate recall + manual merge,' making its purpose unambiguous relative to siblings like recall.

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 clearly states it replaces the separate recall-plus-merge workflow and references recall, full_content, and get_contents for alternative behavior. It does not provide an explicit 'use this when external_context is present, use recall otherwise' rule, but the merge focus and references make the intended usage context clear.

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?

The description goes well beyond the annotations by disclosing the non-obvious shared-bucket side effect: without a session_key, resuming can 're-enable writes for every other keyless session too.' It also explains what `was_active` means and that only the selected bucket is cleared. This is exactly the kind of behavioral nuance annotations do not capture, and there is no contradiction with the readOnlyHint/idempotentHint/destructiveHint flags.

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 compact and front-loaded: the first sentence states the action and return value, and the second sentence details the critical scope side effect. No sentence is wasted, and the bolded scope warning earns its place because incorrect usage could affect other sessions.

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

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

For a one-parameter tool with no output schema, the description covers the essential agent decision points: what operation occurs, which bucket is affected, what happens when session_key is omitted, and what return value to expect. The behavior is fully specified enough for correct invocation, especially with the schema's additional session_key clarification.

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 input schema already documents session_key well, including that it is a partition hint rather than authentication. The description adds value by explaining the real-world consequence of each choice: with a session_key, only your own pause is cleared; without one, the shared keyless bucket is affected. This goes beyond the schema's neutral wording and helps the agent choose correctly.

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

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

The description states a specific action: 'Re-enable persistence immediately, clearing this caller's active no-persist TTL.' It clearly identifies the resource (the caller's no-persist pause bucket) and distinguishes this tool from siblings like pause_persistence and persistence_status by its reversal semantics. It also names the return value, giving the agent a concrete outcome.

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 makes the usage context clear: this tool undoes a pause and works on either the session-specific bucket or the shared keyless bucket depending on session_key. It explains the behavioral difference between providing and omitting session_key, but it does not explicitly state 'use this instead of X' or list conditions when not to use it. This is clear context without formal exclusions.

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

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

Beyond the annotations (readOnly=false, idempotent=true, destructive=false), it explains that the gate is recalibrated immediately, the change is persisted, it is live without restart, and how named levels, raw beta, and empty values resolve. No contradiction with the annotations.

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?

Dense but organized: purpose first, then parameter semantics, then scope. It is longer than average, but every sentence carries behavioral information; minor jargon like 'knob 3' and 'separation curve' keeps it from being perfectly crisp.

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?

Complete for a mutation tool of this complexity: it covers when to use it, all parameter interactions, reset behavior, persistence, and live effect. No output schema exists, but a setter's return value is not needed to invoke it correctly.

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

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

The schema already covers all four parameters (100% coverage), so the baseline is 3. The description adds real value by defining the precision-to-beta mapping (strict/balanced/lenient -> 2.0/1.0/0.5), beta override precedence, and clearing behavior, which go beyond the schema.

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

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

The description opens with a specific verb+resource ('Set an agent's recall precision ... and recalibrate its quality gate') and later adds the distinguishing scope ('per-agent setting, not a per-recall argument'). This separates it clearly from recall-scoped siblings and from get_recall_precision.

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 exclusion — this is for per-agent settings, not per-recall arguments — and explains when the empty+beta<=0 form clears the override and returns to default. It doesn't explicitly name sibling tools like calibrate_threshold or get_recall_precision, but the context is enough for typical routing.

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

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

Annotations only provide idempotentHint and safety flags; the description adds a wealth of behavioral detail: the three result branches with exact shapes, skipped/rejected semantics, the TOCTOU dedup seam, version-migration note about ok/skipped, pause_persistence behavior with persisted:false and id:'no-persist', sanitization and size-cap rejection. This far exceeds what annotations convey and does not contradict them.

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 first sentence front-loads purpose, and nearly every clause is information-dense. However, the description is one long run-on paragraph with dense parentheticals and version notes, making it harder to parse than an equivalent bulleted structure would. Length is justified by complexity, but structure is not concise.

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

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

With no output schema, the description fully specifies return shapes and branch conditions, including embedded, truncated, persisted, id, resolved_project_id, and operating_context_warning. It also covers parameter edge cases, pause-persistence interactions, dedup behavior, and a backward-compatibility note. An agent has nearly everything needed to call it correctly.

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

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

Though schema coverage is 100% (baseline 3), the description considerably enriches each parameter: msg_id/content dedup branches, '@auto' project_id resolution with bug-186 caveats, source-type normalization and legacy shapes, metadata 8000-char cap policy, timestamp drift detection, and session_key pause partitioning. This is substantial meaning beyond the schema.

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

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

The first sentence states a specific verb and resource: 'Store a message in agent memory for future recall.' This distinguishes the tool from read/query siblings like recall and list_memories. The generic name 'store' is fully disambiguated by the description.

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 from the stated purpose — use this to persist a message for future recall — but there is no explicit when-to-use vs alternatives, no prerequisites, and no mention of sibling tools such as recall or update_memory for competing scenarios. It is implied guidance, not explicit routing.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds one behavioral trait beyond them: ownership enforcement when agent_id is provided. It does not disclose failure behavior when ownership check fails, the locked→unlocked state transition semantics, or reversibility, which a mutation tool should surface.

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 totaling 13 words with the primary action and effect front-loaded. Both sentences earn their place: the first states the operation and outcome, the second adds the ownership condition. No filler or redundancy.

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

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

For a mutating tool with no output schema, the description is thin: it omits the state transition semantics (what exactly 'unlocked' means), failure behavior when ownership fails, reversibility, and how session_key interacts with unlock. The schema's odd session_key note ('Full text on recall') is not reconciled in the description, leaving an agent with open questions for a state-changing call.

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 effectively 100%, so all three parameters are already documented and the baseline is 3. The description's agent_id note is consistent with the schema's 'Agent ID for ownership verification' but adds no new meaning; memory_id and session_key are not elaborated in the 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?

The description states a specific verb (unlock) and resource (memory) and explains the effect ('to allow deletion and editing'), which clearly differentiates it from the sibling lock_memory and from delete/update operations. It stops short of explicitly naming sibling contrast, so it misses the top score.

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 purpose clause 'to allow deletion and editing' implies when the tool should be called (before editing or deleting a locked memory), and the ownership condition qualifies agent_id usage. However, no alternatives are named and there is no explicit when-not-to-use guidance or exclusions.

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

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description discloses meaningful behaviors: rejection when locked, ownership enforcement when agent_id is provided, sanitizer max-length truncation with a truncated:true response flag, strip of [Memory from ...] annotations, and refusal of content consisting only of those annotations. This goes well beyond the structured annotations.

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 dense but every sentence earns its place: the primary action is front-loaded, followed by key edge cases (lock, ownership) and the sanitizer behavior. There is no filler or redundant repetition of schema 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 four parameters, no output schema, and rich annotations, the description covers the critical operational details: what happens on locked memories, ownership semantics, sanitizer behavior, truncation signaling, and refusal of annotation-only content. Nothing essential for correctly calling the tool is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra meaning beyond the schema by explaining that the sanitizer caps content length, sets truncated:true, and strips annotation prefixes, and that ownership is enforced only when agent_id is provided. These details enrich the parameter semantics beyond the schema descriptions.

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 'Update memory content by ID', a specific verb and resource that clearly states the tool's function. It further distinguishes itself by noting lock rejection and ownership enforcement, which separates it from store, delete_memory, and lock_memory siblings.

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

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

The description implies when to use the tool through context like 'same sanitizer as store', but it never explicitly states when to use this tool versus alternatives such as store or lock_memory. The usage context is clear but no exclusions or alternative routing are provided.

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?

The description goes beyond the annotations by disclosing the 2000-character cap, the truncated:true response flag, the sanitizer behavior shared with store, and that discarded content is not stored elsewhere. This gives the agent actionable information about side effects and output, though it does not describe auth needs or full response behavior.

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

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

The description is reasonably concise and front-loaded with the core purpose, then adds the critical truncation behavior. The phrasing 'when the cap bit — branch on it' is slightly awkward, but every sentence contributes meaningful information without redundancy.

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

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

For a simple save operation with no output schema, the description covers the main behavioral caveat the agent must handle: truncation and the truncated:true flag. It does not specify the success response shape or whether an existing profile is overwritten, which are minor gaps but not blocking for invoking the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by naming the constant CPERSONA_MAX_PROFILE_LENGTH, mentioning the shared sanitizer, and warning that the discarded remainder is not persisted. It does not add detail on session_key, but the schema already explains it adequately.

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

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

The description clearly says the tool saves a pre-computed agent profile to the database, with a specific verb, resource, and scope. It does not explicitly differentiate update_profile from its sibling store, though the 'pre-computed' qualifier and the reference to store's sanitizer imply a distinct role.

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 intended use is implied: call this when you already have a pre-computed agent profile to save. However, it does not explicitly state when to prefer this over store or any other sibling, nor does it give exclusions or alternatives.

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