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

Annotations already cover destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds useful safety-relevant context beyond the annotations: paths are validated before applying, and the patch is confined to the workspace. There is no contradiction between the description and 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?

The description is three short sentences, each earning its place: it states the operation, mentions a key safety behavior, and gives tool-selection guidance. There is no redundant filler or repetition of schema contents.

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 only two parameters, full schema coverage, and annotations that communicate destructive behavior. The description sufficiently covers scope, validation, and when to use it. Details like failure behavior or partial-apply semantics are not spelled out, but they are not necessary for selecting and 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 100%, so the schema already documents both patch and workspace_id. The description reinforces the path validation and workspace constraint, but it does not add meaningfully new parameter-level details such as patch formatting, defaults, or examples, so the baseline score applies.

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

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

The description opens with a specific verb and resource: 'Apply one unified diff patch inside the workspace.' It also distinguishes apply_patch from its nearest sibling edit by explicitly saying apply_patch is for multi-file diffs, so the agent can tell it apart without needing to inspect other 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 gives direct selection guidance: 'Prefer edit for tiny replacements and apply_patch for multi-file diffs.' This explicitly names the alternative and the condition for choosing each tool, leaving no ambiguity about when to use apply_patch.

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 carry the safety profile (destructiveHint=true, readOnlyHint=false, openWorldHint=true), so the bar is lower. The description adds genuinely useful behavioral constraints beyond the annotations: only allowlisted verification commands may run, only a single command (no chaining), and no shell redirection/pipe constructs. This meaningfully shapes agent behavior without contradicting 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?

Three sentences with zero waste: purpose is front-loaded, exclusions and alternatives follow, then invocation constraints. Every sentence earns its place and the structure makes it skimmable for an agent.

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

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

Given the safety-sensitive nature of a command runner, the combination of annotations (destructive/openWorld), full schema coverage, and the description covers what to run, when to run it, and how to constrain invocations. The main gap is the absence of an output schema and no description of the return format (stdout/stderr/exit code), but for a bash tool this is fairly standard and a minor omission.

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

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

Schema description coverage is 100%, so all five parameters (command, cwd, session_id, timeout_ms, workspace_id) are already documented in the schema, warranting the baseline 3. The description adds marginal value by constraining what values the command parameter may take (single, allowlisted, un-chained), but provides no format or syntax detail beyond that.

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

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

States a specific verb and resource ('Run one allowlisted verification command') with concrete examples (tests, build, lint, typecheck, project script). It also distinguishes itself from siblings by explicitly naming what it is not for (git status/diff, file inspection) and pointing to the correct alternatives, so an agent can route correctly without opening schemas.

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

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

Provides explicit when-to-use guidance ('verification command') and exclusions ('Do not use for git status/diff or file inspection') with named sibling alternatives (show_changes, tree, search, read). Also gives hard constraints on invocation style (no &&, pipes, redirects, or shell file readers). Nothing is left to inference.

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

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

Annotation Contradiction: readOnlyHint is true, yet the description says the tool will 'Forget one opened workspace from this server session,' which is a state-changing action in the server session. This directly contradicts the read-only annotation. The clarification that it does not delete files is helpful, but the contradiction makes the behavioral transparency unreliable.

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

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

Two sentences with no wasted words. The core action is front-loaded, and the second sentence earns its place by disambiguating from file deletion.

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

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

For a single-parameter tool with no nested objects or output schema, the description covers the core behavior, the session scope, and the non-destructive nature. It is adequate for an agent to invoke correctly, though the annotation contradiction prevents full 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?

Schema description coverage is 100% and the only parameter, workspace_id, is already described as 'Workspace id to close.' The description adds only the qualifier 'opened' to the workspace, which is mild extra context. With full schema coverage, the 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 uses the specific verb 'Forget' with a clear resource, 'one opened workspace,' and scopes the action to 'this server session.' It also explicitly distinguishes itself from file-deleting operations by stating 'This does not delete files,' so an agent can separate it from filesystem tools and from open_workspace.

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: use this to forget one opened workspace from the current server session. It does not explicitly name alternatives or when-not-to-use conditions, but the intended use case is evident from the wording and sibling names.

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 a destructive, non-read-only operation, and the description is consistent with that. It adds useful behavioral detail by emphasizing exact replacement and by disclosing the unified-diff return value.

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 that states the core action, the target scope, and the return value. Every element earns its place and there is no 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?

