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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds the scope limit of 'an allowed directory.' It does not disclose recursive behavior, hidden-file handling, or behavior for disallowed paths, but the safety profile is covered by annotations.

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

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

One sentence with no wasted words; the verb and resource are front-loaded. The description is optimally concise for its scope.

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

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

The tool is simple, with one required parameter and no output schema, so the description plus annotations provide a workable baseline. It still omits details like returned entry format and the precise meaning of 'allowed directory,' leaving some ambiguity for an 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 0%, so the description must carry parameter meaning. It does clarify that directory_path points to a directory and that the result is the entries inside it, but it does not specify path format or allowed-path constraints beyond the word 'allowed.' This is adequate for one self-explanatory parameter.

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: 'List files and directories inside an allowed directory,' making the core function clear and distinguishable from read/stat siblings. It does not explicitly name an alternative, so it stops short of a perfect score.

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

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

The use case is implied by the verb 'List files and directories,' so an agent can infer when to use it. However, there is no explicit guidance on when to prefer this over siblings or how to interpret 'allowed directory.'

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

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

Annotations already signal a non-read-only, non-destructive mutation; the description adds useful behavioral detail beyond that: missing parent directories are created and only configured allowed directories are targets. It does not mention failure behavior or what happens if the directory already exists, but no contradiction with annotations exists.

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

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

A single, front-loaded sentence puts the verb first and tucks modifiers after it, with no filler. Every phrase ('including missing parent directories', 'inside configured allowed directories') 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 one-parameter filesystem mutation tool with no output schema and annotations covering read-only/destructive signals, the description is mostly complete: it reveals recursion and scope. Minor omissions such as existing-directory behavior and path resolution rules keep it from a perfect score.

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?

With 0% schema description coverage and a single directory_path parameter, the description partially compensates by explaining that nested paths are accepted and that the path is constrained to configured allowed directories. It does not clarify path format, absolute/relative interpretation, or how allowed directories are determined, leaving some burden still on the parameter name.

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 clear action ('Create a directory') and a specific resource, and adds two defining constraints: recursive parent creation and restriction to configured allowed directories. This distinguishes it from sibling tools like lb_write_text or lb_move_path, which operate on files rather than create directories.

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 directory, including parents, needs to be created) and names the allowed-directory boundary, but it provides no explicit when-not-to-use guidance or comparison with alternatives. Usage context is present but not fully spelled out.

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 annotations already mark this as destructive and non-read-only. The description adds the useful constraint that operations are limited to configured allowed directories. It does not disclose overwrite behavior, error cases, or path resolution, but the annotation coverage reduces the burden.

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 one focused sentence with no filler. The operation and the key boundary are front-loaded, making it easy for an agent to parse quickly.

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 destructive move operation with no output schema, the description lacks important safety and behavior details: destination-conflict handling, behavior when the source does not exist, and directory-versus-file semantics. The allowed-directory boundary is helpful but does not fully specify a safe invocation.

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

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

Schema description coverage is 0%, and the schema only provides names and minLength. The description implies from_path is the source and to_path is the destination through 'move or rename', but it does not explain path formats, absolute versus relative paths, or whether to_path can be an existing directory.

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 an explicit verb phrase, 'Move or rename a file or directory', and adds the boundary 'within configured allowed directories'. This clearly identifies the operation and resource, and it is distinct from sibling tools like lb_read_text, lb_write_text, and lb_stat_path.

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 this tool is for relocation or renaming, but it does not explicitly name alternatives or state when not to use it. It lacks exclusions such as 'for content edits use lb_write_text' or 'for inspection use lb_stat_path', so routing relies on 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known. The description adds valuable behavior beyond that: 'Uses exact replacement first and a bounded fuzzy fallback when one replacement is expected' reveals the matching strategy and the role of expected_matches. However, it does not explain edge cases like zero matches or multiple matches, but the provided detail is meaningful.

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 concise sentences, front-loading the action and then adding behavioral detail. No wasted words; it is appropriately sized for the tool's complexity.

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

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

The description covers the core purpose and matching behavior but omits details about error handling, what happens if no match is found, or if expected_matches is greater than 1. For a destructive operation with no output schema, more guidance on failure modes would improve completeness. However, the essential calling information is present.

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

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

