MCP Custom Tools Server

by SergiFuster

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there are a few potential overlaps: 'build_url' and 'parse_url' both handle URL components, 'encode_decode' and 'url_encode_decode' both handle encoding/decoding, and 'generate_hash' and 'calculate_file_hash' both handle hashing. However, the descriptions clarify their specific contexts (text vs. file vs. URL), so misselection is unlikely.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., 'analyze_text', 'calculate_age', 'get_system_info'). There are no deviations in naming conventions, making the set predictable and readable.
Tool Count3/5
With 31 tools, the count is borderline high for a general-purpose utility server. While many tools are useful, the set feels heavy and could be streamlined (e.g., merging related tools like 'encode_decode' and 'url_encode_decode'). It's not extreme, but it approaches the upper limit of reasonable scope.
Completeness4/5
The server covers a broad range of utility functions (text analysis, system info, file operations, URL handling, etc.) with good coverage in each area. Minor gaps exist, such as no direct tool for writing files or more advanced text processing, but agents can work around these with the available tools.
Average 2.9/5 across 31 of 31 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.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'estadísticas y patrones' (statistics and patterns), which hints at output behavior, but doesn't specify what statistics (e.g., word count, frequency) or patterns (e.g., regex matches, sentiment) are included. It also omits details like performance characteristics, error handling, or any limitations, leaving significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Spanish: 'Análisis completo de texto con estadísticas y patrones'. It's front-loaded with the core purpose and avoids unnecessary words. However, it could be more structured by explicitly separating the analysis types or adding brief examples, but it's efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of text analysis, no annotations, and no output schema, the description is incomplete. It vaguely mentions statistics and patterns but doesn't detail what these entail, making it insufficient for an AI agent to understand the full context or expected results. For a tool with potential rich output, more explanation is needed to compensate for the lack of structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'text' documented as 'Texto a analizar'. The description doesn't add any meaning beyond this, such as constraints on text length, encoding, or language. Since the schema already fully describes the parameter, the baseline score of 3 is appropriate, as no additional value is provided by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Análisis completo de texto con estadísticas y patrones' states the tool performs text analysis with statistics and patterns, which is a clear purpose. However, it's somewhat vague about the specific type of analysis (e.g., sentiment, grammar, keyword extraction) and doesn't distinguish it from sibling tools like 'count_words' or 'split_text' that also process text. The purpose is understandable but lacks specificity for 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, such as when to choose 'analyze_text' over 'count_words' for word counting or 'extract_emails' for email extraction. Without such guidance, users must infer usage based on the vague purpose 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 doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires permissions, rate limits, or what the output looks like (e.g., text, JSON). The description only states the action without 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish, front-loaded with the core action. It's appropriately sized for a simple tool, with no wasted words, though it could be slightly more specific to improve clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain the return values (e.g., calendar format, error handling) or behavioral aspects. For a tool with 2 parameters and no structured output info, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the parameters (year and month with defaults and constraints). The description adds no additional meaning beyond the schema, such as explaining cultural or format considerations. Baseline is 3 since 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mostrar calendario de un mes específico' (Show calendar for a specific month) states the basic purpose with a verb and resource, but it's vague about what type of calendar (e.g., Gregorian, lunar) and format (e.g., grid, list). It doesn't distinguish from siblings like 'get_current_time' or 'days_between_dates', which could involve date-related 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, exclusions, or compare to sibling tools (e.g., 'get_current_time' for current date info). Usage is implied only by the name and description, with no explicit context.
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 for behavioral disclosure. 'Realizar petición HTTP' implies network interaction but doesn't mention important behavioral aspects: whether it follows redirects, handles authentication, manages cookies, supports different content types beyond JSON/string, or what happens on errors/timeouts. For a network tool with zero annotation coverage, this leaves critical behavior undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Spanish phrase that directly states the tool's function. There's no wasted verbiage or unnecessary elaboration. However, this brevity comes at the cost of completeness, making it more under-specified than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex HTTP request tool with 5 parameters, no annotations, and no output schema, the description is severely incomplete. It doesn't explain what the tool returns (status codes, response body, headers, errors), doesn't mention authentication requirements, rate limits, or network behavior. The agent would need to guess critical aspects of how this tool behaves and what results to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly with descriptions, defaults, enums, and constraints. The description adds no additional parameter semantics beyond what's in the schema. According to guidelines, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Realizar petición HTTP a una URL' clearly states the action (make HTTP request) and target (a URL), which is better than a tautology. However, it's quite generic and doesn't distinguish this from what might be expected from any HTTP client tool. It lacks specificity about what makes this particular implementation unique or how it differs from sibling tools that also handle URLs (like parse_url, validate_url, build_url, or url_encode_decode).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like build_url, parse_url, validate_url, and url_encode_decode that also handle URL-related operations, there's no indication that this is the primary tool for making actual HTTP requests while others are for URL manipulation. No context about prerequisites, limitations, or typical use cases is mentioned.
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. The description only states the action ('Dividir texto') without explaining what happens during splitting (e.g., whether it preserves whitespace, handles encoding, or returns an array). It lacks details on error handling, performance, or output format, which are critical for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish ('Dividir texto por diferentes criterios'), which is appropriately concise. It front-loads the core action without unnecessary elaboration. However, it could be slightly more structured by explicitly listing criteria, but it avoids waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the return values (e.g., array of strings), how splitting criteria interact, or edge cases (e.g., empty text). For a text manipulation tool with moderate complexity, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (text, delimiter, max_length) with descriptions. The description adds no additional meaning beyond the schema, such as explaining interactions between parameters (e.g., delimiter ignored if max_length is used) or providing examples. Baseline 3 is appropriate since 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Dividir texto por diferentes criterios' (Split text by different criteria) states the basic purpose but is vague about what specific criteria are available. It mentions 'different criteria' but doesn't specify whether these are delimiters, length-based splitting, or other methods. It distinguishes from siblings like 'count_words' or 'extract_emails' by focusing on splitting rather than counting/extracting, but lacks specificity about the splitting mechanisms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios where splitting text is preferable to other text manipulation tools like 'find_replace' or 'extract_urls', nor does it specify prerequisites or constraints. The agent must infer usage from the tool name and parameters 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 but doesn't cover critical behaviors: whether it reads file contents (likely yes), error handling for missing files, performance implications for large files, or output format. For a tool that interacts with files, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish ('Calcular hash de un archivo') that directly states the tool's purpose. It's front-loaded with no wasted words, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., hash string format), error conditions, or behavioral details. For a tool with 2 parameters and file system interaction, more context is needed to ensure safe and correct usage by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters: 'file_path' as the file path and 'algorithm' with enum values and default. The description doesn't add any meaning beyond the schema (e.g., it doesn't explain hash algorithm differences or file path requirements). Baseline 3 is appropriate since 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Calcular hash de un archivo' clearly states the action (calculate hash) and resource (a file), which is a specific verb+resource combination. However, it doesn't distinguish this tool from 'generate_hash' (a sibling tool), leaving ambiguity about when to use one versus the other. The purpose is understandable but lacks 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'generate_hash' or 'read_file'. It doesn't mention prerequisites (e.g., file must exist), context for choosing hash algorithms, or comparisons with sibling tools. Usage is implied only by the tool name and description, with no explicit when/when-not instructions.
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 but doesn't explain how it behaves—for example, whether it returns absolute values, handles date order, includes/excludes endpoints, or deals with errors. This leaves critical behavioral traits unspecified for a tool performing calculations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase in Spanish ('Calcular días entre dos fechas') that directly conveys the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for a simple calculation tool, with no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no annotations), the description is incomplete. It lacks details on output format (e.g., integer days), error handling, or behavioral nuances like date ordering. While concise, it doesn't provide enough context for reliable agent use without assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters ('start_date' and 'end_date') clearly documented in the input schema regarding format (YYYY-MM-DD). The description doesn't add any additional semantic information beyond what the schema provides, such as explaining parameter interactions 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Calcular días entre dos fechas' clearly states the purpose (calculate days between two dates) in Spanish, which matches the tool name. However, it doesn't differentiate from sibling tools like 'calculate_age' or 'format_timestamp' that also work with dates, and it lacks specificity about the calculation method (e.g., inclusive/exclusive, time zones).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There's no mention of sibling tools like 'calculate_age' or 'format_timestamp' that might handle related date operations, nor any context about prerequisites or limitations (e.g., date formats, handling of invalid inputs).
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 what the tool does but doesn't describe how it behaves: no information on output format (e.g., years, months, days), timezone handling, edge cases (e.g., future dates), or computational characteristics. This is a significant gap for a 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple calculation tool 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, 100% schema coverage) but lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., integer age, formatted string) or behavioral aspects, which are important for an agent to use it correctly. The description should do more to compensate for missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'birth_date' fully documented in the schema (including format: YYYY-MM-DD). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 where 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Calcular edad basada en fecha de nacimiento' clearly states the tool's purpose (calculate age based on birth date) with a specific verb and resource. It distinguishes from siblings like 'days_between_dates' by focusing on age calculation rather than date difference, though it doesn't explicitly name 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'days_between_dates' or 'get_current_time'. It doesn't mention prerequisites, constraints, or typical use cases, leaving the agent to infer usage from the purpose 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 encoding/decoding text in different formats but lacks behavioral details such as error handling, performance characteristics, or what happens with invalid inputs. This is a significant gap for a 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish ('Codificar/decodificar texto en diferentes formatos') that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain return values, error conditions, or provide enough context for safe and effective use, especially with a similar sibling 'url_encode_decode' present. More detail is needed for adequate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (text, operation, format) with descriptions and enums. The description adds no additional meaning beyond what the schema provides, such as examples or edge cases, but the high coverage justifies a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Codificar/decodificar texto en diferentes formatos' clearly states the tool's purpose with specific verbs (encode/decode) and resource (text). It distinguishes from most siblings like 'analyze_text' or 'count_words', though 'url_encode_decode' appears to be a similar sibling with overlapping functionality, which slightly reduces 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling 'url_encode_decode', which seems related, or clarify scenarios like choosing between 'encode_decode' and 'url_encode_decode' or other encoding tools. Usage is implied but not explicitly 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 extracts detailed domain information but doesn't specify what 'detailed' includes (e.g., domain name, TLD, subdomain, registration details), whether it handles invalid URLs gracefully, or what the output format looks like. For a tool with no annotations and no output schema, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action ('Extraer información detallada') and resource ('del dominio de una URL'), making it easy to parse. Every part of the sentence contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'detailed domain information' entails, how errors are handled, or what the return values look like. For a tool that likely returns structured data about domains, more context is needed to guide the agent effectively, especially without structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'url' parameter clearly documented. The description adds no additional parameter semantics beyond what the schema provides, such as URL format requirements or examples. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately describes the single required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'extraer' (extract) and the resource 'información detallada del dominio' (detailed domain information) from a URL. It distinguishes itself from sibling tools like 'parse_url' and 'validate_url' by focusing specifically on domain extraction rather than general URL parsing or validation. However, it doesn't explicitly differentiate from 'extract_urls' which might extract URLs from text rather than domain details from a single URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'parse_url' or 'validate_url'. It doesn't mention prerequisites, exclusions, or specific contexts where domain extraction is preferred over other URL-related operations. The agent must infer usage based on the tool name and description 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 emails from text) but doesn't describe how it behaves: e.g., whether it returns all emails or just the first, handles malformed text, requires specific text formats, or has performance considerations. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish: 'Extraer direcciones de email de un texto.' It is front-loaded with the core action and resource, with no wasted words or redundant information. This makes it easy for an agent to parse quickly and understand the tool's basic function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is minimal but adequate for basic understanding. However, it lacks completeness for effective use: no output details (e.g., format of extracted emails), error handling, or behavioral context. Without annotations or an output schema, the description should provide more operational guidance to compensate, which it doesn't do.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description implies the 'text' parameter is the input from which emails are extracted, aligning with the schema's 100% coverage. However, it adds no additional semantic context beyond what the schema provides (e.g., text length limits, encoding requirements, or examples of valid inputs). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate with extra parameter insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Extraer direcciones de email de un texto' (Extract email addresses from a text). It specifies the verb 'extraer' (extract) and the resource 'direcciones de email' (email addresses) from the input 'texto' (text). However, it doesn't distinguish this tool from potential sibling tools like 'extract_urls' or 'extract_domain', which perform similar extraction operations on different data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'extract_urls' for URLs or 'extract_domain' for domains, nor does it specify use cases, prerequisites, or exclusions. The agent must infer usage based solely on the tool name and description without explicit context.
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 ('extraer URLs') but doesn't explain how URLs are extracted (e.g., regex patterns, handling of malformed URLs), what happens with duplicates, or error handling. For a tool with no annotation coverage, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that directly states the tool's function without any unnecessary words. It's front-loaded and appropriately sized for its purpose, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of URL extraction (which can involve edge cases like multiple URLs, invalid formats, or no URLs found), the description is insufficient. With no annotations and no output schema, it doesn't explain the return format (e.g., list of URLs, error messages) or behavioral details. This leaves gaps in understanding how the tool operates in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'text' parameter clearly documented as 'Texto del que extraer URLs'. The description adds no additional meaning beyond this, such as examples or constraints on text length. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Extraer URLs de un texto' clearly states the tool's purpose: extracting URLs from text. It uses a specific verb ('extraer') and resource ('URLs'), making the function unambiguous. However, it doesn't distinguish itself from sibling tools like 'extract_domain' or 'parse_url', which might have overlapping functionality, so it doesn't reach the highest 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'extract_domain' for domain extraction or 'parse_url' for URL parsing, nor does it specify contexts where this tool is preferred. Without such guidance, users might struggle to choose between similar 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 the full burden of behavioral disclosure. It mentions regex support, which adds some context, but fails to describe important traits like whether the operation is destructive (modifies input text), what the output format is, or any error conditions. The description is minimal and lacks behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that directly states the tool's core functionality. It's front-loaded with the main purpose and includes a key feature (regex support) without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with 5 parameters that performs text manipulation. It doesn't explain the return value, error handling, or behavioral implications, leaving significant gaps for the agent to understand how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no additional parameter semantics beyond implying regex capability, which is already covered by the 'use_regex' parameter in the schema. This 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Buscar y reemplazar texto con soporte para regex' clearly states the tool's purpose as a find-and-replace operation with regex support. It specifies the verb (buscar y reemplazar) and resource (texto), but doesn't explicitly differentiate from sibling tools like 'search_files' or 'split_text', which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage based solely on the tool name and parameters.
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 conversion behavior but lacks critical details: whether the tool handles timezone conversion, what happens with invalid timestamps, if there are formatting constraints, or what the output format looks like. This is inadequate for a 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/5
Is 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's appropriately sized for this simple conversion tool and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a conversion tool with no annotations and no output schema, the description is insufficient. It doesn't explain what format the 'readable date' output takes, doesn't mention timezone handling, and provides no error behavior context. Given the lack of structured fields, the description should do more to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions timestamp conversion generally but provides no additional context about parameter usage, constraints, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: converting Unix timestamps to human-readable dates. It specifies both the input (Unix timestamp) and output (readable date), though it doesn't explicitly differentiate from sibling tools like 'get_current_time' or 'days_between_dates' which also handle dates/times.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools like 'get_current_time' (which might provide current time formatting) or 'days_between_dates' (which handles date calculations), leaving the agent to infer appropriate usage contexts.
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 ('generar hash') but lacks details on output format, error handling, performance, or security implications (e.g., hash collisions for weak algorithms like MD5). This is a significant gap for a 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish ('Generar hash de un texto') that directly conveys the 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/5
Given 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. It doesn't explain what the tool returns (e.g., hash string format), potential errors, or usage constraints, which are crucial for an AI agent to invoke it correctly in various contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters ('text' and 'algorithm'), including an enum for algorithms. The description doesn't add extra meaning beyond the schema, such as explaining algorithm trade-offs or text encoding, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Generar hash de un texto' clearly states the verb ('generar') and resource ('hash de un texto'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'calculate_file_hash' or 'encode_decode', which might have overlapping functionality, so it doesn't reach the highest 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't specify if this is for text hashing only (vs. file hashing with 'calculate_file_hash') or when to choose different hash algorithms, 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 what the tool does but doesn't describe important behaviors like whether it returns all variables or a subset, the format of the output, potential permissions needed, or error conditions. This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence in Spanish that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, 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/5
Given 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 what the tool returns (e.g., a list of key-value pairs, JSON format) or any behavioral nuances, which are critical for an agent to use the tool correctly in a system context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'filter' fully documented in the schema. The description doesn't add any additional parameter semantics beyond what the schema provides, so it meets the baseline for adequate but unremarkable coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Obtener' meaning 'Get') and resource ('variables de entorno del sistema' meaning 'system environment variables'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools, but since no other tools appear to handle environment variables, this 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or compare it to other tools in the sibling list, leaving the agent to infer usage based solely on the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves 'información detallada' (detailed information), but doesn't specify what that includes (e.g., file size, permissions, timestamps) or behavioral traits like error handling, performance, or security implications. For a tool with no 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('Obtener información detallada') and resource, making it easy to parse. Every part of the sentence contributes to understanding, with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that presumably returns structured data about files/directories. It doesn't explain what 'información detallada' entails, how errors are handled, or what the return format looks like. For a tool with no structured metadata, this leaves the agent guessing about key behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter-specific information beyond what's in the schema. The input schema has 100% description coverage, with 'file_path' clearly documented as 'Ruta del archivo o directorio' (Path of the file or directory). Since the schema does the heavy lifting, the baseline score of 3 is appropriate—the description neither compensates nor detracts from parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Obtener información detallada de un archivo o directorio' (Get detailed information about a file or directory). It specifies both the verb ('obtener información') and the resource ('archivo o directorio'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_directory' or 'read_file', which prevents 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_directory' (for listing contents) or 'read_file' (for reading file content), nor does it specify prerequisites or exclusions. The agent must infer usage from the purpose alone, which is insufficient for optimal 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?
No annotations are provided, so the description carries full burden. It mentions listing directory contents but doesn't disclose behavioral traits like permissions needed, error handling, output format, or whether it's read-only. This leaves significant gaps for a tool that interacts with the filesystem.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., list of files, metadata), error conditions, or filesystem interaction details, which are crucial for a directory listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('dir_path' and 'show_hidden') with descriptions and defaults. The description adds no additional meaning beyond what the schema provides, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Listar el contenido') and resource ('de un directorio'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'search_files' or 'get_file_info', which prevents 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_files' or 'get_file_info'. The description only states what it does without context 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 the full burden of behavioral disclosure. It states what the tool does ('parsear y analizar') but doesn't describe behavioral traits such as error handling (e.g., for invalid URLs), output format, or performance characteristics. This is a significant gap for a 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish ('Parsear y analizar componentes de una URL') that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (parsing URLs can involve multiple components like protocol, domain, path), no annotations, and no output schema, the description is incomplete. It doesn't explain what components are analyzed, the return format, or error cases, leaving gaps for the agent to understand the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'url' documented as 'URL a parsear'. The description adds no additional meaning beyond this, as it doesn't elaborate on URL formats, constraints, or examples. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Parsear y analizar componentes de una URL' clearly states the tool's purpose: parsing and analyzing URL components. It uses specific verbs ('parsear', 'analizar') and identifies the resource ('URL'), but it doesn't explicitly differentiate from sibling tools like 'extract_urls', 'validate_url', or 'url_encode_decode', which prevents 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'extract_urls' (for extracting URLs from text), 'validate_url' (for validation), or 'url_encode_decode' (for encoding/decoding), leaving the agent to infer usage context without explicit 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 ('Leer') but doesn't mention critical behaviors like whether it requires read permissions, what happens if the file doesn't exist (e.g., throws an error), or if there are size/rate limits. This leaves significant gaps for a tool that interacts with the file system.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of file operations (potential errors, permissions, etc.), no annotations, and no output schema, the description is incomplete. It doesn't cover what the tool returns (e.g., file content as string, error messages), behavioral aspects, or usage context, leaving the agent with insufficient information for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('file_path' and 'encoding') with descriptions and defaults. The description adds no additional meaning beyond what the schema provides, such as examples or constraints, resulting in the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Leer' - Read) and resource ('contenido completo de un archivo' - full content of a file), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'get_file_info' or 'search_files', which prevents 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'read_file' over 'get_file_info' (which might provide metadata) or 'search_files' (which might search within files), nor does it specify prerequisites like file existence or permissions.
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 files by pattern but doesn't describe what the tool returns (e.g., list of file paths, metadata, errors), whether it has side effects, or any limitations (e.g., performance with large directories). This leaves significant gaps for a tool with 3 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns (e.g., a list of matching files, error handling), which is critical for a search operation. Without annotations or output schema, the description should provide more behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing clear details for all parameters (dir_path, pattern, recursive). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Buscar archivos por patrón en un directorio' (Search files by pattern in a directory), which specifies the verb (search), resource (files), and scope (directory). However, it doesn't explicitly differentiate from sibling tools like 'list_directory' or 'get_file_info', which prevents 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_directory' (which might list files without pattern matching) or 'get_file_info' (which might retrieve metadata for specific files), 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions validating 'formato y accesibilidad' (format and accessibility), which implies checking syntax and possibly making HTTP requests, but it doesn't detail what 'accesibilidad' entails (e.g., HTTP status codes, timeouts, or authentication needs). For a tool with no annotations, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish: 'Validar formato y accesibilidad de una URL'. It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (validating URLs with accessibility checks), no annotations, and no output schema, the description is incomplete. It doesn't explain what 'validar formato' means (e.g., regex validation), what 'accesibilidad' involves (e.g., HTTP requests), or what the return values might be (e.g., success/failure, error details). 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter descriptions: 'url' as 'URL a validar' and 'check_accessibility' as 'Verificar si la URL es accesible'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Validar formato y accesibilidad de una URL' (Validate format and accessibility of a URL). It specifies the verb 'validar' and the resource 'URL', making it clear what the tool does. However, it doesn't explicitly distinguish itself from sibling tools like 'parse_url' or 'extract_urls', which prevents 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'parse_url' (which might analyze URL components) or 'extract_urls' (which might find URLs in text), nor does it specify prerequisites or exclusions. This leaves 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool builds URLs but doesn't describe output format, error handling, or constraints (e.g., URL encoding, validation). For a tool with no annotations and potential complexity in URL construction, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish ('Construir URL a partir de componentes') that is front-loaded with the core purpose. It wastes no words and is appropriately sized for a straightforward tool, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 parameters, including nested objects) and no output schema, the description is minimal. It states the purpose but lacks details on output format, error cases, or usage context. With no annotations and incomplete behavioral transparency, it's adequate but has clear gaps, scoring at the minimum viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters well-documented in the schema (e.g., 'scheme' as 'Esquema de la URL', 'host' as 'Hostname o dominio'). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Construir URL a partir de componentes' clearly states the tool's purpose as building URLs from components, using a specific verb ('construir') and resource ('URL'). It distinguishes itself from sibling tools like 'parse_url' (which decomposes URLs) and 'validate_url' (which validates URLs), though it doesn't explicitly mention these distinctions in the description itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'parse_url' (for reverse operation) or 'validate_url' (for validation), nor does it specify contexts or prerequisites for usage. The agent must infer usage from the tool's name and purpose 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 (counting words, lines, characters) but lacks details on behavioral traits such as performance (e.g., handling large texts), output format, or error handling. For a tool with zero annotation coverage, this is a significant gap, though it's not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, with every part contributing to clarity. No waste or redundancy is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single input parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on output (e.g., what format the counts are returned in) and behavioral context. For a simple counting tool, this might suffice, but it leaves gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'text' documented as 'Texto a analizar'. The description adds no additional meaning beyond this, as it doesn't specify parameter constraints or usage nuances. According to the rules, with high schema coverage (>80%), the baseline is 3 even without param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Contar palabras, líneas y caracteres en un texto' (Count words, lines, and characters in a text). It specifies the verb ('contar') and resource ('texto'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'analyze_text' or 'split_text', which might have overlapping text analysis functions, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios where it's preferred over tools like 'analyze_text' or 'split_text', nor does it specify prerequisites or exclusions. The context is implied (text analysis), but explicit usage instructions are missing.
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 the tool fetches current time with customizable formatting, but doesn't cover aspects like whether it's read-only (implied but not stated), potential rate limits, error conditions (e.g., invalid timezone), or what the output looks like (e.g., string format). This is a significant gap for a 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that directly states the tool's purpose without any wasted 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (simple time-fetching with two optional parameters) and 100% schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it lacks details on behavioral traits (e.g., read-only nature, error handling) and return values, which are important for agent invocation. This results in a score of 3, indicating clear but manageable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('timezone' and 'format') fully described in the schema. The description adds no additional parameter semantics beyond stating the tool allows customizable formatting, which is already implied by the schema. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Obtener la fecha y hora actual con formato personalizable' (Get the current date and time with customizable format). It specifies the verb (obtener/get) and resource (fecha y hora actual/current date and time), though it doesn't explicitly differentiate from sibling tools like 'format_timestamp' or 'days_between_dates', which prevents 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'format_timestamp' (which might handle timestamp formatting without fetching current time) or 'get_calendar_month' (which provides calendar data), 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what information is retrieved but doesn't disclose important behavioral aspects: whether this requires elevated permissions, what format the information is returned in, whether it's real-time or cached data, or if there are any rate limits. For a system information tool with zero 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Spanish phrase that directly states the tool's purpose. There's zero waste - every word contributes to understanding what the tool does. The structure is front-loaded with the complete purpose in one concise statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a system information retrieval tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what specific disk/partition information is returned (e.g., capacity, usage, mount points, filesystem type), whether the information is formatted for human or machine consumption, or if there are any platform limitations. For a tool that presumably returns structured system data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't mention parameters since none exist. No additional parameter semantics are needed beyond what the empty schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtener información de discos y particiones' clearly states the verb ('obtener' - get/retrieve) and resource ('información de discos y particiones' - disk and partition information). It distinguishes from siblings like get_cpu_info, get_memory_info, and get_system_info by specifying the disk/partition focus. However, it doesn't explicitly differentiate from get_file_info which might overlap in some contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are several sibling tools that retrieve system information (get_cpu_info, get_memory_info, get_system_info, get_network_info), but the description doesn't explain when disk/partition information is specifically needed or how this tool differs from get_system_info which might include disk 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 full burden for behavioral disclosure. While 'obtener' implies a read-only operation, the description doesn't specify what information is returned (e.g., total/used/free memory, swap usage percentages), whether it requires special permissions, or if there are any rate limits. For a system information tool with zero annotation coverage, this represents a significant gap in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - a single Spanish phrase that directly states the tool's purpose with no wasted words. It's front-loaded with the essential information and contains no unnecessary elaboration or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's system-level nature and lack of both annotations and output schema, the description is insufficiently complete. It doesn't explain what specific memory information is returned (e.g., metrics, units, format), whether the tool requires elevated permissions, or how the information might be useful in context. For a system information tool with no structured output documentation, the description should provide more context about the return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (though empty). The description appropriately doesn't discuss parameters since none exist. A baseline of 4 is appropriate for zero-parameter tools where the description focuses on the tool's purpose rather than parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Obtener información de memoria RAM y swap' (Get RAM and swap memory information). It specifies the verb ('obtener' - get) and the resource ('información de memoria RAM y swap'), making the function unambiguous. However, it doesn't differentiate from sibling tools like get_cpu_info or get_system_info, which prevents 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling system information tools (get_cpu_info, get_disk_info, get_system_info), but the description doesn't indicate when this specific memory-focused tool is appropriate versus the more general get_system_info or other specialized 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does ('obtener información') without describing behavioral traits such as whether it requires permissions, what format the information is returned in, if there are rate limits, or if it's a read-only operation. This is a significant gap for a 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish ('Obtener información de interfaces de red') that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, with every word earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't provide enough context for the agent to understand what information is returned, in what format, or any behavioral aspects. For a tool that retrieves system information, more details would be helpful to ensure correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics beyond what the schema provides, and it appropriately doesn't mention any parameters. Baseline 4 is applied as per the rules for 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtener información de interfaces de red' clearly states the purpose as retrieving network interface information, using a specific verb ('Obtener') and resource ('interfaces de red'). However, it doesn't differentiate from sibling tools like get_system_info or get_cpu_info, which also retrieve system information but for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate, what prerequisites might be needed, or how it differs from similar sibling tools like get_system_info or get_cpu_info, leaving the agent with no usage context.
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 'Listar' implies a read-only operation, the description doesn't address important behavioral aspects like permissions required, whether this requires elevated privileges, potential rate limits, what specific 'información de uso' includes, or how results are formatted. For a system monitoring tool with zero annotation coverage, this represents significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Spanish sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple listing tool and front-loads the essential information. Every word earns its place in conveying what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with comprehensive parameter documentation (100% schema coverage) but no output schema and no annotations, the description is minimally adequate. It states what the tool does but lacks important context about behavioral characteristics, output format, and differentiation from similar tools. The absence of an output schema means the description should ideally provide more information about what 'información de uso' includes and how results are structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with clear documentation for both parameters (limit and sort_by), including defaults, constraints, and enum values. The description adds no additional parameter information beyond what's already in the schema, which is acceptable given the comprehensive schema coverage. The baseline score of 3 reflects adequate parameter documentation through the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Listar') and resource ('procesos del sistema') with additional context about what information is included ('con información de uso'). It distinguishes this tool from most siblings that handle text, files, URLs, or other system info, though it doesn't explicitly differentiate from other system monitoring tools like get_cpu_info or get_memory_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate, what prerequisites might exist, or how it differs from similar system monitoring tools like get_cpu_info, get_memory_info, or get_system_info that might provide overlapping 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?
No annotations are provided, so the description carries full burden. It states it's a read operation ('obtener'), but doesn't disclose behavioral traits like whether it requires special permissions, what format the information returns in, whether it's cached or real-time data, or any rate limits. For a system information 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Spanish sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and multiple sibling tools that provide similar system information, the description is incomplete. It doesn't explain what 'general' system information includes, how it differs from specific sibling tools, or what format the output takes. For a system information tool in this context, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage. The description appropriately doesn't discuss parameters since none exist. It meets the baseline of 4 for zero-parameter tools by not attempting to describe nonexistent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtener información general del sistema operativo' clearly states the verb ('obtener' - get) and resource ('información general del sistema operativo' - general operating system information). It distinguishes from siblings like get_cpu_info, get_memory_info, and get_disk_info by specifying 'general' system information rather than specific components. However, it's not perfectly specific about what 'general' encompasses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like get_cpu_info, get_memory_info, and get_disk_info that provide specific system information, there's no indication whether this tool aggregates those or provides different information, nor any prerequisites or exclusions mentioned.
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 but doesn't describe how it behaves: no information on error handling, performance, side effects, or output format. For a tool with 3 parameters and no output schema, this leaves significant gaps in understanding the tool's 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase in Spanish that directly states the tool's purpose. It's appropriately sized for a simple utility tool, with no wasted words or unnecessary elaboration. The structure is front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a URL encoding/decoding tool with 3 parameters, 100% schema coverage, and no output schema, the description is minimally adequate. It states the purpose but lacks behavioral details and usage context. The schema handles parameters well, but without annotations or output schema, the description should do more to explain how the tool operates and what it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter-specific information beyond what's in the schema. However, schema description coverage is 100%, with clear descriptions for all parameters (text, operation, component) including enums and defaults. This meets the baseline of 3, as the schema adequately documents parameters without needing description supplementation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Codificar/decodificar componentes de URL' clearly states the tool's purpose as encoding/decoding URL components. It uses specific verbs (codificar, decodificar) and identifies the resource (componentes de URL). However, it doesn't explicitly differentiate from sibling tools like 'encode_decode' or 'parse_url', which appear related to similar URL/text 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'encode_decode' (which seems similar), 'build_url', or 'parse_url', nor does it specify contexts where URL encoding/decoding is needed versus other text operations. Usage is implied but not explicitly 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 only states the action (get detailed CPU information) without mentioning any traits like read-only status, performance impact, permissions needed, or output format. For a tool with zero annotation coverage, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that directly states the tool's purpose without any fluff or redundancy. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema), the description is minimally adequate but incomplete. It lacks behavioral context (e.g., what 'detailed' means, output format, or system dependencies), which is crucial since no annotations or output schema exist to fill these gaps. This makes it functional but not fully helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details, but that's appropriate here. A baseline of 4 is applied since the schema fully handles the parameter aspect, and the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtener información detallada de la CPU' clearly states the action (obtener/get) and resource (CPU), making the purpose understandable. However, it doesn't differentiate from sibling tools like get_system_info or get_memory_info that might provide overlapping system information, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like get_system_info, get_memory_info, and get_disk_info that might offer related system data, the description lacks any context about scope, prerequisites, or comparisons, leaving the agent to guess based on tool names 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:

[![mcp-custom-tools MCP server](https://glama.ai/mcp/servers/SergiFuster/mcp-custom-tools/badges/card.svg)](https://glama.ai/mcp/servers/SergiFuster/mcp-custom-tools)

Score Badge

Copy to your README.md:

[![mcp-custom-tools MCP server](https://glama.ai/mcp/servers/SergiFuster/mcp-custom-tools/badges/score.svg)](https://glama.ai/mcp/servers/SergiFuster/mcp-custom-tools)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SergiFuster/mcp-custom-tools'

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