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

With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states that the tool never moves, edits, or deletes the JSONL transcript, which is a critical non-destructive guarantee. However, it does not explain what 'archive' actually changes in the catalog (e.g., whether the session becomes hidden), nor does it describe return values or side effects. This is a strong but incomplete disclosure.

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, each earning its place. The first states the primary action; the second provides a key clarifier about non-destructiveness. Front-loaded and free of redundancy or filler.

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

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

For a simple tool with one required parameter and no output schema, the description covers the essential action and a critical caveat. It does not mention return values or the effect on catalog visibility, which would enhance completeness, but the tool's simplicity keeps it reasonably complete.

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 0%, so the description must compensate by explaining parameter meanings. It does not mention 'sessionId' or 'cwd' at all. Names alone are insufficient, especially 'cwd' which is ambiguous despite a default of '/root'. The description adds zero value for parameter understanding.

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

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

The description uses a specific verb 'Archive' and identifies both the resource ('Claude conversation') and the context ('MCP-local catalog'). It also clarifies what it does NOT do (move/edit/delete the transcript), which helps distinguish it from destructive operations. This clearly differentiates from siblings like 'unarchive_claude_session'.

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 by describing the archival function and noting it leaves the transcript untouched, but it does not explicitly state when to use this over alternatives (e.g., rename, delete) or mention any prerequisites. The presence of 'unarchive_claude_session' as a sibling suggests reversibility, but that is not stated in the description.

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 disclosing side effects, permissions, and return behavior. It only hints that output is 'visible' (presumably current screen), but does not state whether this is a read-only operation, whether the session must be active, or what happens if no output is available. This is insufficient for a tool with no safety hints.

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, grammatically complete sentence that front-loads the action and resource. It contains no fluff or repetition, but it is somewhat under-specified for a tool with three parameters and no annotations. Still, it is concise and well-formed.

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 moderate complexity (3 parameters, none required, no output schema, no annotations), the description is too minimal. It does not mention return format, error conditions, whether it waits for new output, or how to differentiate between active and inactive sessions. Sibling tools suggest a broader remote control workflow, but this description does not connect to that 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 description coverage is only 33% (only tmuxSession has a description, and it says 'deprecated alias'). The description itself does not explain any parameters, such as 'lines' (which likely controls the number of lines captured) or 'managedSession' (which identifies the target session). The parameter names are somewhat self-explanatory, but the description adds no value beyond the schema, and for 'lines' there is no schema description either.

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 identifies the action ('Capture visible terminal output') and the target resource ('managed native Rail Connector Control session'), distinguishing it from sibling tools like send_text or send_key which modify the session. It lacks explicit mention of returning a snapshot, but 'visible terminal output' is specific enough.

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 no guidance on when to use this tool versus alternatives such as wait_for_claude_turn or get_claude_session. There are no exclusion criteria, prerequisites, or references to sibling tools, leaving the agent to infer the appropriate context.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states that the tool uses bounded probes, avoids interactive sessions, reports advertised and experimental request paths, and notes a limitation: terminal capture cannot authenticate effective runtime posture. This is substantial disclosure, though it does not explicitly state whether the operation is side-effect-free or what happens in error cases.

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

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

The description is two sentences with no filler. The first sentence front-loads the core action and constraints, and the second sentence adds output details and a limitation. 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 zero-parameter tool with no output schema, the description provides sufficient context: what it does, how it does it, what it reports, and a key limitation. It could mention behavior when the CLI is not installed or timeout/error behavior, but given the tool's simplicity, the description is largely complete.

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 tool has zero parameters, and schema coverage is 100% (empty object). Following baseline guidance for zero parameters, a score of 4 is appropriate. The description adds value by explaining what the tool inspects and reports, which compensates for any lack of parameter-level 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 the tool inspects the installed Claude CLI using bounded version/help probes without starting an interactive session. It specifies the verb 'inspect', the resource 'Claude CLI', and how it inspects, which distinguishes it from sibling session-management and remote-control 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 use case is implied: to inspect CLI capabilities before or independently of interactive sessions. However, the description does not explicitly provide when-to-use versus when-not-to-use guidance, nor does it reference any sibling tools as alternatives. The phrase 'without starting an interactive session' hints at a constraint but does not offer exclusionary 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?

