Mews MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific resources and actions, such as addCustomer vs. updateCustomers or getAllReservations vs. cancelReservations. The descriptions reinforce these distinctions, with no ambiguous overlaps that would cause agent misselection.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern throughout, using verbs like add, get, update, delete, export, and merge paired with specific nouns (e.g., addAccountingItems, getAllCustomers, updateReservations). There are no deviations in naming conventions, making the set highly predictable.
Tool Count2/5
With 53 tools, the count is excessive for typical MCP server purposes, making it heavy and potentially overwhelming for agents. While the domain is broad (hotel/enterprise management), many tools could be consolidated or scoped down to improve usability without losing functionality.
Completeness5/5
The tool surface provides comprehensive CRUD/lifecycle coverage across all major domains (customers, reservations, loyalty, accounting, etc.), including add, get, update, delete, and export operations. There are no obvious gaps, ensuring agents can handle full workflows without dead ends.
Average 3/5 across 53 of 53 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It states the action ('cancels') but doesn't disclose whether this is reversible, what permissions are required, whether notifications are sent, what happens to associated data, or any rate limits. For a destructive 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 extremely concise at just three words, which is appropriately sized for such a simple statement. However, it's arguably too brief given the tool's complexity, and it doesn't front-load critical information about the tool's destructive nature.
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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'canceling' entails operationally, what the expected outcome is, whether there are side effects, or what happens if cancellation fails. The agent would need to guess about important behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 4 parameters. The description adds no additional meaning about parameters beyond what's in the schema. The baseline score of 3 is appropriate when the schema does all the parameter 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 'Cancels specified reservations' clearly states the verb ('cancels') and resource ('reservations'), but it's vague about scope and doesn't differentiate from potential alternatives. It doesn't specify whether this cancels individual reservations, bulk reservations, or what 'specified' means beyond the parameter schema.
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 sibling tools include 'updateReservations' which might handle status changes, the description doesn't mention this or provide any context about prerequisites, timing, or when not to use this tool.
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 'Deletes' implies a destructive mutation, it fails to specify critical details such as whether deletion is permanent, requires specific permissions, has rate limits, or what happens to associated data. This is a significant gap for a destructive 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 extremely concise with just two words, which is efficient and front-loaded. However, this brevity borders on under-specification, as it lacks necessary details for a destructive operation. While it earns points for zero waste, it could benefit from slightly more elaboration to be fully helpful.
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 destructive deletion tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects (e.g., irreversibility), error handling, or return values, leaving significant gaps. For such a high-stakes operation, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 'LoyaltyMembershipIds' clearly documented as an array of unique identifiers with a max of 1000 items. The description adds no additional meaning beyond what the schema provides (e.g., no examples or edge cases). Given the high coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Deletes loyalty memberships' clearly states the action (delete) and resource (loyalty memberships), which is specific enough to understand the basic function. However, it doesn't differentiate from sibling tools like 'deleteCompanies' or 'deleteCustomers' beyond the resource name, and it lacks detail about scope (e.g., batch deletion vs. single). This makes it adequate but vague in distinguishing its specific role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't mention prerequisites (e.g., needing loyalty membership IDs from 'getAllLoyaltyMemberships'), exclusions (e.g., irreversible deletion), or comparisons with related tools like 'updateLoyaltyMemberships'. This absence of context leaves the agent without clear usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether this is a read-only operation, potential performance impacts of returning 'all' rates, pagination behavior, authentication requirements, or rate limits. The description is minimal and lacks crucial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 arguably too concise given the tool's complexity and lack of annotations, potentially under-specifying rather than being optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'all rates' means in practice, doesn't mention the filtering capability shown in the schema, and provides no information about return format, data volume, or error conditions. 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description adds no parameter semantics beyond what's in the schema - it doesn't explain how filtering works, the relationship between parameters, or provide usage examples. Baseline 3 is appropriate when schema does all 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 'Returns all rates (pricing) of the enterprise' clearly states the verb ('returns') and resource ('rates/pricing'), but it's vague about scope. It doesn't specify whether this returns ALL rates unconditionally or if filtering is required, and doesn't differentiate from sibling tools like 'getRatePricing'.
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 'getRatePricing'. The description implies it returns 'all rates' but doesn't clarify if this should be used for bulk retrieval versus filtered queries, or 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 a read operation ('returns'), which implies non-destructive behavior, but doesn't disclose rate limits, authentication needs, or return format details. The description is minimal and misses key behavioral traits like pagination or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose. However, it could be more structured by including key details like filtering options, but it's appropriately sized 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 and no output schema, the description is incomplete. It doesn't explain what 'space categories' are, how results are formatted, or any constraints like the 1000-item max. For a tool with 3 parameters and complex filtering, 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?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds no meaning beyond the schema—it doesn't explain parameter interactions or provide examples. With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't detract either.
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 'Returns all space categories of a service' states the action (returns) and resource (space categories), but it's vague about scope—'all' could imply unfiltered, yet the schema shows filtering parameters. It doesn't differentiate from sibling tools like getAllSpaces or getAllServices, which handle related 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 on when to use this tool versus alternatives is provided. The description lacks context on prerequisites, such as needing service IDs, or exclusions, like not using it for individual category lookups. It implies a general retrieval without specifying 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. It states 'merges' which implies a destructive or transformative operation, but it doesn't disclose critical behaviors such as whether data from the source customer is preserved, if the merge is irreversible, what permissions are required, or potential side effects like cascading updates to related records.
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, direct sentence with no wasted words, making it easy to parse. However, it lacks front-loaded critical details like the irreversible nature of merging, which could improve structure by prioritizing key behavioral information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a merge operation (likely destructive), no annotations, and no output schema, the description is insufficient. It doesn't cover behavioral aspects, usage context, or result expectations, leaving significant gaps for an AI agent to understand and invoke the tool 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%, with clear descriptions for 'SourceCustomerId' and 'TargetCustomerId'. The description adds no additional meaning beyond the schema, such as explaining the merge direction or outcome. With high schema coverage, the baseline score of 3 is appropriate as the schema handles parameter documentation adequately.
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 'Merges two customers together' clearly states the action (merges) and resource (customers), but it's vague about what merging entails (e.g., combining records, transferring data). It doesn't differentiate from siblings like 'updateCustomers' or 'deleteCustomers', which could involve customer modifications.
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 specify if this should be used instead of deleting a customer or updating customer details, nor does it mention prerequisites like customer existence or data retention policies.
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 'Updates company information', implying a mutation operation, but fails to mention permissions, side effects, error handling, or response format. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded and to the point, though it could be more informative by including key details like required parameters or scope.
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 information on behavioral traits, error conditions, and what the tool returns, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with detailed parameter descriptions in the input schema. The description adds no additional meaning beyond the schema, such as explaining the structure of 'CompanyUpdates' or constraints on field updates. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Updates company information' clearly states the verb ('Updates') and resource ('company information'), which is adequate. However, it lacks specificity about what fields can be updated and doesn't differentiate from sibling tools like 'updateCustomers' or 'updateReservations', making it somewhat vague.
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 is no mention of prerequisites, such as needing an existing company ID, or comparisons to tools like 'addCompany' or 'deleteCompanies', leaving the agent without contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action ('add new addresses'). It doesn't disclose behavioral traits such as whether this is a mutation requiring permissions, if it's idempotent, what happens on duplicate addresses, error handling, or rate limits. For a write operation, 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, direct sentence with no wasted words. It's front-loaded and efficiently conveys the core purpose without unnecessary elaboration, 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 write operation with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks details on behavior, error cases, return values, and how it fits with sibling tools, making it inadequate for safe and effective use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information beyond the tool name. The schema fully documents the 'Addresses' array and its nested properties with descriptions, so the baseline is 3. The description doesn't enhance understanding of parameters like required fields or data formats.
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 'Add new addresses to accounts' clearly states the action (add) and target (addresses to accounts), but it's vague about scope and doesn't distinguish from sibling tools like 'getAllAddresses' or 'addCustomer'. It specifies what it does but lacks precision about how it differs from related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'addCustomer' (which might include addresses) or 'getAllAddresses' (for reading). The description doesn't mention prerequisites, constraints, or typical use cases, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action is deletion, implying a destructive mutation, but lacks details on permissions, reversibility, effects on related data (e.g., loyalty memberships), or rate limits. This is inadequate for a destructive 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, direct sentence with no wasted words. It is appropriately sized and front-loaded, efficiently conveying the core action 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 destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context like success/error responses, side effects, or safety warnings, leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'LoyaltyProgramIds' documented as an array of unique identifiers with a max of 1000 items. The description adds no additional meaning beyond the schema, such as format examples or deletion behavior specifics, so it meets the baseline for high 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 'Deletes loyalty programs' clearly states the action (delete) and resource (loyalty programs), providing a basic purpose. However, it lacks specificity about scope or constraints and doesn't differentiate from sibling deletion tools like deleteCompanies or deleteLoyaltyTiers, making it 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. The description doesn't mention prerequisites, exclusions, or related tools (e.g., updateLoyaltyPrograms for modifications), leaving usage entirely implicit.
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. 'Updates' implies a mutation operation, but it doesn't specify permissions required, whether 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. 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 insufficient. It doesn't explain what happens when properties are updated, potential side effects, or return values. Given the complexity of updating multiple reservations with various properties, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 fully documents the 'ReservationUpdates' array and its nested properties. The description adds no additional parameter information beyond what's in the schema, resulting in the baseline score of 3 for adequate but no extra value.
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 'Updates reservation properties' clearly states the verb ('Updates') and resource ('reservation properties'), making the purpose understandable. However, it's somewhat vague about what specific properties can be updated and doesn't distinguish this tool from sibling tools like 'updateCompanies' or 'updateCustomers' 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 prerequisites, constraints, or how it differs from related tools like 'addReservation' or 'cancelReservations', 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 full burden. It states it 'Adds new accounting items', implying a write/mutation operation, but doesn't disclose behavioral traits like required permissions, whether it's idempotent, error handling, or side effects (e.g., bill recalculation). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the core action, zero waste. Efficiently conveys purpose 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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks critical context: what happens after adding items (e.g., bill update, notifications), error conditions, or response format. Siblings include related tools like 'addPayment', but no guidance on differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters documented in the schema. The description adds minimal value beyond the schema, only implying that items are added to 'customer bills' (context not in schema). It doesn't explain parameter interactions or provide examples, so baseline 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 action ('Adds') and resource ('accounting items to customer bills'), with examples of item types ('charges, payments, etc.'). It distinguishes from siblings like 'addPayment' by specifying it's for accounting items on bills, not standalone payments. However, it doesn't explicitly contrast with 'exportAccountingItems' or 'getAllAccountingItems'.
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 'addPayment' or 'chargeCreditCard'. The description implies it's for adding accounting items to bills, but doesn't specify prerequisites (e.g., existing customer/bill) or exclusions (e.g., not for updating existing items).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention permissions needed, whether notes are editable/deletable, rate limits, or what happens on success/failure. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action. It avoids redundancy and wastes no words, though it could be slightly more structured by separating purpose from constraints.
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 doesn't cover behavioral aspects like side effects, error handling, or return values, leaving critical gaps for agent understanding despite the clear 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 the single parameter 'AccountNotes' and its nested properties. The description adds no additional meaning beyond implying notes are created and assigned, matching the baseline when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Adds new account notes') and target resource ('to the system and assigns them to specified accounts'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'addTask' or 'addPayment' beyond the resource type, missing explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 lacks context about prerequisites, exclusions, or comparisons to similar tools like 'addTask' or 'updateCompanies', leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Adds' implies a write/mutation operation, the description doesn't address critical behavioral aspects: required permissions, whether the operation is idempotent, what happens on duplicate entries, error conditions, or what the response contains. For a creation tool with zero annotation coverage, this represents significant gaps in behavioral understanding.
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 three-word phrase that communicates the core purpose without any wasted words. It's appropriately sized for a simple creation operation and front-loads the essential information immediately.
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 write/mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address what happens after creation, what identifiers are returned, error handling, or how this operation relates to the broader system context. For a company creation tool in what appears to be a CRM/reservation system, more contextual information would be 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?
The schema description coverage is 100%, with all 7 parameters well-documented in the schema itself. The description adds no parameter information beyond what's already in the structured schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no parameter information 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 clearly states the verb ('Adds') and resource ('a new company'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar sibling tools like 'addCustomer' or 'addAccountingItems' - it simply describes what it does without explaining how it differs from other 'add' operations in the system.
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 about when to use this tool versus alternatives. With sibling tools like 'addCustomer' and 'updateCompanies' available, there's no indication of when company creation is appropriate versus customer creation or company updates. No prerequisites, constraints, or relationship to other operations 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?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create a new customer' implies a write operation but doesn't specify permissions required, whether this is idempotent, what happens on duplicate entries, or what the response contains. For a mutation tool with 15 parameters and no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single three-word phrase that communicates the core purpose efficiently. There's zero wasted language, and the information is front-loaded with no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 15 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after creation, what validation occurs, what errors might be returned, or how this tool relates to other customer management operations like 'updateCustomers' or 'deleteCustomers'.
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 all 15 parameters well-documented in the schema itself. The description adds no parameter information beyond what's already in the schema. According to guidelines, 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 ('Create') and resource ('a new customer'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'addCompany' or 'addLoyaltyMemberships' which follow similar patterns, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when to choose this over similar tools like 'addCompany', or any contextual constraints. It simply states what the tool does without 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Adds' implies a write operation, the description doesn't cover critical aspects like required permissions, whether this is idempotent, rate limits, error handling, or what happens on success (e.g., returns created IDs). This leaves significant gaps for an agent to understand how to use the tool safely and effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's 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 the complexity of adding multiple loyalty memberships with nested objects, no annotations, and no output schema, the description is insufficient. It doesn't address behavioral traits, error conditions, or what the tool returns, leaving the agent with incomplete context for a write operation that could have significant 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 100%, so the schema fully documents both parameters (ChainId and LoyaltyMemberships array). The description adds no additional parameter semantics beyond what's in the schema, such as explaining relationships between fields or usage examples. This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Adds') and resource ('new loyalty memberships to the system'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'updateLoyaltyMemberships' or 'deleteLoyaltyMemberships', but the verb 'Adds' implies creation rather than modification or removal.
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 'updateLoyaltyMemberships' or 'deleteLoyaltyMemberships'. It also doesn't mention prerequisites, such as needing existing accounts or loyalty programs, which are implied by the required parameters but not stated explicitly in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Adds' implies a write/mutation operation, but the description doesn't mention authentication requirements, rate limits, whether duplicates are allowed, what happens on failure, or the response format. 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 sentence with zero wasted words. It's appropriately sized for a tool with good schema documentation and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'adding' entails operationally, what validation occurs, whether there are side effects, or what the response contains. The agent lacks crucial context for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (ChainId and LoyaltyPrograms array). The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score 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 ('Adds') and resource ('new loyalty programs'), making the purpose immediately understandable. It distinguishes from deletion/update siblings but doesn't explicitly differentiate from other 'add' tools like addLoyaltyMemberships or addLoyaltyTiers, which would require more specific scope definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like updateLoyaltyPrograms or getAllLoyaltyPrograms. The description doesn't mention prerequisites, constraints, or typical use cases, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Adds new loyalty tiers' implies a write operation, it lacks crucial behavioral details: what permissions are required, whether this is idempotent, what happens if tiers conflict, what the response looks like, or any rate limits. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a tool with good schema documentation and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'success' looks like, what gets returned, error conditions, or behavioral constraints. The schema covers parameter details well, but the overall tool behavior remains opaque to an AI agent trying 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 schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, but with complete schema coverage and only 2 parameters, a baseline of 3 is appropriate. The description's clarity about the tool's purpose slightly enhances understanding of how parameters relate to that purpose.
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 'Adds new loyalty tiers to the system' clearly states the action (adds) and resource (loyalty tiers), making the purpose understandable. However, it lacks specificity about what 'loyalty tiers' are in this context and doesn't distinguish this tool from sibling tools like 'addLoyaltyPrograms' or 'addLoyaltyMemberships' beyond the resource 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?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools related to loyalty systems (addLoyaltyPrograms, addLoyaltyMemberships, updateLoyaltyTiers, deleteLoyaltyTiers), but the description offers no context about when this specific tool is appropriate versus those others.
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 'Adds' implies a write/mutation operation, it doesn't specify permissions required, whether the action is reversible, rate limits, error conditions, or what happens to the bill balance. For a payment 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.
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 with no wasted words. It's appropriately sized for a tool with good schema coverage, though it could potentially benefit from a second sentence about behavioral aspects 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?
For a payment creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, side effects, or how it differs from similar tools. The combination of mutation behavior, financial implications, and lack of structured metadata requires more comprehensive 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%, so the schema already documents all 6 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters, format expectations beyond schema, or usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Adds a new payment') and target resource ('to a customer's bill'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'chargeCreditCard' or 'getAllPayments', which reduces clarity about when this specific tool should be used versus alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'chargeCreditCard' or 'getAllPayments', nor does it mention prerequisites, exclusions, or specific contexts. It simply states what the tool does without helping the agent choose between available options.
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 'Adds a new reservation' implies a write operation, the description doesn't address critical behavioral aspects: whether this requires specific permissions, if it's idempotent, what happens on conflicts (e.g., overlapping dates), error conditions, or the response format. For a mutation tool with 11 parameters and no annotations, 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 with zero wasted words. It's front-loaded with the core action ('Adds a new reservation') and avoids redundancy. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, mutation operation, no output schema, and no annotations), the description is inadequate. It doesn't explain the tool's behavior, error handling, or return values, leaving the agent to guess. For a reservation creation tool in a system with many sibling tools, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 11 parameters documented in the input schema. The description adds minimal value beyond the schema by vaguely referring to 'specified details' without explaining parameter relationships or business logic (e.g., how CustomerId relates to ServiceId). This meets the baseline 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Adds a new reservation') and specifies the scope ('with the specified details'), which is a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling tools like 'updateReservations' or 'cancelReservations', which would require mentioning it's specifically for creation rather than modification or cancellation.
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's no mention of prerequisites (e.g., existing customer/service), exclusions (e.g., not for modifying existing reservations), or explicit alternatives like 'updateReservations' for changes. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'adds a new task' but doesn't disclose behavioral traits like required permissions, whether tasks are editable after creation, default values beyond State, error conditions, or what happens on success (e.g., returns a task ID). This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Adds a new task') and includes a key optional feature ('optionally to a specified department'). There is no wasted verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover success responses, error handling, authentication needs, or system constraints. Given the complexity of adding tasks in an enterprise context, more behavioral and contextual information 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%, so the schema already documents all 7 parameters thoroughly. The description adds minimal value beyond implying optional department assignment, but doesn't provide additional context like parameter interactions or examples. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Adds') and resource ('new task to the enterprise'), making the purpose understandable. It distinguishes from siblings by focusing on tasks rather than other entities like companies or reservations, though it doesn't explicitly contrast with 'getAllTasks' or other task-related tools.
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 'getAllTasks' or 'update' operations. It mentions optional department assignment but doesn't specify prerequisites, dependencies, or contextual triggers for task creation.
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 'Adds new vouchers' which implies a write operation, but fails to mention critical details like required permissions, whether it's idempotent, error handling, or rate limits. 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 that front-loads the core action and resource, with no wasted words. It's appropriately sized for its purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a write operation with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral aspects like side effects, response format, or error conditions, leaving the agent with incomplete 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 schema description coverage is 100%, so the schema fully documents the single parameter 'Vouchers' and its nested properties. The description adds no additional meaning beyond implying bulk addition ('vouchers' plural), which aligns with the schema but doesn't provide extra semantic context. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Adds') and resource ('new vouchers') with clarifying examples ('discount codes, gift certificates'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'addPayment' or 'addLoyaltyMemberships' beyond the resource type, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as whether it's for bulk creation or single entries, or any prerequisites like authentication. It lacks explicit context or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('charges a credit card') but doesn't cover critical traits: whether this is a destructive/mutative operation, authentication needs, error handling, rate limits, or what happens on failure (e.g., if the charge fails). For a financial transaction 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 that front-loads the core action and outcome. There's no wasted wording, and it directly communicates the tool's function without unnecessary 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 complexity of a financial transaction tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits, error handling, return values, and usage context. While the schema covers parameters well, the overall context for safe and effective use is insufficient.
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. The description adds no additional meaning beyond what the schema provides—it doesn't explain parameter relationships, constraints, or usage examples. With high schema coverage, the baseline is 3, 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.
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: 'Charges a credit card and adds the resulting payment to a customer bill.' It specifies the verb ('charges') and resource ('credit card'), and mentions the outcome ('adds...to a customer bill'). However, it doesn't differentiate from sibling tools like 'addPayment' or other payment-related tools, which prevents a score of 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 (e.g., customer or bill existence), exclusions, or compare it to sibling tools like 'addPayment'. Without such context, an agent lacks clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action ('deletes') without disclosing critical behavioral traits. It doesn't mention whether deletion is permanent/reversible, requires specific permissions, has side effects on related data, or provides confirmation/error responses. For a destructive operation, 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?
Extremely concise with just three words, front-loaded with the core action. Every word earns its place by specifying the operation and target, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 address behavioral risks, return values, error conditions, or usage context. Given the complexity of deletion operations and lack of structured safety hints, more guidance 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?
Schema description coverage is 100% with the parameter CompanyIds fully documented in the schema. The description doesn't add parameter details beyond implying deletion targets, but with zero parameters needing semantic clarification, a baseline of 4 is appropriate as the schema handles all parameter documentation.
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 'Deletes specified companies' clearly states the verb (deletes) and resource (companies), but it's vague about scope and doesn't distinguish from sibling tools like deleteCustomers or deleteLoyaltyMemberships. It specifies 'companies' but doesn't clarify if this means all company data or just specific records.
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 updateCompanies or getAllCompanies. The description doesn't mention prerequisites, consequences, or appropriate contexts for deletion versus other operations on companies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Deletes' implies a destructive mutation, but the description doesn't specify whether deletions are permanent, reversible, require specific permissions, have rate limits, or what happens to associated data (e.g., reservations, payments). For a destructive tool with zero annotation coverage, this is a significant gap in safety and operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Deletes specified customers' is front-loaded and directly conveys the core action. Every word earns its place, 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 (destructive deletion), lack of annotations, and no output schema, the description is incomplete. It doesn't address critical aspects like return values, error conditions, side effects, or safety warnings. For a high-stakes operation like customer deletion, more context is needed to ensure safe and correct usage by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'CustomerIds' clearly documented as 'Array of customer IDs to delete' with a maxItems constraint. The description adds no additional parameter semantics beyond what the schema provides, such as ID format examples or deletion behavior per ID. 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 'Deletes specified customers' clearly states the action (deletes) and resource (customers), making the purpose immediately understandable. It distinguishes from sibling tools like 'deleteCompanies' or 'deleteLoyaltyMemberships' by specifying the customer resource. However, it doesn't specify scope or constraints beyond 'specified', which keeps it from being fully specific.
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., customer must exist), exclusions (e.g., cannot delete customers with active reservations), or sibling tools like 'mergeCustomers' that might be alternatives. This leaves the agent with insufficient 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('deletes') but fails to mention critical details such as whether deletion is permanent, requires specific permissions, has side effects (e.g., on associated memberships), or includes confirmation steps. For a destructive tool, this omission is significant and leaves the agent under-informed.
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 just two words, 'Deletes loyalty tiers', which is front-loaded and wastes no space. It directly conveys the core action without unnecessary elaboration, making it efficient 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 destructive nature, lack of annotations, and no output schema, the description is incomplete. It fails to address key contextual aspects such as the impact of deletion, error handling, or return values, which are essential for safe and effective use. The high schema coverage does not compensate for these behavioral and usage 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 100% description coverage, with the parameter 'LoyaltyTierIds' well-documented as an array of unique identifiers with a max of 1000 items. The description does not add any parameter details beyond the schema, but since schema coverage is high and there is only one parameter, a baseline of 3 is appropriate. The score is raised to 4 because the description implicitly confirms the tool's focus on loyalty tiers, aligning with the parameter's purpose, though it does not enhance semantic understanding.
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 'Deletes loyalty tiers' clearly states the verb (deletes) and resource (loyalty tiers), which is better than a tautology. However, it lacks specificity about scope (e.g., bulk deletion) and does not distinguish it from sibling tools like 'deleteLoyaltyPrograms' or 'deleteLoyaltyMemberships', leaving room for confusion about what exactly is being deleted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple deletion tools (e.g., deleteCompanies, deleteCustomers) and related loyalty tools (e.g., updateLoyaltyTiers, getAllLoyaltyTiers), but no indication of prerequisites, consequences, or appropriate contexts for deletion, which is critical for a destructive operation.
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 export functionality but lacks critical behavioral details: whether this is a read-only operation, if it generates downloadable files, has rate limits, requires specific permissions, or what the output looks like (e.g., file download vs. inline data). The description is too vague for a tool with potential side effects like file generation.
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 front-loads the core purpose. However, it could be more structured by separating purpose from key constraints, and it omits necessary behavioral details that would require additional sentences.
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 6-parameter export tool with no annotations and no output schema, the description is inadequate. It doesn't address what the export produces (e.g., file, data stream), error conditions, or how results are delivered. Given the complexity and lack of structured metadata, more descriptive context is needed for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing detailed parameter documentation. The description adds marginal value by implying date range filtering ('period') and format specification, but doesn't explain parameter interactions (e.g., if AccountingItemIds overrides date range) or provide usage examples beyond what the schema already covers.
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 ('Exports') and resource ('accounting items') with examples of what items are included ('charges, payments, etc.'). It distinguishes from sibling tools like 'getAllAccountingItems' by specifying export functionality rather than retrieval. However, it doesn't explicitly differentiate from 'exportReservations' 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 minimal guidance on when to use this tool, mentioning only the 'specified format and period' without clarifying when to choose this over 'getAllAccountingItems' for listing items or 'exportReservations' for other data exports. No alternatives, prerequisites, or exclusions are 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the export action but doesn't mention whether this is a read-only operation, if it requires specific permissions, potential rate limits, or what the output entails (e.g., file generation, data format). This is a significant gap for a tool with mutation implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function, making it appropriately 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 lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like safety, permissions, or output details, which are crucial for an export tool. The high schema coverage helps with parameters, but overall context is insufficient for confident tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents all six parameters. The description adds minimal value by mentioning 'format and period', which aligns with the 'Format', 'StartUtc', and 'EndUtc' parameters but doesn't provide additional context beyond what's in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Exports') and resource ('reservations'), specifying the format and period parameters. It distinguishes from sibling tools like 'getAllReservations' by emphasizing export functionality rather than retrieval, though it doesn't explicitly contrast with 'exportAccountingItems'.
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 'getAllReservations' or 'exportAccountingItems'. The description mentions format and period but doesn't specify use cases, prerequisites, or exclusions, leaving the agent to infer usage from 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 but lacks behavioral details. It doesn't disclose if this is a read-only operation, potential rate limits, authentication needs, or what 'within the chain' entails. The mention of 'Returns all' implies a retrieval, but no further context is given.
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, clear sentence that efficiently states the tool's purpose without unnecessary words. It's front-loaded with the core action, though it could be slightly more structured by explicitly mentioning filtering or scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, nested objects, no output schema) and lack of annotations, the description is minimally adequate. It covers the basic purpose but misses behavioral transparency, usage guidelines, and output details, leaving 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?
The input schema has 100% description coverage, so parameters are well-documented structurally. The description adds no additional semantic context beyond implying filtering by accounts, which is already covered in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Returns') and resource ('all the account notes associated with the specified accounts within the chain'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'getAllAccountingItems' or 'getAllAddresses' beyond the resource type, missing specific sibling comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for 'within the chain', or compare with other note-related tools (e.g., 'addAccountNotes'), leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'returns all bills by filter parameters,' implying a read-only operation, but doesn't clarify if it's safe, whether it requires authentication, if there are rate limits, or what happens with large result sets (e.g., pagination). The mention of 'filter parameters' hints at filtering but lacks details on default behavior or constraints, leaving 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: 'Returns all bills by filter parameters, used for retrieving billing information.' It's front-loaded with the core action and avoids unnecessary words. However, it could be slightly more structured by explicitly stating the tool's role among siblings, but it's still concise and clear.
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 (6 parameters, nested objects) and lack of annotations and output schema, the description is insufficient. It doesn't explain return values, error handling, or behavioral traits like pagination (implied by 'Limitation' in schema but not described). For a tool with rich filtering options and no structured output, 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 input schema has 100% description coverage, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'filter parameters,' which aligns with the schema's properties but doesn't provide additional syntax, format, or usage details. This 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 tool's purpose: 'Returns all bills by filter parameters, used for retrieving billing information.' It specifies the verb ('returns'), resource ('bills'), and scope ('by filter parameters'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'getAllPayments' or 'getAllAccountingItems', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'used for retrieving billing information,' but this is generic and doesn't help an agent decide between this and other retrieval tools (e.g., 'getAllPayments' for payments vs. bills). There's no mention of prerequisites, exclusions, or specific contexts, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns data (implying read-only) but doesn't mention potential side effects, rate limits, authentication requirements, or what happens with large result sets. The description lacks details on return format, error conditions, or whether this is a paginated operation (though the schema hints at pagination via 'Limitation').
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 7 words, front-loading the core purpose with zero wasted language. Every word earns its place: 'Returns' (action), 'all companies' (resource), 'optionally filtered by criteria' (capability).
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 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'returns' means in practice (format, structure), doesn't warn about potential performance implications of 'all companies,' and provides no context about the filtering system. The schema handles parameter documentation, but behavioral and usage context is missing.
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. The description adds minimal value beyond stating 'optionally filtered by criteria,' which is already implied by the parameter existence. No additional semantic context is provided about parameter interactions or filtering logic.
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: 'Returns all companies, optionally filtered by criteria.' It specifies the verb ('returns') and resource ('companies'), and mentions filtering capability. However, it doesn't distinguish this tool from other 'getAll' siblings like 'getAllCustomers' or 'getAllReservations' 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 any prerequisites, when filtering is appropriate, or how this differs from other company-related tools like 'deleteCompanies' or 'updateCompanies' in the sibling list. The phrase 'optionally filtered' hints at usage but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool returns data but does not cover critical aspects like whether it's read-only, requires authentication, has rate limits, pagination behavior (implied by 'Limitation' parameter but not explained), or error handling. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and briefly mentions filtering options. There is no wasted wording, making it appropriately 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 (8 parameters, nested objects) and lack of annotations and output schema, the description is insufficient. It does not explain return values, pagination, error cases, or behavioral traits, leaving the agent with incomplete context to use the tool effectively despite the detailed input 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 mentions optional filtering by 'specific loyalty tier identifiers or other filter parameters', which loosely maps to parameters like 'LoyaltyTierIds' but does not add meaningful details beyond the schema. With 100% schema description coverage, the baseline is 3, as the schema already documents all parameters thoroughly, and the description adds minimal 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 action ('Returns') and resource ('all loyalty tiers of the enterprise'), making the purpose evident. However, it does not explicitly differentiate this tool from sibling tools like 'getAllLoyaltyPrograms' or 'getAllLoyaltyMemberships', which reduces the score from 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 optional filtering by 'specific loyalty tier identifiers or other filter parameters', providing some implied context for usage. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., vs. 'getAllLoyaltyPrograms'), prerequisites, or exclusions, resulting in minimal guidance.
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 but offers minimal insight. It doesn't mention whether this is a read-only operation, potential side effects, rate limits, authentication needs, or the return format (e.g., pagination details implied by the 'Limitation' parameter). This leaves significant gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that directly states the tool's function. It's front-loaded with the core purpose and avoids unnecessary words, making it efficient 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 tool's complexity (7 parameters, nested objects, no output schema, and no annotations), the description is insufficient. It lacks details on behavioral traits, output structure, error handling, and usage context, making it incomplete for an AI agent to reliably invoke this 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?
The schema description coverage is 100%, providing detailed parameter documentation, so the description adds no additional parameter semantics beyond implying filtering. This meets the baseline for high schema coverage, but the description doesn't clarify how parameters interact (e.g., if multiple filters are applied) or provide usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Returns') and resource ('all payments'), making it understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'getAllBills' or 'getAllAccountingItems', which follow a similar pattern 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 mentions 'based on filter parameters' but doesn't specify scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions one important constraint: 'The time interval between StartUtc and EndUtc must not exceed 100 hours.' This is valuable behavioral information. However, it doesn't disclose other critical behaviors: whether this is a read-only operation, pagination behavior (though Limitation parameter hints at it), rate limits, authentication requirements, or what happens when filters return no results. For a tool with 6 parameters and no annotations, 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 appropriately concise - just two sentences. The first sentence states the core purpose, and the second adds a critical constraint. There's no wasted language. However, it could be slightly more front-loaded by mentioning the constraint earlier or integrating it more seamlessly.
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 complexity (6 parameters, nested objects, no output schema, no annotations), the description is minimally adequate. It states the purpose and one critical constraint, but leaves many questions unanswered: return format, error conditions, pagination details, and how this differs from similar reservation tools. With no output schema and no annotations, the description should provide more context about what to expect from this operation.
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 one important semantic constraint about the time interval between StartUtc and EndUtc parameters, which is valuable beyond the schema. However, it doesn't provide additional context about how filters combine (AND/OR logic), parameter dependencies, or default behaviors. With high schema coverage, baseline 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: 'Get reservations with filters.' This specifies the verb ('Get') and resource ('reservations'), and mentions filtering capability. However, it doesn't differentiate from sibling tools like 'exportReservations' or 'getAllReservations' (which appears to be the same tool name but listed as sibling - this is confusing). The purpose is clear but sibling differentiation is missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple reservation-related tools in the sibling list (addReservation, cancelReservations, exportReservations, updateReservations), but the description offers no comparison or context about when this specific filtering tool is appropriate versus other reservation 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 but only states it 'returns all services,' lacking details on permissions, rate limits, pagination, or data freshness. It doesn't disclose behavioral traits like whether it's read-only, safe, or has performance implications, which is inadequate for a tool with parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the core purpose ('Returns all services') without unnecessary elaboration. It's appropriately sized for a straightforward tool.
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 return values, error handling, or behavioral context, which is insufficient for a tool with filtering parameters and potential complexity in enterprise services.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the three parameters (ServiceIds, ServiceTypes, UpdatedUtc). The description adds no additional meaning beyond implying a retrieval operation, resulting in a baseline score of 3 as the schema handles parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Returns') and resource ('all services offered by the enterprise'), making the purpose immediately understandable. However, it doesn't differentiate from sibling 'getAll' tools (like getAllCompanies, getAllCustomers) beyond specifying 'services' as the resource type, missing explicit distinction in scope or behavior.
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 any prerequisites, exclusions, or comparisons to other tools (e.g., whether it's for bulk retrieval vs. specific lookups), 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns data, implying a read-only operation, but doesn't cover critical aspects like pagination, rate limits, authentication requirements, or error handling. For a tool that likely handles large datasets (e.g., 'all spaces'), this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality ('Returns all spaces of the enterprise') and adds a brief qualifier. There's no wasted verbiage, but it could be slightly more structured (e.g., by explicitly listing filter types). Overall, it's concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the return format, pagination, or error conditions, which are crucial for a tool that retrieves multiple items. Without annotations or an output schema, the agent lacks sufficient context to use this tool effectively beyond basic calls.
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 clear descriptions for all parameters (e.g., 'Filter by specific space IDs'). The description adds minimal value by hinting at filtering ('or only those specified') but doesn't elaborate on parameter interactions or usage examples. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Returns') and resource ('all spaces of the enterprise'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'getAllSpaceCategories' or 'getAllServices', which reduces specificity. The mention of optional filtering ('or only those specified') adds some detail but doesn't fully distinguish it from other 'getAll' tools.
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 mentions filtering options but doesn't explain scenarios where filtering by space IDs, service IDs, category IDs, or update dates is appropriate, nor does it reference sibling tools like 'getAllSpaceCategories' for related data. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Returns'), but doesn't specify whether it requires authentication, has rate limits, what happens if languages or scopes are invalid, or the format of returned data. This leaves significant gaps for a tool with potential complexity.
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 with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that likely returns complex translation data. It doesn't explain what 'texts' refer to (e.g., UI strings, content), how translations are structured, or error handling. For a read operation with potential nuance, 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?
Schema description coverage is 100%, so the schema already documents both parameters ('LanguageCodes' and 'Scope'). The description adds minimal value by mentioning 'specified languages' and 'scope of texts', which aligns with but doesn't expand beyond the schema. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Returns translations') and resource ('texts in the specified languages'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'getAllLanguages' or specify what types of texts are involved, leaving some ambiguity.
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 'getAllLanguages' or other 'getAll' tools. It lacks context about prerequisites, such as whether texts must exist or be configured, and doesn't mention any exclusions or specific 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 states the tool returns prices but doesn't describe the return format, pagination, rate limits, authentication needs, or error handling. For a read operation with no annotation coverage, this leaves significant gaps in understanding how the tool behaves beyond its 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose and appropriately sized for a straightforward tool. Every part of the sentence contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a read operation with 3 required parameters) and lack of annotations and output schema, the description is incomplete. It doesn't address return values, error cases, or behavioral traits like rate limits. For a tool that fetches pricing data, more context on output structure and usage constraints would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for RateIds, StartUtc, and EndUtc. The description adds minimal value beyond the schema by implying the parameters define a period and rate selection, but it doesn't provide additional context like date format examples or constraints beyond maxItems. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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: 'Returns prices of rates during the specified period.' It specifies the verb ('Returns'), resource ('prices of rates'), and scope ('during the specified period'). However, it doesn't explicitly differentiate from sibling tools like 'getAllRates' or 'getAllReservations', which might also return pricing-related data.
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, exclusions, or compare it to sibling tools such as 'getAllRates' or 'getAllReservations', which might overlap in functionality. Without this context, users must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. 'Updates' implies a mutation operation, but it doesn't disclose whether this requires specific permissions, what happens to fields not included in updates (partial vs. full replacement), whether changes are reversible, or any rate limits/constraints. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable. Every word earns its place by conveying essential purpose 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?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what constitutes 'personal information' beyond the schema fields, provide error handling context, describe response format, or address batch update implications (since CustomerUpdates is an array). Given the complexity of updating multiple customer records, more guidance 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%, providing detailed documentation for all parameters. The description adds minimal value beyond the schema, only implying that updates apply to 'personal information' (which aligns with fields like name, email, birth details). No additional syntax, format, or constraint details are provided beyond what's in the schema descriptions.
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 ('Updates') and resource ('personal information of existing customers'), making the purpose immediately understandable. It distinguishes from sibling tools like 'addCustomer' (creation) and 'deleteCustomers' (deletion), though it doesn't explicitly differentiate from 'updateCompanies' or 'mergeCustomers' which operate on 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 customer IDs), when not to use it (e.g., for new customers), or how it differs from related tools like 'mergeCustomers' or 'updateCompanies'. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's an update operation but doesn't cover critical aspects like required permissions, whether changes are reversible, rate limits, error handling, or what the response looks like. The Portfolio Access Token note is helpful but insufficient 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 brief and to the point with two sentences. The first sentence states the purpose clearly, and the second adds a relevant authentication note. There's no 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?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'updates' entail (e.g., partial vs. full updates), success/failure responses, or important behavioral constraints. The Portfolio Access Token note is the only contextual addition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions, which is acceptable but not exceptional.
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 ('Updates') and resource ('information about the specified loyalty memberships'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'updateLoyaltyPrograms' or 'updateLoyaltyTiers', 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 'supports Portfolio Access Tokens' but provides no guidance on when to use this tool versus alternatives like 'addLoyaltyMemberships' or 'deleteLoyaltyMemberships'. There's no mention of prerequisites, constraints, 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. While 'Updates' implies a mutation operation, the description lacks details on permissions, side effects, error handling, or response format. It doesn't mention the batch capability (up to 1000 items) or the ChainId parameter's conditional requirement, which are critical for correct usage.
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 with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by directly stating the tool's 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 the complexity (a batch update tool with conditional parameters and no output schema) and the lack of annotations, the description is incomplete. It doesn't address behavioral aspects like the batch limit, authentication needs for ChainId, or what the tool returns, leaving significant gaps for the agent to operate 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?
The schema description coverage is 100%, so the schema fully documents the two parameters (ChainId and LoyaltyProgramUpdates) and their nested properties. The description adds no additional meaning beyond the schema, such as explaining the update semantics or the null-value handling for optional fields. This meets the baseline score when schema coverage is high.
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 ('Updates') and resource ('information about the specified loyalty programs'), providing a specific purpose. However, it doesn't distinguish this tool from sibling tools like 'updateLoyaltyMemberships' or 'updateLoyaltyTiers', which have similar naming patterns and likely operate on related but 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, context, or exclusions, such as how it differs from 'addLoyaltyPrograms' or 'deleteLoyaltyPrograms' in the sibling list, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool updates loyalty tiers but fails to mention critical details like whether this is a destructive operation, if it requires specific permissions, rate limits, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration, earning a top score for brevity and 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 the tool's complexity (a mutation operation with 2 parameters, no output schema, and no annotations), the description is insufficient. It lacks details on behavioral traits, usage context, and expected outcomes, making it incomplete for safe and effective agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, detailing both parameters ('ChainId' and 'LoyaltyTierUpdates') and their nested properties comprehensively. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 without compensating 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 action ('Updates') and resource ('information about the specified loyalty tiers'), making the purpose evident. However, it does not differentiate from sibling tools like 'updateLoyaltyMemberships' or 'updateLoyaltyPrograms', which also update loyalty-related entities, leaving room for confusion about when to use this specific 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?
No guidance is provided on when to use this tool versus alternatives like 'addLoyaltyTiers' or 'deleteLoyaltyTiers', nor does it mention prerequisites such as authentication or permissions. The description lacks context for usage, 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?
No annotations are provided, so the description carries full burden. It states a read operation ('Get'), implying non-destructive behavior, but lacks details on permissions, rate limits, pagination, or return format. For a tool with no 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 with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 minimally adequate for a simple read tool but lacks depth. It covers the basic purpose but misses behavioral context and usage guidance, which are important for a tool in a server with many similar 'getAll' operations.
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 the single parameter 'AccountIds' as an array of account IDs. The description adds minimal value by mentioning 'specified accounts', which aligns with but doesn't expand beyond the schema. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('addresses') with scope ('associated with specified accounts'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'addAddresses' or other 'getAll' tools, which would require more specific context about what makes this tool unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 like 'getAllCustomers' or 'getAllCompanies', there's no indication of prerequisites, when this is appropriate, or what other tools might be better for related tasks.
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 returns data but does not specify format, pagination, rate limits, or authentication needs. This is a significant gap for a read operation 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 that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and no output schema, the description is incomplete. It does not explain return values, format, or any behavioral traits, which are essential for an agent to use the tool 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 tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description appropriately does not discuss parameters, aligning with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Returns') and resource ('all countries supported by the API'), making the purpose immediately understandable. However, it does not differentiate from sibling tools like 'getAllCurrencies' or 'getAllLanguages', which follow the same pattern, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 context, prerequisites, or exclusions, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering and optional parameters but fails to describe key behaviors such as pagination (implied by 'Limitation' in schema but not explained), rate limits, authentication requirements, or error handling. This leaves significant gaps for an agent to understand operational constraints.
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 front-loads the core purpose and briefly mentions filtering. It avoids redundancy and waste, though it could be slightly more structured by explicitly listing key filter types for 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 the complexity (7 parameters, nested objects) and lack of annotations and output schema, the description is insufficient. It doesn't explain the return format, pagination behavior, or error scenarios, which are critical for a tool with multiple filter options and no structured output documentation. This leaves the agent with incomplete context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning 'optionally filtered by specific loyalty program identifiers or other filter parameters,' which loosely maps to parameters like 'LoyaltyProgramIds' but doesn't provide additional semantics beyond what the schema offers. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Returns') and resource ('all loyalty programs of the enterprise'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'getAllLoyaltyTiers' or 'getAllLoyaltyMemberships', which reduces it from 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'optionally filtered by specific loyalty program identifiers or other filter parameters,' suggesting when to use it for filtered vs. unfiltered retrieval. However, it lacks explicit guidance on when to choose this over other 'getAll' tools or alternatives like 'export' tools, leaving some ambiguity.
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 'Returns' implies a read-only operation, it doesn't specify whether this is a complete list or filtered view, whether there are pagination considerations, rate limits, authentication requirements, or what format the taxations are returned in. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 states the core functionality without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential information about what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with good schema coverage but no annotations or output schema, the description provides the basic purpose but lacks important context. It doesn't explain what 'taxations' includes (types, formats, structure), doesn't mention whether filtering is optional or required, and provides no information about the return format or potential limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, with the single parameter clearly documented as 'Filter by tax environment IDs.' The description doesn't add any meaningful parameter semantics beyond what the schema already provides, so it earns the baseline score of 3 for adequate but not additive parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Returns') and resource ('all taxations supported in tax environments'), making the purpose immediately understandable. However, it doesn't distinguish this tool from similar 'getAll' siblings like getAllTaxEnvironments, which would require explicit differentiation for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 getAllTaxEnvironments that might return related data, there's no indication of when this specific taxation retrieval tool is appropriate or what distinguishes it from other data retrieval tools in the system.
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 'Returns all tax environments', implying a read-only operation, but doesn't disclose behavioral traits like whether it's paginated, requires authentication, has rate limits, or what the return format is. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, and there's no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is minimal but incomplete. It lacks behavioral context (e.g., return format, pagination) and usage guidelines, which are important even for simple tools. With no annotations and no output schema, it should do more to inform the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, so a baseline of 4 is appropriate. It implicitly confirms no inputs are required by not mentioning any.
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 ('Returns') and resource ('all tax environments supported by the API'), making the purpose understandable. It distinguishes from siblings by specifying 'tax environments' rather than other resources like companies or customers. However, it doesn't explicitly differentiate from 'getAllTaxations' (a sibling tool), which could be related, so it's not a perfect 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 any context, prerequisites, or exclusions, such as whether this is for setup, reporting, or other scenarios. With many sibling tools, including 'getAllTaxations', the lack of differentiation leaves 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 the full burden. It mentions returning configuration but does not disclose behavioral traits like whether it's read-only, requires authentication, includes rate limits, or what format the configuration is in. This leaves significant gaps for an agent to understand how to use it safely.
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 function without unnecessary words. It is front-loaded and appropriately sized 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 the complexity of configuration data and no annotations or output schema, the description is incomplete. It does not explain what 'configuration' entails (e.g., settings, preferences, system info) or the return format, making it hard for an agent to use effectively without additional 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 0 parameters with 100% coverage, so no parameter information is needed. The description does not add param details, which is acceptable here, but it could have clarified if any implicit parameters (like context) are involved. Baseline is 4 due to the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Returns') and the target ('configuration of the enterprise and the client'), making the purpose understandable. However, it does not differentiate from sibling tools like 'getAllCompanies' or 'getAllCurrencies' that also retrieve data, leaving room for ambiguity in tool selection.
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, such as whether it's for system-wide settings or specific client data. With many sibling 'getAll' tools, the lack of context makes it unclear when this tool 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 the full burden of behavioral disclosure. It states the tool returns data, implying a read-only operation, but doesn't cover important aspects like rate limits, authentication requirements, error handling, or response format. 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.
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 function without unnecessary words. It's front-loaded with the core purpose and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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), the description is adequate but minimal. It covers the basic purpose but lacks context about the return format (e.g., list structure, currency fields) and behavioral details like error cases. For a read-only tool with no annotations, more completeness would be helpful, though it's not entirely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100% (though empty). The description doesn't need to explain parameters, and it correctly implies no inputs are required. This meets expectations for a parameterless tool, earning a baseline score of 4.
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 ('Returns') and resource ('all currencies supported by the API'), making it easy to understand what the tool does. However, it doesn't distinguish this tool from its sibling 'getAll' tools (e.g., getAllCountries, getAllLanguages), which follow the same pattern 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 prerequisites, timing considerations, or how it differs from other currency-related tools (though none are listed in siblings). The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns data, implying a read-only operation, but fails to mention potential behaviors like pagination, rate limits, authentication needs, or error handling. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core functionality without any wasted words. It is front-loaded with the essential information, 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.
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. It explains what the tool does but lacks details on return format, error conditions, or integration context. For a basic read operation, it meets the minimum viable standard but could be more informative to fully guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description does not need to add parameter semantics, as there are none to document. A baseline score of 4 is appropriate since the description accurately reflects the lack of inputs without unnecessary elaboration.
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 ('Returns') and resource ('all languages supported by the API'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'getLanguageTexts' or other 'getAll' tools, which slightly limits its clarity in a crowded namespace.
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, such as 'getLanguageTexts' or other data retrieval tools in the sibling list. It lacks context on prerequisites, exclusions, or specific use cases, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions the required filter constraint. It doesn't disclose important behavioral traits like whether this is a read-only operation, pagination behavior (though the Limitation parameter hints at it), rate limits, authentication requirements, or what happens when no items match filters. The description adds minimal value beyond the basic operation.
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 sized with two sentences: the first states the purpose, the second provides critical usage constraint. Both sentences earn their place, and the important requirement is front-loaded in the second sentence. It could be slightly more structured by explicitly listing the required parameters.
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 complexity (11 parameters, nested objects, no output schema, and no annotations), the description is minimally adequate. It covers the core purpose and critical filter requirement but lacks information about return format, pagination behavior, error conditions, or relationship to sibling tools. For a retrieval tool with many parameters, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description adds value by specifying which parameters are required filters (AccountingItemIds, RebatedItemIds, ClosedUtc, ConsumedUtc, UpdatedUtc) and that at least one must be specified, which isn't captured in the schema's required fields. This compensates for the schema's limitation of having 0 required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Returns') and resource ('all accounting items') with examples of what's included ('charges, payments, etc.'). It distinguishes from sibling tools like 'exportAccountingItems' by being a retrieval rather than export operation, though it doesn't explicitly contrast with other 'getAll' tools that retrieve different resource types.
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 explicit guidance on when to use this tool by stating the REQUIRED filter condition ('At least one of the following filters must be specified'), which helps the agent understand prerequisites. However, it doesn't specify when NOT to use it or mention alternatives like 'exportAccountingItems' for bulk data export scenarios.
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 adds valuable context about mandatory filtering requirements and time interval limits, which aren't evident from the schema alone. However, it doesn't describe important behavioral aspects like pagination, rate limits, authentication requirements, or what happens when no blocks match filters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly sized with two sentences: the first states the purpose, the second provides critical constraints. Every word earns its place with zero waste or redundancy. The structure is front-loaded with the core functionality followed by important usage notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 5 parameters (2 required) and no output schema, the description covers the basic purpose and critical constraints well. However, it lacks information about return format, error conditions, pagination, or what constitutes a valid response. Given the complexity of the nested CollidingUtc parameter and the absence of annotations, more behavioral context would be 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?
With 100% schema description coverage, the schema already documents all 5 parameters thoroughly. The description adds marginal value by mentioning filter parameters generally and listing some examples (CreatedUtc, UpdatedUtc, etc.), but doesn't provide additional syntax, format, or semantic details beyond what's in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Returns') and resource ('all availability blocks') with specific scope ('reservations blocked by rate, space category, or space'). It distinguishes from sibling tools like getAllReservations or getAllServices by focusing on availability blocks, which are a distinct resource type in this system.
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 about when to use this tool ('based on filter parameters') and includes important constraints ('At least one filter must be provided' and 'time interval must not exceed 100 hours'). However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the requirement for at least one filter, limitations on date range filters (max 3 months and 1 day), array filter limits (1000 items each), and pagination requirements (Limitation parameter with Count is mandatory). This covers constraints and operational details, though it could mention potential performance impacts or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose followed by requirements and limitations. Each sentence adds necessary information without redundancy. It could be slightly more structured with bullet points for clarity, but it remains efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, nested objects, no output schema, and no annotations), the description is fairly complete. It covers purpose, usage rules, and behavioral constraints. However, it lacks details on output format or error responses, which would be helpful since there's no output schema. For a tool with rich input schema and no annotations, it does well but has minor gaps in output 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 parameters thoroughly. The description adds value by clarifying that at least one filter is required and specifying limitations (e.g., max interval for date filters, item limits for arrays), which are not in the schema. However, it does not provide additional meaning beyond these constraints, aligning with the baseline of 3 when schema coverage is high.
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: 'Returns all tasks of the enterprise, filtered by identifiers or other filters.' It specifies the verb ('Returns') and resource ('tasks of the enterprise'), but does not explicitly differentiate from sibling tools like 'getAllReservations' or 'getAllCompanies', which follow a similar pattern. The filtering aspect is mentioned, which adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'REQUIRED: At least one filter must be provided' and lists the specific filters (TaskIds, DepartmentIds, etc.). It implies when to use this tool (for retrieving tasks with filters) but does not explicitly state when not to use it or name alternatives among siblings, such as if there's a simpler 'getTask' tool. The guidance is practical but lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context beyond basic functionality: it explicitly mentions pagination ('Note this operation uses Pagination') and authentication requirements ('supports Portfolio Access Tokens'), which are critical for correct usage. However, it does not detail rate limits, error conditions, or response format.
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 front-loaded with the core purpose in the first sentence, followed by two concise sentences that add critical behavioral context (pagination and authentication). Every sentence earns its place with no wasted words, making it appropriately sized and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, no output schema, no annotations), the description is reasonably complete. It covers the purpose, key behavioral traits (pagination, authentication), and hints at filtering capabilities. However, without an output schema, it does not explain return values or structure, leaving a gap in full context 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 schema description coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description adds minimal value by mentioning filtering by 'loyalty membership identifiers, activity states, or other filter parameters', but does not provide additional syntax, format, or usage details beyond what the schema provides. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Returns') and resource ('all loyalty memberships of the enterprise'), and distinguishes it from siblings by specifying it's a 'getAll' operation for loyalty memberships, unlike 'addLoyaltyMemberships', 'deleteLoyaltyMemberships', or 'updateLoyaltyMemberships' which are mutation tools.
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 through optional filtering parameters (e.g., 'optionally filtered by specific loyalty membership identifiers, activity states, or other filter parameters'), but does not explicitly state when to use this tool versus alternatives like 'getAllLoyaltyPrograms' or 'getAllLoyaltyTiers', nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 effectively describes key behavioral traits: the requirement for at least one filter, default filtering behavior, and important limitations like maximum date intervals (3 months and 1 day) and array limits (typically 1000, except CompanyIds limited to 1). This provides crucial operational context beyond basic functionality.
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 well-structured and appropriately sized. It front-loads the core purpose, then provides essential usage rules, and concludes with important limitations. Every sentence serves a clear purpose, though it could be slightly more concise by integrating the filter list more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, no annotations, no output schema), the description does a good job of providing necessary context. It covers usage requirements, defaults, and limitations. However, it doesn't describe the return format or pagination behavior (though Limitation parameter hints at it), leaving some gaps for a tool with this many parameters and no 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?
Schema description coverage is 100%, so the schema already documents all 13 parameters thoroughly. The description adds value by explaining the 'at least one filter' requirement and specific limitations on date ranges and array sizes, but doesn't provide additional semantic meaning for individual parameters beyond what's in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get customers with filters.' It specifies the resource (customers) and the action (get with filtering). However, it doesn't explicitly distinguish this from sibling tools like 'getAllCompanies' or 'getAllReservations' beyond the resource name, so it doesn't fully achieve sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'At least one filter must be provided' and lists the specific filters. It also states the default behavior when no filters are specified (ActivityStates: ['Active']). This gives clear instructions on when and how to use the tool, including edge cases.
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:

[![mews-mcp MCP server](https://glama.ai/mcp/servers/code-rabi/mews-mcp/badges/card.svg)](https://glama.ai/mcp/servers/code-rabi/mews-mcp)

Score Badge

Copy to your README.md:

[![mews-mcp MCP server](https://glama.ai/mcp/servers/code-rabi/mews-mcp/badges/score.svg)](https://glama.ai/mcp/servers/code-rabi/mews-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/code-rabi/mews-mcp'

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