Schema coverage is 0%, so the description must compensate. It indirectly explains expected_matches via 'when one replacement is expected', and implies find_text and replace_text are the texts involved. However, it does not explicitly describe each parameter or provide format details, leaving some interpretation to the agent. The parameter names are self-explanatory, so it partially compensates.

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: 'Replace a text block in a UTF-8 file', identifying the verb and resource. It also distinguishes itself from siblings like lb_write_text (which writes whole files) and lb_read_text (which reads) by focusing on targeted block replacement. The mention of exact replacement and fuzzy fallback adds further specificity.

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 its use case (targeted block replacement) but does not explicitly state when to choose it over alternatives like lb_write_text or when not to use it. It does not mention exclusions or alternative tools. The behavior described (exact then fuzzy) offers some guidance but lacks explicit comparison.

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

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

Annotations already convey readOnlyHint=true and destructiveHint=false, and the description adds useful behavioral context: UTF-8 encoding, allowed-directory restrictions, and batched single-call reading. However, it does not disclose what happens if a path is missing, whether line_count/line_offset apply per file or across all files, or any error behavior.

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

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

The description is a single front-loaded sentence with no filler or repetition. Every phrase adds meaningful information: what is read, the encoding, the directory restriction, and the batching behavior.

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

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

This is a multi-file read tool with no output schema and 0% parameter descriptions, so the description needed to explain return shape, error handling for invalid paths or paths outside allowed directories, and how line_count/line_offset apply. The annotations cover the safety profile, but the operational details an agent needs for reliable invocation are missing.

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

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

With schema description coverage at 0%, the description needed to explain file_paths, line_count, and line_offset. It only indirectly contextualizes file_paths as multiple UTF-8 text files; line_count and line_offset are left entirely to inference from their names, and their exact relationship to the batch read is unclear.

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

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

The description states a specific action (Read), resource (multiple UTF-8 text files), and constraints (inside configured allowed directories, in one call). This clearly distinguishes it from the singular lb_read_text sibling and leaves no ambiguity about the tool's core function.

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 establishes a clear use case: reading multiple UTF-8 text files in a single batch call, restricted to configured allowed directories. It does not explicitly name alternatives or say 'use this instead of lb_read_text', but the 'multiple' and 'in one call' phrasing gives an agent sufficient context to select it over the singular sibling.

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

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

Annotations already establish read-only and non-destructive behavior, so the description adds value by disclosing the allowed-directory restriction and the UTF-8 requirement. It does not describe output or error behavior, but for a read-only operation with annotations present 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?

Two short sentences with no filler, with the core purpose and scope front-loaded and the optional parameters stated second. Every sentence earns its place.

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

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

For a simple read-only tool, the core behavior is covered, but there is no return-value description or explanation of line_offset/line_count semantics, and no output schema to compensate. An agent can call it correctly in basic cases but may misread partial-read behavior without more detail.

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

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

Schema descriptions cover 0% of parameters, so the description must supply meaning. It identifies 'line offset' and 'line count' as supported parameters, but it leaves file_path semantics to the name and does not clarify whether offsets are zero-based, defaults, or how line_count behaves when omitted.

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

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

The description names the action (read), the resource (a UTF-8 text file), and a precise scope (inside configured allowed directories). This makes it easy to distinguish from siblings like lb_read_many_texts and lb_write_text.

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 communicates that the tool applies only to files inside allowed directories and that line offset and line count are supported for partial reads. It does not explicitly name alternative tools or state when not to use it, but the context is sufficiently clear.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the mutation risk is covered. The description adds useful context beyond annotations: commands are checked against a blocklist, sessions are persistent, output is paginated, and stdin can be provided later.

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 tight sentences with the action front-loaded. The first sentence states the verb and resource; the second adds lifecycle and safety context. No filler or redundancy.

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

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

The description sketches the full workflow—start, later stdin, paginated output, blocklist—but omits practical integration details such as how the session is identified after creation, how output is retrieved via lb_shell_output, and how to terminate the session. Since there is no output schema, these missing return-value and follow-up details leave an agent partially guessing.

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%, and the description does not compensate. It only implies command_line's role via 'shell command', while wait_ms and shell_path are left entirely unexplained. The parameter names are somewhat self-evident, but no real semantic guidance is provided.

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

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

