Code Buddy
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation3/5
Most tools have distinct purposes, but there is notable overlap in several areas. For example, 'curl_tool' and 'http_request_tool' both handle HTTP requests, and 'docker_tool', 'docker_compose_tool', and 'docker_build_tool' are all Docker-related with unclear boundaries. However, descriptions help differentiate many tools like 'find_replace' vs. 'find_replace_all'.
Naming Consistency4/5Naming is mostly consistent with a verb_noun pattern (e.g., 'analyze_code', 'copy_file', 'create_directory'), but there are minor deviations such as 'curl_tool' and 'docker_tool' using '_tool' suffix inconsistently. Overall, the pattern is readable and predictable across most tools.
Tool Count2/5With 28 tools, the count feels excessive for a general-purpose coding assistant. Many tools could be consolidated (e.g., Docker-related tools, HTTP request tools) or are redundant (e.g., 'run_command' vs. specific command tools). This bloat may overwhelm agents and reduce usability.
Completeness5/5The tool set provides comprehensive coverage for code development tasks, including file operations (CRUD), code analysis, formatting, linting, Docker management, Git operations, and HTTP requests. There are no obvious gaps; agents can handle a wide range of coding workflows without dead ends.
Average 2.8/5 across 28 of 28 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits 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
This repository is licensed under MIT License.
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.jsonto 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?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It doesn't mention that docker-compose commands typically manage multi-container applications, may require specific file structures, can start/stop services, or have side effects like building images or pulling dependencies. The description lacks critical behavioral context for a tool with potentially significant system impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words. While it's under-specified in terms of content, it contains zero wasted words and is front-loaded with the core action. Every word earns its place, making it maximally efficient in terms of word count.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is inadequate. Docker-compose commands can have significant system impact (starting/stopping containers, building images), but the description provides minimal context about what the tool actually does, when to use it, or what behaviors to expect. It fails to compensate for the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'run docker-compose commands' is a tautology that essentially restates the tool name. It doesn't specify what docker-compose commands do (orchestrate multi-container Docker applications) or what resources they affect. While it mentions the action 'run', it lacks specificity about the target resource or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There's no mention of when to choose docker_compose_tool over the sibling docker_tool or docker_build_tool, nor any context about prerequisites (e.g., requiring docker-compose.yml files) or typical use cases for docker-compose commands.
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 full burden for behavioral disclosure. 'Build Docker image' implies a potentially resource-intensive operation that creates artifacts, but doesn't mention execution context (local vs remote), permissions needed, whether it modifies system state, typical runtime, or error conditions. For a tool that likely executes docker build commands, this lacks important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, which is appropriate for a simple concept. However, it's arguably too minimal given the tool's complexity - a Docker build operation has many behavioral considerations that aren't addressed. The single-phrase structure is front-loaded but lacks necessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a Docker build tool with 3 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens during execution, what the output looks like, error handling, or how it differs from running 'docker build' via run_command. The minimal description fails to provide sufficient context for proper tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (tag, dockerfile, context) with their purposes. The description adds no additional parameter information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Build Docker image' clearly states the action (build) and resource (Docker image), but it's vague about scope and doesn't differentiate from sibling tools like 'docker_tool' or 'docker_compose_tool'. It provides basic purpose but lacks specificity about what distinguishes this particular Docker operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple Docker-related sibling tools (docker_tool, docker_compose_tool) but no indication of when this specific build tool is appropriate versus those other tools or when it should be used instead of general command execution tools.
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 full burden but offers minimal behavioral insight. It implies execution of commands but doesn't disclose critical traits like permissions needed, side effects (e.g., file modifications), error handling, or output format. This is inadequate for a tool that can perform diverse operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, which is efficient. However, it's under-specified rather than appropriately sized—it lacks necessary details for a tool with broad capabilities, slightly reducing its effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of Git operations, lack of annotations, and no output schema, the description is incomplete. It doesn't cover usage scenarios, safety considerations, or expected results, making it insufficient for an agent to reliably invoke this tool across varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the two parameters (command and cwd). The description adds no meaning beyond this, such as examples of valid commands or cwd usage, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run git commands' states the general purpose (execute Git operations) but is vague about scope and resources. It doesn't specify what types of Git commands are supported or distinguish this from sibling tools like git_diff, git_log, and git_status, which handle specific Git operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It doesn't mention when to prefer this general-purpose Git tool over the specific sibling tools (git_diff, git_log, git_status) or other command-execution tools like run_command, leaving the agent without context for selection.
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 carries full burden. 'Show git diff' implies a read-only operation but doesn't disclose behavioral traits like whether it requires git repository initialization, what happens with invalid paths, output format (e.g., patch format), or error handling. It lacks context on permissions, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two words, which is efficient and front-loaded. However, it's arguably too brief, bordering on under-specified rather than optimally concise, as it sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a tool with potential complexity (git operations), the description is incomplete. It doesn't explain what the tool returns (e.g., diff output as text), error conditions, or how it integrates with the git workflow. For a tool with three parameters and behavioral nuances, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters (filepath, staged, cwd). The description adds no additional meaning beyond what's in the schema, such as explaining interactions between parameters (e.g., how staged interacts with filepath) or default behaviors. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show git diff' states the basic purpose (display git differences) but is vague about scope and lacks differentiation from sibling tools like git_log and git_status. It doesn't specify what kind of diff (e.g., working directory vs. staged vs. commit comparisons) or what resources are involved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like git_status (which shows status changes) or git_log (which shows commit history). The description doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone.
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 carries the full burden of behavioral disclosure. It mentions 'provide statistics' but doesn't specify what kind (e.g., lines of code, complexity metrics), whether it's read-only or has side effects, or any performance or permission considerations. This leaves critical behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just one sentence with no wasted words. It's front-loaded with the core purpose, making it easy to scan and understand quickly, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of code analysis and lack of annotations or output schema, the description is incomplete. It doesn't explain what statistics are returned, how analysis is performed, or any limitations (e.g., supported languages). This leaves the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'filepath' clearly documented. The description adds no additional meaning beyond the schema, as it doesn't elaborate on file format expectations or analysis scope. With high schema coverage, 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.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Analyze code file and provide statistics' states a clear verb ('analyze') and resource ('code file'), but it's vague about what 'analyze' entails and what 'statistics' means. It doesn't distinguish from siblings like 'lint_code' or 'format_code', which might also analyze code in different ways.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'lint_code' (likely for code quality checks) and 'get_functions' (likely for extracting function info), there's no indication of what makes 'analyze_code' different or when it's the appropriate choice.
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 full burden for behavioral disclosure but only states the action without details on permissions, side effects, output format, or error handling. 'Run docker commands' implies execution but doesn't clarify if this runs locally, requires Docker installation, or has security implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words with zero wasted text. It's front-loaded with the core action, though this brevity contributes to its lack of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that executes arbitrary docker commands with no annotations and no output schema, the description is insufficient. It doesn't address complexity, safety, or what the tool returns, leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'command' documented as 'Docker command to execute'. The description adds no additional meaning beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run docker commands' states the action (run) and target (docker commands), but is vague about scope and doesn't distinguish from siblings like docker_build_tool or docker_compose_tool. It doesn't specify what types of docker commands are supported or their context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like docker_build_tool, docker_compose_tool, or the generic run_command tool. The description offers no context about appropriate use cases or exclusions.
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 carries the full burden of behavioral disclosure. It states the action ('Make HTTP requests') but doesn't cover critical aspects like authentication needs, rate limits, error handling, or what the response looks like (e.g., status codes, body format). This is inadequate for a tool that performs network operations with potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste: 'Make HTTP requests to specified URLs'. It's front-loaded and appropriately sized for the tool's purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of HTTP requests (with 5 parameters, no output schema, and no annotations), the description is incomplete. It doesn't explain return values, error cases, or behavioral traits like idempotency or side effects. For a general-purpose tool with potential security and operational implications, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all 5 parameters (url, method, headers, body, timeout). The description adds no additional meaning beyond what the schema provides, such as examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Make HTTP requests to specified URLs' clearly states the verb ('Make HTTP requests') and resource ('specified URLs'), but it's generic and doesn't differentiate from sibling tools like 'curl_tool' that likely serve similar purposes. It's not tautological but lacks specificity about what makes this tool unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'curl_tool' or other HTTP-related tools. It doesn't mention prerequisites, exclusions, or specific contexts where this tool is preferred, leaving the agent to infer usage based on the name alone.
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 carries the full burden of behavioral disclosure. It states the action ('Copies') but doesn't mention whether it overwrites existing files, handles errors (e.g., if source doesn't exist), requires specific permissions, or returns any output. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a file operation (mutation with potential side effects), no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like overwriting, error handling, or return values, which are crucial for safe tool invocation in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('source_path' and 'destination_path') clearly documented in the schema. The description adds no additional meaning beyond what the schema provides, such as path format examples or constraints, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Copies') and resource ('a file'), specifying the operation as moving a file from one path to another. However, it doesn't distinguish this from the sibling 'move_file' tool, which performs a similar path-based file operation, so it doesn't fully differentiate from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'move_file' or 'write_file'. It lacks context about prerequisites (e.g., file existence, permissions) or exclusions, leaving the agent to infer usage from the tool name alone.
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 full burden for behavioral disclosure. While it implies a write operation ('Creates'), it doesn't mention permissions required, whether it creates parent directories recursively, what happens if the directory already exists, or what the return value looks like. This leaves significant gaps 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple tool with one parameter and no complex behavior to explain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain error conditions, return values, or important behavioral details like whether parent directories are created automatically. Given the complexity of file system operations, more context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter 'dirpath' with its description. The description adds marginal value by clarifying that paths can be 'absolute or relative to project' (whereas the schema says 'relative to the project root'), but this is a minor enhancement beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Creates') and resource ('directory at the specified path'), making the purpose immediately understandable. It distinguishes from siblings like 'delete_directory' by specifying creation rather than deletion, though it doesn't explicitly differentiate from all other file/directory operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_directory' or 'get_directory_tree', nor does it mention prerequisites (e.g., parent directory must exist) or error conditions. It simply states what the tool does without contextual usage information.
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 states the tool executes curl commands but doesn't mention safety considerations (e.g., potential for destructive operations, authentication needs, rate limits, or output format). For a tool that executes arbitrary curl commands, this is a significant gap in 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single, clear sentence with no wasted words. It's front-loaded with the core purpose, making it easy for an agent to parse quickly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing arbitrary curl commands (which can include mutations, authentication, etc.), the lack of annotations and output schema means the description should do more. It doesn't address behavioral traits, error handling, or output expectations, leaving the agent with insufficient context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter-specific information beyond what's in the schema. However, with 100% schema description coverage (the 'curl_command' parameter is fully documented in the schema), the baseline is 3. The description doesn't compensate but doesn't need to since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Make HTTP requests using curl command'. It specifies the action (make HTTP requests) and the mechanism (curl command). However, it doesn't differentiate from the sibling 'http_request_tool', which appears to serve a similar purpose, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling 'http_request_tool' or explain any differences in functionality, prerequisites, or appropriate contexts. This leaves the agent without clear 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the destructive action ('Deletes') but lacks critical details: whether deletion is permanent or reversible, what happens to contents (files/subdirectories), permission requirements, error conditions (e.g., non-existent paths), or safety warnings. This is inadequate for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'delete' entails (recursive? permanent?), what the tool returns (success confirmation? error details?), or critical behavioral aspects. The context demands more completeness for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'dirpath' fully documented in the schema. The description adds no additional parameter semantics beyond what's already in the schema, so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deletes') and resource ('a directory at the specified path within the project'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'delete_file', but the distinction is implied through the resource type (directory vs. file).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives like 'delete_file' or 'create_directory'. The description only states what the tool does, without context about prerequisites, consequences, or appropriate scenarios for its use.
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. While 'Deletes' correctly implies a destructive mutation, it fails to address critical aspects like whether deletion is permanent or reversible, what happens if the file doesn't exist, permission requirements, or any rate limits. This leaves significant behavioral gaps for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that efficiently conveys the core functionality without any wasted words. It's appropriately sized for a simple tool with one parameter and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive file operation with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens on success versus failure, whether there's confirmation or error handling, or what (if anything) the tool returns. Given the complexity of file deletion and lack of structured safety information, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'filepath' clearly documented in the schema as 'Path to the file to delete'. The description adds no additional parameter semantics beyond what's already in the structured schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deletes') and resource ('a file at the specified path'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'delete_directory' or 'move_file' which also involve file system modifications, missing an opportunity for clearer sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'move_file' for relocation or 'delete_directory' for folder removal. It also lacks information about prerequisites such as file existence checks or permission requirements, leaving the agent without contextual usage cues.
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 states the tool edits a file by replacing content, implying a mutation operation, but doesn't address critical aspects like permissions required, whether changes are reversible, error handling (e.g., if old_content isn't found), or side effects. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and avoids unnecessary elaboration, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavior, error conditions, return values, and differentiation from siblings. Given the complexity of file editing and the rich sibling toolset, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters clearly documented in the schema itself. The description adds no additional meaning beyond what's in the schema—it doesn't explain parameter interactions, format expectations, or edge cases. The baseline score of 3 reflects that the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Edit a file') and the method ('by replacing specific content'), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'find_replace' or 'write_file', which appear to have overlapping functionality for file content modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'find_replace', 'find_replace_all', or 'write_file'. There's no mention of prerequisites, constraints, or typical use cases, leaving the agent to infer usage from the tool name alone.
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 full burden for behavioral disclosure. While it implies a mutation operation ('replace'), it doesn't address critical aspects like whether changes are saved automatically, if there's undo capability, permission requirements, or error handling for non-existent files. This leaves significant gaps for a tool that modifies files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without any wasted words. It's appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens on success/failure, whether the operation is atomic, or what side effects might occur. Given the complexity of modifying files and the lack of structured safety information, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any additional meaning about parameters beyond what's in the schema, meeting the baseline expectation but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('find and replace') and resource ('text in a single file'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'find_replace_all' or 'edit_file', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'find_replace_all' (which likely handles multiple files) or 'edit_file' (which might offer more general editing capabilities). The description lacks any context about appropriate use cases or exclusions.
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 full burden for behavioral disclosure. It mentions the tool performs find-and-replace operations but doesn't specify whether this is destructive (overwrites files), requires backups, has confirmation prompts, or handles errors. For a mutation tool affecting multiple files, this is a significant gap in safety and operational 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's appropriately sized and front-loaded with the core functionality, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool (find-and-replace) with no annotations and no output schema, the description is incomplete. It doesn't address critical aspects like what happens on execution (e.g., file modifications, success/failure responses), making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (find, replace, file_pattern) adequately. The description adds no additional parameter semantics beyond what's in the schema, such as regex support, case sensitivity, or default file patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('find and replace text') and scope ('across multiple files'), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from the sibling 'find_replace' tool, which might be a single-file version or have different parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'find_replace' (a sibling tool) or 'edit_file'. There's no mention of prerequisites, limitations, or typical use cases beyond the basic functionality.
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 full burden for behavioral disclosure. It states the tool uses 'black' for formatting, implying a mutation operation, but doesn't specify whether it overwrites the file in-place, creates backups, requires specific permissions, or has side effects. This leaves critical behavioral traits undocumented for a tool that modifies files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with zero wasted words. It's front-loaded with the core purpose and uses specific terminology ('black'). Every word earns its place by conveying essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'formatting' entails, what 'black' does, whether the operation is idempotent, error conditions, or what happens on success/failure. Given the complexity of file modification and lack of structured data, more context is needed for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'filepath' fully documented in the schema. The description adds no additional parameter semantics beyond what's in the schema (e.g., file format expectations, path validity rules). This meets the baseline of 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Format a Python file using black' specifies both the action (format) and the resource (Python file). It distinguishes from siblings like 'lint_code' or 'edit_file' by focusing specifically on formatting with a particular tool (black). However, it doesn't explicitly mention what 'black' is or how it differs from general code formatting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when formatting is appropriate, prerequisites (e.g., file must exist), or comparisons to siblings like 'lint_code' (which might handle style issues differently). The agent must infer usage from the tool name alone.
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 carries the full burden of behavioral disclosure. It states the tool 'Gets the directory tree structure' but doesn't describe what the output looks like (e.g., format, depth limitations, error handling), whether it's read-only, or any performance considerations. This leaves significant gaps for a tool that likely returns structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words and gets straight to the point, though it could be slightly more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain the return format (e.g., tree structure details), potential errors, or how it differs from similar tools like 'list_directory'. For a tool that likely returns complex hierarchical data, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('dirpath' and 'max_depth'). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline score of 3 for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Gets') and resource ('directory tree structure'), and specifies the scope ('starting from the specified path within the project'). However, it doesn't explicitly differentiate from sibling tools like 'list_directory' or 'search_in_files', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_directory' or 'search_in_files'. It mentions the starting path but doesn't clarify use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
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 carries the full burden of behavioral disclosure. It states what the tool does ('extract function and class definitions') but lacks critical behavioral details: it doesn't specify the output format (e.g., structured data, plain text), error handling (e.g., what happens with invalid Python syntax), or performance characteristics (e.g., speed, memory usage). For a tool with no annotation coverage, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It is appropriately sized for a simple tool and front-loaded with the core functionality, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (parsing Python files), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list of definitions, JSON structure), how it handles edge cases (e.g., nested classes, decorators), or any limitations (e.g., file size constraints). For a parsing tool with no structured output documentation, this leaves too much ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'filepath' clearly documented in the schema. The description adds no additional semantic information about parameters beyond what's in the schema (e.g., no details on path formats, relative vs. absolute paths, or file encoding). With high schema coverage, 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('extract') and resource ('function and class definitions from a Python file'). It distinguishes itself from siblings like 'read_file' (which reads raw content) or 'analyze_code' (which might perform broader analysis). However, it doesn't explicitly differentiate from potential similar tools like 'search_in_files' for finding definitions, keeping it at a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer 'get_functions' over 'read_file' followed by manual parsing, or over 'analyze_code' for more comprehensive analysis. There's also no mention of prerequisites (e.g., file must exist, be valid Python) or exclusions (e.g., not for non-Python files).
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. 'Show git commit history' implies a read-only operation, but it doesn't specify whether this requires git repository access, what happens if no commits exist, or how errors are handled. For a tool with zero annotation coverage, this leaves significant behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise at just three words ('Show git commit history'). Every word earns its place by establishing the core functionality without any fluff or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficiently complete. While the purpose is clear, it doesn't address what the output looks like (commit format, data structure), error conditions, or behavioral constraints. For a tool with no structured safety or output information, more descriptive context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, which is acceptable given the comprehensive schema coverage. The baseline of 3 reflects adequate but minimal value added by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show git commit history' clearly states the verb ('show') and resource ('git commit history'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'git_diff' or 'git_status', but the focus on commit history is specific enough to avoid confusion with those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While the purpose is clear, there's no mention of when to choose 'git_log' over other git-related tools like 'git_diff' or 'git_status', nor any context about prerequisites or typical use cases.
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 full burden but only states what the tool does without any behavioral context. It doesn't disclose whether this is a read-only operation, what permissions are needed, what format the output takes, or any error conditions. 'Get' implies a read operation, but this isn't explicitly confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple tool. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'git status' means operationally, what information is returned, or how to interpret results. Given the lack of structured fields, the description should provide more context about the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single optional parameter. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('git status of the project'), making the purpose immediately understandable. It distinguishes from siblings like git_diff or git_log by focusing specifically on status. However, it doesn't explicitly contrast with other git operations beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like git_diff or git_log. It doesn't mention prerequisites, typical use cases, or when other tools might be more appropriate. The agent must infer usage from the tool name alone.
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 carries full burden. It mentions the linters used but doesn't disclose behavioral traits like whether it modifies files, requires specific environments, outputs results, or has rate limits. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and includes relevant details (Python file, ruff/flake8). Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that likely produces linting results. It doesn't explain what the tool returns, how errors are handled, or dependencies required. For a code analysis tool with rich expected output, this minimal description is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter 'filepath'. The description adds no additional meaning beyond what the schema provides, such as file format expectations or path examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('lint') and target ('a Python file'), specifying the tools used ('ruff or flake8'). It distinguishes from siblings like 'format_code' or 'analyze_code' by focusing on linting, but doesn't explicitly contrast with them. The purpose is specific but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'format_code' or 'analyze_code'. The description implies usage for Python files but doesn't specify prerequisites, constraints, or when-not-to-use scenarios. It's a basic statement of function without contextual 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Lists') but lacks details on permissions, rate limits, output format, pagination, or error handling. This is inadequate for a tool with potential complexity in file system operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain what the output looks like (e.g., list format, error messages) or address behavioral aspects like permissions or limitations, which are crucial for file system tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents both parameters ('dirpath' and 'recursive'). The description does not add any additional meaning beyond what the schema provides, such as examples or edge cases, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Lists') and resource ('files and directories'), and specifies the scope ('at the specified path within the project'). However, it does not explicitly differentiate from sibling tools like 'get_directory_tree' or 'search_in_files', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'get_directory_tree' (which might provide a tree structure) or 'search_in_files' (which might filter results), leaving the agent without context for tool selection.
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 states the action ('moves') but doesn't clarify if this is destructive (e.g., overwrites existing files at destination), requires specific permissions, handles errors, or provides any output details. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's action without unnecessary words. It's appropriately sized and front-loaded for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a mutation operation, lack of annotations, and no output schema, the description is incomplete. It fails to address critical aspects like behavioral traits, error handling, or output expectations, leaving significant gaps for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters clearly documented in the input schema. The description adds no additional meaning beyond implying path-based movement, which is already covered by the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('moves') and resource ('a file') with the scope of path relocation ('from one path to another'). It distinguishes from copy_file by implying movement rather than duplication, though not explicitly. However, it doesn't fully differentiate from other file operations like delete_file or write_file in terms of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like copy_file or delete_file, nor does it mention prerequisites such as file existence or permissions. It lacks context for choosing between move_file and similar operations in the sibling list.
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 carries the full burden. It states the tool reads text files, implying it's read-only, but doesn't disclose critical behavioral traits such as error handling (e.g., what happens if the file doesn't exist or isn't a text file), permissions required, or output format (e.g., raw text, encoding). This leaves significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any fluff. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a file-reading tool. It doesn't explain what the tool returns (e.g., file content as a string, error messages), how it handles edge cases, or any dependencies. This leaves the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, fully documenting the 'filepath' parameter. The description adds no additional semantic context beyond what's in the schema (e.g., examples of valid paths or constraints). With high schema coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reads') and resource ('content of a text file at the specified path'), making the tool's purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'get_directory_tree' or 'search_in_files', but the specificity of reading file content is sufficient for 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'search_in_files' or 'get_directory_tree' that might overlap in file access, there's no indication of when 'read_file' is preferred or what its limitations are (e.g., only for text files).
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 full burden but only states the basic action without disclosing critical behavioral traits. It doesn't mention security risks (e.g., arbitrary command execution), error handling, output format, or side effects like file changes, leaving significant gaps for a tool that runs shell commands.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by directly conveying the tool's function, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of running shell commands (with security and behavioral implications), no annotations, and no output schema, the description is incomplete. It fails to address risks, output expectations, or error scenarios, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the three parameters (command, cwd, timeout). The description adds no additional meaning beyond implying execution in a project directory, which is partially covered by the cwd parameter's default. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run') and target ('a shell command in the project directory'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'run_python' or 'curl_tool' that also execute commands, missing explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'run_python' for Python scripts or 'curl_tool' for HTTP requests. It lacks context about prerequisites, such as needing shell access or project setup, offering minimal 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?
With no annotations provided, the description carries full burden but offers minimal behavioral information. It doesn't disclose execution environment (sandboxed?), security implications, output handling (stdout/stderr capture), error behavior, or what happens with the timeout parameter. 'Run' implies execution but lacks critical operational 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at 5 words with zero wasted text. The description is front-loaded with the core functionality. Every word earns its place, though this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a code execution tool with 3 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain execution results, error handling, environment context, or safety considerations. The agent lacks sufficient information to use this tool effectively beyond basic parameter passing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional parameter semantics beyond what's in the schema properties. It mentions 'script or code' which aligns with the code/filepath parameters but provides no extra context about their relationship or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run a Python script or code' clearly states the action (run/execute) and the target (Python script/code). It distinguishes this from non-Python execution tools like 'run_command' or code analysis tools like 'analyze_code', but doesn't explicitly differentiate from all siblings. The purpose is specific but could be more precise about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description doesn't mention when to prefer 'code' vs 'filepath', when to use this instead of 'run_command' for Python execution, or any prerequisites like Python installation. Usage context is implied but not stated.
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 carries the full burden of behavioral disclosure. It states the tool searches across files but doesn't mention performance aspects (e.g., speed, large file handling), output format (e.g., list of matches with line numbers), error handling (e.g., invalid patterns), or side effects (e.g., read-only). This is inadequate for a search tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Search for text or pattern across project files.' It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a straightforward tool. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search across files with 4 parameters) and lack of annotations or output schema, the description is incomplete. It doesn't cover behavioral traits (e.g., search scope, result format), usage context, or how parameters interact. For a search tool with no structured output documentation, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (pattern, file_pattern, case_sensitive, max_results). The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain pattern syntax (regex vs. plain text), file_pattern globbing details, or default behaviors. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for text or pattern across project files.' It specifies the verb ('search') and resource ('project files'), but doesn't differentiate from sibling tools like 'find_replace' or 'get_functions' which might also involve searching or analyzing files. The purpose is clear but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer this over 'find_replace' (for replacement), 'get_functions' (for code analysis), or 'read_file' (for viewing content). There's no context about prerequisites, file types, or project scope, leaving usage decisions ambiguous.
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 states the write action but doesn't mention critical behaviors like whether it overwrites existing files, creates new files, requires specific permissions, handles errors, or has side effects. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file-writing tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens on success/failure, return values, or behavioral nuances (e.g., overwriting vs. appending). Given the mutation nature and lack of structured data, more context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters ('filepath' and 'content'). The description adds no additional semantic context beyond what the schema provides, such as file format details or path resolution rules, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('writes content') and target ('to a text file at the specified path'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'edit_file' or 'create_directory', which would require more specific context about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'edit_file', 'create_directory', or 'copy_file'. It lacks context about prerequisites (e.g., file existence, permissions) or typical scenarios, leaving the agent to infer usage from the tool name alone.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/Abhi-vish/code-buddy'
If you have feedback or need assistance with the MCP directory API, please join our Discord server