Given the fully documented schema, the annotations, and the description's disclosure of the diff return value, the tool is sufficiently specified for correct invocation. The main missing piece is routing guidance relative to apply_patch, already penalized under usage guidelines.

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 parameters are already well documented. The description reinforces the exact-replacement nature of old_text/new_text but does not add meaning beyond what the schema provides.

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

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

The description names a specific verb and resource ('Apply a targeted exact text replacement inside a workspace text file') and also states the return format. It is clear, though it does not explicitly contrast itself with sibling tools like apply_patch or write.

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

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

The description gives no direct guidance on when to use this tool versus apply_patch or write, nor does it mention exclusions. The word 'targeted' implies surgical edits, but the agent must infer routing to this tool from 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: the tool intentionally avoids returning pixel data and instead reports metadata plus a tile grid recommendation. This tells the agent what side effects it avoids and what kind of result to expect.

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

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

Two sentences, no filler. The first sentence defines the tool's core purpose and its key limitation, while the second sentence states the outputs. Every phrase contributes meaning, and the distinguishing 'without returning its pixels' is front-loaded.

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

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

There is no output schema, so the description correctly takes responsibility for explaining what the tool returns: dimensions, bytes, and a recommended tile grid. Combined with the 100%-covered input schema and read-only annotations, an agent has enough information to invoke the tool correctly and interpret its result.

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

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

Schema description coverage is 100%, so the schema fully documents path, tile_overlap, and workspace_id. The description mentions the tile grid concept, which loosely ties to tile_overlap, but adds little parameter-level detail beyond the schema. A baseline of 3 is appropriate when the schema already carries the parameter documentation burden.

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, 'Inspect a workspace-local image', and clearly distinguishes the tool from siblings by saying it does not return pixels. It then names the concrete outputs: original dimensions/bytes and a recommended tile grid. This makes the tool's purpose unambiguous even before looking at 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 'for high-detail follow-up reads' gives clear context for when to use this tool. The negative statement 'without returning its pixels' implicitly tells the agent not to use it when pixel data is required, though it does not explicitly name read_image or read_image_crop as the pixel-returning alternatives. This is strong but not fully explicit.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds 'bounded' and 'coverage warnings,' hinting at output limitations, but it does not discuss pagination, truncation behavior, or analysis cost. This is adequate given the annotations, but not rich.

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 filler. It front-loads the core action and output scope, then enumerates the components compactly. 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 tool with 9 parameters and no output schema, the description gives only a high-level output list. It does not cover mode selection, pagination/default limits, or when to choose this over siblings. The input schema fills parameter details, but the overall invocation context remains thin.

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 parameter semantics are already fully documented. The description does not repeat parameter details, but it aligns output concepts like symbols and relationships with include_symbols and include_relationships, adding marginal context. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Build') and resource ('bounded repository map') and enumerates the map's contents: languages, project types, entrypoints, areas, symbols, relationships, and coverage warnings. This clearly distinguishes it from file-level tools like read or tree, though it does not explicitly name any sibling alternative.

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 inspect_workspace versus related tools like tree, search, or list_workspaces. No conditions, exclusions, or alternative-routing hints are provided; the only signal is the tool's name.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the scoping detail that only currently opened workspaces for the server/config are returned, which is useful, but it does not disclose return format or pagination 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?

A single sentence with no filler; the verb and scope are front-loaded. 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 zero-parameter read-only list tool, the description is mostly complete: it states what is listed and the scope. However, with no output schema, it does not describe the return shape (e.g., workspace names vs. metadata), leaving a small gap.

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

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

There are zero parameters and schema coverage is 100%, so the baseline of 4 applies. The description adds no parameter information because there is nothing to document.

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 the specific verb 'List' and identifies the resource: currently opened LocalWorkspaceBridge workspaces, scoped to the server/config. This distinguishes it clearly from sibling tools like open_workspace, close_workspace, or inspect_workspace.

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 guidance is given on when to prefer this tool over related siblings such as inspect_workspace or open_current_workspace. The phrase 'currently opened' implies a use case, but there is no explicit when/when-not or alternative routing.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by noting the load is bounded and path-restricted, but it does not explain response format, truncation behavior, or error handling.

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

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