The description states a precise action and resource: start a shell command in a persistent local terminal session. It also distinguishes this tool from siblings like lb_shell_output, lb_shell_input, and lb_shell_kill by emphasizing session creation and later stdin/output capabilities.

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: when a command should run in a persistent session that can later receive stdin and expose paginated output. However, it does not explicitly name alternatives or state when not to use it, leaving usage guidance mostly inferred.

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

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

Annotations already indicate this is not read-only and not destructive, so the description's 'Cancel' action is consistent. The word 'active' adds a useful scoping hint that cancelling an inactive session may not be valid, but the description provides no further behavioral details such as side effects, idempotency, or error behavior.

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

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

The description is a single, front-loaded sentence with no redundant words. Every part contributes to stating the tool's core action.

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

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

For a simple one-parameter tool, a one-sentence description can almost suffice, but there is no output schema and no guidance on error cases like invalid or already-finished sessions. The description is minimally viable but leaves minor gaps that an agent might need filled for reliable invocation.

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

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

With 0% schema description coverage, the description carries the burden of explaining search_id but does not explain what it is, where it comes from, or how it relates to search sessions. The parameter name is somewhat self-explanatory, but the description adds no meaning beyond the bare schema definition.

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 ('Cancel') and resource ('an active search session'), making the tool's purpose immediately clear. It is easily distinguishable from sibling tools like lb_search_start, lb_search_read, and lb_search_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 'active search session' gives an implicit condition for use: the session must exist and be active. However, there is no explicit comparison with alternatives, no when-not guidance, and no mention of how to obtain a valid search_id.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the pagination concept ('a page of results') but does not detail behavior like offset handling or session validity, which is expected for a read operation.

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

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

Single sentence with a clear verb and object, no fluff. Front-loaded with the core purpose.

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

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

Description is minimal; it does not explain how pagination works (e.g., using result_offset to get subsequent pages), what the response contains, or error conditions. With no output schema, the agent lacks guidance on return format. However, the tool is simple and the schema provides basic parameter constraints, so a 3 is appropriate.

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%, and the description provides no information about search_id, result_count, or result_offset beyond their names. The schema includes defaults and constraints, but the description does not add meaning to parameters or explain how they interact for pagination.

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 (Read) and resource (results from an existing search session). Clearly distinguishes from siblings like lb_search_start and lb_search_sessions, which are about starting or listing 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?

Implies it must be used after a search session exists, but does not explicitly state when to use this over alternatives or any exclusions. No mention of alternative tools or when not to use it.

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 wording is consistent with the readOnlyHint=true and destructiveHint=false annotations, and it adds the small behavioral detail that status is included in the result. Since annotations already cover the read-only and non-destructive traits, the description adds only minimal behavioral 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 a single clean sentence with no filler, front-loading the core purpose and the key output detail. Every word contributes meaning.

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 parameterless, read-only listing tool, the description provides the essential information: what is listed and what aspect is reported. It could add more detail about what 'status' values or session scope look like, but this is a minor gap given the tool's simplicity.

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 100% schema description coverage, so the description bears no real burden for parameter semantics. The baseline of 4 applies here because nothing about parameters needs clarification.

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, resource, and focus: 'List search sessions and their status.' It clearly separates this from sibling tools like lb_search_start, lb_search_read, and lb_search_cancel because this one is about listing sessions rather than performing an operation.

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

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

The intended use is implied: use this tool when you need an overview of search sessions and their statuses. However, it does not explicitly contrast itself with sibling search tools or state when not to use it.

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

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

Annotations already establish read-only and non-destructive behavior. The description adds that the operation is asynchronous and ripgrep-backed, which is useful. Still, it does not disclose how results are delivered, whether a session handle is returned, or how 'allowed directories' are enforced. These are meaningful behavioral gaps given the async lifecycle.

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

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

A single, information-dense sentence with no filler. The core action, engine, scope, and asynchronous nature are front-loaded, and every word earns its place.

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

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

