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

With zero annotations the description carries the full burden and largely discharges it: it discloses the side effect of every resolution ('memory no longer injected', 'archives the peer source_url', 'stops reminding'), states that memory_wins leaves the edit to the user's rule file, and marks explain as read-only. These are exactly the mutation/destructiveness facts an agent needs before acting.

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

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

Front-loaded and logically ordered into three numbered classes, but the entire content is duplicated in Chinese, roughly doubling length without adding information for a single-language reader. The resolution explanations are dense run-on clauses rather than scannable structure.

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 nine-parameter, no-annotation, no-output-schema tool, the description explains conflict classes, resolution semantics, and the read-only explain path — enough to act safely. It still omits the 'scan' action entirely and says nothing about what list returns or how paging interacts with status filtering.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine meaning beyond it by tying each resolution value to the conflict class it applies to and to its real-world effect, and by stating conflict_id is required for explain. It does not cover limit/offset/status/bootstrap_run_id, but the schema already documents 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?

Opens with a specific verb pair plus resource ('List or resolve suspected conflicts') and then partitions the domain into three named conflict classes with their own vocabularies. Nothing in the sibling list (rsi_review, rsi_memory_health, rsi_knowledge_review) could be confused with this, since the description names its own artifact — a conflict card with resolution options.

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?

Strong guidance for the explain path ('Call explain first when the user wants detail; do not close the card') and implicit guidance for choosing a resolution per conflict class. However, the action enum includes 'scan' and the description never mentions scanning at all, and there is no stated condition for choosing list versus resolve versus scan.

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 behavioral burden. It discloses the return shape well: top-level modules with counts, member items with title/brief/id, and related/conflicts graph edges. It does not explicitly state read-only/no-side-effects or pagination behavior, so it falls short of a 5.

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

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

The English portion is front-loaded and efficient, covering behavior, output shape, and the rsi_recall handoff. The full Chinese translation duplicates the same information, which adds length without adding new semantics for a single-language reader.

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

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

There is no output schema and no annotations, yet the description explains both top-level and drill-down return contents, including member fields and graph edges. It also tells the agent how to get full content afterward, which is enough 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 description coverage is 100%, so path, depth, and limit are already documented. The description restates the empty-path behavior and examples already present in the schema, adding little parameter meaning beyond the structured fields.

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

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

States a specific verb and resource: navigating the knowledge tree by domain module. It clearly distinguishes browsing behavior from full-content retrieval by naming rsi_recall as the follow-up tool.

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

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

Gives explicit usage conditions: an empty path lists top-level modules, while a path such as backend or backend/api drills down. It also directs agents to rsi_recall for full content, but does not contrast with other siblings such as rsi_knowledge_search or state 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?

With no annotations, the description must carry the full behavioral burden; it usefully discloses that a rejected action's comment is extracted as a prohibition, a persistent side effect. However, it omits other important behavior for a write operation: token lifetime, idempotency, what confirmation is returned, and how rating and action interact beyond a schema note.

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 purpose is front-loaded, but the entire description is duplicated in Chinese, which adds length without new information for an agent that reads the English text. The two sentences are not wasteful individually, but the bilingual duplication weakens conciseness.

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 feedback-writing tool with no annotations and no output schema, the description covers the action taxonomy and the key rejected→prohibition consequence. It does not explain whether a success confirmation is returned, whether the feedback_token expires, or what permissions are needed, leaving gaps an agent would want closed.

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

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

Schema description coverage is 100%, so all five parameters already have documented meaning, including the enum and the modified_content diff-ratio note. The description adds little beyond restating the action vocabulary and the rejected-comment rule, making baseline 3 appropriate.

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

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

States a specific verb+resource ('Submit feedback on a recall') and enumerates the exact action vocabulary, so an agent can identify the operation without opening the schema. It does not explicitly contrast itself with siblings such as rsi_recall, but the purpose is distinct enough to infer.

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

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

Usage is implied by the required feedback_token ('from rsi_recall'), but the description never says explicitly to call this after a recall or what alternatives exist. The rejected/comment rule is a behavioral detail rather than when-to-use 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 well: it explicitly warns that RSI cannot see real host token usage and that a savings number is only produced when ab is supplied, and it discloses that export=true writes a markdown file to ~/.rsi/exports/. It omits one notable side effect — the snapshot flag persisting a daily aggregate — which is only disclosed in the schema, not the description.

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

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