Two sentences, no fluff, with the core operation and the most important usage constraint front-loaded. Every clause 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 read-only tool with 7 well-documented parameters, the description gives the essential sequence (inventory first, then load by name) and the critical restriction on paths. It does not detail output shape, but 'SKILL.md body' communicates the main return value, and annotations cover safety.

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

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

Schema description coverage is 100%, so the schema already documents all 7 parameters. The description adds the key constraint that names come from skill_inventory and that arbitrary paths are rejected, which complements the path/name parameters but does not need to repeat the full 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 ('Load') and a specific resource ('bounded SKILL.md body') for discovered workspace, user, or plugin skills. It also distinguishes itself from arbitrary file reading by explicitly rejecting arbitrary paths.

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

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

It clearly states the precondition: use after open_current_workspace/open_workspace shows skill_inventory. It also gives a negative guideline ('Does not accept arbitrary paths'), helping the agent know when this tool is not appropriate.

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. The description adds value by stating it cannot call tools disabled by the current mode, which is behavioral context beyond the annotations. This justifies a score above the baseline.

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 purpose is front-loaded ('Stable wrapper'), and the constraint is placed at the end. It is concise and well-structured, though the phrase 'advanced ChatGPT connector setups' is slightly vague but not verbose enough to warrant a 3.

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 wrapper tool with two parameters and no output schema, the description covers the core mechanics, the mode constraint, and directs to list_actions. It does not explain potential side effects beyond annotations, but annotations already cover destructive behavior. Overall it is complete enough for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add anything beyond what the schema already provides for the two parameters; it simply echoes 'pass action plus args' without enriching the meaning.

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 it is a stable wrapper that passes action plus args to an already-registered LocalWorkspaceBridge tool, which is a specific verb-resource combination. It distinguishes itself as a generic dispatcher, though it does not explicitly compare to sibling tools, so it gets a 4 rather than a 5.

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 implies use for advanced ChatGPT connector setups and for invoking an already-registered tool without schema changes. It provides a constraint (cannot call disabled tools) but does not explicitly state when to use this vs alternatives or when not to use it, so it is adequate but incomplete.

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 declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful context by stating the test will not modify workspace files and is 'controlled' and 'local.' It also clarifies the scope of checks, which goes beyond the annotations, though it does not describe what output the diagnostic produces.

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

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

The description is a single, dense sentence that front-loads the core action and then lists the diagnostic scope without wasted words. Every phrase contributes to understanding the tool's behavior and constraints.

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 selecting and invoking the tool, and the schema covers all parameters. However, there is no output schema and the description does not explain what the diagnostic returns or how an agent should interpret the result, which is a notable gap for a self-test tool.

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

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

Schema description coverage is 100%, so all four parameters are already well documented in the schema. The main description does not add parameter-level detail, but that is acceptable because the schema carries the full burden. Baseline 3 is appropriate here.

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

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

The description names a specific verb ('Run'), a clear resource ('a controlled local diagnostic'), and enumerates the exact areas covered: workspace access, tool registration, skills, git, and bash policy. It also adds the key constraint 'without modifying workspace files,' which distinguishes this self-test from file-inspection siblings like inspect_workspace.

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 'controlled local diagnostic' implies this tool is for verifying bridge health, but the description does not explicitly state when to prefer it over alternatives such as inspect_workspace or tree. Usage context is implied rather than spelled out, and no exclusions or alternative recommendations are 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them. It adds useful beyond-schema context: the tool is intended as the initial workspace-opening call, it accepts no path, and it establishes a root context such that following it with open_workspace means switching roots.

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 compact sentences with zero padding. The main instruction is front-loaded and the alternative-tool warning appears in the second sentence, giving a clear and efficient structure.

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

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

For a simple optional-parameter tool, the description covers the core invocation rule, the no-path constraint, and the relationship to open_workspace. The schema covers parameter details, and the annotations cover safety, so nothing essential for selecting and calling this tool is 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?

All four parameters are fully documented in the input schema (types, ranges, defaults, and behavior such as 'Default: false for speed'), so the description does not need to add much. The description adds no parameter-specific guidance, matching the baseline for high 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 names a specific verb ('open'), a specific resource ('the configured default workspace'), and an explicit constraint ('without accepting a path'). It also contrasts directly with open_workspace, making it easy for an agent to distinguish this from the sibling tool.

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

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

