wsl-bridge-mcp

by Darling209

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action: file operations, process management, environment variables, and system queries are cleanly separated. Even similar tools like run_command vs start_process or read_file vs read_multiple_files have clear behavioral differences. No two tools appear to do the same thing.
Naming Consistency5/5
Tool names consistently follow a verb_noun pattern in snake_case, such as write_file, list_directory, get_system_info, and stop_process. Minor exceptions like diagnose or check_wsl_status still fit the general style. The naming is predictable and makes it easy to infer what each tool does.
Tool Count2/5
With 28 tools, this exceeds the 25-tool threshold considered 'too many', though the broad scope of a WSL bridge justifies many of them. Still, consolidation is possible, e.g., merging get_file_info into list_directory or having diagnose call other tools. The set feels heavy even if each tool is individually useful.
Completeness4/5
The tool surface covers a comprehensive set of WSL operations: file CRUD and search, process execution and management, environment controls, system information, path translation, and an audit log. A minor gap is the lack of distro lifecycle management (start/stop/shutdown), but that is not essential for typical bridging tasks. Core workflows are fully covered with no dead ends.
Average 3.9/5 across 28 of 28 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It only mentions 'recursive' but omits important behaviors such as whether the operation is idempotent (if directory already exists), whether intermediate parent directories are created, how distro selection works, permissions required, or return values. This is a mutation tool, so more transparency is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single imperative sentence that is front-loaded with the action. There is zero wasted wording, and it conveys the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple, the description omits critical operational context such as return values, error behavior (e.g., existing directory, invalid path), and distro parameter semantics. No output schema is provided, so the description should compensate, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 mention 'path' or 'distro' at all. It does not clarify that 'path' is the target directory path or that 'distro' specifies the WSL distribution, nor whether distro has a default. The description adds no meaning beyond the raw schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), resource ('a directory'), context ('in WSL'), and behavior ('recursive'). This distinguishes it from sibling file/content manipulation tools like write_file or edit_file, which create/modify files rather than directories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, run_command could also create a directory via shell commands, but the description does not mention this alternative or any exclusions. The usage context is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states the action but does not mention overwrite behavior, whether it is destructive, permissions required, atomicity, or what happens if the destination exists. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the core action and resource. It contains no filler words, redundancy, or irrelevant details. It is appropriately sized for the simple operation it describes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a seemingly simple operation, the tool has no output schema and no annotations. The description does not explain return values, error handling, whether the move is synchronous, or effects of the optional 'distro' parameter. Given the environment is WSL, more context is needed for the agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no explanation of 'from', 'to', or 'distro' parameters. While 'from' and 'to' are self-explanatory, 'distro' is ambiguous without additional context. The description must compensate for the missing schema descriptions, but it fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'move or rename' and identifies the resource as 'a file/directory within WSL'. This clearly distinguishes it from siblings like write_file, edit_file, or delete_path, and the scope 'within WSL' adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or scenarios like copying, overwriting, or cross-filesystem moves. The context of 'move or rename' implies a distinct operation, but the tool does not state this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It implies a read-only list operation but 'mark the default' introduces uncertainty about potential side effects. It does not explicitly state that the tool is non-mutating or what happens in edge cases (e.g., no distros installed).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words. It conveys the main purpose and the expected output fields efficiently, though the phrase 'mark the default' could be more precise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter, no-annotation tool, the description covers the core output (distributions, state, version) but leaves the phrase 'mark the default' unexplained, and it omits any error behavior or preconditions. It is minimally adequate but has gaps given the absence of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so the baseline is 4. The description adds no parameter-specific semantics, but none are needed; it does not conflict with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List') and resource ('installed WSL distributions') and indicates the output fields (state, version). It is distinguishable from sibling tools like check_wsl_status. However, 'mark the default' is ambiguous—it could mean indicating the default or modifying it—slightly weakening clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention prerequisites (e.g., WSL must be installed) or contexts where this is preferable to check_wsl_status, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden for disclosing behavior. It lists output fields but does not explicitly state that the operation is read-only, whether symlinks are followed, whether permissions are needed, or how non-existent paths are handled. The read-only nature is only implicit in 'stat'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the operation and the key output fields. Every word adds value, and there is no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must cover both parameter semantics and behavioral context. It lists return fields but omits the distro parameter, error cases, and any discussion of permissions or side effects. The tool is simple, but the description still leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameter descriptions, so the description must compensate. It clarifies that 'path' is a WSL path, but it does not explain the 'distro' parameter at all, leaving it ambiguous. This is inadequate given the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'stat' and identifies the resource as a 'WSL path', making the tool's purpose immediately clear. It also lists the exact metadata returned (type, size, mode, mtime, atime), which distinguishes it from sibling tools like read_file (content) and list_directory (listing entries).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is used to obtain file metadata, but it does not explicitly state when to use it versus alternatives such as read_file or list_directory. There is no mention of exclusions, prerequisites, or direct comparisons to sibling tools, leaving usage guidance only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It lists the components checked, which gives good insight into behavior, but it does not disclose potential side effects (e.g., whether the UNC write/read probe creates files or modifies state), nor does it mention any permissions needed. The 'write/read probe' could be a write operation, which is not flagged as non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence that front-loads the action ('Run a diagnostic sweep') and enumerates specific checks. No wasted words; every element contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderately complex nature of a multi-part diagnostic and the absence of an output schema, the description does a good job explaining the scope of checks and the output format ('pass/fail report'). However, the unexplained 'distro' parameter and lack of side-effect disclosure hold it back from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional string parameter 'distro' with 0% schema description coverage. The description does not mention or explain this parameter at all, leaving the agent uncertain whether it is a filter, target, or something else. The description completely fails to compensate for the schema's lack of info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run a diagnostic sweep') and names concrete resources being checked (distros, UNC reachability, persistent shell, /tmp/wsl-bridge, UNC write/read probe). It clearly distinguishes itself from individual sibling tools like list_distros or check_wsl_status by being a composite health report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for overall environment diagnostics and mentions it returns a pass/fail report, but it does not explicitly state when to use this tool versus the individual sibling tools, nor does it list any exclusions or prerequisites. The usage context is inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains that the tool checks both reachability and persistent shell responsiveness, providing some insight, but does not describe return behavior, side effects, error handling, or whether any command is sent to the distro.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. It is front-loaded with 'Health check' and contains no filler or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description is adequate but incomplete. It does not explain what the agent should expect as a return value or result, which is important for a health check that may indicate success or failure. The description could be more complete by specifying output format or failure behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the 'distro' parameter already described. The description adds no additional meaning to the parameter, so the baseline of 3 is appropriate. It does not clarify default behavior beyond the schema's mention of defaultDistro.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a health check on a WSL distro, confirming reachability and persistent shell responsiveness. This specific verb+resource pairing distinguishes it from siblings like list_distros (which lists distros) and run_command (which executes commands).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a health check before engaging with a distro, but does not explicitly state when to use it over alternatives or mention exclusions. The purpose is evident, but no direct comparison is made to sibling tools like list_distros or get_process_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses useful behavior: entries include type and size, directories sort first, and offset/limit pagination is supported. However, it does not mention return format details, hidden-file handling, symlink behavior, or potential errors, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and every clause earns its place: it states the operation, output fields, sort order, and pagination support. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters and no output schema. The description covers the core listing behavior and pagination, but does not clarify the role of the 'distro' parameter or the structure of the returned entries. Given the WSL context and sibling tools like list_distros, this is a significant omission for a fully self-contained description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% (limit and offset have descriptions; path and distro do not). The description mentions offset/limit pagination, reinforcing the schema for those parameters, but it adds nothing about path semantics or how distro is selected, so the low-coverage parameters remain under-explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('entries in a WSL directory') and specifies additional output details (type and size). It clearly distinguishes from sibling tools like read_file and get_file_info, which focus on file content or single-file metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it is for listing directory entries and mentions pagination for large directories. However, it does not explicitly state when to prefer this tool over alternatives, nor does it provide exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It reveals the uniqueness constraint and dryRun preview feature, but does not explain failure modes (e.g., what happens if oldString is not found), whether the file must pre-exist, or any permission requirements. This is adequate but incomplete for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the core purpose, a key constraint, and the preview option without fluff. Every word earns its place; no redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no output schema, the description covers the main edit operation but falls short on the distro parameter and failure behavior. It's moderately complete for a simple edit tool, but the missing parameter semantics and lack of error disclosure prevent a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It explains oldString, newString, replaceAll, and dryRun, but completely omits 'distro' and 'path', which are core parameters. Without schema descriptions, the distro parameter's purpose remains unclear, making this a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs line/substring-based edits on a WSL file, replacing oldString with newString. This distinguishes it from siblings like write_file, which creates/overwrites whole files, and read_file, which reads content. The verb 'edit' and resource 'WSL file' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete guidance: oldString must be unique unless replaceAll=true, and dryRun=true is recommended for previewing. While it doesn't explicitly contrast with write_file, the substring-based nature implies editing existing content, and the dryRun/replaceAll hints give practical usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly indicates a read operation ('Get') and lists the information categories, which adds context. However, it does not disclose any prerequisites, error behavior, side effects (e.g., whether it boots the distro), or return format. For a read-only tool, this is adequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It leads with the action and resource, then parenthetically lists the specific data points, making every word informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter, the description adequately conveys the purpose and output scope. The listed info categories hint at the return content. However, the absence of an output schema and annotations means some details like return format or error handling are not covered, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter 'distro' with its default behavior (100% coverage). The description's mention of 'for a distro' aligns with the schema but adds no new semantic information. The baseline of 3 is appropriate since the schema handles the parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and resource 'WSL system info' with scope 'for a distro', and enumerates the exact data categories (OS, kernel, uptime, memory, disk, user). This clearly distinguishes it from sibling tools like check_wsl_status, which likely focuses on WSL installation health rather than system details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but provides no explicit guidance on when to use it instead of alternatives. Usage context is implied by the 'Get' action and mention of 'distro', but there are no exclusions or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the persistent nature of the change across run_command calls, which is useful, but it does not mention side effects like overwriting existing values, distro scoping, or any permission requirements. The persistence trait lifts it above a bare 'set' description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource, then adds the most important behavioral qualifier. Every phrase earns its place and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits the optional 'distro' parameter and does not clarify whether the variable is set in the default distro or one specified by the parameter. The persistence behavior is covered, but without more parameter or default-scope context the description is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to compensate for parameter documentation. It does not explain the 'distro' parameter at all, and while 'name' and 'value' are self-explanatory, the lack of any parameter detail leaves the optional distro behavior ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific action 'Set' and clearly identifies the resource as 'an environment variable in the persistent WSL shell.' This distinguishes it from sibling tools like get_env (which reads) and run_command (which executes commands), and the parenthetical persistence note adds key scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'persists across run_command calls' gives a clear context for when to use this tool: to prepare environment variables for later shell commands. It does not explicitly mention alternatives or exclusion cases, but the context is sufficient to differentiate it from get_env and set_cwd.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It omits important details such as the requirement of a distro for posix-to-unc conversion, whether the operation is read-only, and potential error conditions. The description is too minimal to fully inform the agent about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the core functionality and then provide a practical use case. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, a well-described schema, and no output schema, the description is reasonably complete. It explains the purpose and a common application. Minor gaps remain, such as not explicitly mentioning the return type, but the overall context is sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters (path, distro, direction) with useful descriptions, including the auto-detection of direction. The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Translate') and the exact resource types (WSL POSIX path, Windows UNC path), covering both directions. This distinguishes it from sibling tools like resolve_path or get_system_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a concrete use case ('understanding where a WSL file lives on the Windows side') that helps the agent know when to use it. However, it does not explicitly mention alternatives or when not to use the tool, missing an opportunity for fuller guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. The verb 'Read' implies a non-destructive operation, and the scope is clarified by 'persistent WSL shell'. However, it doesn't disclose the return format or behavior when a name is not found, which could be expected for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the core purpose, and the second provides immediate usage guidance, with no redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should describe what is returned, but it doesn't. Additionally, the 'distro' parameter is missing from the description, making the tool's invocation only partially specified. Given the tool's simplicity, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains the 'name' parameter ('Pass name for one var, or omit for all'), but the 'distro' parameter is entirely unexplained, leaving a gap in the tool's semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read') and resource ('environment variables'), and specifies the context ('persistent WSL shell'). It clearly differentiates from the sibling 'set_env' by focusing on reading rather than writing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage instructions: 'Pass name for one var, or omit for all.' This defines when to use optional parameters. However, it does not explicitly mention alternatives or when-not-to-use, though the read/write contrast with set_env is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It discloses ordering and filter behavior, and 'query' implies a read-only operation, but it does not describe return format, pagination, or whether results are truncated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the core action, ordering, and filter options efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 optional parameters and no output schema or annotations. The description covers purpose, ordering, and filters, but omits details like limit behavior and the structure of returned entries, so it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (limit and since are documented), while tool and keyword lack schema descriptions. The description adds meaning by identifying tool, since, and keyword as filters, partially compensating for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Query'), the resource ('audit log of past tool calls'), and a key behavior (most-recent-first ordering). This distinguishes it from sibling tools like search_content or read_process_output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is implied by 'audit log of past tool calls', but there is no explicit when-to-use guidance or comparison to alternatives. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the guardrail behavior (confirm requirement) and that recursive is needed for non-empty directories. But it does not mention irreversibility, error handling, or permission requirements, leaving moderate gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with no unnecessary content. The first sentence states the main purpose; the second adds essential conditions. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature and no output schema, the description covers the core action, recursion requirement, and guardrail confirmation. It leaves some ambiguity about distro behavior and error responses, but overall it is sufficiently complete for a delete tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, and the description adds meaning by clarifying that recursive is for non-empty directories and confirm is a guardrail confirmation. It does not explain the distro parameter, and path semantics are only lightly implied ('file or directory'). It partially compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Delete' and resource 'file or directory in WSL', clearly distinguishing it from sibling tools like move_file or create_directory. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific usage conditions: recursive directory deletion requires recursive=true and may require confirm=true for shallow paths, which is clear operational guidance. However, it does not explicitly mention alternatives or when-not-to-use, so it stops short of full alternative differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the core behavior (checking running status, returning exit code) but does not disclose edge-case behavior such as invalid handles or error conditions. This is a moderate gap for a status-check tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly conveys the tool's purpose and return information. No filler or redundancy, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description adequately explains what the tool does and the key return concept (exit code if finished). It doesn't specify the exact response format or invalid-handle behavior, but the core functionality is sufficiently covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter details, including a description of 'handle' as 'Process handle from start_process'. The tool description adds no additional parameter meaning beyond what the schema already provides. Baseline of 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: checking whether a started process is still running and retrieving its exit code if finished. The verb 'check' and resource 'process status' are specific, and the reference to 'started process' distinguishes it from siblings like list_processes or read_process_output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after a process has been started via start_process, and the schema parameter references start_process, providing clear context. It doesn't explicitly exclude alternatives like list_processes or read_process_output, but the purpose is distinct enough that an agent could infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It reveals implementation details ('via ss, falling back to /proc/net/tcp') and notes WSL2 behavior, which adds transparency. However, it does not describe the output format or any potential side effects, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core purpose, and includes only useful context. Every clause adds value: the mechanism, the use case, and the WSL2 note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but with no output schema, the description should explain what the tool returns (e.g., port numbers, format). It also fails to explain the 'distro' parameter. While the purpose and use case are clear, these gaps make the description only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one optional parameter 'distro' with no schema description. The description does not mention or explain this parameter at all, leaving the agent to guess its meaning and valid values. Given 0% schema coverage, the description should have clarified it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists TCP ports listening in WSL, using a specific verb ('List') and specific resource ('TCP ports listening in WSL'). It also distinguishes itself from sibling tools by focusing on ports rather than processes, files, or system info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Useful to find where a dev server is reachable (WSL2 forwards localhost to Windows).' This gives context for when to use the tool, though it does not explicitly mention when not to use it or name alternative tools. Overall, the guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses a key behavioral trait: failures do not abort the batch and each entry is returned independently. This is valuable. However, it does not describe the return format or mention any permissions required, which would add more context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with information front-loaded. The first sentence states the action and benefit, the second explains batch behavior. Every word earns its place, with no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 failure isolation, but for a batch tool with no output schema and minimal annotations, it would benefit from mentioning the return structure, ordering of results, and the distro parameter. The missing return format is a notable gap given the output schema is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (paths has a description, distro does not). The description does not explain the distro parameter or add any parameter-level detail. The purpose implies paths are files in WSL, but the optional distro parameter remains ambiguous, leaving the agent uncertain about how to use it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Read multiple files from WSL in one call', with the specific benefit of reducing round-trips. It distinguishes itself from the single-file sibling read_file by emphasizing the batch nature. The independent return and failure isolation further clarify the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'reduces round-trips' implies this tool is for batch reading, and the independent failure handling indicates it can be used when some files may fail. However, it does not explicitly mention alternatives like read_file or specify when not to use this tool (e.g., for a single file).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It adds useful behavioral details: it returns POSIX paths and behaves like 'find -name'. However, it omits details like default recursion depth, handling of hidden files, and error behavior, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that packs purpose, method, and output with no redundancy. It is front-loaded and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity tool with no output schema and no annotations, the description covers core purpose and return type adequately. The 'find -name' reference and maxDepth parameter imply recursive search, but explicit default behavior is not stated, leaving minor completeness gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 of 4 parameters explained). The description only reinforces pattern semantics via 'find -name' and does not compensate for the undocumented 'distro' parameter. Overall, it adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Find', resource 'files in WSL', and method 'by name pattern (find -name)'. It also specifies output ('matching POSIX paths'), distinguishing it from siblings like search_content (content search) and list_directory (listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for locating files by name pattern in WSL, providing clear context. However, it does not explicitly contrast with sibling tools or state when not to use it, so it lacks exclusions but is still directional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses that the process is backgrounded, returns a handle and pid, and streams output to a log file. This provides meaningful insight beyond what annotations would offer, though it does not cover potential failure modes or process lifecycle details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core action and outcome. It efficiently conveys purpose, return values, and output handling without superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main behavioral aspects and return values, but with 6 parameters and no output schema, it leaves important details unexplained (e.g., what 'confirm' does, how distro is selected, env handling). It is adequate for a high-level understanding but not fully complete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%; cwd, env, distro, and confirm lack descriptions. The tool description does not elaborate on any parameters, so it fails to compensate for the low schema coverage. Only command and separateStderr have schema descriptions, leaving the other parameters semantically under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a long-running process in WSL, explicitly noting it is backgrounded. It distinguishes from siblings like run_command by highlighting the backgrounded nature and the returned handle/pid, plus the log-file output mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for long-running, backgrounded tasks and indicates how output is retrieved via read_process_output. However, it does not explicitly state when to avoid this tool (e.g., for short foreground commands) or name alternatives like run_command. The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the default and force signals and the uppercase naming requirement, but omits side effects (e.g., process termination, unsaved data) and does not clarify whether the process must be started by this tool. Additional disclosure of destructive consequences would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy, immediately front-loading the tool's purpose and then providing essential usage details. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple process signal tool, the description covers the essentials: action, default behavior, and signal syntax. It lacks edge-case behavior (e.g., errors, success output) but given the tool's simplicity, this is acceptable. The absence of output schema and annotations is partially mitigated by the clear description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only signal has a description). The description adds meaningful detail about default signal and uppercase enforcement, compensating somewhat for the undocumented handle parameter, but handle semantics still remain unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send a signal to a started process' with a specific verb and resource, and distinguishes itself from siblings like start_process and get_process_status by focusing on signal delivery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives context on default behavior (SIGTERM) and a specific usage hint for force killing with KILL, but does not explicitly mention alternatives or when not to use it. The guidance is clear enough for common use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does so well: it discloses persistence and the precise effect on subsequent run_command calls. It does not cover edge cases like invalid paths or default distro behavior, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The descriptions uses two short, front-loaded sentences with no wasted words. Every clause adds useful information about what the tool does and its consequences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool, the description covers the main behavioral contract. However, it omits details about distro selection, error handling, and whether the setting persists across WSL sessions, leaving some contextual gaps given the lack of annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%; the distro parameter has no description. The description mentions 'for a distro' but does not clarify valid values, defaults, or how to reference the distro, leaving a significant semantic gap that the schema does not fill.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and resource ('persistent shell working directory for a distro'), making the tool's purpose unambiguous. It also implicitly distinguishes itself from siblings like run_command by explaining how it affects future run_command calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining that subsequent run_command calls without an explicit cwd will use this setting. It does not explicitly mention alternatives or exclusions, but the relationship to run_command gives a strong sense of when 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses several behavioral traits: default encoding, base64 option, automatic parent directory creation, and sha256 return behavior. It does not explicitly state whether existing files are overwritten, which is a minor gap, but the provided details add substantial value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every clause adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the essential behavior for a file-writing tool: encoding, parent dirs, and hash verification. It omits overwrite semantics and distro parameter, but overall it is sufficiently complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, but the description adds meaning for 'content' (UTF-8 default), 'encoding' (base64 option), 'sha256' (returns hash), and implicitly 'path' (creates parent dirs). The 'distro' parameter is not addressed, but the description compensates significantly for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Write a file in WSL', which clearly identifies the verb (write) and resource (file in WSL). It distinguishes from read/delete tools, but does not explicitly differentiate from sibling edit_file, so a 4 is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage guidance: 'content is UTF-8 text by default; set encoding="base64" for binary content' and 'sha256=true returns a hash... for round-trip verification'. It also notes parent directory creation. However, it does not mention when to choose this over edit_file, so it misses explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It discloses incremental offset behavior, follow semantics (brief wait), stream behavior (pushes notifications/message and progress when progressToken provided), and return of next offset. This goes beyond basic 'read' and covers the most important behavioral nuances, though edge cases like invalid handles or binary output are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose. Each sentence earns its place: primary read mechanism, follow/stream options, and stream selection plus return value. No redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and no output schema, the description covers the main workflow (offset-based reading, follow, stream, choosing stdout/stderr, return offset). It omits details on limit, binaryOutput, and streamMs, but these are optional and the overall operation is clear. Adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 63%, and the description adds meaning for follow, stream, which, and offset (via 'byte offset' and 'next offset'). However, it does not explain limit or binaryOutput, which are also missing from schema descriptions for limit and binaryOutput, leaving a gap for these parameters. Still, the key parameters are well covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific action and object: 'Read new output from a started process log, incrementally by byte offset.' This clearly distinguishes it from file-reading tools (read_file) and process-status tools (get_process_status) by focusing on process logs and incremental offset-based reading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use after starting a process, with follow/stream modes. It explains how to use follow and stream and which stream to select. While it doesn't explicitly name alternatives or exclusions, the context is unambiguous and implies use for process output rather than file content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behavioral details: handling of ~, ., and ..., and the role of cwd and distro home. It implies a pure computation with no side effects, which is sufficient for a path resolution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the purpose and key nuances without any redundant words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple utility tool, the description is quite complete: it states the input (path, cwd, distro), the behavior, and the output (absolute POSIX path). It lacks explicit error behavior, but that is a minor gap for a pure resolution function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds extra meaning by explaining that ~ resolves to the distro home, and that relative paths use the working directory, enhancing the schema parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Resolve') and resource ('WSL POSIX path'), and specifies the exact behavior: converting possibly-relative paths to absolute, handling ~, ., and ... This distinguishes it from siblings like translate_path and read_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the description (i.e., when you need to resolve a path), but it does not explicitly mention alternatives or when not to use the tool. No exclusions or comparisons to sibling tools like translate_path are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses important behaviors: it waits for completion, returns stdout/stderr and exit code, merges stderr unless separateStderr is true, and explains the guardrail blocking dangerous commands with confirm override. It does not discuss side effects or permission requirements, but for a command runner the key behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences: the first states the core action and mode, the second enumerates capabilities, the third describes output and guardrail behavior. No redundant or filler language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the essential return values, synchronous execution, stderr handling, and safety guardrail. It is slightly incomplete regarding the unannotated 'distro' parameter and default behavior for timeout/cwd, but overall sufficient for a shell-command tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 88%, so the schema already documents most parameters. The description adds semantic context for behavior (stderr merging, guardrail, multi-line) but does not add meaning to the undocumented 'distro' parameter or explain defaults like timeoutMs/cwd, keeping it at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Run a shell command in WSL' with the key qualifier '(foreground, waits for completion)', clearly distinguishing it from background process siblings like start_process. It also previews supported capabilities (multi-line scripts, cwd, env, timeout), leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the synchronous/foreground behavior explicit, implying it should be used when a command's completion and exit code are needed immediately. It does not explicitly name alternatives like start_process for background execution, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It honestly discloses the recursive search behavior, output format, and the implementation fallback (ripgrep vs grep). It does not mention error handling or file types, but these are less critical for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and output format, then adding the implementation detail. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explicitly states the return format (file:line:match). The tool is straightforward, and the description covers its scope (WSL, recursive), output, and implementation, making it complete enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, with descriptions for path, include, pattern, and maxResults. The description itself does not add parameter-level detail beyond what the schema provides, but the schema already covers most semantics, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches file contents in WSL recursively, returning file:line:match entries. This distinguishes it from sibling tools like search_files (which likely searches filenames) and read_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: recursive grep in WSL, with a fallback from ripgrep to grep. It does not explicitly mention when not to use it or name alternatives, but the purpose is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It transparently states the tracking scope (processes started via start_process) and implies a read-only list operation. It does not detail edge cases like whether finished processes are included, but for a simple list tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the action and scope. Every word earns its place; there is no fluff or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, no output schema). The description sufficiently explains the tool's purpose and scope. However, since there is no output schema, it could have briefly mentioned what the returned list contains (e.g., process IDs, names), but the current wording is adequate for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides complete coverage. Baseline for 0 params is 4. The description adds no parameter-related meaning, but none is needed—the tool requires no arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'all processes started via start_process that this server is tracking.' This clearly distinguishes it from sibling tools like get_process_status or stop_process, which target individual processes, and from broader system process listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the scope: it lists only processes started via start_process and tracked by the server. This gives the agent context for when to use it vs. alternatives, though it doesn't explicitly mention alternative tools or exclusions. The intended use is implied strongly enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It clearly states that text files return UTF-8 content, binary files return base64 with a mimeType, and describes partial reads and hashing. It does not mention distro selection or error behavior, but the disclosed behaviors are significant and well stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and wastes no words. It front-loads the core action, then packs return-type behavior and advanced parameters into concise, purposeful clauses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately explains return values for both text and binary files. It covers offset/limit and sha256, which addresses the main usage complexities. However, the distro parameter is not explained at all, and there is no mention of error conditions or path resolution nuances, leaving slight gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers path, limit, offset, and sha256 (80% coverage), so the baseline is 3. The description adds value by explaining how binary files are returned (base64 + mimeType) and what sha256=true actually does, beyond the schema's description. The distro parameter remains undocumented, preventing a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Read a file from WSL', specifying both the action and resource, and differentiates this tool from siblings by detailing text vs. binary handling. It clearly distinguishes read_file from read_multiple_files and list_directory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use offset/limit (large files) and sha256 (round-trip verification), implying appropriate use cases. It does not explicitly mention alternatives or exclusions, but the guidance is sufficient for selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![wsl-bridge-mcp MCP server](https://glama.ai/mcp/servers/Darling209/wsl-bridge-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Darling209/wsl-bridge-mcp)

Score Badge

Copy to your README.md:

[![wsl-bridge-mcp MCP server](https://glama.ai/mcp/servers/Darling209/wsl-bridge-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Darling209/wsl-bridge-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Darling209/wsl-bridge-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server