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

With no annotations provided, the description carries the full burden. It discloses key side effects: status change, dropping from recall, and writing a durable note. Lacks detail on error behavior or permissions, but is reasonably transparent for a simple closure operation.

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

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

A single, well-structured sentence that immediately conveys the core purpose and side effects. No wasted words.

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 100% schema coverage and no output schema, the description adequately explains the tool's behavior. It could mention that the checkpoint must exist, but the required 'name' parameter implies that. Overall, it provides sufficient context for an agent to invoke 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 description adds no extra parameter information beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states the verb (close) and resource (checkpoint), and describes the specific actions: marking status as done, dropping out of recall, and writing a session summary note. It effectively distinguishes from siblings like rms_checkpoint_save.

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 explicit guidance on when to use this tool versus alternatives, such as rms_checkpoint_save or rms_checkpoint_query. No context on prerequisites (e.g., checkpoint must exist and be open).

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It indicates a read-like operation ('load'), but does not explicitly state whether it has side effects, requires authentication, or any other behavioral traits beyond the implied reading of checkpoints.

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 with no wasted words. The first sentence delivers the core purpose, and the second provides immediate, actionable usage guidance. Front-loaded and efficient.

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 absence of output schema, the description provides a reasonable overview of what the tool returns ('full body and bounded previews'). It also relates to its sibling tools by specifying the prerequisite query step. Could be slightly more explicit about the return format, but sufficient for a load 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 already documents both parameters. The description adds minimal extra meaning: it implies the 'name' comes from the query tool's results, but does not add details about format or constraints for the parameters.

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

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

The description clearly states the verb 'load' and the resource 'checkpoint', specifying it loads the full body and bounded previews of linked notes, which distinguishes it from the sibling tool 'rms_checkpoint_query' that presumably lists or searches checkpoints.

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 advises to use 'rms_checkpoint_query' first to find checkpoint names, providing a clear prerequisite. However, it does not specify when not to use this tool or mention any alternatives beyond the prerequisite.

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

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

With no annotations provided, the description carries the full burden. It discloses that checkpoints are returned newest first, with full pending text, and filtered by status. However, it does not mention pagination, limits, or what happens if no checkpoints match, leaving some behavioral gaps.

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 sentence, efficiently packed with key information: purpose, ordering, content, and filtering. Every word earns its place, and the structure is front-loaded with the main action.

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 tool's simplicity (list checkpoints with filter) and absence of output schema, the description covers sorting, content, and filtering adequately. It could mention pagination or maximum results, but overall it provides enough context 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 coverage is 100% and both parameters have descriptions. The description adds value by stating the default value for 'status' ('default all') and explaining when the 'project' parameter is needed ('when the MCP client did not provide a workspace root'). This goes 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 clearly states the verb ('List'), the resource ('checkpoints'), the context ('for the current project'), and key attributes ('newest first', 'with full pending text'). It also specifies a filter parameter, making the tool's function unambiguous and distinguishing it from siblings like rms_checkpoint_load.

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 for listing checkpoints with filtering, but does not explicitly state when to use this tool versus alternatives (e.g., when to use rms_checkpoint_load instead). However, the context is sufficiently clear from the sibling tool names and the description of the filter options.

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

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

No annotations are provided, so the description carries the full burden. It discloses important behavioral details: that it can create or update, and that updating preserves id/created_at and keeps omitted fields. However, it does not explain the exact behavior for creating vs updating (e.g., how it decides), error handling, or authorization requirements.

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

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

The description is three sentences long, each providing essential information: the action and location, the usage timing, and the behavioral nuance on update. There is no redundancy or unnecessary detail, making it very efficient.

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 complexity (5 parameters, no output schema), the description covers the core functionality but leaves gaps. It does not explain the return value, error conditions, or prerequisites. The behavior for creating versus updating is implied but not fully specified, so the description is adequate but not comprehensive.

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 clarifying the file naming convention ('artifacts/checkpoints/<name>.md') and that the checkpoint status is 'active'. This provides helpful context that the schema alone does not convey.

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 creates or updates a session checkpoint, specifying the file path and status. It is specific about the action and resource, but it does not strongly differentiate from the sibling tool 'rms_checkpoint_done', which might mark a checkpoint as completed. However, the purpose is still clear and actionable.

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 explicit guidance on when to use the tool: 'Save before context compaction or a long pause so work can be resumed.' This provides a clear context for usage. However, it does not mention when not to use it or provide alternative tools, leaving some ambiguity for the agent.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well by noting that the index is optional, that unindexed projects yield an empty list, that `projects` is read-only, and that the active bind is not changed. These are meaningful behavioral details beyond the basic 'search' action.

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 four sentences, each earning its place: scope, result contents, index-availability caveat, and federation behavior. The most important differentiator is front-loaded in the first sentence, and no filler or redundant restatement of the tool name 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?