It gives an explicit usage trigger ('Use this once at the start') and an explicit exclusion ('Do not call open_workspace after this unless switching roots'). This tells the agent both when to invoke this tool and when not to invoke the obvious alternative.

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 the safety profile (read-only, non-destructive). The description goes beyond them by detailing the workspace_id plus git status, AGENTS.md, and compact file tree that will be returned, giving the agent a concrete expectation of the response. It does not discuss potential scan costs or non-idempotent behavior, but this is minor given the parameter schema and 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?

Two short sentences carry the purpose and the output contract with no filler. The return value list is front-loaded after the verb phrase, making the core behavior immediately 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?

Although there is no output schema, the description names the important returned fields. All optional parameters are documented in the schema, and the annotations cover safety concerns, so an agent has enough context to invoke the tool and interpret its result.

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?

All seven parameters are fully described in the schema (100% coverage), so the baseline applies. The description's mention of 'local project directory' simply echoes the path/root parameter without adding syntax or edge-case detail beyond the schema.

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

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

The description states a specific action ('Open a local project directory as a LocalWorkspaceBridge workspace') and names the key results (workspace_id plus git status, AGENTS.md, and file tree). This clearly differentiates it from siblings like open_current_workspace, which works on the current directory rather than a user-supplied root.

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: call this when you need to open a local project directory into a workspace. However, the description does not explicitly contrast it with open_current_workspace or say when to prefer one over the other, leaving the agent to infer routing.

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

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

Annotations already mark readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that output includes line numbers and counsels against redundant rereads, which is useful but modest behavioral context; no pagination or encoding behavior is disclosed.

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

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

Two sentences with no filler. The purpose and the key usage caveat are front-loaded in a compact, easily parsed form.

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?

All five parameters are documented in the schema, annotations cover safety, and the description adds the one non-obvious operational tip about avoiding redundant rereads. There is no output schema, but mentioning line numbers gives a rough return-format expectation; minor omissions like pagination behavior are inferable from max_bytes and start_line parameters.

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

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

Schema covers 100% of parameters with descriptions, so baseline is 3. The description adds no parameter-specific detail beyond 'text file' and line numbers; start_line, end_line, max_bytes, and workspace_id semantics live in the schema.

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

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

Description opens with 'Read a specific text file with line numbers,' identifying the verb, resource, and output format. It clearly distinguishes itself from sibling tools like write/edit and read_image by restricting scope to text files.

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

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

Gives explicit when-not guidance: avoid rereading after write/edit/apply_patch unless exact final content is needed. It does not explicitly name alternative listing/search tools, but the text-file scope and read-only safety make the intended use 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 declare the operation is read-only and non-destructive, so the bar is lower. The description adds valuable behavioral context beyond the annotations: default preview sizing of 1600 px, the experimental nature of values above 1600 in ChatGPT, and the guarantee of returning native MCP image content. It does not fully describe failure behavior or output-size edge cases, but the schema covers those partially.

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 uses only three sentences, each earning its place: purpose, sizing behavior, and alternative routing. It front-loads the core purpose and avoids redundant restatement of the tool name or schema details.

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 read-only preview tool with fully documented parameters and annotations, the description is complete. It clarifies the output type (native MCP image content), supported formats, preview sizing limits, and the available sibling tools for pixel-level work. No output schema exists, but the description sufficiently covers what the agent needs to know.

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

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

Schema description coverage is 100%, so the schema already documents path, workspace_id, max_dimension, and return_original with detailed constraints. The description adds no new parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description states a specific verb-resource pair: 'Read a workspace-local JPEG, PNG, or WebP as native MCP image content.' It clearly differentiates from the closely related siblings image_info, read_image_crop, and read_image_tile by naming them as alternatives for pixel-level detail rather than whole-image previews.

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

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

The description explicitly tells the agent when not to use this tool: 'For pixel-level detail, prefer image_info plus read_image_crop/read_image_tile.' It also implies the correct use case through 'Safe default previews' and the mention of returning native MCP image content. This is explicit enough for an agent to route correctly.

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, covering the safety profile. The description adds genuinely useful behavior beyond that: the crop is 'rendered at a safe maximum longest side of 1600 px' (so output may be downscaled) and coordinates are 'original-image pixels from the top-left corner.' 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?

