LumbreTravel MCP Server

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 targeting specific resources and actions, but there is some overlap between delete_passenger and delete_passengers, and between get_*_by_name tools that could cause confusion if the user's intent is ambiguous. The descriptions help clarify, but the boundaries are not perfectly clear in a few cases.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as create_agency, delete_agency, update_agency, list_agencies, and get_agency_by_name. This predictability makes it easy for agents to understand and select the correct tool based on the desired action and resource.
Tool Count2/5
With 68 tools, the count is excessive for the travel management domain, leading to a heavy and potentially overwhelming interface. While the domain is broad, many tools could be consolidated or generalized to reduce complexity and improve usability without losing functionality.
Completeness5/5
The tool set provides comprehensive CRUD and lifecycle coverage for all core entities (e.g., agencies, hotels, programs, passengers), including create, get, update, delete, list, and reactivate operations. There are no obvious gaps, and the surface supports full workflows from creation to reactivation.
Average 2.7/5 across 68 of 68 tools scored. Lowest: 1.7/5.
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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'Crear un vehículo,' which implies a write operation but reveals nothing about permissions, side effects, error handling, rate limits, or what happens on success/failure. This leaves critical behavioral aspects completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with a single sentence, the description is under-specified rather than efficiently informative. It fails to front-load useful information, wasting its brevity on a tautological statement that doesn't help the agent understand the tool's role or behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description is severely incomplete. It doesn't explain what 'create' entails, what data is returned, or how it integrates with sibling tools like list_vehicles or delete_vehicle, leaving 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?
Schema description coverage is high at 83%, with all parameters documented in the schema, so the baseline is 3. The description adds no additional meaning about parameters beyond what the schema provides, such as explaining relationships between fields or usage examples, but it doesn't need to compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Crear un vehículo' (Create a vehicle) is a tautology that merely restates the tool name in Spanish, providing no additional specificity about what 'create' entails or what distinguishes it from other creation tools like create_agency or create_program. It fails to clarify the verb+resource relationship beyond the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, such as update_vehicle or list_vehicles, nor does it mention prerequisites, dependencies, or contextual constraints. Without any usage instructions, the agent must infer everything from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers none. 'Reactivar' implies a state change operation, but there's no information about permissions required, whether this is reversible, what happens to associated data, rate limits, or what the operation returns. This leaves the agent completely in the dark about behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three words, this is under-specification rather than effective conciseness. The description fails to provide essential information that would help an agent understand and use the tool correctly, making it inefficient despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is completely inadequate. It doesn't explain what reactivation means operationally, what state changes occur, what permissions are needed, or what the tool returns. Given the complexity implied by 'reactivate' and the lack of structured metadata, this description provides insufficient 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?
Schema description coverage is 100% with the single parameter 'id' well-documented as 'ID de la agencia a reactivar'. The description adds no parameter information beyond what the schema provides, but with complete schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reactivar una agencia' is a tautology that essentially restates the tool name in Spanish, providing no additional clarity about what 'reactivate' entails or what an 'agency' represents in this context. It doesn't distinguish this tool from sibling reactivation tools like reactivate_hotel or reactivate_program.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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's no mention of prerequisites (e.g., agency must be deactivated), when-not-to-use scenarios, or how this differs from similar tools like update_agency or create_agency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only states the action 'reactivate' without disclosing behavioral traits: whether this requires specific permissions, what happens to associated data, if there are side effects, rate limits, or what the response looks like. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with a single sentence, this is under-specification rather than effective brevity. The description doesn't earn its place by providing necessary context for a mutation tool. It's front-loaded but incomplete, failing to convey essential information about the tool's behavior and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is completely inadequate. It doesn't explain what reactivation means operationally, what state changes occur, potential side effects, or return values. Given the complexity of vehicle management and the presence of multiple similar tools, this minimal description fails to provide necessary 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?
Schema description coverage is 100% with one parameter 'id' documented as 'ID del vehículo a reactivar'. The description doesn't add any parameter information beyond what the schema provides. With high schema coverage and only one parameter, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reactivar un vehículo' (Reactivate a vehicle) is a tautology that restates the tool name in Spanish. It specifies the verb 'reactivar' and resource 'vehículo', but doesn't distinguish from sibling tools like reactivate_agency or reactivate_hotel. While it indicates the basic action, it lacks specificity about what reactivation entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., vehicle must be deactivated), when-not scenarios, or how it differs from similar tools like update_vehicle or create_vehicle. With multiple reactivate_* siblings, this omission is particularly problematic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'Actualizar una agencia' only indicates it's a mutation operation but provides no information about permissions required, whether changes are reversible, what happens to existing data not mentioned in parameters, error conditions, or what the tool returns. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral transparency.
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 at just two words ('Actualizar una agencia'), which could be appropriate if it were more informative. However, this brevity comes at the cost of being under-specified rather than efficiently informative. It's front-loaded but lacks the necessary content to be truly helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with 4 required parameters (including a nested object), no annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool does beyond the basic verb, provides no behavioral context, offers no parameter guidance, and gives no indication of what happens after invocation. For a tool with this complexity and lack of structured metadata, the description should do much more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, meaning most parameters have descriptions in the schema itself. The tool description adds no information about parameters beyond what's already in the schema. It doesn't explain the relationship between parameters, provide examples, or clarify semantics like what constitutes a valid 'provider' object. With 4 parameters and no parameter information in the description, it fails to compensate for the 25% coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Actualizar una agencia' (Update an agency) is a tautology that merely restates the tool name in Spanish. It doesn't specify what aspects of an agency can be updated, what the operation entails, or how it differs from sibling tools like 'create_agency' or 'reactivate_agency'. While it indicates a basic action, it lacks specificity and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 tools for agency operations (create_agency, delete_agency, reactivate_agency, list_agencies, get_agency_by_name), but the description doesn't indicate when this update operation is appropriate versus creating a new agency or reactivating a deleted one. No prerequisites, constraints, or contextual usage information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but provides none. It doesn't indicate this is a mutation operation, mention permission requirements, specify whether updates are partial or complete (all 6 parameters are required), describe error conditions, or explain what happens on success. The single Spanish phrase offers no 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three words, this represents under-specification rather than effective brevity. The description fails to provide necessary information about a mutation tool with 6 required parameters, making it inefficient for agent understanding despite its short length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 required parameters, no annotations, and no output schema, the description is completely inadequate. It provides no behavioral context, no usage guidance, no error information, and minimal purpose clarification. The agent would struggle to use this tool correctly based solely on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 6 parameters clearly documented in the input schema. The description adds no parameter information beyond what the schema already provides, so it meets the baseline score of 3 for adequate schema coverage without additional value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Actualizar un hotel' (Update a hotel) is a tautology that restates the tool name in Spanish without adding specificity. It doesn't distinguish this tool from sibling update tools like update_agency or update_program, nor does it clarify what aspects of a hotel can be updated beyond what's implied by the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing hotel ID), differentiate from create_hotel for new hotels, or specify when to use update_hotel versus other hotel-related tools like get_hotel_by_name or list_hotels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides almost none. 'Actualizar' implies a mutation operation, but there's no information about permissions required, whether this is a partial or complete update, what validation occurs, whether changes are reversible, error conditions, or what the response contains. For a mutation tool with zero annotation coverage, this represents a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one Spanish sentence, this represents under-specification rather than effective brevity. The description is too minimal to be helpful - it doesn't provide the necessary context for proper tool usage. A truly concise description would still include essential information about what an 'include' represents in this system and the scope of the update operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is completely inadequate. It doesn't explain what an 'include' is in this domain (hotel extras? program inclusions?), what fields can be updated beyond name and description, what happens on success/failure, or any behavioral characteristics. Given the complexity of an update operation and the lack of structured metadata, this description fails to provide the necessary context for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all three parameters (id, name, description) have descriptions in the schema itself. The tool description adds no additional parameter information beyond what's already documented in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Actualizar un extra o incluído' is a tautology that essentially restates the tool name 'update_include' in Spanish. While it indicates the action (update) and target (extra/included), it doesn't specify what an 'include' represents in this domain or what aspects are being updated beyond the basic verb-noun pairing. It doesn't distinguish this from sibling tools like 'update_activities' or 'update_service' beyond the different resource names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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's no mention of prerequisites, when this operation is appropriate, what happens if the include doesn't exist, or how it differs from related tools like 'create_include' or 'delete_include'. The agent receives no contextual usage information beyond the basic action implied by the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'Actualizar un servicio' implies a mutation operation but reveals nothing about permissions required, whether changes are reversible, rate limits, error conditions, or what happens on success/failure. For a tool that modifies data with 4 required parameters, this lack of transparency is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three words, this is under-specification rather than effective brevity. The description fails to provide necessary information that would help an AI agent use the tool correctly. Every word should earn its place, but here the words don't provide enough value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations, no output schema, and 4 required parameters (including a nested object), the description is completely inadequate. It doesn't explain what 'updating a service' entails, what fields can be modified, what the expected outcome is, or any behavioral aspects. The agent would be operating with minimal guidance.
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 adds no parameter information beyond what's in the schema. However, schema description coverage is 75% (3 of 4 parameters have descriptions in the schema), so the baseline is 3. The description doesn't compensate for the 25% gap (the nested provider object lacks overall description), but it doesn't make things worse either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Actualizar un servicio' (Update a service) is a tautology that essentially restates the tool name 'update_service' in Spanish. It doesn't specify what aspects of a service are updated, how the update works, or what distinguishes it from sibling update tools like update_agency or update_provider. While the verb and resource are clear, it lacks specificity and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 (e.g., needing an existing service ID), when not to use it, or how it differs from similar tools like update_provider or create_service. With many sibling tools available, this absence of context is problematic for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'Crear un servicio' only indicates this is a creation operation but reveals nothing about permissions required, whether this is a mutating operation (implied but not stated), what happens on success/failure, rate limits, or any other behavioral characteristics. For a creation tool with zero annotation coverage, this is completely inadequate.
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 maximally concise - a single Spanish phrase 'Crear un servicio'. While this represents severe under-specification, from a pure conciseness perspective, it's front-loaded with zero wasted words. Every word (both of them) directly states the tool's action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a creation tool with 3 required parameters (including a nested object), no annotations, no output schema, and 67% schema coverage, the description is completely inadequate. It provides no context about what a service is in this domain, what happens after creation, error conditions, or how this fits with the many sibling tools. The description fails to compensate for the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (2 of 3 parameters have descriptions in the schema), but the description adds zero information about parameters. It doesn't explain what a 'service' consists of, what the provider object represents, or provide any context beyond what's minimally documented in the schema. With 3 required parameters including a nested object, the description should add meaningful context about parameter relationships and semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Crear un servicio' is a tautology that essentially restates the tool name 'create_service' in Spanish. It doesn't specify what kind of service is being created or what domain this operates in, nor does it differentiate from sibling tools like 'create_agency', 'create_hotel', or 'create_provider' which appear to be similar creation operations in the same system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. With many sibling tools including other 'create_' operations and various 'get_', 'list_', 'update_', and 'delete_' tools, there's no indication of when this specific service creation tool is appropriate versus creating other entities or using related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 the action (delete) but reveals nothing about behavioral traits: no mention of whether deletion is permanent, requires specific permissions, affects related data, has confirmation steps, or returns any output. For a destructive operation with zero annotation coverage, this is critically inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (3 words) but under-specified rather than efficiently informative. While it avoids waste, it fails to provide necessary context for a destructive operation. Conciseness without substance doesn't earn high marks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is completely inadequate. It doesn't explain consequences, return values, error conditions, or usage context. Given the complexity of deletion operations and lack of structured data, this description leaves critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 100% description coverage ('ID del vehículo a eliminar'), so the schema fully documents the parameter. The description adds no parameter information, which is acceptable given the high schema coverage. With 0 parameters needing semantic clarification, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Eliminar un vehículo' (Delete a vehicle) is a tautology that merely restates the tool name in Spanish. It specifies the verb (delete) and resource (vehicle), but doesn't differentiate from sibling tools like 'delete_activities' or 'delete_program' beyond the resource name. This provides minimal clarity beyond the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 sibling tools like 'reactivate_vehicle' and 'update_vehicle', the description doesn't indicate if deletion is permanent, reversible, or has prerequisites. It fails to help an agent choose between deletion and other vehicle-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 'Crear un proveedor' which implies a write/mutation operation but reveals nothing about permissions required, whether creation is idempotent, what happens on duplicate names, error conditions, or response format. For a mutation tool with zero annotation coverage, this is critically 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 extremely concise at just three words ('Crear un proveedor'). While this represents under-specification rather than ideal conciseness, according to the scoring framework, conciseness evaluates whether the description is appropriately sized and front-loaded. This description wastes no words and gets straight to the point, earning full marks on this dimension despite its inadequacy elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool (create operation) with no annotations and no output schema, the description is completely inadequate. It doesn't explain what a provider is, when to create one, what permissions are needed, what the response contains, or how it differs from other creation tools. The description fails to provide the necessary context for an agent to use this tool 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%, meaning all parameters (name, description, email, phone) are documented in the input schema with descriptions. The tool description adds no additional parameter information beyond what's already in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Crear un proveedor' (Create a provider) is a tautology that essentially restates the tool name 'create_provider' in Spanish. While it indicates the action (create) and resource (provider), it doesn't specify what a 'provider' represents in this context or differentiate it from similar creation tools like create_agency, create_hotel, etc. The purpose is stated but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 creation tools (e.g., create_agency, create_hotel, create_program) with no indication of what distinguishes a 'provider' from these other entities. No prerequisites, context, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 ('crear') without detailing outcomes, permissions, side effects, or response format. For a creation tool with zero annotation coverage, this is inadequate as it omits critical behavioral traits like whether it's idempotent, what happens on duplicate names, or if it requires specific authentication.
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 extremely concise with a single sentence, 'Crear un idioma de servicio.', which is front-loaded and wastes no words. It directly states the tool's action without unnecessary elaboration, making it efficient in structure, though this conciseness contributes to gaps in other dimensions like guidelines and transparency.
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 a creation tool with no annotations and no output schema, the description is incomplete. It fails to explain what a 'service language' is, how it integrates with other tools, or what the tool returns upon success or error. The lack of behavioral and contextual details makes it insufficient for an agent to use the tool effectively in isolation.
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 'name' documented as 'Nombre del idioma de servicio' (Name of the service language). The description adds no additional meaning beyond the schema, such as format constraints or examples. Since schema coverage is high, the baseline score of 3 applies, as the schema adequately handles parameter documentation without extra input from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Crear un idioma de servicio' (Create a service language) restates the tool name 'create_service_language' with minimal elaboration, making it tautological. It specifies the verb 'crear' (create) and resource 'idioma de servicio' (service language) but lacks differentiation from sibling tools like 'create_service' or 'create_program', failing to clarify what a 'service language' entails in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It does not mention prerequisites, context, or exclusions, such as how it relates to sibling tools like 'list_service_languages' or 'delete_service_language'. The description offers no usage instructions, leaving the agent without direction on appropriate scenarios for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'Reactivar' implies a mutation operation, but the description doesn't specify permissions required, side effects (e.g., changes leader status, affects associated programs), error conditions, or response format. This leaves critical behavioral traits undocumented.
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 action. It's front-loaded with the core purpose and wastes no words, making it highly concise and well-structured for its limited 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 no annotations, no output schema, and a mutation tool with unclear behavioral implications, the description is incomplete. It fails to address key contextual aspects like what 'reactivate' entails operationally, success/failure responses, or how it integrates with sibling tools (e.g., 'delete_leader' might deactivate). The high schema coverage doesn't compensate for these 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 the single parameter 'id' documented as 'ID del guía a reactivar'. The description adds no additional meaning beyond this, such as format examples (e.g., numeric vs. string) or validation rules. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reactivar un guía' (Reactivate a guide) restates the tool name 'reactivate_leader' with minimal elaboration. It specifies the verb 'reactivar' and resource 'guía', but doesn't clarify what 'reactivate' means in this context (e.g., restoring a deactivated leader, changing status) or how it differs from sibling tools like 'create_leader' or 'update_leader'. The description is tautological rather than informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 (e.g., the leader must be deactivated first), exclusions (e.g., cannot reactivate an active leader), or comparisons to sibling tools like 'reactivate_agency' or 'update_leader'. Without any usage context, an agent cannot make informed decisions.
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. 'Crear' implies a write/mutation operation, but the description doesn't disclose behavioral traits like required permissions, whether creation is idempotent, what happens on conflicts, or the response format. It lacks essential context for a creation tool.
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. However, it's under-specified rather than efficiently informative—it uses minimal words but fails to convey useful information beyond the tool name.
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 creation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what an 'include' is in this domain, what happens after creation, or any prerequisites. Given the complexity implied by sibling tools (e.g., includes vs. services), more context is needed 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?
Schema description coverage is 100%, with both parameters (name, description) documented in the schema. The description adds no meaning beyond the schema—it doesn't explain what 'name' or 'description' represent for an 'include', their constraints, or 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Crear un extra o incluído' (Create an extra or included) restates the tool name 'create_include' in Spanish, making it tautological. It doesn't specify what resource is being created beyond the vague 'extra o incluído', nor does it distinguish this from sibling tools like 'create_service' or 'create_program'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 many sibling tools for creating different entities (e.g., create_agency, create_hotel, create_service), the description offers no context on what an 'include' represents or when it's appropriate to create one.
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. 'Reactivar' implies a state change operation (likely from inactive to active), but the description doesn't specify what reactivation entails, whether it requires specific permissions, what happens to associated data, or what the expected outcome is. For a mutation tool with zero annotation coverage, this is inadequate.
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. While appropriately brief, it's arguably too minimal given the tool's complexity (a state-changing operation). However, it doesn't contain unnecessary words 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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what reactivation means in this context, what prerequisites exist (e.g., provider must be deactivated), what side effects occur, or what the tool returns. Given the complexity of state transitions and the lack of structured metadata, more context is needed.
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 single parameter 'id' clearly documented as 'ID del proveedor a reactivar'. The description doesn't add any additional parameter information beyond what the schema provides, but with complete schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reactivar un proveedor' (Reactivate a provider) is a tautology that essentially restates the tool name 'reactivate_provider' in Spanish. While it indicates the action (reactivate) and resource (provider), it doesn't provide any additional specificity about what reactivation entails or how it differs from similar tools like 'create_provider' or 'update_provider'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives. There are multiple sibling tools for reactivating different entities (reactivate_agency, reactivate_hotel, etc.), but no indication of when reactivate_provider specifically should be used versus other reactivation tools or versus create_provider/update_provider.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool edits passengers, implying a mutation operation, but doesn't disclose critical behavioral traits: whether it requires specific permissions, if changes are reversible, what happens to unspecified fields (partial vs full updates), error handling, or rate limits. The description adds minimal context beyond the basic edit action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that's reasonably concise, but it's not optimally structured. It front-loads the main action ('Edita pasajeros') but buries the important constraint about passenger ID in a subordinate clause. While not wasteful, it could be more direct and better organized to highlight key information first.
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 (11 required nested parameters, mutation operation), absence of annotations, and no output schema, the description is incomplete. It doesn't explain what constitutes a successful edit, return values, error conditions, or the scope of changes. For a tool with such rich parameter requirements and no structured documentation support, the description provides inadequate context for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters beyond implying passenger ID is involved. With schema description coverage at 0% (no parameter descriptions in schema) and 11 required nested parameters, the description fails to compensate. It doesn't explain what 'passengers' array contains, the meaning of fields like 'documenttype' or 'gender', or default behaviors mentioned in schema descriptions (e.g., deducing values from names).
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 states the tool 'edits passengers' which is a clear verb+resource combination, but it's vague about what specific aspects are edited. It mentions 'teniendo en cuenta que se conoce el ID del pasajero' (considering that the passenger ID is known), which adds some context but doesn't fully distinguish it from sibling tools like 'update_activities' or 'update_program' beyond the resource type.
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 explicit guidance on when to use this tool versus alternatives. While it implies usage when passenger ID is known, it doesn't mention when NOT to use it (e.g., vs 'create_passengers' for new passengers or 'delete_passenger' for removal) or reference any sibling tools. The phrase about knowing the ID is more of a prerequisite than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'Crear' (Create) implies a write/mutation operation, but the description reveals nothing about permissions required, whether creation is idempotent, what happens on duplicate entries, error conditions, or what the tool returns. For a creation tool with zero annotation coverage, this is a critical 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 extremely concise at just two words ('Crear un guía'). While this represents under-specification rather than ideal conciseness, within the scoring framework it earns maximum points for having zero wasted words and being front-loaded with the core action. Every word serves a purpose, even if that purpose is minimally fulfilled.
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 creation tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what a 'guía' is in this system, what happens after creation, whether there are prerequisites, or how this relates to other entities. The language parameter warning in the schema suggests complexity, but the description doesn't address this context. With rich sibling tools and no structured metadata, more descriptive context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 5 parameters well-documented in the schema itself. The description adds no parameter information beyond what's already in the schema. The baseline score of 3 reflects that the schema does the heavy lifting for parameter documentation, though the description could have provided additional context about parameter relationships or business rules.
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 'Crear un guía' (Create a guide) states the basic action and resource but is vague about what a 'guía' represents in this system. It doesn't distinguish this from sibling tools like 'create_agency', 'create_hotel', or 'create_service', which all appear to create different entity types. The purpose is understandable but lacks specificity about the domain context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 many sibling tools for creating different entities (agency, hotel, service, etc.), there's no indication of what distinguishes a 'guía' from these other resources or when this specific creation tool is appropriate. The language parameter note warns against using other tools but doesn't provide positive 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. 'Reactivar' implies a mutation that changes a hotel's state, but it fails to specify required permissions, whether the operation is reversible, potential side effects (e.g., reactivating bookings), or error conditions. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('Reactivar un hotel') with zero wasted words. It is appropriately sized and front-loaded, making it easy to parse quickly 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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., what reactivation entails, success/failure responses), usage context, and differentiation from siblings. Given the complexity of state-changing operations, this minimal description does not provide sufficient guidance for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'id' parameter documented as 'ID del hotel a reactivar'. The description adds no additional parameter information beyond what the schema provides, but since schema coverage is high, the baseline score of 3 is appropriate as the schema adequately handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reactivar un hotel' (Reactivate a hotel) is a tautology that restates the tool name 'reactivate_hotel' without adding meaningful context. It specifies the verb (reactivate) and resource (hotel) but lacks differentiation from sibling tools like 'reactivate_agency' or 'reactivate_program', failing to clarify what makes hotel reactivation unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 does not mention prerequisites (e.g., the hotel must be deactivated), exclusions, or comparisons to sibling tools like 'create_hotel' or 'update_hotel', leaving the agent without context for appropriate 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 full burden for behavioral disclosure. 'Actualizar' implies a mutation/write operation, but the description doesn't mention required permissions, whether partial updates are supported, what happens to unspecified fields, error conditions, or side effects. The language parameter warning hints at behavioral constraints but doesn't fully compensate for the missing safety/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 extremely concise - a single Spanish phrase 'Actualizar un guía' - with zero wasted words. While this represents under-specification rather than ideal conciseness, it meets the technical criteria for being front-loaded and having every sentence (in this case, the only sentence) earn its place by stating the core purpose.
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 mutation tool with 6 required parameters and no annotations or output schema, the description is inadequate. It doesn't explain what 'guía' represents in this domain, doesn't provide usage context, and offers minimal behavioral transparency. The schema provides parameter documentation but the description fails to add meaningful value beyond the 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%, so the schema already documents all 6 parameters thoroughly. The description adds no parameter information beyond what's in the schema. However, the schema provides good parameter descriptions including the language parameter warning, establishing a baseline score of 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Actualizar un guía' is a tautology that simply restates the tool name 'update_leader' in Spanish. It doesn't specify what 'guía' refers to (likely a tour guide/leader based on context) or what fields can be updated. While it indicates a mutation operation, it lacks the specificity needed to distinguish it from sibling tools like 'create_leader' or 'reactivate_leader'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 related tools (create_leader, delete_leader, reactivate_leader, get_leader_by_name, list_leaders) but the description offers no context about prerequisites, when this update is appropriate, or what distinguishes it from other leader-related operations.
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 a prerequisite check ('se debe preguntar al si quiere que primero se busque el hotel') but doesn't disclose critical behavioral traits: whether this is a write operation, what permissions are needed, whether duplicates are allowed, what happens on success/failure, or what the response contains. For a creation 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it's poorly structured - it starts with a prerequisite instruction rather than stating the tool's purpose. The sentence is somewhat awkwardly phrased and could be more direct about what the tool does.
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 creation tool with 5 required parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what happens after creation, what validation occurs, whether there are side effects, or what the return value looks like. The focus on a prerequisite check doesn't compensate for missing 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?
Schema description coverage is 100%, so the schema already documents all 5 parameters with clear descriptions. The description adds no parameter information beyond what's in the schema - it doesn't explain relationships between parameters, validation rules, or format requirements. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool creates a new hotel, which is a clear verb+resource combination. However, it doesn't distinguish this from sibling tools like 'create_agency' or 'create_provider' - all appear to be similar creation operations for different entities. The description focuses more on a prerequisite check than on what the tool actually does.
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 some guidance about checking if a hotel exists first, but doesn't specify when to use this tool versus alternatives like 'update_hotel' or 'get_hotel_by_name'. It mentions a prerequisite action but doesn't provide clear context about when this creation operation is appropriate versus other hotel-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only states the action without disclosing behavioral traits like read-only vs. destructive, authentication needs, rate limits, error handling, or return format. 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 in Spanish, front-loaded with the core action. There's zero waste, making it appropriately concise and well-structured for its purpose.
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 a simple parameter, the description is incomplete. It lacks details on behavior, usage context, and output, making it insufficient for an agent to reliably invoke the tool without guesswork.
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 'fullname' documented as 'Nombre completo del pasajero'. The description adds no additional meaning beyond the schema, such as format examples or search behavior. 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 'Obtiene pasajeros por nombre completo' (Gets passengers by full name) states the verb and resource, but it's vague about scope (e.g., exact match, partial, case-sensitive) and doesn't differentiate from sibling 'get_passengers_by_email'. It's not tautological but lacks specificity for a 4 or 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_passengers_by_email' or 'list_passengers' (if existed). The description implies usage by full name but doesn't specify scenarios, exclusions, or prerequisites, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action ('adds') without disclosing behavioral traits. It doesn't mention whether this is a mutation, what permissions are needed, if duplicates are allowed, how failures are handled, or what the response looks like. For a write operation with zero annotation coverage, this is inadequate.
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 that directly states the tool's purpose. It's appropriately brief and front-loaded with the core action, though it could benefit from slightly more detail given the lack of annotations and output schema.
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 mutation tool with no annotations, no output schema, and multiple similar sibling tools, the description is incomplete. It doesn't address behavioral aspects, usage context, or result expectations. The agent would need to guess about important operational details when invoking this 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 (programId and passengers). The description doesn't add any meaning beyond what the schema provides - no explanation of what constitutes valid program IDs, passenger data formats, or constraints. Baseline 3 is appropriate when schema does the documentation work.
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 'Agrega pasajeros a un programa' clearly states the action (adds) and target (passengers to a program), but it's vague about scope and doesn't distinguish from sibling tools like 'create_passengers' or 'update_passengers'. It provides basic purpose but lacks specificity about what 'adding' entails in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'create_passengers' or 'update_passengers'. The description doesn't mention prerequisites, constraints, or appropriate contexts for use, leaving the agent with no usage differentiation from similar-sounding 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. 'Eliminar' implies a destructive operation, but it doesn't specify if deletion is permanent, requires specific permissions, has side effects (e.g., on related data), or what happens on success/failure. This leaves critical behavioral traits unclear for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('Eliminar un hotel') that directly states the action. It's appropriately sized and front-loaded with no wasted words, though it could be slightly more informative 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?
For a destructive tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permanence, error handling, or return values, which are crucial for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 'id' parameter clearly documented as 'ID del hotel a eliminar'. The description adds no additional parameter semantics beyond what the schema provides, 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 'Eliminar un hotel' (Delete a hotel) clearly states the verb and resource, making the purpose understandable. However, it doesn't differentiate from sibling deletion tools like delete_agency or delete_program, which follow the same pattern, so it lacks specific distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention prerequisites like checking if a hotel exists first or when to use reactivate_hotel instead. The description offers no context for selection among sibling 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. It states it's a deletion operation ('Elimina'), implying it's destructive, but doesn't disclose critical behavioral traits such as whether deletions are permanent, reversible via reactivation tools, require specific permissions, or have side effects on related data. For a destructive 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is reasonably concise, but it's not optimally structured. It front-loads the action and resource but could be more direct. While it avoids unnecessary words, it lacks clarity in distinguishing from siblings, making it somewhat inefficient in conveying full utility.
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 destructive nature, lack of annotations, no output schema, and low parameter semantics, the description is incomplete. It doesn't cover behavioral aspects like permanence, error handling, or relationships with reactivation tools, nor does it provide usage context. This leaves the agent poorly equipped to use the tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds minimal semantics by mentioning that passenger IDs are required ('se conoce el ID del pasajero'), but it doesn't explain the array structure, format of IDs, or any constraints. This is inadequate compensation for the lack of schema documentation, leaving parameters largely unexplained.
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 ('Elimina' meaning 'Delete') and the resource ('pasajeros' meaning 'passengers'), specifying it requires passenger IDs. It distinguishes from siblings like 'delete_passenger' (singular) by indicating it handles multiple passengers. However, it doesn't fully clarify if it's batch deletion or how it differs from other deletion tools beyond the plural form.
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 'delete_passenger' (singular) or 'reactivate_passenger'. It mentions the requirement of passenger IDs but gives no context about prerequisites, error conditions, or typical use cases. This leaves the agent with insufficient information to choose appropriately among sibling 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. 'Eliminar' implies a destructive mutation, but the description doesn't specify if deletion is permanent, requires specific permissions, has side effects (e.g., cascading deletions), or includes confirmation steps. For a destructive 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('Eliminar un servicio') that directly states the action. It's front-loaded with the verb and avoids unnecessary words. However, it's overly terse for a destructive operation—adding a bit more context (e.g., 'permanently') could improve clarity without sacrificing 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 the tool's destructive nature, lack of annotations, and no output schema, the description is incomplete. It doesn't address critical aspects like return values, error conditions, or behavioral nuances (e.g., irreversible deletion). For a mutation tool with high stakes, this minimal description fails to provide sufficient context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 'id' parameter clearly documented as 'ID del servicio a eliminar'. The description adds no additional parameter semantics beyond what the schema provides. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Eliminar un servicio' (Delete a service) states a clear verb ('eliminar') and resource ('servicio'), which is better than a tautology. However, it doesn't differentiate from sibling tools like 'delete_activities' or 'delete_program'—it only specifies the resource type without clarifying what distinguishes a 'service' from other deletable entities in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 (e.g., needing an existing service ID), exclusions, or comparisons to other deletion tools (e.g., 'delete_service_language'). Without such context, an agent might misuse it or overlook related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool searches by name, but doesn't disclose behavioral traits such as whether it's read-only, if it returns partial matches, error handling, or performance characteristics. 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.
Conciseness4/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. It's front-loaded with the core action and resource, with no wasted words, though the ambiguity in terminology slightly reduces clarity.
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 'extras o incluídos' are, the return format, or any behavioral context. For a search tool in a domain with many siblings, more detail 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?
The input schema has 100% description coverage, with the parameter 'name' documented as 'Nombre del include'. The description adds no additional meaning beyond this, as it only repeats the search-by-name concept. Baseline score of 3 is appropriate since the schema fully describes the parameter.
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 'Buscar extras o incluídos por su nombre' specifies the action (buscar/search) and resource (extras o incluídos), but it's vague about what 'extras o incluídos' refers to in this domain. It distinguishes from siblings like 'list_includes' by indicating a name-based search rather than listing all, but the terminology is ambiguous.
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 explicit guidance on when to use this tool versus alternatives like 'list_includes' or other 'get_by_name' siblings (e.g., 'get_agency_by_name'). The description implies usage for searching by name, but it doesn't specify contexts, prerequisites, or exclusions, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the search action without detailing what 'buscar' entails—e.g., whether it's a read-only operation, if it returns exact or partial matches, error handling, or authentication needs. For a tool with no annotations, this leaves critical behavioral traits unspecified.
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 ('Buscar guías por su nombre.') that is front-loaded and wastes no words. However, it's slightly under-specified given the lack of annotations and sibling context, which affects completeness more than 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 the complexity (a search tool with no annotations and no output schema), the description is incomplete. It doesn't explain what 'guías' are, how results are returned, or any behavioral nuances. With no output schema, the description should ideally hint at return values or search behavior, but it fails to do so, leaving gaps for the 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?
The input schema has 100% description coverage, with the 'name' parameter documented as 'Nombre del guía'. The description adds no additional meaning beyond this, as it merely restates the parameter's purpose. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 'Buscar guías por su nombre' (Search guides by their name) states a clear verb ('buscar') and resource ('guías'), but it's vague about what 'guías' refers to (likely leaders/guides based on tool name) and doesn't differentiate from sibling tools like 'get_agency_by_name' or 'get_hotel_by_name' that follow the same pattern. It's functional but lacks specificity.
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 prerequisites, when-not-to-use scenarios, or comparisons to sibling tools like 'list_leaders' (which might retrieve all leaders without filtering). The description implies usage for searching by name but offers no contextual boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states a read operation ('obtiene'), implying non-destructive behavior, but doesn't disclose critical traits like authentication needs, rate limits, error handling, or return format (e.g., list of passengers, single record). For a tool with zero annotation coverage, this is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish ('Obtiene pasajeros por email'), which is appropriately sized and front-loaded with the core action. However, it could be more structured by including key details like scope or alternatives, but it avoids unnecessary verbosity.
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 a lookup tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'pasajeros' includes (e.g., fields returned), how results are formatted, or error cases. For a tool that likely returns passenger data, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 'email' documented as 'Email del pasajero'. The description adds no additional meaning beyond this, such as format requirements or examples. With high schema coverage, the baseline is 3, as the schema adequately handles parameter documentation without extra input from 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 'Obtiene pasajeros por email' (Gets passengers by email) states a clear verb ('obtiene') and resource ('pasajeros'), but it's vague about scope and doesn't distinguish from sibling tools like 'get_passengers_by_fullname' or 'list' operations. It specifies the lookup method ('por email') but lacks detail on what 'pasajeros' entails (e.g., passenger records, details).
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_passengers_by_fullname' and 'list' tools, the description doesn't indicate whether this is for exact email matches, partial searches, or when email is the preferred identifier over names. Usage context is implied but not explicit.
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 searching but doesn't specify if this is a read-only operation, how results are returned (e.g., exact match, partial match, pagination), error handling, or any rate limits. 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.
Conciseness4/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. It's appropriately sized and front-loaded with no wasted words, though it could benefit from more detail given the lack of annotations.
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 a search tool with no annotations and no output schema, the description is incomplete. It doesn't explain return values, match behavior, or error cases, leaving gaps that could hinder an AI agent's ability to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 'name' parameter documented as 'Nombre del proveedor.' The description adds no additional meaning beyond this, such as format examples or search behavior. Baseline score of 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 'Buscar proveedores por su nombre' translates to 'Search providers by their name,' which clearly states the action (search) and resource (providers) but lacks specificity about what 'providers' are in this context and doesn't differentiate from sibling tools like 'list_providers' or 'get_agency_by_name.' It's vague but conveys the basic purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 such as 'list_providers' or other 'get_by_name' tools for different resources. The description implies usage by name but doesn't specify prerequisites, exclusions, or context, leaving the agent to infer 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.
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 searching but doesn't specify whether this is a read-only operation, if it requires authentication, what happens on no match (e.g., returns empty or error), or any rate limits. This leaves significant gaps for a tool that likely queries a database.
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 that directly states the tool's function. It's front-loaded with the core action and resource, though it could be slightly more structured by including key details like output format or usage context.
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 lacks details on behavioral traits (e.g., read-only nature, error handling), return values, and differentiation from siblings. For a search tool in a system with many similar 'get_by_name' tools, this leaves the agent under-informed.
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 'name' documented as 'Nombre del idioma de servicio'. The description adds no additional meaning beyond this, such as format examples or search behavior (e.g., exact match vs. partial). 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 'Buscar idiomas de servicio por su nombre' (Search service languages by their name) states the action (search) and resource (service languages) with a specific filter (by name), but it doesn't differentiate from sibling tools like 'list_service_languages' or other 'get_by_name' tools (e.g., 'get_agency_by_name'), leaving the purpose somewhat vague in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 such as 'list_service_languages' for broader queries or other 'get_by_name' tools for different resources. The description implies usage for searching by name but offers no explicit 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states it updates a program but doesn't mention what permissions are required, whether the update is reversible, what happens to existing data not mentioned in parameters, or what the response looks like. For a mutation tool with zero annotation coverage, this is insufficient 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 that states the core purpose without unnecessary words. It's appropriately concise for what it does cover, though it could be more helpful with additional context.
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 mutation tool with 5 required parameters, no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, side effects, or response format. The description should provide more context about what this update operation entails beyond the basic statement of purpose.
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 and constraints. The description adds no additional parameter information beyond what's in the schema. According to the guidelines, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Actualiza un programa de viajes en LumbreTravel' which translates to 'Updates a travel program in LumbreTravel'. This clearly indicates the action (update) and resource (travel program), but it doesn't differentiate from sibling tools like update_activities, update_agency, etc. It's a generic update statement without specifying what distinguishes updating a program from other update 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. There are many sibling tools including other update operations and related tools like create_program, delete_program, reactivate_program, and get_program, but the description doesn't mention any of these or provide context about when this specific update operation is appropriate.
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. 'Actualizar' implies a mutation, but it doesn't disclose behavioral traits like required permissions, whether updates are partial or full, if changes are reversible, error handling, or rate limits. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. However, it's under-specified rather than concise, as it lacks necessary details for a mutation tool, but within its minimal scope, it's structurally sound.
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 mutation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what happens on success/failure, return values, or side effects, leaving significant gaps for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 with clear descriptions. The description adds no additional meaning beyond what's in the schema, such as validation rules or interdependencies. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Actualizar un proveedor' (Update a provider) clearly states the verb and resource, but it's vague about what aspects can be updated. It doesn't differentiate from sibling update tools like update_agency or update_hotel, which have similar descriptions.
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. It doesn't mention prerequisites (e.g., needing an existing provider ID), exclusions, or how it differs from create_provider or other update_* tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Actualizar' implies a mutation, but the description doesn't disclose behavioral traits like required permissions, whether the update is partial or full, if it's idempotent, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. However, it's under-specified rather than concise, as it lacks necessary details for a mutation tool. It's front-loaded but too minimal to be fully effective.
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 mutation tool with 7 required parameters, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, usage context, or return values, leaving significant gaps for an AI agent to understand how to invoke it correctly.
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 high (86%), with all parameters well-documented in the schema. The description adds no additional meaning beyond the schema, such as explaining relationships between fields (e.g., provider object structure) or constraints. Baseline 3 is appropriate when the schema does most of the work.
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 'Actualizar un vehículo' (Update a vehicle) clearly states the verb and resource, but it's vague about what aspects of the vehicle are updated. It doesn't distinguish this tool from other update_* tools in the sibling list, like update_activities or update_program, beyond the resource type.
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. It doesn't mention prerequisites (e.g., needing an existing vehicle ID), exclusions, or how it differs from similar tools like create_vehicle or delete_vehicle in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states a read operation ('obtiene'), implying it's likely non-destructive, but doesn't disclose behavioral traits such as authentication needs, rate limits, pagination, or what the return format looks like. This is inadequate for a tool with 5 parameters and 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.
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, with zero 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 complexity (5 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return values, error conditions, or how filtering works beyond what's in the schema. For a tool that likely returns structured activity data, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter clearly documented in the input schema. The description adds no additional meaning beyond the schema, such as explaining relationships between filters or default behaviors. 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 'Obtiene las actividades diarias' (Gets the daily activities) states a clear verb ('obtiene') and resource ('actividades diarias'), but it's vague about scope and doesn't distinguish from sibling tools like 'get_program' or 'get_programs_by_date_range'. It lacks specificity about what 'daily activities' entails in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 many sibling tools like 'get_program' or 'get_programs_by_date_range', the description doesn't clarify if this is for filtered activity listings versus broader program queries, leaving usage context implied at best.
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 'Elimina' clearly indicates a destructive operation, the description doesn't specify whether this is a hard or soft deletion, whether it's reversible, what permissions are required, what happens to associated data, or what the response looks like. For a destructive operation with zero annotation coverage, this represents significant gaps in behavioral transparency.
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 Spanish sentence that gets straight to the point. There's no wasted language or unnecessary elaboration. However, it could be more front-loaded with critical behavioral information given this is a destructive operation.
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 destructive deletion tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't address critical questions about deletion behavior (hard vs soft, reversibility), error conditions, permissions, or what happens to related data. The presence of 'reactivate_passenger' as a sibling tool suggests a soft deletion system exists, making this omission particularly significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description mentions 'se conoce su ID' (its ID is known), which provides some context about the passengerId parameter, but doesn't explain the ID format, where to find it, or provide any examples. With 1 parameter completely undocumented in the schema, the description adds minimal semantic value beyond what's obvious from the parameter name.
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 ('Elimina' - delete/destroy) and the resource ('un pasajero' - a passenger), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'delete_passengers' (plural) or 'reactivate_passenger', leaving some ambiguity about when to use this singular deletion tool versus the batch deletion tool.
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 minimal guidance - it only mentions that the passenger ID must be known. It doesn't explain when to use this tool versus alternatives like 'delete_passengers' (plural deletion), 'reactivate_passenger' (which suggests soft deletion might be available), or when deletion is appropriate versus updating passenger data. No explicit when/when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose if reactivation requires specific permissions, affects billing or status, is reversible, or has side effects. For a mutation tool, this leaves critical 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 phrase in Spanish that directly states the tool's action. It's appropriately sized and front-loaded with zero wasted words, making it highly 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?
Given the tool's complexity (a mutation with no annotations or output schema), the description is incomplete. It lacks details on what reactivation entails, success/failure outcomes, or how it fits into the service lifecycle, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter 'id' documented as 'ID del servicio a reactivar'. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reactivar un servicio' (Reactivate a service) states a clear verb+resource action, but it's vague about what 'reactivate' entails (e.g., restoring from suspension vs. re-enabling billing). It doesn't distinguish from sibling tools like reactivate_agency or reactivate_program, which follow the same pattern 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the service must be deactivated first), exclusions, or related tools like delete_service or create_service for lifecycle 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 full burden for behavioral disclosure. 'Elimina' implies a destructive operation, but it doesn't specify if deletion is permanent, reversible (e.g., via reactivate_program), requires specific permissions, or has side effects (e.g., cascading deletions). This leaves critical behavioral traits undocumented.
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 action without unnecessary words. It's 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 tool's destructive nature (implied by 'delete'), lack of annotations, 0% schema coverage, no output schema, and multiple sibling tools, the description is incomplete. It doesn't address behavioral risks, parameter meaning, or usage context, making it inadequate for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter documentation. It mentions no parameters at all, failing to explain that 'id' is required or what it represents (e.g., a program identifier). This leaves the single required parameter undocumented in both schema and 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 'Elimina un programa de viajes' clearly states the action (elimina/delete) and resource (programa de viajes/travel program), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like delete_activities or delete_agency, which follow similar naming patterns but target 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 prerequisites (e.g., needing an existing program ID), exclusions, or compare it to related tools like reactivate_program or update_program, leaving usage context unclear.
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. 'Reactiva' implies a state change (likely from inactive to active), but it doesn't disclose behavioral traits like required permissions, whether this is reversible, what happens to associated data, or error conditions. For a mutation 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 sentence in Spanish with zero waste. It's appropriately sized and front-loaded, though its brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation), lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It fails to address key aspects like parameter meaning, usage context, behavioral implications, or expected outcomes, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions no parameters at all—not even hinting at the required 'id' parameter for identifying which program to reactivate. This leaves the single parameter completely undocumented beyond the schema's type information.
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 'Reactiva un programa de viajes' clearly states the action (reactivate) and resource (travel program) in Spanish. It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like 'reactivate_agency' or 'reactivate_hotel' beyond the resource type.
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 'update_program' and 'create_program' available, there's no indication of prerequisites (e.g., program must be deactivated first) or when reactivation is appropriate versus creating a new program.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool creates passengers but doesn't mention whether this is a write operation, what permissions are required, whether it's idempotent, what happens on failure, or what the return value looks like. For a creation tool with zero annotation coverage, this leaves significant behavioral gaps that could affect agent decision-making.
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 appropriately concise with just one sentence in Spanish. It front-loads the core purpose ('Crea pasajeros') followed by usage context. There's no wasted text, though it could benefit from slightly more detail given the complexity of passenger creation.
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 creation tool with no annotations, no output schema, and 1 parameter (though complex with nested objects), the description is insufficient. It doesn't address behavioral aspects like error handling, authentication requirements, or response format. While the input schema provides detailed property descriptions, the description itself doesn't add meaningful context about the creation operation's semantics or constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the single parameter 'passengers' beyond what's implied by the tool name. With 0% schema description coverage (the schema has descriptions but they're not counted in coverage metrics), the description fails to compensate for the lack of parameter documentation. It doesn't explain what the passengers array should contain, format expectations, or any constraints beyond the basic creation context.
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: 'Crea pasajeros' (creates passengers) which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'add_passengers_to_program' or 'update_passengers' by focusing on initial creation rather than modification or addition to existing entities. However, it doesn't explicitly differentiate from 'create_agency' or other 'create_' tools beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance: 'usa esta tool cuando el asistente recibe los datos de los pasajeros como parte del pedido del usuario' (use this tool when the assistant receives passenger data as part of the user's order). This implies the context but doesn't explicitly state when NOT to use it or mention alternatives like 'add_passengers_to_program' for adding to existing programs. The guidance is helpful but incomplete.
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 deletes an include, implying a destructive mutation, but doesn't specify whether this action is permanent, reversible, requires specific permissions, or has side effects (e.g., affecting related data). For a deletion tool with zero annotation coverage, this lack of behavioral details is a significant gap, leaving critical operational risks unaddressed.
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 ('Eliminar un extra o incluído'), which is appropriately sized for a simple deletion tool. It's front-loaded with the core action and resource, with zero wasted words or redundant phrasing, making it highly concise and well-structured for quick comprehension.
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 as a deletion operation with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., permanence, permissions), usage context compared to siblings, and expected outcomes. For a destructive tool in a system with multiple related operations (e.g., reactivate_include), this minimal description fails to provide sufficient context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 single parameter 'id' clearly documented as 'ID del include a eliminar'. The description doesn't add any parameter-specific information beyond this, but with high schema coverage and only one parameter, the baseline is strong. The description's mention of 'extra o incluído' loosely aligns with the parameter context, but no additional semantic value is provided.
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 'Eliminar un extra o incluído' (Delete an extra or included) states the action (eliminar/delete) and resource (extra o incluído), which clarifies the tool's purpose. However, it's somewhat vague about what exactly an 'extra o incluído' refers to, and while it distinguishes from siblings like 'delete_activities' or 'delete_hotel' by resource type, it doesn't explicitly differentiate from similar tools like 'delete_include' vs 'reactivate_include' in terms of action specificity.
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 (e.g., needing an existing include), exclusions (e.g., not for deactivating), or comparisons to siblings like 'reactivate_include' or 'list_includes'. Without such context, users must infer usage from the tool name alone, which is insufficient for clear decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action ('eliminar') without behavioral details. It doesn't disclose if deletion is permanent, requires specific permissions, has side effects (e.g., cascading deletions), or returns confirmation. For a destructive operation 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 phrase ('Eliminar un guía') that directly conveys the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero 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?
For a destructive deletion tool with no annotations and no output schema, the description is incomplete. It lacks critical context: permanence of deletion, error conditions, return values, or how it differs from reactivation tools. The schema covers the parameter, but behavioral aspects are underspecified.
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 one parameter 'id' documented as 'ID del guía a eliminar'. The description adds no parameter semantics beyond what the schema provides, but the schema fully covers the single parameter, 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 'Eliminar un guía' clearly states the action (eliminar/delete) and target resource (guía/leader) in Spanish, matching the tool name. It distinguishes from siblings like 'create_leader' and 'update_leader' by specifying deletion, but doesn't clarify what a 'guía' represents beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'reactivate_leader' or other deletion tools (e.g., 'delete_agency'). The description implies it's for removing a leader, but doesn't specify prerequisites, consequences, or when deletion is appropriate versus deactivation.
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 deletes a provider but does not clarify critical aspects: whether this is a permanent or soft delete, if it requires specific permissions, what happens to associated data (e.g., linked services or programs), or if there are confirmation prompts. For a destructive operation 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 ('Eliminar un proveedor') that directly states the tool's purpose without unnecessary words. It is appropriately sized for a simple deletion tool and front-loaded with the essential action. Every part of the sentence earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a deletion tool (a destructive operation) with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., permanence, side effects), usage context, and expected outcomes. While the schema covers the single parameter, the description does not compensate for the missing safety and operational details, making it inadequate for informed 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 the 'id' parameter clearly documented as 'ID del proveedor a eliminar.' The description does not add any meaning beyond this, as it does not mention parameters at all. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter info in the description, which applies here.
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 'Eliminar un proveedor' clearly states the action (delete/eliminar) and the resource (provider/proveedor) in Spanish. It distinguishes this tool from sibling tools like 'create_provider' or 'update_provider' by specifying the deletion operation. However, it lacks specificity about what a 'provider' entails in this context, which slightly reduces clarity compared to a more detailed explanation.
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 does not mention prerequisites (e.g., needing the provider ID), exclusions (e.g., not for deactivated providers), or sibling tools like 'reactivate_provider' or 'delete_program' that might be relevant in different scenarios. Usage is implied only by the verb 'eliminar,' which is insufficient for effective 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 full burden for behavioral disclosure. While 'Eliminar' implies a destructive operation, it doesn't specify whether deletion is permanent or reversible, what permissions are required, or what happens to associated data. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Spanish sentence ('Eliminar un idioma de servicio') that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple deletion operation 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?
For a destructive operation with no annotations and no output schema, the description is insufficient. It doesn't explain what 'eliminar' entails (permanent vs soft delete), what confirmation or side effects exist, or what the tool returns. Given the complexity of deletion in a system with 'reactivate' tools, more context is needed.
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 single parameter 'id' clearly documented in the schema as 'ID del idioma de servicio a eliminar'. The description adds no additional parameter information 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 clearly states the action ('Eliminar' meaning 'Delete') and the resource ('idioma de servicio' meaning 'service language'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'delete_service' or 'reactivate_service_language', which would require more specificity to earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 'reactivate_service_language' (which appears to restore deleted items) or other deletion tools. There's no mention of prerequisites, consequences, or appropriate contexts for deletion versus other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool returns the found agency ('retorna la agencia encontrada'), which is basic output information. However, it doesn't describe error handling (e.g., what happens if no agency matches the name), authentication requirements, rate limits, or whether it's a read-only operation. For a lookup 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that states the action and outcome. It's appropriately sized for a simple lookup tool with one parameter. However, it could be slightly more structured by separating purpose from behavior.
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 lookup tool with no annotations and no output schema, the description is incomplete. It mentions the return value but doesn't describe the response format, error cases, or behavioral constraints. Given the server context with many sibling tools, more guidance on when to use this versus alternatives would be valuable.
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 one parameter 'name' documented as 'Nombre de la agencia'. The description doesn't add any additional parameter semantics beyond what the schema provides (e.g., format expectations, case sensitivity, examples). Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 una agencia por nombre' (Get an agency by name) with the verb 'obtener' and resource 'agencia'. It distinguishes from sibling 'list_agencies' by specifying retrieval by name rather than listing all. However, it doesn't explicitly differentiate from other 'get_by_name' tools like 'get_hotel_by_name' beyond the resource type.
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_agencies' for broader queries or 'create_agency' for adding new agencies. There's no context about prerequisites, error conditions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the action (search by name) and output (list of hotels found), but lacks details on permissions, rate limits, pagination, error handling, or what constitutes a 'found' hotel (e.g., exact match, partial match). For a read operation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of one sentence that states the purpose and output. There is no wasted text, but it could be slightly more structured by separating purpose from output details. It efficiently conveys the core function without 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 complexity (a search tool with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits, output format (e.g., structure of the hotel list), error cases, and differentiation from siblings. For a tool that returns data, more context is needed to guide effective use, especially without annotations or output schema.
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 adds minimal semantic value beyond the input schema. It implies the 'name' parameter is used for searching, but the schema already has 100% coverage with a clear description ('Nombre del hotel'). No additional details on format, constraints, or search behavior (e.g., case sensitivity) are provided. With high schema coverage, the baseline is 3, as the description does not compensate with extra 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: 'Buscar hoteles por su nombre' (Search hotels by their name) and 'retorna la lista de hoteles encontrados' (returns the list of hotels found). It specifies the verb (search/retrieve) and resource (hotels), but does not explicitly differentiate it from sibling tools like 'list_hotels' or other 'get_by_name' tools, which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 does not mention sibling tools such as 'list_hotels' (which might list all hotels without filtering) or other 'get_by_name' tools for different resources, nor does it specify prerequisites or exclusions. Usage is implied by the name and description 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. It states it 'gets' a program, implying a read-only operation, but doesn't disclose behavioral traits like whether it returns full details, error handling for invalid IDs, authentication needs, rate limits, or data format. For a retrieval 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. It's front-loaded with the key action and resource, with no wasted words or redundant information, 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 complexity of a retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what data is returned (e.g., program details, structure), error conditions, or how it fits into the broader context of sibling tools. For a tool in a system with many create/update/delete operations, more guidance on its role is needed.
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 'id' parameter documented as 'ID del programa'. The description adds no additional meaning beyond this, as it only mentions 'por ID' without specifying format, constraints, or examples. With high schema coverage, the baseline is 3, and the description doesn't compensate with extra 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 verb ('Obtiene' - gets) and resource ('un programa de viajes' - a travel program) with the specific identifier ('por ID' - by ID). It distinguishes from siblings like 'get_programs_by_name' or 'get_programs_by_date_range' by specifying ID-based retrieval. However, it doesn't explicitly mention what 'programa de viajes' entails beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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_programs_by_name', 'get_programs_by_date_range', and 'list_providers', the description lacks context on prerequisites (e.g., needing the ID first) or comparisons to other retrieval methods. It implies usage by ID only but doesn't state this explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it retrieves programs but doesn't disclose behavioral traits like whether it's read-only (implied by 'get'), what happens if no programs match, if results are paginated, or if it requires authentication. For a retrieval 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 sentence in Spanish that directly states the tool's purpose without redundancy. It's appropriately sized and front-loaded, with zero waste, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 'programas de viajes' entails, the return format, or error handling. For a retrieval tool with 2 parameters, it should provide more context about behavior and results 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%, with both parameters ('startDate', 'endDate') fully documented in the schema. The description adds no additional meaning beyond implying date-range filtering, 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 clearly states the action ('Obtiene' - gets/retrieves) and resource ('programas de viajes' - travel programs) with a specific scope ('por rango de fechas' - by date range). It distinguishes from siblings like 'get_program' (singular) and 'get_programs_by_name' (by name), though not explicitly. However, it doesn't fully differentiate from potential date-based queries in other tools, keeping it at 4.
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 'get_programs_by_name' or 'get_program'. It lacks context on prerequisites, such as whether date ranges must be valid or programs exist, and doesn't mention exclusions or complementary 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 full burden. It states it's a search operation, implying read-only behavior, but doesn't disclose critical traits like authentication needs, rate limits, pagination, or return format. For a search tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/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. It's front-loaded with the core action and resource, with zero wasted words. Every element earns 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 no annotations, no output schema, and a simple parameter, the description is incomplete. It lacks behavioral context (e.g., search scope, result format) and usage guidelines. While concise, it doesn't provide enough information for the agent to fully understand the tool's operation and constraints.
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 'name' fully documented in the schema. The description adds no additional meaning beyond implying name-based filtering. With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't need to heavily.
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 'Busca programas de viajes por nombre' clearly states the action (busca/search) and resource (programas de viajes/travel programs) with a specific filter (por nombre/by name). It distinguishes from siblings like 'get_program' (singular) and 'get_programs_by_date_range' (different filter), but doesn't explicitly contrast them. The purpose is specific and actionable.
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 'get_program' or 'get_programs_by_date_range'. The description implies usage for name-based searches, but lacks explicit context, prerequisites, or exclusions. Without this, the agent must infer usage from naming patterns alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool searches by name and returns a list, but doesn't describe key behaviors: whether it's a read-only operation (implied by 'get'), what happens if no vehicles are found (e.g., empty list or error), if it supports partial name matching, or any rate limits or authentication requirements. For a tool with no annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of one sentence that directly states the tool's purpose and output. There's no wasted language or redundancy. However, it could be slightly improved by structuring it to highlight key points more clearly, but it's efficient overall.
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 (one parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic action and return value, but lacks details on behavioral traits (e.g., error handling) and usage context compared to siblings. For a simple read operation, it's complete enough to understand what it does, but not rich enough to guide optimal use without additional inference.
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 'name' parameter documented as 'Nombre del vehículo' (name of the vehicle). The description adds no additional meaning beyond this, such as format examples (e.g., case sensitivity) or constraints (e.g., minimum length). With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately defines the parameter without extra help from 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: 'Buscar vehículos por su nombre' (search vehicles by their name) and 'retorna la lista de vehículos encontrados' (returns the list of found vehicles). It specifies the verb (search), resource (vehicles), and action (return list). However, it doesn't explicitly differentiate from sibling tools like 'list_vehicles' or 'get_agency_by_name', which follow similar patterns 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 sibling tools like 'list_vehicles' (which might list all vehicles without filtering) or other 'get_by_name' tools for different resources. There's no context about prerequisites, such as needing a vehicle name to search, or limitations, like partial matches or case sensitivity.
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 a read operation ('obtiene') but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns paginated results, or what format the output takes. 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.
Conciseness4/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. It's appropriately sized for a simple tool with no parameters, though it could be slightly more informative without losing 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 simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It lacks context on output format, behavioral constraints, and differentiation from siblings. For a read-only list tool, it should ideally specify return structure or usage context to be fully helpful.
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 schema fully documents the absence of inputs. The description doesn't need to add parameter semantics, and it correctly implies no filtering parameters by stating 'todos' (all). Baseline is 4 for zero parameters with 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 'Obtiene todos los proveedores disponibles' (Gets all available providers) clearly states the verb ('obtiene') and resource ('proveedores'), but it's vague about scope and doesn't differentiate from sibling tools like 'get_provider_by_name' or 'list_agencies' which serve similar listing functions for other entities. It specifies 'todos' (all) but lacks detail on what 'available' means or if there are filters.
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_provider_by_name' for filtered lookups and other list_* tools for different resources, the description doesn't indicate this is for unfiltered provider listings or suggest any context for choosing it over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a state change (reactivation) but doesn't disclose effects (e.g., whether it restores associated data, requires permissions, or has side effects). For a mutation 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 ('Reactivar un extra o incluído') with zero wasted words. It's 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?
For a mutation tool (reactivation) with no annotations and no output schema, the description is incomplete. It lacks details on behavior, side effects, error conditions, or return values, which are crucial for safe and effective use by an AI agent in this context.
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 input schema has 1 parameter with 100% description coverage ('ID del include a reactivar'), so the schema fully documents the parameter. The description adds no extra parameter details, but with high schema coverage and only one parameter, a baseline of 4 is appropriate as 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reactivar un extra o incluído' clearly states the action (reactivate) and target (an extra or include), which is better than a tautology. However, it's vague about what 'reactivate' entails operationally and doesn't distinguish this tool from sibling reactivation tools like reactivate_agency or reactivate_hotel, missing specific 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., that the include must be deactivated first), exclusions, or refer to sibling tools like delete_include or create_include for context, leaving usage unclear.
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. 'Reactivar' implies a mutation that changes state from inactive to active, but the description doesn't disclose behavioral traits like required permissions, whether it's idempotent, what happens on success/failure, or if it affects related entities. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose 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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks context on behavior, error conditions, or what the tool returns. Given the complexity of state change operations and the absence of structured data, more information is needed for the agent to use this tool 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?
The input schema has 100% coverage with one parameter (id) fully described in Spanish. The description adds no parameter information beyond what the schema provides, 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 'Reactivar un idioma de servicio' clearly states the action (reactivate) and resource (service language) in Spanish, which matches the tool name. It's specific but doesn't distinguish from sibling tools like reactivate_service or reactivate_agency, which follow the same pattern 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?
No guidance is provided on when to use this tool versus alternatives. While the name implies it's for reactivating service languages, there's no mention of prerequisites (e.g., the language must be deactivated first) or when to choose this over creating a new service language with create_service_language.
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 'Actualizar' (update), implying a mutation, but doesn't specify permissions needed, whether updates are reversible, rate limits, or error handling. The description is too brief to cover these critical aspects for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for the complexity, with zero 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?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'update' entails (e.g., partial vs. full updates), success criteria, or return values. Given the complexity of updating multiple activities with nested objects, 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 input schema already documents all parameters thoroughly. The description adds no additional semantic meaning beyond what's in the schema, such as explaining relationships between parameters or usage patterns. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Actualizar' meaning 'Update') and resource ('múltiples actividades asociadas a un programa'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'update_program' or 'update_agency', which could also involve updating related entities, though the focus on 'activities' is clear.
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 'add_activities' or 'delete_activities'. It lacks context about prerequisites (e.g., activities must exist) or scenarios where this tool is appropriate, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Actualizar' implies a mutation operation, the description doesn't specify required permissions, whether changes are reversible, potential side effects, or what the response looks like (e.g., success confirmation or error handling). This leaves significant gaps for a tool that modifies data.
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 ('Actualizar un idioma de servicio'), which directly conveys the core action without unnecessary words. It's 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 complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., permissions, side effects), usage context, and expected outcomes. While the schema covers parameters well, the overall tool understanding remains insufficient for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('id' and 'name') clearly documented in the schema. The description doesn't add any meaning beyond the schema, such as explaining the format of 'id' (e.g., numeric or UUID) or constraints on 'name' (e.g., length or uniqueness). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Actualizar' meaning 'Update') and the resource ('un idioma de servicio' meaning 'a service language'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'create_service_language' or 'delete_service_language', which would require mentioning it modifies existing records rather than creating or deleting them.
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 (e.g., needing an existing service language ID), exclusions (e.g., not for creating new languages), or refer to sibling tools like 'create_service_language' or 'delete_service_language' for different operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it indicates this is a read operation ('Obtiene'), it doesn't address important behavioral aspects like whether this returns all services or is paginated, what format the results come in, or any authentication/rate limiting considerations. This leaves 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, efficient Spanish sentence that gets straight to the point without unnecessary words. It's appropriately sized for a simple list operation with no parameters. The only minor improvement would be front-loading the core purpose more explicitly.
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 tool with no annotations and no output schema, the description is insufficiently complete. It doesn't describe what the return value looks like (list format, fields included), whether results are filtered or paginated, or any error conditions. Given the complexity of the sibling toolset and lack of structured metadata, more behavioral 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 schema fully documents the parameter situation. The description appropriately doesn't waste space discussing non-existent parameters. A baseline of 4 is appropriate since there's no parameter information needed or missing.
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 with a specific verb ('Obtiene' - gets) and resource ('servicios disponibles'), and specifies the context ('para asociar a una actividad en un programa de viajes'). However, it doesn't explicitly distinguish itself from sibling tools like 'get_services_by_name' or 'list_service_languages', which slightly reduces 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 some context about when to use the tool ('para asociar a una actividad en un programa de viajes'), but offers no explicit guidance on when NOT to use it or when to choose alternatives like 'get_services_by_name' for filtered searches. This leaves the agent with incomplete decision-making 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates this is a read operation ('obtiene'), but lacks details on permissions, rate limits, pagination, or return format. For a list tool with zero annotation coverage, this is insufficient to inform the agent about key behavioral traits.
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 that conveys the core purpose without waste. It is appropriately sized for a simple list tool, though it could be slightly more structured (e.g., front-loading key terms).
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 0 parameters, the description is minimal. It states the purpose but lacks details on behavior, return values, or usage context relative to siblings. For a tool in a complex server with many siblings, this leaves significant gaps in helping the agent 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't mention parameters, focusing on the tool's purpose. A baseline of 4 is applied since no parameters exist, and the description doesn't add unnecessary param info.
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 'obtiene' (gets/retrieves) and the resource 'vehículos disponibles' (available vehicles), specifying the purpose as retrieving vehicles for associating with activities in a travel program. However, it doesn't explicitly differentiate from sibling tools like 'get_vehicle_by_name' or 'create_vehicle', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the context 'para asociar a una actividad en un programa de viajes' (for associating with an activity in a travel program), which implies usage when vehicles are needed for activity association. However, it provides no explicit guidance on when to use this tool versus alternatives like 'get_vehicle_by_name' or 'create_vehicle', nor any exclusions or prerequisites.
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 that referenced entities must already exist, which is useful context, but doesn't cover critical aspects like whether this is a write operation (implied by 'Crea'), what happens on success/failure, error conditions, or any rate limits. For a creation tool with zero annotation coverage, this leaves 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point. It's appropriately sized for its purpose, though it could potentially be more structured by separating the core action from the prerequisites.
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 the tool (creating activities with multiple nested objects), no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, error handling, or the full behavioral context needed for a creation operation. The prerequisite note helps but doesn't compensate for the missing information.
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%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Crea' - creates) and resource ('actividades asociadas a un programa' - activities associated with a program), providing a specific purpose. However, it doesn't explicitly differentiate from sibling tools like 'update_activities' or 'daily_activities' beyond the creation aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by stating that services, hotels, guides, vehicles, and extras must already exist, which suggests prerequisites. However, it doesn't explicitly state when to use this tool versus alternatives like 'create_program' or 'update_activities', nor does it mention exclusions or specific 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. It states the tool searches and returns a list, but lacks details on behavioral traits such as whether it's a read-only operation, if it requires authentication, how it handles no matches (e.g., empty list or error), rate limits, or pagination. The description is minimal and does not compensate for the absence of annotations.
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 front-loads the purpose and outcome. It uses no unnecessary 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.
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 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic action and result but lacks completeness in behavioral context, usage guidelines, and output details (e.g., what the returned list contains). For a simple search tool, it meets the minimum viable threshold but has clear 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?
The input schema has 100% description coverage, with the parameter 'name' documented as 'Nombre del servicio' (Name of the service). The description adds no additional meaning beyond this, as it only repeats that it searches by name without specifying format, case-sensitivity, or partial matching. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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: 'Buscar servicios por su nombre' (Search services by their name) and 'retorna la lista de servicios encontrados' (returns the list of services found). It specifies the verb (search) and resource (services), but does not distinguish it from sibling tools like 'list_services' or 'get_programs_by_name', which follow a similar pattern 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 does not mention sibling tools like 'list_services' (which might list all services without filtering) or other 'get_*_by_name' tools for different resources, nor does it specify any prerequisites or exclusions for usage.
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. 'Reactiva' implies a mutation that changes state (likely from inactive to active), but the description doesn't clarify permissions required, side effects (e.g., impact on related data), or what 'reactivation' entails (e.g., restoring access, resetting status). It lacks details on error conditions or response format, leaving behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/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 and key constraint. It's front-loaded with the main action and resource, with no redundant information, making it appropriately sized and easy to parse.
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 (a mutation tool with no annotations and no output schema), the description is incomplete. It lacks details on what 'reactivation' means operationally, expected outcomes, error handling, or how it differs from other passenger-related tools (e.g., delete_passenger, update_passengers). For a tool that likely changes system state, more context is needed 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 input schema has 1 parameter (id) with 0% description coverage, so the schema provides no semantic information. The description adds meaning by specifying that the ID must be known ('se conoce su ID'), which clarifies the parameter's role as a pre-existing identifier. However, it doesn't detail the ID format (e.g., numeric, string pattern) or source, leaving some ambiguity.
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 ('reactiva') and target resource ('un pasajero'), making the purpose understandable. It specifies that the passenger ID must be known, which adds useful context. However, it doesn't explicitly differentiate from sibling reactivate_* tools (like reactivate_agency, reactivate_hotel, etc.), which all follow the same pattern.
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 minimal guidance by stating 'se conoce su ID' (its ID is known), implying the prerequisite of having the passenger ID. However, it offers no explicit guidance on when to use this tool versus alternatives (like update_passengers or create_passengers), nor does it mention any exclusions or specific scenarios for reactivation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly identifies this as a deletion operation, implying destructive behavior. However, it lacks details about permissions needed, whether deletions are permanent or reversible, error handling, or confirmation requirements. The schema description provides a warning about irreversibility, but the main description doesn't expand on this.
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 without unnecessary words. It's appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive deletion tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after deletion, whether there are confirmation steps, what permissions are required, or what the response format might be. Given the complexity and risk of a batch deletion operation, more context is needed.
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 well-documented in the schema itself. The main description doesn't add any additional parameter semantics beyond what's already in the schema descriptions, 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 clearly states the action ('Eliminar' - delete) and the resource ('múltiples actividades asociadas a un programa'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling deletion tools like delete_program or delete_passenger, which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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, constraints, or compare it to other deletion tools in the sibling list, leaving the agent with insufficient context for proper 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 states it 'gets all available agencies' but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires authentication, potential rate limits, pagination behavior, or what 'available' means (e.g., active vs. all). For a list operation with zero annotation coverage, this leaves 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.
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 unnecessary details. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place by contributing to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate as a minimum viable explanation. It covers the basic purpose but lacks details on behavior, output format, or usage context that would be helpful for an AI agent. Without annotations or output schema, more guidance on what 'gets all' returns would improve completeness.
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 (empty schema). The description doesn't need to explain parameters, and it appropriately doesn't mention any. It adds context about the purpose ('para asociar a un programa de viajes') which provides semantic value beyond the schema. Baseline for 0 params is 4, and the description meets this by being relevant without redundancy.
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 'obtiene' (gets) and the resource 'agencias disponibles' (available agencies) with the purpose 'para asociar a un programa de viajes' (to associate with a travel program). It distinguishes from siblings like 'get_agency_by_name' which filters by name, but doesn't explicitly contrast with all list_* siblings. The Spanish language is clear but not perfectly specific about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: it implies usage when needing agencies for travel program association. However, it doesn't specify when to use this versus alternatives like 'get_agency_by_name' for filtered lookup, or 'create_agency' for adding new agencies. No explicit when-not-to-use or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read operation ('Obtiene') but does not disclose behavioral traits such as whether it requires authentication, has rate limits, returns paginated results, or what format the data is in. The description is minimal and misses key operational details needed for safe and effective use.
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 that directly states the tool's purpose without unnecessary words. It is front-loaded with the key action and resource. However, it could be slightly more structured by explicitly mentioning the lack of parameters or output details.
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 parameters and no output schema, the description is incomplete. It does not explain what the return values look like (e.g., list format, data structure), any dependencies, or error conditions. For a retrieval tool in a system with many siblings, more context is needed to ensure proper use without relying on trial and error.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter information, which is appropriate here. A baseline of 4 is applied as it correctly avoids redundancy, though it could briefly note the lack of parameters for clarity.
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 ('Obtiene' - Gets/Retrieves) and the resource ('todos los incluye o extras disponibles' - all available includes or extras), specifying their purpose ('para asociar a una actividad en un programa de viajes' - to associate with an activity in a travel program). It distinguishes from siblings like 'get_includes_by_name' by indicating it retrieves all available includes rather than filtered ones. However, it could be more specific about what 'includes or extras' entail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to associate includes/extras with activities in travel programs, suggesting it's for retrieval purposes. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_includes_by_name' (which filters by name) or 'create_include' (for creation), and does not mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool 'es muy útil' (is very useful) but doesn't disclose critical behavioral traits such as whether it's a read-only operation, what format the summary returns (e.g., aggregated counts, breakdowns), if there are rate limits, or authentication requirements. The description adds minimal value beyond the basic purpose.
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 two sentences, front-loaded with the core purpose and followed by a utility statement. It avoids unnecessary fluff, but the second sentence ('Esta tool es muy útil...') is somewhat redundant and could be more informative about output or usage instead of just stating it's useful.
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 no annotations and no output schema, the description is incomplete for a tool that presumably returns complex aggregated data. It mentions a summary with total passengers and agency distribution, but doesn't detail the return format, potential errors, or data scope limitations. This leaves gaps for an AI agent to understand the full context of 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 definitions for 'startYear' and 'endYear'. The description doesn't add any additional semantic context about these parameters beyond what's in the schema (e.g., it doesn't explain season boundaries or date format nuances), so it meets the baseline of 3 for high schema coverage without extra 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: 'Obtiene un resumen de pasajeros a lo largo de una temporada' (Gets a summary of passengers throughout a season). It specifies the verb (obtiene/gets) and resource (resumen de pasajeros/passenger summary), but doesn't explicitly differentiate it from sibling tools like 'get_passengers_by_email' or 'get_programs_by_date_range' which might also retrieve passenger data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context with 'para obtener el total de pasajeros de una temporada y ver como se distribuye por agencias' (to get the total passengers for a season and see how they are distributed by agencies), suggesting it's for aggregated seasonal analysis. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'get_programs_by_date_range' or 'list_agencies', nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a read operation ('obtiene' - gets), which implies it's non-destructive, but doesn't disclose any behavioral traits like whether it returns all guides or filtered ones, pagination, rate limits, authentication needs, or response format. For a tool with zero annotation coverage, this is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that states the purpose clearly. It's appropriately sized for a simple list tool with no parameters. While it could be slightly more detailed about behavior, every word contributes to understanding the tool's role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It explains what the tool does but lacks behavioral details like return format or any constraints. For a read-only list tool, it meets minimum viability but doesn't provide complete context for optimal agent 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 with 100% schema description coverage (empty schema). The description doesn't need to explain parameters, and it appropriately doesn't mention any. Baseline for 0 parameters is 4, as there's nothing to compensate for and no schema burden.
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: 'Obtiene todos los guías disponibles para asociar a una actividad en un programa de viajes' (Gets all available guides to associate with an activity in a travel program). It specifies the verb ('obtiene' - gets) and resource ('guías' - guides), and distinguishes it from siblings like 'create_leader' or 'get_leader_by_name' by focusing on listing all guides. However, it doesn't explicitly differentiate from other list tools like 'list_agencies' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when you need to associate guides with activities in travel programs. It suggests this is for selection purposes, but doesn't explicitly state when to use this vs. alternatives like 'get_leader_by_name' for specific lookups or 'create_leader' for adding new guides. No explicit exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the action (retrieves all languages) and a constraint on usage (only for associating with services), but lacks behavioral details such as whether this is a read-only operation, potential rate limits, authentication requirements, response format, or pagination behavior. For a tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences in Spanish that efficiently convey the tool's purpose and a key constraint. It's front-loaded with the main action and avoids unnecessary elaboration. However, the translation aspect might add minor complexity for non-Spanish-speaking agents, though the content itself is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description provides basic purpose and usage constraints but lacks details on behavioral aspects like response format, error handling, or operational limits. For a simple list operation, this is minimally adequate but leaves room for improvement in completeness, especially regarding what the output looks like.
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 no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and constraints. This meets the baseline expectation for a parameterless tool.
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 ('Obtiene todos los idiomas' - Gets all languages) and the resource (idiomas/languages), specifying they are for associating with activities in travel programs. It distinguishes from siblings like 'get_service_language_by_name' by indicating it retrieves all languages rather than a specific one. However, it doesn't explicitly differentiate from other list tools like 'list_services' or 'list_agencies' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('para asociar a una actividad en un programa de viajes' - for associating with an activity in a travel program) and provides a constraint ('Estos idiomas solo se pueden usar para asociar a un servicio' - These languages can only be used to associate with a service). However, it doesn't explicitly state when to use this tool versus alternatives like 'get_service_language_by_name' or other list tools, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes a read operation ('obtiene') but doesn't disclose important behavioral traits: whether this returns all hotels or paginated results, what 'disponibles' means operationally (e.g., active vs inactive), authentication requirements, rate limits, or response format. For a list operation with zero annotation coverage, this leaves 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.
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 and context without unnecessary words. It's appropriately sized for a simple list tool and front-loads the essential information ('Obtiene todos los hoteles disponibles'). Every part of the sentence contributes meaning.
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 zero-parameter list tool with no output schema, the description provides adequate basic context about what it retrieves and why. However, without annotations covering behavioral aspects and no output schema to describe return values, the description should ideally mention what information is returned about hotels and any limitations. It's minimally viable but leaves gaps in understanding the full operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage (empty schema). The description appropriately doesn't discuss parameters since none exist. It earns a baseline 4 because when there are no parameters, the description needn't compensate for schema gaps, and it correctly focuses on the tool's purpose rather than parameter details.
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 ('obtiene' - gets/retrieves) and resource ('hoteles disponibles' - available hotels) with specific context ('para asociar a una actividad en un programa de viajes' - to associate with an activity in a travel program). It distinguishes from obvious siblings like 'create_hotel' or 'get_hotel_by_name' by indicating it retrieves all available hotels rather than creating or filtering by name. However, it doesn't explicitly differentiate from other list tools like 'list_agencies' or 'list_services' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('para asociar a una actividad en un programa de viajes') suggesting this tool is used when needing hotels to associate with travel activities. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'get_hotel_by_name' for specific lookups or 'create_hotel' for adding new hotels. No exclusion criteria or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses behavioral traits: it's a mutation tool (implied by 'Crea'), requires user input for missing parameters (dates, agency ID), and suggests a pre-check for existing programs. However, it lacks details on permissions, error handling, or what happens on success, leaving gaps 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized (three sentences) but not optimally front-loaded. The first sentence states the purpose, but the second and third sentences mix usage guidelines and behavioral instructions, making it slightly cluttered. Every sentence adds value, but the structure could be more streamlined for clarity.
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 complexity (mutation tool with 4 required parameters), no annotations, and no output schema, the description is incomplete. It covers purpose and some behavioral aspects but misses details like response format, error cases, or side effects. For a creation tool with full parameter coverage but no output info, it's adequate but has clear 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%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain parameter interactions or formats). Baseline is 3 when schema does the heavy lifting, and the description doesn't compensate with extra 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 verb ('Crea') and resource ('un nuevo programa de viajes'), making the purpose specific and understandable. It distinguishes from siblings like 'update_program' or 'delete_program' by focusing on creation. However, it doesn't explicitly differentiate from other creation tools (e.g., 'create_agency'), 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: before creating, ask the user if they want to search for existing programs first. It also specifies prerequisites (dates and agency ID must be provided by the user). However, it doesn't explicitly mention alternatives like 'get_programs_by_name' for checking existence or when not to use this tool, which keeps it from a score of 5.
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 mentions a prerequisite check (searching for existing agencies), which adds some context beyond basic functionality. However, it lacks details on critical behavioral traits such as whether this is a mutating operation (implied by 'create'), what permissions are required, whether the creation is idempotent, or what happens on success/failure. For a creation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: it states the main purpose in the first phrase ('Crear una agencia'), followed by a usage guideline. Both sentences are relevant and earn their place, with no redundant information. However, it could be slightly more structured (e.g., separating purpose from guidelines with punctuation or formatting).
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 complexity (a creation tool with 3 required parameters, including a nested object, and no output schema or annotations), the description is partially complete. It covers purpose and usage guidelines well, but lacks details on behavioral aspects (e.g., mutation effects, error handling) and parameter semantics. Without annotations or output schema, the description should do more to explain what happens after creation or potential side effects.
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 67% (2 out of 3 parameters have descriptions in the schema: 'name' and 'description', but 'provider' lacks a description for its nested properties beyond IDs and names). The tool description adds no information about parameters beyond what the schema provides—it doesn't explain what 'name', 'description', or 'provider' mean in context, their formats, or constraints. With moderate schema coverage, the baseline is 3, as the description doesn't compensate for gaps.
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: 'Crear una agencia' (Create an agency). It specifies the action (create) and resource (agency), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'create_provider' or 'create_program', which are similar creation operations 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Antes de crear una nueva agencia se debe preguntar al si quiere que primero se busque la agencia a ver si existe' (Before creating a new agency, you should ask if they want to first search for the agency to see if it exists). This indicates a prerequisite check and suggests an alternative approach (searching first), which helps the agent decide when to invoke this tool versus alternatives like 'get_agency_by_name' or 'list_agencies'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the destructive nature ('eliminar') and a key consequence ('no se puede usar para asociarle programas'), which is valuable behavioral context. However, it doesn't mention permissions needed, whether deletion is reversible, or what happens to associated data beyond programs.
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 two concise sentences that efficiently convey the core action and a critical consequence. It's appropriately sized for a destructive operation, though it could be slightly more structured by explicitly separating action from implications.
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 destructive tool with no annotations and no output schema, the description provides basic but incomplete context. It covers the irreversible consequence regarding programs but lacks details about permissions, error conditions, return values, or broader system impacts, leaving gaps for agent understanding.
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 single parameter 'id' well-documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('eliminar' - delete) and resource ('una agencia'), making the purpose specific and unambiguous. It distinguishes this tool from siblings like 'create_agency', 'update_agency', 'reactivate_agency', and 'list_agencies' by focusing on permanent removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating the agency cannot be used for programs after deletion, suggesting this is for permanent removal when an agency is no longer needed. However, it doesn't explicitly state when to use this versus alternatives like 'reactivate_agency' or provide clear exclusions.
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:

[![lumbretravel-mcp MCP server](https://glama.ai/mcp/servers/lumile/lumbretravel-mcp/badges/card.svg)](https://glama.ai/mcp/servers/lumile/lumbretravel-mcp)

Score Badge

Copy to your README.md:

[![lumbretravel-mcp MCP server](https://glama.ai/mcp/servers/lumile/lumbretravel-mcp/badges/score.svg)](https://glama.ai/mcp/servers/lumile/lumbretravel-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lumile/lumbretravel-mcp'

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