For a 10-parameter asynchronous tool with no output schema, this description is incomplete. It does not explain what the tool returns, how to retrieve results, how cancel/read sessions work, or important parameter semantics. An agent would need substantial external inference to call this correctly and consume its outcome.

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, but it explains almost none of the 10 parameters. The phrase 'filename or content' maps faintly to query_kind, and 'allowed directories' hints at search_root, but query_text, file_glob, deadline_ms, result_limit, fixed_string, case_insensitive, include_dotfiles, and context_line_count are left entirely undocumented.

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 ('Start') and resource ('search'), and adds meaningful qualifiers: 'asynchronous', 'ripgrep-backed', 'filename or content', and 'inside allowed directories'. This clearly separates it from siblings like lb_search_read, lb_search_cancel, and lb_search_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?

Usage is implied rather than explicit: starting an asynchronous search suggests that results are retrieved separately, likely via lb_search_read. However, the description never states when to prefer this over siblings, what to do after starting, or any exclusions. The role is evident from naming, but no direct guidance is given.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false, so the description's job is to add behavioral context beyond that. The description does not disclose what happens to the session after input, whether the input is echoed, whether it blocks, or any side effects. It also does not mention that sending input to a persistent session may have irreversible effects, which is important given the destructive hint.

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 with no wasted words, and the core action is front-loaded. It is appropriately concise, though it could have used the available space to add parameter or usage context.

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 that sends input to a persistent shell session, the description is incomplete. It does not explain how to identify the session (process_id), what happens if the session is inactive, or how this relates to lb_shell_output and lb_shell_sessions. With no output schema and no parameter documentation, an agent has limited guidance for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate for the two parameters. It does not explain what process_id refers to (e.g., how to obtain it from lb_shell_sessions) or what format stdin_text should take (e.g., whether newlines are appended). The description adds no meaning beyond the parameter names.

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 ('Send') and resource ('a line of stdin to an active persistent terminal session'), which clearly distinguishes it from sibling tools like lb_run_shell or lb_shell_output. It lacks a title but the description is unambiguous about the tool's core function.

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 context ('active persistent terminal session') but does not explicitly state when to use this tool versus alternatives like lb_run_shell or lb_shell_kill. It gives no exclusions or conditions, so an agent must infer that this is for interacting with an already-running session rather than starting a new one.

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

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

Annotations already declare destructiveHint=true, so the destructive nature is known. The description adds the escalation behavior (SIGINT to SIGKILL) and the constraint that it targets an 'active' session, providing extra context beyond annotations. No contradiction with annotations.

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

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

One sentence that front-loads the action and escalation behavior. No filler or redundancy.

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

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

For a simple kill operation with one parameter and no output schema, the description covers the core behavior. It does not mention return values, failure handling, or prerequisites like needing to list sessions first, but given the tool's simplicity and annotations covering safety, it is reasonably complete. However, it could note that the session must be active and that the PID comes from a session list.

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 a single parameter process_id with type integer and bounds. The description only says 'by PID' which reiterates the property name without adding new meaning. With 0% schema coverage, the description does not compensate for the lack of documentation in the schema, but the property name is self-explanatory.

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 terminates a terminal session by PID, using the verb 'terminate' and resource 'active terminal session'. It distinguishes itself from siblings like lb_run_shell or lb_shell_output by its destructive 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 does not explicitly mention when to use this tool versus alternatives. It implies it is for ending a session, but does not reference sibling tools like lb_shell_sessions or lb_shell_input, nor does it provide exclusions. The context of being a kill operation is clear, but no guidance on prerequisites or alternative scenarios is given.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, lowering the burden on the description. The description adds meaningful extras: output is paginated, captures stdout/stderr, and is available only for active or recently completed sessions, implying a session-lifetime limitation. This is useful beyond the annotations.

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

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

A single, front-loaded sentence with no wasted words. It states the action, the data, and the temporal scope compactly while remaining readable.

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 and session-scope constraint, which is adequate for a simple read tool. However, it leaves important context unstated, such as how the pagination parameters map to output and how process_id relates to a shell session, and there is no output schema to fill those gaps.

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

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