Two sentences with zero waste: purpose first, then the two critical constraints (rendering cap and coordinate frame). Every sentence earns its place and nothing is redundant with the schema.

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 with no output schema, the description covers purpose, coordinate system, and rendering cap, but omits out-of-bounds behavior and any guidance on how this tool relates to read_image and read_image_tile. An agent can invoke it correctly, but the sibling selection context is left unresolved.

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 of 3 applies. The description adds the 'from the top-left corner' origin clarification and the 1600 px cap context for max_dimension, but most parameter semantics (x/y/width/height in original-image pixels) are already fully documented in the schema, making the description's additive value modest.

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

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

The description names a specific operation ('Read a rectangular crop directly from the original image') with a clear resource and scope. 'Rectangular crop' plus 'directly from the original image' separates it from sibling tools like read_image and read_image_tile without needing to open their schemas.

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

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

The description implies when to use it — when a rectangular region of the original image is needed — but it never names read_image or read_image_tile as alternatives, and gives no explicit when-not-to-use guidance. Usage context is inferable rather than stated.

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

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

Annotations already mark the tool as read-only and non-destructive. The description adds useful behavioral details beyond that: tiles come from original pixels, default to 8% overlap, and are capped at a 1600 px longest side. This helps set expectations about fidelity and output limits.

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 well-structured sentence that front-loads the core purpose and packs only high-value behavioral details. No filler or repetition of schema information.

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 six parameters and no output schema, but the schema itself is detailed with 100% coverage. The description covers the essential behavior, overlap default, and size limit. It does not explicitly connect to image_info or rule out alternatives, but the schema and sibling names fill most of that gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that tiles are original-pixel-based and constrained to a safe 1600 px path, which clarifies the intent behind overlap and max_dimension parameters even before reading their descriptions.

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

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

The description opens with a specific verb and resource: 'Read one tile from an automatically recommended high-detail grid.' This clearly differentiates it from whole-image reading and arbitrary cropping tools among the siblings.

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

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

The description implies use for high-detail grid tiles, and schema parameters reference image_info's recommended grid, but the description itself does not explicitly say when to use this tool versus read_image_crop or read_image, nor does it state prerequisites like calling image_info first.

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 strategic guidance but not additional behavioral details such as output truncation, result ordering, or performance characteristics. With annotations present, this is an acceptable but not rich contribution.

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 short sentences with no redundant phrasing. The primary use case is front-loaded, and the practical guidance about avoiding repeated broad searches 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?

The tool has 10 parameters including an enum-based intent field and no output schema, yet the description only provides use-case guidance. The schema covers parameters and annotations cover read-only safety, but the description does not address result behavior, workspace scope, or structured-search modes, leaving moderate 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 100%, so all 10 parameters are already documented in the input schema. The description adds no parameter-level meaning beyond what the schema provides, so the 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 identifies the tool's purpose as targeted verification and code lookup, which is specific enough to orient an agent. It stops short of explicitly stating that it searches file contents across the workspace, and it does not differentiate itself from siblings like read or tree.

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

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

The description gives explicit context: use for targeted verification or code lookup. It also provides a clear strategy: prefer one specific final search rather than repeated broad verification searches. It does not name alternative tools or exclusion conditions, so it is not 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?

Annotations already mark the tool as read-only and non-destructive, and the description reinforces this by saying it 'Shows' configuration. It adds meaningful behavioral disclosure with 'Does not reveal auth tokens,' telling agents what sensitive data will not be exposed.

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 short sentences with no filler. The core purpose is front-loaded in the first sentence, and the important privacy constraint is succinctly added in the second.

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 read-only configuration inspection tool, the description is complete: it states what is shown, implies read-only behavior, and explicitly discloses the auth-token exclusion. Nothing needed for correct invocation is 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?

The tool has zero parameters and the schema coverage is 100%, so there are no parameter semantics for the description to clarify. The baseline of 4 applies because no parameter documentation is needed.

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' with a clear resource: 'LocalWorkspaceBridge server configuration.' It further specifies the exact contents (safety modes, limits, blocked paths), making it easy to distinguish from file/workspace manipulation siblings like write, edit, and inspect_workspace.

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

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

The description clearly indicates this tool is for reading server configuration and safety-related settings, with zero parameters and no prerequisites. It does not explicitly name alternatives or exclusions, but the sibling tools are mostly file/workspace operations, so the usage context is clear enough.

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 says the tool 'Set[s]' a workspace as default/active, which implies a state change. This directly contradicts the annotation readOnlyHint=true, which indicates the tool does not modify state. Therefore the description contradicts 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?