The description discloses that the tool reads a log and returns text and a URL, implying a read-only operation. However, with no annotations, the agent must infer that it is non-destructive and that no modifications occur. It does not mention error conditions, authentication, or rate limits, but it does specify 'local native' as a scope constraint, adding useful context.

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

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

The description is two sentences, front-loaded with the core action and outcome, and contains no redundant information. It is appropriately sized for the tool's simplicity and clearly structured.

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

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

The description states the primary output but omits explanations for all parameters and any error behavior. Given the lack of annotations and output schema, it doesn't fully equip an agent to handle edge cases or know the exact meaning of cwd. However, for a read-only log inspection tool, the description is reasonably complete in conveying its main function.

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 description maps sessionId via 'by id' and maxMessages via 'recent' text, but it does not explain the cwd parameter at all. With 0% schema description coverage, the description carries the full burden of parameter semantics, and it only partially covers two of the three parameters. The default values in the schema help but are not semantically explained.

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 inspects a session log by id and returns recent user/assistant text and any Remote Control URL. The verb 'inspect' and the 'by id' qualifier distinguish it from list_claude_sessions, which presumably lists all sessions. However, it doesn't explicitly mention any contrast with sibling 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 implies usage when you have a specific session ID and need its log contents, but it does not explicitly mention when to use this tool over list_claude_sessions or other session-related tools. There is no guidance on exclusions or prerequisites, such as needing a running session or having permission. The 'by id' phrasing hints at singular lookup but doesn't fully clarify when to choose this tool.

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 discloses key behavior: it lists local logs, returns metadata by default, and makes prompt/output snippets optional. This adds privacy-relevant context beyond a simple 'list' statement, although search/filter behavior is not described.

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

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

The description is exactly two sentences, front-loaded with the primary action, and every phrase earns its place. It does not waste words or duplicate schema fields.

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

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

For a 7-parameter tool without an output schema, the description gives a high-level overview but omits important behaviors like query search, archive filtering, and scan limits. Parameter descriptions compensate partially, but the overall return shape (metadata fields) is vague.

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 high (86%), so the description does not need to repeat parameter details. It adds a minor link between 'project directory' and cwd, and 'optional snippets' to includeSnippets. Most semantics are already 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 uses a specific verb 'List' with a clear resource: 'local native Claude Code session logs for a project directory.' It distinguishes from siblings like get/archive/rename by indicating a bulk listing operation, and clarifies default output mode.

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 phrase 'for a project directory,' but there is no explicit guidance about when to use this over get_claude_session or archive_claude_session. No alternatives are mentioned, leaving the selection decision to 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 the full burden of behavioral disclosure. It adds value by stating that the tool not only renames but 'verify[ies] the title in Claude's local session log', which is a behavioral step beyond the obvious action. It also implies that the session must be running, giving useful context. However, it does not mention side effects or permissions, but for a rename operation this is acceptable.

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, front-loaded with the action 'Rename', and contains no wasted words. It communicates the core action and the verification step efficiently, earning a perfect score for 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?

The description covers the core action and the verification step, giving enough context for an agent to understand what the tool does and when to use it. Given the tool's simplicity (3 params, no output schema), the description is reasonably complete. It does not mention return values or error handling, but these are not essential for a straightforward rename operation. A minor gap is lack of clarification on the managedSession parameter, but the schema default covers that.

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

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