For a search tool with no output schema, the description covers output fields, an important edge case (empty results for unindexed projects), and federation semantics. The remaining details like limits and inclusion flags are fully described in the input schema. Nothing critical is missing for an agent to invoke this 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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds contextual color like 'read-only' and 'does not change the active bind,' but the precedence rule for `project` vs `projects` is already in the schema. This is a baseline case where the description mostly reinforces, not extends, the parameter guidance.

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: 'Search only the derived semantic code index.' This clearly distinguishes the tool from general search tools like rms_search and states exactly what domain it operates on. The result fields are also enumerated, making the tool's purpose concrete.

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 the tool is useful: it searches only the derived semantic index)Skip and warns that unindexed projects return empty results. It also explains the `projects` parameter for cross-project federation and the precedence rule. However, it does not explicitly name an alternative tool or state when to prefer rms_search over this one.

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

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

No annotations are provided, so the description carries full burden. It discloses that it returns structured JSON and that the repair flag is conditional, and it mentions 'refuses sticky-bind repair'. However, it does not explicitly state whether the tool is read-only beyond the repair flag, nor does it mention required permissions or side effects on the vault.

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 sentences, front-loading the purpose and output format, with the usage constraint in the second. No redundant wording.

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

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

For a two-parameter tool with no output schema, the description covers the seven diagnostic areas, notes that output is structured JSON, and provides a safety constraint. It could elaborate on what the diagnostics examine or any prerequisites, but it is sufficient for an agent 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?

Schema coverage is 100%, so both parameters are already described. The description adds the conditional requirement 'only with an explicit project,' which is already in the schema, and adds 'refuses sticky-bind repair,' which is behavioral rather than parameter-specific. Thus it adds minimal value 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 'Run' and resource 'seven-point vault health diagnostics' and enumerates the seven checks (structure, IDs, links, LanceDB, wiki isolation, registry, freshness). It clearly distinguishes from siblings by focusing on diagnostics rather than sync, search, or write operations.

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 does not explicitly mention when to use this tool vs siblings, but it provides a key usage constraint for repair_frontmatter (requires an explicit project). The overall context of when to run diagnostics is implied but not stated, so guidance is partial.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by stating 'no shell', lazy catch-up on query, default omission of commit messages, and commit-count budgets on catch-up/reindex. It does not detail side effects of reindex or exact budget behavior, but the disclosed behaviors are materially useful and not contradicted by any 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?

The description is compact and front-loaded: it opens with the core purposeable, then gives preference guidance, action context, defaults, and constraints. Every sentence adds distinct information without fluff or repetition, making it well-structured for quick agent scanning.

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 tool has no output schema)Skip the description explains the key operation, actions, defaults, and constraints, so an agent can select and invoke it correctly. The main gap is that return shape beyond commit messages is not described, such as which commit fields are included, but the schema and description are otherwise adequate for safe use.

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 parameter semantics baseline is 3. The description reinforces action semantics such as 'use action=reindex' and 'requires explicit project', but it does not add meaning beyond what the schema already documents. The schema itself carries the parameter documentation load.

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 precise operation and resource: 'Query the derived code_path git file→commit history cache (no shell).' This clearly identifies what the tool does and sets it apart from generic shell-based git commands or other search-style read tools. The phrase 'file→commit history cache' leaves no ambiguity about the purpose.

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 explicit when-to-use guidance: 'Prefer this over `git log` for when a source file changed.' It also provides conditional action guidance, saying to use reindex after a force-push/rebase and that it requires an explicit `project`. This is strong routing and selection guidance.

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

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