The description is a single, front-loaded sentence with no filler. Every part contributes meaning: the target workspace, the precondition that it is already opened, and the effect on omitted workspace_id calls.

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 tool, the core effect is stated, but the contradiction with readOnlyHint leaves the behavioral profile unreliable. The description also does not clarify persistence, session scope, or whether this changes any stored server state.

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% and the schema already explains that workspace_id comes from open_workspace/list_workspaces. The tool description adds no additional parameter semantics beyond the schema, so the baseline 3 is appropriate.

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

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

The description states a specific verb ('Set'), a specific resource ('an already-opened workspace'), and the exact purpose ('default and active workspace for omitted workspace_id calls'). The phrase 'already-opened' also distinguishes it from open_workspace, which actually opens a workspace.

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: after a workspace is already opened and when you want it to be the default for calls that omit workspace_id. However, it does not explicitly mention alternatives like list_workspaces/open_workspace or state when not to use the 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?

Annotations already establish read-only and non-destructive behavior. The description adds that the tool aggregates multiple git views into a single review-oriented result and clarifies the optional diff. It doesn't explicitly surface the mark_reviewed checkpoint side effect, but that is already documented in the parameter schema, so the description is not misleading.

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

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

Two sentences with no filler: the core action and output are front-loaded, and the routing guidance is in the second sentence. Every phrase 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 read-only tool with 6 self-describing parameters and no output schema, the description provides a clear output sketch and usage context. It could be more explicit about the review-checkpoint behavior, but the parameter docs and annotations cover the remainder.

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?

All 6 parameters are covered at 100% in the schema, so the description needn't repeat details. It adds a high-level mapping to output components like diff stats and optional diff, but no parameter-specific meaning beyond the schema.

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

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

Description uses a specific verb (summarize), names the exact resource (current workspace changes), and enumerates output components (git status, diff stats, optional diff). It also explicitly contrasts with sibling git/bash tools, so an agent can distinguish show_changes from 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?

States the use case ('when reviewing work') and explicitly says 'Use this instead of bash git status, bash git diff, git_status, or git_diff'. This gives both a positive trigger and named alternatives to avoid.

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 one useful behavioral limitation, 'excluding blocked paths', but does not disclose output format or truncation behavior; still a reasonable mid-level contribution.

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 states the action, scope, and a key limitation with no filler. It is concise and front-loaded, every word contributing value.

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

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

For a simple read-only listing tool, the description combined with the rich schema and safety annotations is largely complete. It does not describe the exact return format, which is a minor gap, but an agent likely has enough context to invoke the tool correctly.

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

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

All five parameters are fully described in the input schema, so the schema carries the semantic weight. The description itself adds no parameter-level detail beyond what is already structured, matching the baseline for high 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 clearly states a specific action ('List'), a resource ('files and directories'), and a scope ('inside the workspace'), so an agent can tell it apart from content-reading or searching tools. It does not explicitly name a sibling alternative, but the behavior is 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 no explicit guidance about when to choose tree over related tools like search, read, or inspect_workspace. The intended use is implied by the action 'List files and directories', but no conditions or alternatives 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 destructiveHint=true and readOnlyHint=false, and the description reinforces this with 'overwrite.' Beyond annotations, it discloses that the tool returns a unified diff and warns against empty placeholder files, adding useful behavioral context. It does not contradict 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?

The description is two concise sentences with no filler. The primary action is front-loaded first, followed by the return behavior and a key usage rule. Every phrase carries necessary information.

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

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

For a 5-parameter tool with no output schema, the description covers the essential context: workspace scope, create/overwrite behavior, return format, and a critical guideline about placeholders. It relies appropriately on the schema for parameter details and annotations for destructive behavior. It is nearly complete, though it does not discuss failure modes or diff formatting in more depth.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema itself documents path, content, overwrite, create_dirs, and workspace_id. The description adds little parameter-level detail beyond 'meaningful text file' and 'inside the workspace.' This meets the baseline but does not exceed it.

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

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

The description clearly states the tool creates or overwrites a text file inside the workspace, which differentiates it from sibling tools like edit or apply_patch that modify existing content. The scope is specific: a meaningful text file within the workspace. It leaves no ambiguity about the core 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 description provides clear usage context: use this tool to create or overwrite files in the workspace. It also gives an explicit constraint, 'do not create empty placeholder files,' which guides agent behavior. However, it does not directly name alternatives or state when to prefer edit or apply_patch over write, so it stops short of full exclusions.

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