Schema description coverage is 0%, so the description must compensate, but it only says 'paginated' and does not explain process_id, line_count, or line_offset. The parameter names and default values are somewhat self-explanatory, but the meaning of process_id as the terminal session identifier is not clarified.

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 ('Read') and names a concrete resource ('paginated stdout/stderr captured for an active or recently completed terminal session'). It clearly differentiates this from sibling tools like lb_shell_input, lb_shell_sessions, and lb_shell_kill without needing to open the schema.

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 'active or recently completed terminal session' gives useful context about when the tool applies, but it does not explicitly state when to use this tool versus alternatives such as lb_shell_sessions or lb_run_shell. No exclusions or alternative-selection guidance are provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the detail about including 'recently completed' sessions, which is useful context beyond the annotations. However, it does not disclose what 'recently' means or any potential limits on the list size, though these are minor for a simple read-only list operation.

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

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

The description is a single sentence with no wasted words. It is front-loaded with the action and resource, and completely appropriate for the tool's simplicity.

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 is adequate for a basic list tool, but it does not specify the return format (e.g., whether it returns session IDs, names, or other metadata). Since there is no output schema, the agent must infer what the list contains to use the results with sibling tools. A brief mention of the returned fields would improve completeness.

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

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

The tool has zero parameters, so the schema fully covers everything. According to the rubric, a baseline of 4 is appropriate for 0-parameter tools since nothing is needed to clarify parameter usage. The description correctly contains no parameter information.

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 clear verb ('List') and resource ('persistent terminal sessions'), and specifies the scope ('active and recently completed'). It distinguishes from siblings like lb_shell_output or lb_shell_kill, which operate on individual sessions rather than enumerate them.

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

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

No explicit guidance is given about when to use this tool versus alternatives. While it's implied that this is the enumeration tool before using session-specific tools (lb_shell_output, lb_shell_input, etc.), the description does not state that or any usage context. This is a gap for an agent that needs to decide between multiple session-related tools.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that it returns metadata (size, type, canonical path, modification time) but does not disclose behavior around non-existent paths, permission errors, or whether symlinks are resolved. With annotations covering the main behavioral aspects, a 3 is appropriate.

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 one clear sentence with zero wasted words. It front-loads the action and lists the return fields compactly. Every part earns its place.

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

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

For a simple, read-only, single-parameter tool with annotations declaring reading safety, the description is nearly complete. However, it lacks details on error behavior (missing path, permissions) and path resolution specifics (canonical path implies symlink resolution), which would help an agent handle failures. Given the simplicity and annotation coverage, a 3 is fair.

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. The description clarifies that target_path refers to a file or directory path, which is the core meaning beyond the raw schema. However, it does not specify path format (relative/absolute), whether it must be an existing path, or anything about handling of directories vs files. Since the description adds some semantic meaning but not complete parameter documentation, 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 states a specific verb ('Return') and names the resource ('a file or directory') plus the specific data fields (size, type, canonical path, modification time). This clearly distinguishes it from siblings like lb_list_entries or lb_read_text, though it does not explicitly name any sibling.

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

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

The tool's purpose and the 'file or directory' scope imply when to use it, especially compared to lb_list_entries or lb_read_text, but there is no explicit guidance about when not to use it, such as when a listing or reading content is needed. The description gives context but no explicit exclusions or alternative selection guidance.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description adds value by specifying that rewrite mode replaces existing content and that operations are confined to configured allowed directories. This goes beyond the annotations but does not cover other behaviors like file creation or error handling. With annotations covering the safety profile, a 3 is appropriate.

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 concise sentences, with the primary action front-loaded in the first sentence and the mode detail in the second. There is no waste, and every word contributes meaning.

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 write tool with no output schema, the description covers the core action and mode but omits details such as whether files are created if absent, path formats (absolute/relative), or success/error responses. Given the tool's simplicity and the annotations, it is adequate but not fully comprehensive.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the write_mode parameter via 'Rewrite mode replaces existing content' and implies text is the content and file_path is the target, but it does not provide syntax, format, or constraint details for file_path and text. The description adds some meaning but leaves gaps, warranting a 3.

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

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

The description explicitly states the tool writes or appends UTF-8 text to files within allowed directories, and clarifies rewrite mode replaces content. This clearly distinguishes it from sibling tools like lb_read_text (reading) and lb_patch_text_block (patching), so an agent can identify its purpose immediately.

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: it is for writing or appending text, not for reading or other operations. However, it does not explicitly name alternative tools or state when-not-to-use scenarios. The verb 'write' makes the usage obvious, but explicit guidance against using it for reads is absent.

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