The content is front-loaded and the honesty constraint is well placed, but the entire text is duplicated verbatim in Chinese, roughly doubling length for an English-reading agent without adding information. Redundancy costs it points even though no individual sentence is wasted.

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

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

For a 4-parameter, dependency-free reporting tool with no output schema, the definition covers the main inputs and the key limitation. The remaining gap is that the return payload's shape (what the 'panel' actually looks like) is only gestured at, and snapshot behavior is delegated entirely to the schema.

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 baseline is 3; the description goes beyond it by spelling out the nested ab shape (baseline/treatment with tokens and tasks) and, more importantly, the precondition that numbers must come from the host's own reported usage rather than being estimated. period and snapshot are left to 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?

It names a concrete deliverable — a value/impact panel composed of cost, recall value, behavioral gains, a time curve, and an A/B calculator — so an agent knows exactly what it produces. It does not, however, distinguish itself from the sibling rsi_stats, which plausibly also returns statistics, leaving overlap ambiguous.

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

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

The phrase 'for evangelism' and 'a one-page markdown' imply the presentation/reporting scenario, and the ab condition is stated precisely. But there is no explicit when-not-to-use or routing versus rsi_stats / rsi_memory_health, so selection among siblings is left to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: not whether new items are pending review, deduplicated, indexed for recall, or what permissions are needed. For a write tool with 10 parameters and a review sibling (rsi_knowledge_review), the absence of lifecycle context is a real 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?

Short and front-loaded with zero padding beyond the bilingual repetition, which duplicates the same sentence rather than adding information. The size is appropriate, but the second sentence earns no new 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?

With 10 parameters, no annotations, and no output schema, an agent still cannot tell what happens after a successful add or how optional fields like trigger_condition and expiry_condition interact with the record's lifecycle. The description is far too thin for a 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?

Schema description coverage is 100%, so every parameter is already documented, and the description only repeats the two required ones. Baseline 3 applies; the description adds no interpretation of conditional fields like pack_id or expiry_condition beyond the schema.

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

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

States a specific verb and resource ('Add a knowledge item') and names the two required fields, which is enough to distinguish it from rsi_knowledge_update and rsi_knowledge_delete. It does not, however, differentiate it from rsi_memory or rsi_learn, which could plausibly also write knowledge.

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

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

There is no guidance on when to add a new item versus updating an existing one (rsi_knowledge_update) or when this tool is appropriate at all. The only condition mentioned is that title and content are required, which is already in the schema.

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

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

With no annotations, the description carries the behavioral burden. 'Delete' makes the destructive nature clear, and '(deletion right)' implies an authorization requirement, but the description does not state whether deletion is permanent, what happens to related records, or what errors to expect if the item does not exist.

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 very short and front-loaded with the core action. The Chinese translation duplicates the English content, which may be intentional for bilingual users but slightly reduces conciseness.

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 one-parameter tool with full schema coverage, the description covers the basic action and hints at permission. However, because this is a destructive operation with no annotations or output schema, it should more clearly describe the consequences of deletion and any irreversibility.

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 single 'id' parameter is already documented in the schema. The description adds no content about parameter format or semantics beyond what the schema provides, which meets the baseline 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?

The description states a specific verb and resource: 'Delete a knowledge item.' It is clear what the tool does, but it does not explicitly differentiate itself from sibling tools such as rsi_knowledge_update or rsi_knowledge_add.

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 no guidance on when to use this tool versus alternatives, nor any exclusion criteria. The parenthetical '(deletion right)' hints at a permission prerequisite, but it does not explain usage conditions.

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 and does useful work: it discloses that approve relocates files to official directories and injects prohibitions, that reject archives rather than deletes, that no new bodies are created, and that approved conventions are recall-only with no rule files written. It does not mention irreversibility, permission needs, or what 'skip' does behaviorally.

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?

Each sentence is front-loaded and earns its place, with the side effects stated before the caveats. However, the entire text is then repeated verbatim in Chinese, roughly doubling length without adding information for a monolingual reader.

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

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