With no annotations, the description carries the full burden and does add meaningful behavioral detail: mutations require explicit `project`, ensure only reconciles when empty or `force=true`, path uses BFS, and semantic edges are ephemeral. It does not disclose return shapes, side effects, or error behavior, but the key operational traits are present.

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 dense paragraph, but every clause earns its place: the operation type, action list with key semantic annotations, mutation requirement, and usage guidance. It is front-loaded and efficient, though the packed action list is somewhat hard to scan.

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 19 parameters, 10 actions, and no output schema, the description gives a solid action overview but not full contextual completeness. It lacks action-specific return expectations, node/edge key format guidance, and sequencing advice such as 'call status first,' leaving the agent to infer some behavior from parameter names.

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 and the schema already documents all 19 parameters. The description adds some grouping value by associating actions with relevant parameters and flagging `project` as required for mutations, but it does not substantially compensate 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 clear verb-resource pair ('Query and mutate the durable Markdown/code knowledge graph') and then enumerates the specific actions. It also distinguishes itself from the search siblings by stating it is for dependency traversal, so an agent can tell it apart from rms_search and rms_code_search.

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 explicit usage context: 'Prefer this for dependency traversal instead of guessing from search alone,' which names the alternative and the condition for choosing it. It does not enumerate when not to use the tool or contrast with the other siblings like rms_read or rms_write, so it stops short of a full 5.

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

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

With no annotations, the description provides crucial behavioral info: fail-closed on missing project context, single-project scope. This goes beyond basic purpose and helps the agent understand failure mode and constraints.

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?

Extremely concise: two sentences plus a note. Front-loaded with the key purpose and outcome. Every sentence adds information without fluff.

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 overview tool with no output schema, the description sufficiently explains what the tool returns and its failure conditions. No additional context needed for effective 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%, baseline 3. The description adds value by explaining when 'project' is needed (when no workspace root) and setting context for usage, improving parameter understanding beyond 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 clearly states it provides a 'structured orientation summary for exactly one project' including specific elements like document counts, recent notes, and active checkpoints. It distinguishes from sibling tools like rms_checkpoint_load and rms_search.

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 advises 'Call this at session start' and notes fail-closed behavior requiring a bound workspace or project key. Does not list alternatives but the constraint 'never aggregates across projects' helps decide when not to use.

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

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

No annotations are provided, so the description carries full behavioral disclosure burden. The description only mentions that the tool works without a workspace root but does not disclose whether it is read-only, requires authentication, has rate limits, or returns cached data. For a tool with no annotations, this is insufficient.

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 consists of two short sentences with no wasted words. The first sentence states the purpose, and the second adds a crucial contextual note. 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 simple tool with no parameters and no output schema, the description is moderately complete. It explains the tool's output (list of project keys) and a key behavior (works without workspace root). However, it does not describe the return format or whether the list is sorted or filtered, leaving some ambiguity for the agent.

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 the baseline is 4. The description does not need to add parameter information, and it correctly avoids extraneous detail.

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

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

The description clearly states it lists RMS Memory project keys, with a specific verb ('List') and resource ('registered RMS Memory project keys'). The additional note about working without a workspace root helps distinguish it from tools that may require one, though it doesn't explicitly differentiate from its 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 usage when a workspace root is missing ('works even when the MCP client did not provide a workspace root'), but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternative tools among the 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?

With no annotations, the description carries the full burden. It discloses the critical safety behaviors: defaults to a dry run and never deletes notes. It also specifies the archive destination. It does not clarify whether archiving moves or copies notes, and omits permission requirements, but the core safety profile is transparent enough for safe invocation.

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

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

Two sentences, no fluff. The first sentence captures purpose and the dry-run default; the second reinforces the non-destructive nature. Key constraints are front-loaded, and 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?

For a three-parameter tool with all optional params and no output schema, the description covers the essential intent and safety. It leaves out details like the project parameter's fallback usage and the exact output/return behavior, but those are either in the schema or not critical for correct invocation. The description is sufficiently complete for an agent to call the tool safely.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds minimal extra meaning—it maps 'apply=true' to the archive action and 'retention window' to age, but these are largely redundant with the schema descriptions. It does not elaborate on the `project` parameter's purpose beyond what the schema states.

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

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