The schema has only 33% description coverage (only tmuxSession is described, as a deprecated alias). The description does not mention the title parameter, the managedSession default, or the relationship between parameters. Since schema coverage is low, the description should compensate, but it does not add any parameter-level semantics beyond what is 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 clearly states 'Rename the Claude conversation attached to a running managed session' – a specific verb (Rename), resource (Claude conversation), and scope (attached to a running managed session). It also mentions a verification step, distinguishing it from sibling tools like archive or list. This is more specific than a generic 'rename' and includes a unique follow-up action.

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

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

The description provides clear context for when to use: when you need to rename the Claude conversation on a running managed session. It does not explicitly name alternative tools or state when not to use, but the action is well-defined. The prerequisite of a 'running managed session' is implied, which helps guide usage.

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 disclose behavioral traits. It does not mention prerequisites (e.g., starting remote control), side effects on the session, error behavior, or whether it waits for a response. The action of sending a key is a state change, but the description leaves these aspects opaque.

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

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

The description is a single, front-loaded sentence that efficiently conveys the core function and examples. Every word adds value, with no wasted content.

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

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

The description covers the core purpose but omits important context such as how to target a non-default session, session lifecycle dependencies, and relationship to remote-control tools. Given the simple nature of the tool and no output schema, it is minimally adequate but has clear gaps in session handling and prerequisites.

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 low (33%), leaving the 'key' parameter without a description. The tool description compensates with examples of valid key names, which adds practical meaning. However, it does not clarify the session parameters (managedSession, deprecated tmuxSession) beyond the generic 'managed native Claude session,' so coverage remains incomplete.

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 action ('Send') and the resource ('a single key name to the managed native Claude session'), with concrete examples (Enter, Escape, C-c, Up, Down). This distinguishes it from sibling tools like send_text, which sends text, making the purpose unambiguous.

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

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

The description gives clear context by specifying the target session and providing representative key examples, which imply when to use this tool (when sending key presses rather than text). However, it does not explicitly mention when to prefer alternatives (e.g., send_text) or exclude any scenarios, so it falls short of a 5.

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

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

With no annotations, the description carries the transparency burden. It warns 'This can affect a live Claude session' and discloses the newline behavior ('newlines sent here may submit early'). It does not detail return values or error conditions, but covers key side effects and a behavioral quirk, earning a strong score.

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 sentences, each with clear value: purpose, usage, and a caution. No redundant wording. It is front-loaded with the core action and then provides key details efficiently.

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

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

The description covers purpose, usage alternatives, and a critical warning, making it useful for a simple tool. However, it does not address how to select a specific session (managedSession parameter) or mention the deprecation of tmuxSession, leaving minor gaps in 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 description coverage is low (25%). The description adds meaning for 'text' (literal) and 'submit' (press Enter), but does not explain 'managedSession' or 'tmuxSession'. It partially compensates for the coverage gap, but not fully, so a 3 is appropriate.

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

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

The description clearly states the tool's function: 'Send literal text to the managed native Claude session.' It uses a specific verb and resource, and explicitly contrasts with submit_prompt, distinguishing this tool from a key sibling. This meets the 'specific verb+resource+scope' criterion.

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?

Provides explicit guidance: 'Use submit=true to press Enter after sending' and 'For multi-line prompts use submit_prompt; newlines sent here may submit early.' This gives clear when-to-use and when-not-to-use instructions, including an alternative tool recommendation.

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 disclosure burden. It does reveal a meaningful behavioral trait: sessions are persistent per-user on Windows and use tmux on Linux/macOS. However, it does not disclose other important behaviors such as potential session termination via killExisting/forceKillExisting, the need for confirmations with bypassPermissions, or the long-running nature of sessions. The description adds some context but is not fully 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?

