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, the description carries full burden. It discloses that the tool searches a derived semantic index, returns specific fields, and explains that the projects parameter does not change active bind (read-only). It implies read-only nature but doesn't explicitly state no side effects, which is a minor 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 concise at three sentences, front-loading the purpose. Each sentence adds meaningful information without redundancy. It efficiently covers purpose, result fields, index behavior, and parameter nuances.

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 5 parameters, no output schema, and no nested objects, the description adequately covers purpose, edge cases (unindexed projects), and parameter interactions. However, it does not describe the output format in detail beyond listing fields, and lacks mention of pagination or ordering, which are minor omissions.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value beyond schema by explaining the interplay between 'project' and 'projects' parameters, the federation behavior, and the implication of unindexed projects. This provides behavioral context that the schema descriptions lack.

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 'Search only the derived semantic code index,' specifying the tool's unique function. It lists result fields and distinguishes from sibling tools like rms_search by emphasizing the 'derived semantic code index' and mentioning 'read-only cross-project code federation.'

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 on when to use the tool (for semantic code search), mentions that the code index is optional and unindexed projects return empty results, and explains the behavior of project parameters and federation. However, it lacks explicit guidance on when not to use this tool versus alternatives like rms_search.

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?

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?

Without annotations, the description carries the full burden. It discloses RRF behavior, abstention logic, content bounding, and cross-project federation rules. Missing explicit read-only declaration but implied by 'search' and 'read-only federation'. Rate limits or auth not mentioned but not critical for a search tool.

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

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

Three dense sentences with no wasted words. Front-loaded with purpose and return envelope. Every sentence adds crucial behavior detail (RRF, federation, abstention, budget). Perfectly sized for a tool with 9 params and complex logic.

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 no output schema, the description adequately explains the return envelope. Parameter count 9, all covered. Edge cases (err on missing cross_project_vault, abstention, project preference) are documented. An agent can correctly invoke the tool without additional knowledge.

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

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

Schema coverage is 100%, so baseline is 3. The description adds substantial meaning: explains RRF rationale, project vs projects precedence, error condition for cross_project_vault, abstention when min_score set, and content truncation with max_chars. This goes far 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 clearly states the tool searches RMS Memory and returns a decision envelope. It distinguishes from siblings by specifying three corpora (vault, code, all) and explaining RRF for 'all', which differs from rms_code_search (which likely only searches code) and read 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 usage context: e.g., setting min_score to force abstention, caution about min_confidence, and prerequisites for cross-project federation. However, it lacks explicit when-not-to-use guidance or comparison to alternative search tools like rms_read or rms_code_search.

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?

Annotations are absent, so the description carries full burden. It fails to disclose behavioral traits such as whether writes are idempotent, how the vault handles duplicate paths, or if there are side effects. The description is too brief to inform the agent about write behavior beyond the purpose.

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 superfluous text. The first sentence defines purpose and scope; the second provides 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?

For a tool with 10 parameters and no output schema, the description lacks details on what happens after writing (e.g., return value, error handling). It covers when to use but not enough about the complete usage context.

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

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

Schema coverage is 90%, so the schema already documents most parameters well. The description adds minimal extra meaning (e.g., 'proactively' hints at timing) but does not elaborate on parameter relationships or usage tips. It meets the baseline for high coverage.

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's purpose ('Save new architectural decisions... to the RMS Memory vault') and provides specific examples of when to use it. It distinguishes from sibling tools like rms_read and rms_search by focusing on writing 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?

The description explicitly instructs to use the tool 'PROACTIVELY at the end of a task' and lists concrete scenarios (new user preference, solved bug, architectural decision). However, it does not mention when not to use it or compare directly with alternatives.

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