For a 7-parameter mutation tool with no annotations and no output schema, the description covers side effects well but omits the skip action and the entire batch-approval surface (all_pending, content_type, bootstrap_run_id, include_archived). An agent could not infer from the prose alone that bulk approval exists.

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; every parameter including skip, ids, all_pending and bootstrap_run_id is already documented in the schema. The description adds nothing beyond echoing the approve/reject semantics that the action enum already encodes.

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 specific verb and resource ('Approve pending norms') and spells out the result of each action (approve moves files and injects prohibitions, reject archives). It does not differentiate itself from the sibling rsi_review, which an agent would also consider for review-like work.

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

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

Usage is only implied: it is clearly the tool for acting on pending items, but there is no statement of when to prefer it over rsi_review, rsi_knowledge_update or rsi_conflicts. The 'skip' action and the batch modes (all_pending, bootstrap_run_id) are entirely absent, so the agent gets no guidance on those paths.

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

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

With no annotations, the description carries the full burden. It does disclose something genuinely useful about matching behavior (default pure FTS5 + CJK bigram, embedding as optional enhancement), but says nothing about read-only safety, ordering/ranking, result size behavior, or permissions — gaps that matter for a search tool with no output 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?

Front-loaded with the core action, but the entire sentence is duplicated in Chinese with no added information, roughly doubling length for a one-line tool. No wasted hedging beyond that, but the parallel-language repetition is pure redundancy for a token-sensitive agent.

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?

A read-only, 3-parameter search with fully documented parameters and no output schema needs modest description — and this covers the mechanism but not what comes back (count, ranking, snippet format) or how to choose between the default FTS mode and the optional embedding path. Adequate but with clear gaps given a crowded sibling set.

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 query, role and top_k are already documented in structured form; baseline 3 applies. The description adds no syntax hints (e.g., quoting, CJK tokenization implications of the bigram mode) or guidance on how role/top_k interact with the search mode.

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

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

States a specific verb and resource ('Search the knowledge base') and adds the retrieval mechanism (FTS5 + CJK bigram, optional embedding), which clearly separates it from the write-side siblings rsi_knowledge_add/update/delete. It does not differentiate itself from read-side siblings such as rsi_recall or rsi_explore, so an agent still cannot tell which retrieval tool to pick.

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 when-to-use or when-not-to-use guidance, no mention of prerequisites, and no routing among the many sibling retrieval tools. The only usage-like signal is the incidental note that embedding is optional, which concerns internals rather than selection.

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 zero annotations the description carries the full load and does well: it discloses that merge archives rather than hard-deletes (recoverable), writes a supersedes edge, preserves id and location, and defaults keep_id to the longest/newest entry. It doesn't cover error behavior for a missing id or what the response contains, which for a mutation tool leaves a small 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 English sentence is front-loaded with the core action and the merge semantics follow logically. The full Chinese restatement roughly doubles the length without adding new information, which is a deliberate bilingual choice but still dilutes density.

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

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

For a 12-parameter mutation tool with no annotations and no output schema, the description covers the essential risk surface: partial vs whole-field replacement, recoverability of merge, and identity preservation. It stops short of stating failure modes (nonexistent id, conflicting keep_id) or what a successful call returns.

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 every one of the 12 parameters is already documented in the schema, including id/ids requirements and the action enum. The description restates the field list and merge semantics but adds no format or constraint detail beyond what the schema already provides, so the baseline applies.

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

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

States a specific verb and resource (update an existing memory in place by id) and enumerates exactly which fields can change, which cleanly separates it from sibling rsi_knowledge_add (creation) and rsi_knowledge_delete. The two modes (update vs merge) are named up front so the agent can tell what it is invoking.

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?

"prefer updating over re-adding duplicates" is an explicit routing directive away from the add tool, and merge's purpose (combine near-duplicates) is stated. What's missing is a when-NOT clause — e.g. what to do if the id is unknown, or when to fall back to add/delete instead.

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

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

With no annotations, the description carries the full burden, and it does disclose two useful traits: responsibility for lesson authoring lies with the host (RSI will not generate it), and gated actions return not_in_phase with a message to redirect. It does not say which actions mutate persistent state, what promote or teach_record actually change, or whether any operation is reversible.

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 action categories are front-loaded, which is good, but the entire content is duplicated in Chinese, roughly doubling length with zero new information for a single locale-driven audience. No sentence is wasted individually, yet the deliverable is twice the necessary size.

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?