The description is two sentences, front-loaded with the primary action. Every sentence earns its place: the first states the purpose, the second provides a key platform nuance. No redundant or vague 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 complex tool with 26 parameters, no annotations, and no output schema. The description covers the core purpose and platform persistence but does not provide an overview of key behaviors like session killing, permission modes, or parameter interactions. Given the richness of the schema, the description is adequate but not complete 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%, with each of the 26 parameters having detailed descriptions (e.g., permissionMode, killExisting, ultracode). The tool description itself does not add parameter-level semantics, but the schema already does the heavy lifting. Baseline of 3 is appropriate.

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

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

The description clearly states the action ('Start or resume') and the resource ('native Claude Code session with Remote Control enabled'). It distinguishes itself from sibling tools like stop_remote_control and capture_remote_control by focusing on session lifecycle initiation. The platform-specific detail (Windows broker vs tmux) adds additional clarity.

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

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

The description implies when to use the tool: to start a new or resume an existing remote-controlled session. It provides context about platform-specific behavior (Windows broker vs tmux) that informs usage. However, it does not explicitly mention alternatives or when not to use it, but the context is clear enough 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 must disclose non-obvious behavioral traits. It does not mention side effects, output format, potential sensitive information disclosure (beyond the parameter description in the schema), or any requirements. The 'Show' verb implies read-only, but additional transparency is lacking.

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 focused sentence that front-loads the core purpose with no redundant or filler words. It earns its place without unnecessary elaboration.

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, so the description should ideally explain what the returned status looks like and how to interpret it. The description is adequate for a simple status check but lacks details about return values or the meaning of 'status'. Given the tool's low complexity, the gaps are not severe.

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 applies. The parameter includeAgentDetails is fully described in the schema, including its default and disclosure risk. The tool description does not add further parameter semantics, but no additional explanation is necessary given the schema 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 uses a specific verb ('Show') and clearly identifies the resource: terminal backend and Claude process status. It distinguishes itself from sibling session-focused tools by focusing on process/backend status rather than session management. However, it could more precisely clarify the relationship to managed Remote Control sessions.

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 'relevant to managed Remote Control sessions' implies a context for use, but there is no explicit guidance on when to use this tool versus alternatives like list_claude_sessions or get_claude_session. No when-not-to-use guidance is provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Stop' without explaining the consequences, such as whether the session terminates abruptly, what happens to active work, or if it requires specific permissions. The force and graceful parameters are described in the schema, but the description itself adds no transparency about side effects or safety.

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

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

The description is a single, front-loaded sentence with no superfluous words. It is efficient and clearly structured, though it may be under-specified for a tool with four parameters. Still, it earns its place and does not contain 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?

The tool has no output schema and no annotations, leaving the description as the primary source of context. The description is minimal and does not explain return values, side effects, or the lifecycle of a managed session. With four parameters and a specialized domain (Rail Connector Control), the description is too sparse to provide a complete picture for an AI 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?

Schema description coverage is 75%, so the schema already documents most parameters. The description adds no parameter-level information, so it does not compensate for the missing managedSession description (only a default is provided). With 75% coverage, a baseline of 3 is appropriate; the description neither enhances nor detracts significantly from parameter understanding.

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

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

The description uses a specific verb ('Stop') and a specific resource ('managed native Rail Connector Control session'), clearly indicating the tool's function. However, it does not explicitly distinguish itself from sibling tools like capture_remote_control or start_remote_control, so it lacks direct sibling differentiation.

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

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

There is no guidance on when to use this tool versus alternatives. The description does not mention prerequisites, when a stop is appropriate, or how it relates to start_remote_control or other session management tools. This leaves the agent to infer usage solely 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 provided, the description carries the full burden of disclosing behavioral traits. It mentions 'safer chunked input' and the return value, but omits critical aspects such as preflight blocking (e.g., busy/non-idle captures), the force bypass, retry behavior, and the fact that it sends keystrokes to a terminal. These are significant behavioral details that an agent needs to safely invoke the 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 description is two sentences long, with the action front-loaded and no filler. Every clause contributes meaning, and the key return behavior is stated efficiently. It is a model of concision.

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 complex 10-parameter mutation tool with no annotations and no output schema. The description only provides the high-level purpose and a single return detail (waitAfterCursor), but it lacks context on preflight blocks, retry mechanics, session management, and parameter relationships. It is not sufficient for an agent to use the tool effectively and safely without additional information.

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

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