The description states a specific verb ('Find'), a precise resource ('superseded vault notes'), a retention condition ('older than a retention window'), and an optional action ('archive them'). It also clearly distinguishes itself from sibling tools like rms_search and rms_code_search by focusing on pruning/archiving, not retrieval or editing.

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 the tool (to identify and optionally archive superseded notes) and explicitly states the dry-run default and the `apply=true` switch to finalize. It does not explicitly name alternatives or say 'do not use when...', but the purpose is self-evidently distinct from the search and write tools.

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

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

No annotations are provided, so the description carries the full burden. It states the tool reads content and implies no side effects (e.g., noPromote parameter notes vault reads are side-effect free). However, it lacks details on authentication, rate limits, or response format, making it minimally adequate.

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 consists of two concise sentences that are front-loaded with the key action and resource. Every sentence adds value with no waste.

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 4 parameters, no output schema, and no annotations, the description covers the main usage (path and retrieval context) but fails to mention the 'id', 'project', and 'noPromote' parameters. The schema partially covers these, but the description could be more complete by briefly explaining optional parameters.

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 75% (3 of 4 parameters described in schema). The description adds emphasis on the 'path' parameter but does not provide new meaning beyond the schema for 'project' and 'noPromote'. The 'id' parameter is not described in either the schema or the description, so the description does not fully compensate for the gap.

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

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

The description clearly states the verb 'Read' and the resource 'full contents of a markdown document from the RMS Memory vault'. It distinguishes itself from sibling tools, especially rms_search, by specifying that it is used to retrieve the full context of a document found via search.

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 tells when to use the tool: after finding a document via rms_search, to retrieve its full context. It does not provide explicit exclusions or alternatives, but the context is clear 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It clearly warns that the operation is destructive to derived tables and requires explicit project selection, which are critical behavioral traits. It does not detail side effects like downtime or reversibility, but the core destructive behavior is transparent.

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 with no filler. The destructive warning and the required project condition are front-loaded, and the alternative tool is named efficiently. 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?

Given only two parameters, no output schema, and no annotations, the description covers purpose, destructiveness, a required parameter, and the preferred alternative. It does not mention return behavior or further operational impacts, but for a simple reindex tool the core information an agent needs is present.

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 both parameters are already documented in the schema. The description adds context about full rebuild and 'vault and/or code indexes,' which loosely maps to the corpus parameter, but it does not provide additional parameter-level detail beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Full rebuild of vault and/or code indexes.' It clearly identifies the destructive nature and differentiates from rms_sync by naming the alternative. An agent can distinguish this tool from siblings without inspecting 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 explicitly says to prefer rms_sync for incremental catch-up, which tells the agent when not to use this tool. It also emphasizes that an explicit project is required, giving a clear prerequisite. This is strong usage guidance.

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

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

With no annotations, the description carries the full burden and delivers: it discloses the decision envelope (`inject|abstain`, `injected_ids`, `results`), fail-closed abstention when `min_score` is set, hard errors on invalid `cross_project_vault` usage with no silent degrade, RRF combination rather than raw vector distances, and `max_chars` bounding. These are substantive behavioral traits beyond a simple 'search' statement.

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 organized: purpose and return envelope first, then corpus semantics, then federation constraints, then threshold and bounding behavior. Every clause earns its place, and there is no redundant 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?

Despite having 11 parameters and no output schema, the description plus the rich input schema provide enough for an agent to select and invoke the tool correctly. It specifies the return envelope, key failure modes, federation constraints, and result-bounding behavior, leaving no critical invocation gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining RRF combination for `corpus=all`, the compatibility rationale for `projects` winning over `project`, and the hard-error policy for vault/all federation. These are useful additions, though most individual parameter details already live 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 opens with a specific verb and resource ('Search RMS Memory') and immediately gives the decision envelope, which makes the tool's role clear. However, it never explicitly differentiates itself from the sibling `rms_code_search` even though `corpus=code` overlaps with that tool, so sibling differentiation is only implicit.

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 concrete selection context: `corpus=vault` vs `corpus=code` vs `corpus=all`, when to pass `projects` for read-only cross-project federation, and the precedence rule when both `project` and `projects` are set. It stops short of a 5 because it does not explicitly name alternatives or state when not to use this tool in favor of a sibling.

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

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