This is a 13-action dispatcher with 25 parameters, nested objects, no annotations, and no output schema — the highest-burden case — yet the description explains only the teach loop and the pack trio. The audit pipeline (audit_start → audit_probes → audit_report → audit_finish), extract, promote, skip, and rubric are unaddressed, leaving an agent unable to sequence most of the tool's surface.

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 80%, so the baseline is 3 and the schema already documents the individually described fields. The description adds only indirect hints by naming some action values in prose (teach_record, pack_list, pack_open, pack_done) but says nothing about scope/scope_id pairing, pack_id vs id aliasing, or the payload object.

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 noun list ('Teaching / audit / closeout learn / promote / reading-pack actions') rather than a single clear verb+resource, and it never says outright that this is a multi-action dispatcher for the RSI learning lifecycle. The second sentence does name concrete actions (teach_record, pack_list/pack_open/pack_done), which gives partial specificity, but nothing distinguishes this from siblings like rsi_recall or rsi_review.

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 real procedural guidance for one path: 'The host agent writes the lesson (Catch→Teach→Fix) then teach_record; RSI does not write the lesson.' That tells an agent who must supply content. But for the other nine-plus actions (audit_start/probes/report/finish, extract, promote, skip, rubric) there is no when-to-use, ordering, or alternative-tool 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?

No annotations are supplied, so the description must carry the full behavioral burden. It hints that reindex mutates a cache, but never says whether reindex is expensive, idempotent, or permission-gated, what index returns, or what happens with a malformed id. Only 'graph returns mermaid text' discloses output shape.

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

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

The action-mode breakdown is front-loaded and useful, but the entire English sentence is then repeated verbatim in Chinese. That duplication roughly doubles length without adding information for a single-language reader, so a significant portion of the text does not earn 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?

With no annotations, no output schema, and a dispatcher spanning four behaviors, the description is thin: it does not describe index/read return formats, reindex cost or side effects, locale behavior, or failure modes. An agent can pick a mode but cannot predict consequences.

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 id (32-hex, for open), lang (zh/en), and the action enum. The description adds only the action-to-parameter link for open, while the lang override and its effect on returned text are never mentioned, so 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 definition enumerates four concrete modes (index lists entries, open reads one id, reindex rebuilds cache, graph returns mermaid text), which is specific. However, the opening phrase 'Open or search memory files' promises a search capability that no action provides, and nothing distinguishes rsi_memory from siblings such as rsi_memory_health or rsi_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?

Each action is described in isolation ('index 列目录', 'open 按 id 读全文'), which hints at when to use each. But there is no guidance on when to choose this tool over rsi_recall, rsi_explore, or rsi_memory_health, and no prerequisites or exclusions are stated.

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

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

With no annotations, the description carries the full burden and does well: it discloses what scan writes (a finding against every retrieved id), the exact conditions that open incorrect and stale_source findings, and the important safety fact that 'scan never archives by itself.' It still omits whether resolve actions like archive are reversible and what side effects resolve has on the underlying memory.

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 front-loaded with the action list and dense with useful rules, but the entire description is duplicated verbatim in English and Chinese, roughly doubling the length without adding new information for most readers.

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

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

For a 5-parameter, no-annotation, no-output-schema tool, the description covers the action semantics, the finding-opening rules, and the key safety boundary. It stops short of describing finding shape or resolve side effects, which are the remaining gaps an agent must infer from the schema.

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 enums and inline descriptions for action, status, finding_id and resolution, so the schema already does the heavy lifting. The description reinforces the resolution enum and the resolve workflow but adds no format or constraint detail beyond what the schema provides, making baseline 3 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 resource (memory health findings) and enumerates its four action modes, with concrete behavioral detail for scan (attributing rejected/low-rated recalls, opening incorrect and stale_source findings). It distinguishes this tool from generic recall/review siblings by framing it around health findings, though it never names an alternative tool directly.

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

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