Schema description coverage is about 50%, but the tool description adds no explanation for parameters like lines, chunkSize, chunkDelayMs, managedSession, or tmuxSession. The mention of 'chunked input' hints at chunking-related params but does not clarify their values or how they interact. The description fails to compensate for the undocumented 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 what the tool does: 'Paste and submit a complete prompt to Claude using safer chunked input.' It specifies the resource ('a complete prompt'), the action ('paste and submit'), and the method ('chunked input'), and it distinguishes the tool from siblings like send_text/send_key by noting the return of waitAfterCursor for wait_for_claude_turn.

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 describes the primary use case (submitting a complete prompt) and signals the intended workflow by stating it returns a waitAfterCursor for wait_for_claude_turn. While it doesn't explicitly compare with alternatives like send_text, the phrase 'complete prompt' and 'chunked input' imply when this tool is appropriate, providing clear context if not explicit exclusions.

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

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

No annotations are provided, so the description carries the burden. It discloses a key behavioral trait: the transcript is unchanged, meaning only the catalog listing is affected. It also clarifies the operation is local to the MCP archive. This adds value beyond basic functionality.

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, immediately front-loaded with the verb and resource. The second sentence adds essential non-destructive context. 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 low-complexity tool with no annotations and no output schema, the description covers the core function and one crucial behavior (transcript unchanged). It omits return values or edge cases (e.g., what if session not archived), but these are not critical for this simple 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 0%, so the description must compensate. It does not mention sessionId or cwd at all. However, the parameter names are fairly self-explanatory (sessionId identifies the session), but since there is zero parameter documentation and the description adds no meaning, the score is low.

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

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

The description uses a specific verb ('Remove from the archive catalog') and clearly identifies the resource (Claude conversation/session). It states the effect ('appears in active listings again'), which distinguishes it from its sibling archive_claude_session.

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

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

The description implies when to use it: when a previously archived conversation should be active again. It clearly conveys the context and outcome, though it doesn't explicitly list alternatives or exclusions. The sibling tool name 'archive_claude_session' provides natural contrast.

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 bear the full burden of behavioral disclosure. It reveals the mechanism (local session-log completion and terminal state) but does not describe side effects, timeout behavior, or whether it blocks indefinitely. It also does not state if it is safe to call multiple times or if it modifies any state.

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

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

The description is a single, front-loaded sentence followed by a brief directive. Every word is purposeful, with no fluff or repetition. It efficiently conveys the core function and a key usage detail.

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 has 6 parameters, no annotations, and no output schema, the description is too sparse. It does not explain key parameters (e.g., lines, timeoutSeconds), nor does it describe what the tool returns or whether it throws errors on timeout. This leaves significant gaps for an agent invoking the tool correctly.

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

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

Schema description coverage is only 33% (only waitAfterCursor has a description). The description adds meaning only for waitAfterCursor ('Pass submit_prompt.waitAfterCursor verbatim'), while other parameters like lines, pollIntervalMs, timeoutSeconds, and managedSession rely solely on their names and defaults, which are insufficient for correct use.

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 ('Wait') and resource ('Claude's current turn') and details the mechanism ('record-ordered local session-log completion and terminal state'). This clearly distinguishes it from sibling tools like send_text, submit_prompt, and capture_remote_control, which perform different 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?

The instruction 'Pass submit_prompt.waitAfterCursor verbatim' implies it should be used after submitting a prompt, providing a clear usage context. However, it does not explicitly state when to use this tool instead of alternatives such as capture_remote_control, nor does it mention any exclusions or fallback scenarios.

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