No annotations are present, so the description must disclose behavior; it only says 'incremental' and CLI equivalence, but doesn't state side effects, whether it mutates the index, required environment, or failure modes.

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

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

Two sentences, front-loaded purpose, no filler; the CLI parenthetical gives a concrete anchor without bloating.

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 single-optional-param tool the basics are covered, but absent annotations and output schema leave behavior (index mutation, incremental semantics) unexplained. It is minimally adequate.

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

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

Schema coverage is 100% and already explains the project fallback. The description adds a practical 'prefer project in multi-root' heuristic, which is useful but minimal.

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 action (incremental sync) and resource (vault index), and the CLI equivalence helps identify it. Does not name a sibling, but 'incremental' distinguishes it from a full reindex.

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?

Only guidance is a condition for setting the `project` parameter. It says nothing about when to choose sync over sibling tools like rms_reindex or rms_prune.

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

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

With no annotations, the description carries the full burden. It accurately describes the tool as returning a protocol, implying a safe read operation. While it doesn't explicitly state no side effects, the nature of the tool makes that clear.

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

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

Two sentences, front-loaded with the main action, and no wasted words. 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 tool with one optional parameter, no output schema, and no annotations, the description is sufficiently complete. It covers purpose and benefit without needing additional detail.

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

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

Schema coverage is 100%, so the description adds no meaning beyond what the schema provides for the single 'project' parameter. Baseline 3 is appropriate.

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

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

The description clearly states it returns the canonical RMS Memory usage protocol, with a specific verb and resource. It distinguishes from sibling tools by mentioning self-bootstrapping without injected rule files, which is unique among the listed 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 the tool is for initial self-bootstrapping, but does not explicitly state when to use it versus alternatives like rms_search or rms_checkpoint_load. There is no guidance on exclusions or prerequisites.

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

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

With no annotations provided, the description bears full burden for behavioral disclosure. It does not mention side effects (e.g., whether the vault or code index are modified), authorization needs, or rate limits. The 'refresh_code' parameter hints at a potential write action but is not explained.

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

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

Two sentences, zero waste. The purpose is front-loaded and every word adds value. No redundant phrasing or padding.

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

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

Given the lack of an output schema, the description should explain the return material format or structure. It only says 'Returns material', which is vague. For a tool that generates a pack, an agent needs to know what to expect (e.g., a path, file list, or structured data) to use the output effectively.

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 marginal value beyond the schema by framing the pack as 'for an agent to create human-readable documentation', but does not clarify how parameters like 'refresh_code' affect output. Schema already describes each parameter 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?

Description clearly states the tool generates a 'wiki context pack' from vault and code index, distinguishing it from siblings like search or read tools. The verb 'Generate' and resource 'wiki context pack' are 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?

No explicit guidance on when to use this tool versus alternatives like rms_search or rms_code_search. It does not state prerequisites or when not to use it, leaving the agent to infer usage from the name.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, yet only states that the tool saves content. It does not mention side effects such as writing to disk, adding to the index, mode-specific overwrite/append behavior, or soft-superseding behavior, all of which an agent must know for a write operation.

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

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

Two sentences deliver the core purpose and the key usage trigger with no filler. The primary action is front-loaded and the proactive usage cue is placed immediately after.

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 tool is complex (11 parameters, no output schema, no annotations) and the description only covers purpose and one usage pattern. It omits expected return values, operational side effects, and how modes (create/append/replace) affect behavior, leaving a substantial gap for a write 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 91%, so the input schema already documents the 11 parameters in detail. The description adds high-level context about what kind of content belongs in the vault, but no parameter-specific meaning beyond the schema, matching the baseline 3.

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 ('Save') and a concrete resource ('new architectural decisions, constraints, development rules, or project context') targeted at the RMS Memory vault. This clearly differentiates the tool from the read/search/prune siblings, which operate on the same vault but do not write.

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 explicit when-to-use conditions: 'Use this tool PROACTIVELY at the end of a task if you learned a new user preference, solved a tricky bug, or made a new architectural decision.' It does not offer when-not-to-use guidance or name alternatives such as rms_checkpoint_save, so it stops short of the full 5.

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