Usage is only implied: the action list plus notes like 'resolve is archive, revise, keep, or snooze' and 'Scan never archives by itself' hint at the workflow (scan → list/explain → resolve), but the description states no explicit when-to-use, when-not-to-use, or alternative-sibling 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 behavioral burden and does well: it discloses returned categories (prohibitions, items, skill catalog, and decisions by implication) and the required workflow after recall. It does not state whether the tool is read-only or otherwise side-effect-free, which leaves a minor gap for an unannotated 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?

The English portion is front-loaded and purposeful, covering trigger, outputs, and follow-ups efficiently. However, the full Chinese translation duplicates the same content, which is redundant for an agent and makes the definition longer than necessary.

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 explains the main return categories and the required downstream workflow, which is the critical context for this orchestration tool. It could be more complete by clarifying how feedback_token is obtained or what the decisions field represents.

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 explains role, task, and top_k. The description adds no further parameter semantics, making the baseline 3 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 gives a specific trigger and output set: call before coding/adaptation/debugging/design tasks to get prohibitions, related items, and a skill catalog. It names several sibling tools for follow-up, but does not explicitly distinguish itself from rsi_knowledge_search or rsi_explore, so sibling differentiation is incomplete.

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 clearly states when to call (before coding, adaptation, debugging, or design tasks) and gives explicit follow-up rules: use feedback_token with rsi_feedback before wrapping up, and call rsi_conflicts / rsi_knowledge_review immediately if decisions is non-empty. It lacks explicit when-not-to-use guidance or a direct comparison to search-oriented alternatives.

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

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

No annotations are provided, so the description carries the full disclosure burden, yet it only implies mutations via the action names (approve/reject/rollback). It says nothing about permissions, reversibility, what rollback or snapshot_switch actually change, blast radius, or whether generate/snapshot_export write files.

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 a single bare enumeration duplicated verbatim in Chinese, which wastes tokens for most agents without adding information. It is front-loaded but not structured, and every sentence is just a restatement of the schema enum.

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 mutation-capable actions and no annotations and no output schema, the description is severely underspecified: no lifecycle of proposals, no effect of approve vs rollback, no snapshot semantics, no return info. An agent can guess from action names but cannot call it confidently.

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 action, reason, status, out_dir, version, and proposal_id. The description merely repeats the action enum values and adds no additional semantics (e.g., which ids come from where, what versions mean).

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?

It names a resource ('Harness improvement proposals') and enumerates actions (list/approve/reject/rollback/generate) plus config snapshots, but lumps two distinct domains into one tool without explaining what a 'harness improvement proposal' actually is. The purpose is recognizable but vague, and nothing distinguishes it from siblings like rsi_feedback or rsi_learn.

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 only lists action values; it never says when to use this tool versus the many rsi_* siblings, nor when approval/rollback/generate are appropriate. There are no prerequisites, exclusions, or alternative-tool 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?

No annotations are supplied, so the description carries the full disclosure burden, and it discloses very little: nothing about read-only vs mutating behavior, the fact that export=true writes files to disk, cost/latency, or what the returned summary looks like. The one behavioral side effect an agent would care about (file export) is only visible in the schema, not the description.

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

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

The purpose is front-loaded in the first clause, which is good. But the description is given twice (English then Chinese) with no additional information in the second copy, roughly doubling length without adding value for an agent that can read either language.

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?

This is a six-parameter reporting tool with no output schema, so the description is the only place an agent can learn what the summary contains or how it is shaped. It lists metric names but not their structure, grouping semantics, or the export side effect, leaving significant gaps for a tool with no annotations and no return schema.

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 period, export, format, group_by, stale_days and include_stale are already documented in the schema. The description repeats only the period enum values and adds no interpretation of what group_by=intent vs arm means or when to set include_stale. Baseline 3 is appropriate when the schema does the work.

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

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

States a specific resource (memory usage stats) and enumerates the four metric families computed (reach, adoption, prohibition follow-through, proposal pass rate) alongside the period granularity. That is clearly more than a name restatement. It does not, however, position itself against the obvious sibling rsi_memory_health, which likely also reports memory statistics.

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

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

There is no explicit when-to-use or when-not-to-use guidance; the agent must infer that this is for aggregate reporting rather than record-level work. The presence of rsi_memory_health among the siblings makes the missing differentiation a real ambiguity, since both plausibly answer 'how healthy is my memory'.

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