@walletap/mcp-server
OfficialServer Quality Checklist
Latest release: v0.3.7
- Disambiguation5/5
Each tool targets a distinct resource and action (templates, passes, files, locations, sub-accounts, notifications, translation). Even similar tools like list_passes vs search_passes are clearly separated by browsing vs. finding a specific customer, and notify_pass vs send_template_notification distinguish single vs. bulk. No ambiguity exists.
Naming Consistency5/5All tools follow a consistent verb_noun pattern with snake_case (e.g., list_templates, create_pass, update_location, upload_file_from_url). Even longer names like send_template_notification and translate_pass_text follow the same convention. No mixing of styles or vague verbs.
Tool Count4/526 tools is slightly above the typical well-scoped range, but the server covers a broad domain with multiple resource types (templates, passes, files, locations, sub-accounts, notifications, translation). Each tool contributes to a distinct workflow, and the count is manageable without being bloated.
Completeness4/5The tool surface provides full CRUD for templates, locations, and sub-accounts, and robust pass management (create, read, update, search, export, notify) but lacks a delete_pass tool. File operations lack listing, and certificate management is minimal, but these are minor gaps that do not block core workflows.
Average 4.2/5 across 26 of 26 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare destructiveHint: true, which implies the operation may destroy data. However, the description states 'Create a new business location,' which is inherently an additive operation. This is a direct contradiction. The description also provides no additional behavioral context (e.g., side effects, permissions, reversibility) beyond what annotations already give. This contradiction makes the description misleading for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, with the core purpose stated upfront. It is concise and contains no redundant information. The structure is logical: statement of purpose, usage context, and a note about associations. It earns a 4 rather than a 5 because the final sentence adds only minor context and could be more directly relevant to the create action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose and when to use it, but does not mention return values (no output schema exists) or any operational constraints such as required permissions, duplicate handling, or location uniqueness rules. The annotation contradiction (destructiveHint vs. create) also leaves the safety profile unclear. For a moderately complex create tool with 5 parameters, this is inadequate but not severely incomplete, hence a 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters have descriptions in the schema itself. The description does not add any parameter-specific meaning beyond what the schema already provides (e.g., it does not clarify coordinate format or labeling conventions). According to the rubric, with high schema coverage the baseline is 3, and the description adds no extra value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 business location') and provides context about its use for reader deployment and pass management. It is distinct from sibling tools like list_locations, update_location, and delete_location, so an agent can easily distinguish it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when setting up a new store, venue, or checkpoint,' which gives clear guidance on when the tool should be invoked. It also mentions that locations can be associated with passes and readers, adding contextual usage info. It does not explicitly list alternatives for updating or deleting locations, but the context strongly implies that this is the creation path.
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?
Annotations provide destructiveHint=true, and the description adds context (automatic vs manual triggering) without contradicting it. However, the description doesn't explicitly disclose that renewing replaces/destroys the existing certificate, though the verb 'renew' implies it. With the annotation covering destruction, the marginal disclosure is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The primary action is front-loaded, and the usage note earns its place by clarifying the manual-renewal case. Nothing extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a single-parameter action tool. The description covers what it does and when to use it, annotations cover the destructive safety profile, and the schema fully documents the one required parameter. The only minor absence is expected return/response behavior, but with no output schema defined this is an acceptable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — templateId is already documented as 'Template id.' The description reinforces the parameter's role ('for a template') but adds no syntax or semantics beyond the schema. Baseline of 3 is correct when the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Create or renew the Apple Wallet certificate') and the target ('for a template'). Unambiguous even against 25 siblings — it is the only certificate-related action, and the description further separates it from the automatic template-creation flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent this is 'for manual renewals' and that creation is 'usually triggered automatically on template create'. This is clear when-to-use context with no named sibling alternative (the alternative is automation, not another tool). Slight deduction because it doesn't spell out when not to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already include destructiveHint: true, so the mutation is disclosed. The description adds valuable context about the side effect on templates: their JSON stays intact but the linked URL returns 404. This goes beyond the annotation and helps the agent anticipate consequences, which is strong behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero filler. The primary action is front-loaded, and the important side effect regarding templates is stated immediately after. Every word earns its place, making it highly efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description covers the essential behavior: what gets deleted and the impact on referencing templates. The destructiveHint annotation covers the irreversibility aspect. Nothing critical is missing for an agent to call it correctly, so it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a description for fileId ('File id.'). The tool description does not add any further meaning beyond what the schema provides. Since the schema already documents the parameter, baseline 3 is appropriate; the description adds nothing extra for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Delete') and resource ('a file and all its variants from storage'). It is unambiguous and distinguishes itself from sibling delete tools like delete_template or delete_location by specifying the resource type. No confusion about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you want to delete a file) but provides no explicit guidance on when to use this versus alternatives, nor any exclusions or conditions. It doesn't mention prerequisites or typical scenarios beyond the basic operation. This is adequate but lacks proactive routing to/from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, so the read-only nature is already known. The description adds useful domain context about the fetched field ids being used as keys at issuance time, which goes beyond the annotation. However, it does not disclose the response format, error behavior, or any other side effects. With annotations covering the safety profile, a 3 is appropriate because the description adds limited but valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core action is front-loaded in the first sentence, and the second sentence provides essential workflow context. Every word earns its place, and the structure is highly effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only fetch operation, the description is reasonably complete. It states what it does, why to use it, and what the returned data is useful for. No output schema exists, but the description hints at the response content (field ids). It does not cover error cases or pagination, but these are not critical for a simple fetch. Overall, an agent has enough to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for templateId with a description 'Template id.' The description does not add any new parameter-specific details such as format, constraints, or examples. It does indirectly explain why templateId matters (to fetch the template with its field ids), but this is not parameter-specific. Per the calibration baseline, schema coverage is high so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a single template by id' with a specific verb and resource. It distinguishes this from list_templates (fetching all) and other get_* tools by focusing on a single template. It also explains the practical purpose: inspecting field ids before issuing passes, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context: 'Use this to inspect existing field ids (rows, linkRows, header) before issuing passes'. This tells an agent when to use the tool. It does not name alternative tools (like list_templates) but clearly implies a workflow. The guidance is specific and actionable, though it could have explicitly stated not to use this for listing all templates.
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 readOnlyHint:true annotation already covering the read-only nature, the description adds value by disclosing the return structure: 'Returns pass objects with IDs, emails, phones, and device counts.' It also mentions pagination and status filtering, which are behavioral aspects. Since annotations cover safety and the description adds return and pagination context, this is above the baseline 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose ('List all passes...'), followed by usage examples and return information. Every sentence contributes content: clarity, use cases, and output structure. There is no redundancy or fluff, 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description partially compensates by stating returned fields (IDs, emails, phones, device counts). It also covers pagination and filtering. However, it does not explicitly explain cursor usage or any edge cases, but the schema already documents cursor parameters. Overall, it provides sufficient context for an agent to know what it does and what it returns, without being overly detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — every parameter (limit, status, endBefore, startAfter, templateId) already has its own description in the schema. The tool description mentions 'status filtering' and 'pagination' which are already implied by schema, adding no new semantic detail. Thus, the description provides no extra value beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: 'List all passes for a given template' with a specific resource (passes) and scope (template). It also mentions pagination and status filtering, which distinguishes it from a plain list. However, it does not explicitly contrast with the sibling 'search_passes' tool, so an agent might wonder when to use one vs the other. Overall, it is specific and understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use this to browse passes, check counts, or find passes by their installation status.' This tells the agent when to invoke this tool. It does not, however, explicitly mention alternative tools like 'search_passes' or when not to use this one, so it lacks explicit exclusions. That corresponds to 'clear context, no exclusions' (score 4).
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?
Annotations already declare readOnlyHint=true, and the description does not contradict it. The description adds valuable behavioral context beyond the annotation: it mentions cursor-pagination and the exact return object structure, which are not covered by annotations. It also specifies 'owned by this account,' clarifying scope. This is meaningful transparency for a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action ('List pass templates') followed by scope, pagination, and return format. Every phrase earns its place: no filler, no repetition. It is concise yet informative, ideal for quick agent comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with two optional parameters, the description covers the essential operational context: scope, pagination behavior, and return shape. It does not explain error handling or security requirements, but those are likely implicit for an API tool and are not expected in a brief description. Given no output schema exists, providing the return structure explicitly increases completeness. The description is sufficient for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (limit and startingAfter) are fully documented in the schema. The description does not add any parameter-specific meaning beyond what the schema already provides, and it only references the return format, not the parameters. With high schema coverage, the baseline is 3, and the description adds no param semantics, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (List) and resource (pass templates owned by this account), which clearly identifies the tool's function. It also mentions cursor-pagination, adding scope and pagination behavior. The purpose is unambiguous and distinguishes it from sibling tools like get_template (single retrieval) or list_passes (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (use this to list account-owned templates) but does not explicitly state when to use it over alternatives, nor does it mention exclusions or prerequisites. It does not reference sibling tools like get_template or create_template, so an agent lacking prior knowledge might not know when this is the appropriate choice. However, the purpose is clear enough that usage can be inferred.
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?
Annotations already declare readOnlyHint=true, so the description doesn't need to restate safety. It adds useful behavioral detail by specifying that results are 'ordered by creation date,' which is beyond the annotation. However, it doesn't mention behavior for no matches, pagination, or limits. Given the annotations cover the safety profile, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with zero filler. The first sentence states the core action and criteria, and the second sentence gives the use case and return behavior. Information is front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool with a read-only annotation, the description is nearly complete. It covers purpose, usage, return ordering, and the required parameters are documented in the schema. It does not mention edge cases (e.g., empty results) or pagination, but these are minor omissions given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters already documented (templateId as 'Template ID to search within' and searchQuery as 'Email address or phone number to search for'). The description essentially restates these facts ('within a template' and 'by email or phone number') without adding new semantic detail. It meets the baseline but adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search') with a clear resource ('passes within a template') and the search criteria ('by email or phone number'). It distinguishes from siblings like list_passes or get_pass by specifying the search mechanism, and explicitly mentions finding a specific customer's pass. This leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear use case: 'Use this when you need to find a specific customer's pass.' This implies when to use it, but does not explicitly state when not to use it or mention alternative tools. It could be improved by naming alternatives (e.g., list_passes for browsing all passes), but the context given is sufficient for most agents.
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?
The destructiveHint annotation already signals mutation, and the description adds specific behaviors like invalidating a pass and adjusting balance. However, it does not disclose additional traits such as permission requirements, reversibility, or side effects on related data. Given the annotation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the core action ('Update an existing pass's...') followed by usage examples. Every word contributes value with no redundancy or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters and nested objects, the description provides a solid high-level overview of functionality and identification methods. It groups operations into logical categories (fields, stamps, balance) and covers invalidation. The schema handles detailed parameter semantics, so the description does not need to enumerate everything. It is sufficiently complete for an agent to understand when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented. The description adds a useful identification note ('by ID or by externalId + templateId') which is also present in the schema properties, but it does not introduce new meaning beyond grouping operations into stamps, balance, and fields. This meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing pass's fields, stamps, or balance' with a specific verb and resource. It explicitly lists the modification aspects (fields, stamps, balance) and mentions invalidation, making it distinct from siblings like create_pass, get_pass, and list_passes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct usage scenarios: 'modify customer data, add/remove loyalty stamps, adjust balance, or invalidate a pass.' It implicitly differentiates from creation by specifying 'existing pass,' but it does not explicitly mention when not to use it or name alternative tools for creation, such as create_pass.
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?
The annotations include destructiveHint: true, which already signals side effects. The description adds valuable behavior beyond that: it can optionally send pass links via email or SMS. This extra disclosure aligns with the annotation and provides useful context, though it does not cover other potential side effects like rate limits or reversibility, which are not required given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core function and then adding usage context and optional delivery methods. Every sentence serves a purpose, with no redundant text. It is concise and well-structured, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema thoroughly documents parameters, the description lacks a mention of the return value (e.g., created pass objects or confirmation) and does not summarize the batch limit (1-10 per call) which is only in the schema. Given the tool's complexity and absence of an output schema, the description could provide more high-level context about expected outcomes or error handling to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema provides detailed descriptions for all parameters, including nested fields like collectedStamps and templateFields. The description adds no additional parameter meaning beyond a high-level summary of the tool's purpose. Since the schema fully covers parameter semantics, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (create wallet passes) on a clear resource (templates/passes) and lists concrete use cases (loyalty cards, event tickets, coupons, membership passes). This clearly differentiates it from sibling tools like update_pass and list_passes, which operate on existing passes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool ('issue new... passes') which implies it is for creation, but it does not explicitly contrast with alternatives like update_pass for modifications or notify_pass for notifications. While the context is clear, it would benefit from naming the specific sibling tools it complements or replaces.
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?
Annotations already set destructiveHint=true, but the description adds valuable context: the operation is permanent (irreversible), readers need reassignment, and the subscription updates automatically. These side effects go beyond the mere destructive flag, giving the agent a clearer picture of consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and immediately follows with the most critical caveat and side effect. Every word contributes value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description covers permanence, side effects (reader reassignment), and automatic subscription updates. This is sufficient for an agent to understand the full impact of calling this tool without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter description ('Location ID to delete'), so the description does not need to add parameter details. The description mentions associated readers but does not tie that to the id parameter specifically, so it adds little beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Delete a location permanently.' It specifies the resource (location) and the action (delete), and the permanence distinguishes it from update_location. It also differentiates from sibling delete tools by referencing location-specific side effects like reader reassignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is destructive and should be used with caution, but it does not explicitly state when to use it versus alternatives like delete_template or update_location. It implies the use case (permanent removal of a location) but offers no exclusions or alternative routes.
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?
Annotations include destructiveHint: true, which lowers the burden on the description. The description adds context about own login credentials and limited access, but does not explain the destructive implications (e.g., potential removal of existing permissions or credential revocations). No contradiction with annotations, but it could elaborate on the side effects of creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core action and purpose are front-loaded, and the secondary sentence clarifies the outcome (credentials). Every word contributes to comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter creation tool with no output schema, the description covers the purpose, the access-control model, and the creation of credentials. It does not mention response behavior, but that is not required given no output schema. Required fields are handled by the schema. Minor gap: no mention of any prerequisites or post-creation implications, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all five parameters are documented. The description adds meaning by grouping them: 'specific permissions and template access' maps to permissions and templateIds, while 'own login credentials' maps to email, password, and displayName. This enhances understanding beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb-resource pair ('Create a new sub-account') and precisely states its function: granting team members limited access to manage specific templates. It also notes that the sub-account gets its own login credentials, which distinguishes it from sibling tools like list_sub_accounts, update_sub_account, and delete_sub_account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Use this to grant team members limited access to manage specific templates' gives explicit context for when to employ this tool. While it does not explicitly mention when not to use it or name alternatives, the sibling tools (list/update/delete) make the intended use case clear in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description consistently reflects a read-only operation ('Get', 'Returns'). The description adds specific return content details (wallet URLs, badge URLs) and the behavior of includeTemplate, but does not disclose error conditions, prioritization of id vs externalId, or authorization requirements. With the annotation covering safety, the added value is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the primary purpose and lookup methods, then adding return content and an optional flag. Every sentence carries useful information with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with five documented parameters and no output schema, the description covers the essential usage patterns (lookup methods) and the notable optional behavior (includeTemplate). It does not address edge cases like conflicting parameters or response error shapes, but these are minor against the readOnlyHint and schema guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by clarifying that id is exclusive with externalId+templateId, and that includeTemplate controls inclusion of full template data. This helps an agent choose the correct parameter combination and understand the boolean's effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'single pass', and specifies two lookup methods (by ID or externalId + templateId). It also enumerates what the response contains (wallet download URLs and installation badge URLs), distinguishing it from siblings like list_passes, search_passes, and export_passes which involve multiple or different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two acceptable lookup modes and the purpose of includeTemplate, effectively guiding when to use this tool. However, it does not explicitly contrast it with alternative siblings or state when not to use it, such as when needing multiple passes or template-only data, leaving some implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is known to be safe. The description adds context by naming the external service (Google Cloud Translation) and noting language coverage. It doesn't disclose rate limits or return format, but these are not critical for a read-only translation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and purpose, and no wasted words. Every sentence contributes to the agent's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with three primitive parameters and no output schema, the description covers purpose, usage, and the external service. It lacks an explicit return format, but that can be inferred from typical translation tools and the read-only annotation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is described. The description reinforces the meaning of the parameters (e.g., 'texts' are pass content strings) without adding new syntax or edge-case details. This meets the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Translate'), the resource ('pass text'), the method ('Google Cloud Translation'), and the purpose ('localize pass content for international customers'). Clearly distinguishes from sibling tools that create or update passes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('to localize pass content') and implies the context of internationalization. It doesn't mention alternatives or exclusions, but since no other translation tool exists among siblings, the guidance is adequate.
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?
The destructiveHint annotation is already present, so the core mutation risk is disclosed. The description adds valuable behavioral information beyond that: 'Only provided fields are updated — omitted fields remain unchanged,' which clarifies the partial-update semantics and prevents the agent from assuming a full replacement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero fluff. The primary purpose is stated first, followed by the critical partial-update constraint. Every word earns its place, and the structure is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with six scalar parameters and no output schema, the description covers the essential behavior: what it does, when to use it, and its partial-update rule. It does not mention return values, but that is not mandated since there is no output schema. The description is sufficient for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters are individually documented. The description adds general guidance by tying parameters to use cases (address, name, coordinates) but does not enrich each parameter's meaning beyond the schema. Baseline 3 is appropriate given high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Update an existing location's details.' It also provides concrete use cases (correct addresses, rename locations, update coordinates) that distinguish it from sibling tools like create_location and delete_location without needing to reference them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool ('Use this to correct addresses, rename locations, or update coordinates') and adds the partial-update behavior. However, it does not explicitly name alternatives or state when not to use it, though the sibling list makes this evident.
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?
The description adds the key behavioral detail 'Only provided fields are updated,' indicating a partial-update semantics. This goes beyond the destructiveHint annotation, which already signals potential destructive effects. The description is consistent with the annotation, and the added partial-update behavior is valuable for correct invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no filler. The main purpose is front-loaded, and the usage guidance and partial-update note follow directly. Every sentence adds distinct value: purpose, usage, and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with full schema descriptions and a destructiveHint annotation, the description is largely complete. It covers what the tool does, when to use it, and how it behaves (partial update). It does not specify error handling or edge cases (e.g., setting permissions to empty array), but such details are not essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter description coverage, so each parameter is already documented. The tool description references the main fields ('permissions, template access, or active status') and explains 'grant/revoke access' and 'deactivate,' which adds some interpretive value. However, this is mostly a restatement of schema content, so the incremental value over the schema is modest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates a sub-account's permissions, template access, or active status. It names the specific resource (sub-account) and the updatable aspects, distinguishing it from siblings like create_sub_account, delete_sub_account, and list_sub_accounts. The verb 'update' is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage context: 'Use this to grant/revoke access or deactivate a team member.' This tells the agent when to employ the tool. However, it does not explicitly mention alternatives or conditions like 'For creating a new sub-account, use create_sub_account.' The guidance is clear but not exhaustive.
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?
Annotations already declare readOnlyHint=true, so the description need not restate safety. It adds value by disclosing the exact CSV column set returned, which is useful behavioral context beyond the structured annotation. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler. The purpose is front-loaded, and the column listing earns its place as the only required detail. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple 2-param tool. The missing output schema is compensated by the explicit CSV column listing, and the use cases (reporting/migration) are stated. Nothing an agent needs to call it correctly is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters (templateId, status with enum) are already fully documented in the schema. The description adds no additional parameter-level semantics beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (export), resource (passes), scope (for a template), and format (CSV data). The phrase 'full data dump of passes for reporting or migration' makes the purpose unmistakable and distinguishes it from sibling list_passes and search_passes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it ('Use this to get a full data dump... for reporting or migration'). It provides clear context for selection but stops short of naming alternatives or stating when NOT to use it, given list_passes and search_passes exist as siblings.
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?
Annotations already declare readOnlyHint=true, and the description adds valuable context by enumerating the exact metadata fields returned (url, mime_type, size, width, height, variants, purpose, source_url, timestamps). This supplements the annotation without contradiction, though it does not cover edge cases like errors or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the purpose and efficiently lists return fields. No wasted words; every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool with no output schema, the description covers purpose, input, and expected output fields. An agent has all necessary information to invoke this tool correctly without further ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the fileId parameter with a format hint (starts with file_), giving 100% coverage. The description adds no additional parameter detail, so it meets the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (retrieve) and the resource (file metadata by id), and lists the return fields. This distinguishes it from sibling tools like upload_file_from_url and delete_file, which operate on the same resource but with different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it unambiguous that this tool is for fetching metadata, so an agent knows when to use it. However, it does not explicitly mention alternatives or exclusions, though the distinct resource (file vs. pass/template) makes routing obvious.
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?
The description does not contradict the annotations (destructiveHint: true). However, it adds no behavioral context beyond the annotation itself—no mention of side effects, replacement behavior, or irreversibility. Since annotations provide the destructive hint and the description is otherwise silent, the bar is low and this is adequate, but there is room to disclose more (e.g., whether a notification replaces an existing one).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and immediate usage guidance. No filler, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple notification tool with fully documented parameters, a clear usage distinction, and a relevant annotation, the description is complete. Output schema is not needed for a fire-and-forget notification, and optional params are covered by the schema. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a clear description. The tool description adds use-case context (e.g., balance update, reward earned) but no extra meaning for individual parameters. Baseline 3 applies 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Send a push notification'), resource ('a single pass holder via Google Wallet'), and scope ('targeted messages to individual customers'), clearly distinguishing it from the bulk alternative. It names the exact sibling tool, send_template_notification, making the intended use unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('targeted messages to individual customers') and when to use the alternative ('For bulk notifications to all pass holders, use send_template_notification instead'). This provides clear decision guidance without ambiguity.
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?
Annotations include destructiveHint: true, so the agent already knows this is a mutating operation. The description adds context about the broadcast scope ('every pass holder') and platform coverage ('Apple, Google, Huawei'), but does not disclose additional behaviors like auth requirements, rate limits, or failure handling. With the annotation covering the destructive nature, the added value is moderate, warranting a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The first sentence states the action and scope, the second gives usage context and the alternative. The critical information is front-loaded, making it easy for an agent to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a broadcast notification tool with 5 parameters, the description covers the core use case and distinguishes from the sibling. The schema documents parameter defaults (validFrom, validUntil), and the destructiveHint annotation alerts the agent to the impact. No missing information that an agent would need for correct invocation is apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented in the input schema. The description does not add any parameter-specific meaning beyond what the schema provides. Per guidelines, baseline 3 applies when the schema covers everything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Send a push notification to every pass holder of a template', specifying the verb, resource, and scope. It also explicitly differentiates from the sibling tool notify_pass by naming it as the alternative for individual notifications, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use for announcements that apply to all customers. For individual notifications, use notify_pass.' This states when to use the tool, when not to, and points to the specific alternative, leaving no ambiguity.
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?
The annotation readOnlyHint=true already marks this as safe, so the description need not repeat that. It adds value by disclosing the return content ('location names, addresses, and coordinates'), which is useful because no output schema exists. It doesn't cover pagination or ordering, but for a no-parameter list tool that's a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences: the first states the core action, the second adds usage context and return summary. It is front-loaded with the verb and resource, and every word contributes to clarity. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no parameters, read-only, simple list), the description covers the essential details: what it lists, the account scope, usage purpose, and return fields. It lacks details on pagination or ordering, but for a typical 'list all' tool this is unlikely to hinder correct invocation. The annotations cover safety, so overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description adds no parameter info, which is fine since there are none. The schema coverage is 100% (vacuously), so no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact verb ('List'), resource ('locations'), and scope ('for the authenticated account'). It also specifies the intended use cases ('for reader deployment or pass association'), clearly distinguishing it from create/update/delete location tools and the list_templates sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use this tool ('to see available business locations for reader deployment or pass association'). It doesn't explicitly name alternatives or when not to use it, but the purpose is clear enough that an agent can infer it's the read-only option among location tools.
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?
Annotations only provide destructiveHint: true, but the description adds significant detail: it removes the Firebase auth account and all template access records, and is irreversible. This goes well beyond the annotation and fully discloses the impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. The core action and warning are front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool, the description covers purpose, consequences, and irreversibility. It is complete for an agent to decide whether and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for userId is 'Sub-account user ID to delete', which fully covers the parameter. The description adds no extra parameter detail, but with 100% schema description coverage, a score of 3 is appropriate as it does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('delete') and resource ('sub-account'), and specifies the scope: 'revoke all their access'. It is distinct from sibling tools like delete_template or delete_location, making it unambiguous which resource is affected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly signals caution and implies this is for permanent removal ('cannot be undone'), but doesn't explicitly mention alternatives or when not to use it (e.g., for temporary disabling). Since there is no alternative sub-account deletion tool, the guidance is adequate though not exhaustive.
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?
The description discloses behavioral details beyond the destructiveHint annotation: it deactivates Stripe billing meters, orphans existing passes, and cannot be undone. These specifics help the agent understand the full impact of the call, which the annotation alone does not convey. No contradiction with the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The primary action is stated first, followed by critical consequences and irreversibility. Every sentence serves a purpose: the first states what it does, the second explains the impactful side effects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one required parameter, no output schema, no nested objects), the description covers all essential contextual information: what it does, the deactivation of meters, the orphaned passes, and irreversibility. Nothing an agent needs to make a safe, informed call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, templateId, and the schema description covers it fully ('Template id to delete.'). The tool description does not add additional semantic meaning beyond what the schema provides, so the baseline score of 3 applies; no extra guidance is needed or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'delete' with the resource 'template' and states the exact scope: permanent deletion and deactivation of billing meters. It gives clear behavioral context (orphaned passes) and the impossibility of undo, which unambiguously distinguishes it from sibling tools like update_template or create_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this is the tool for permanently removing a template and warns of consequences (orphaned passes, irreversible). It does not explicitly name alternative tools or exclusion criteria, but for a destructive delete operation the intent is obvious, and the warning about consequences serves as implicit guidance for when not to use it (e.g., if retention is needed).
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?
Annotations already include readOnlyHint=true, so the description doesn't need to restate that. The description adds value by specifying the return content: 'Returns sub-account details with template access counts.' This tells the agent what to expect in the output, which is not covered by the annotations or schema. There is no contradiction with the read-only annotation; 'List' clearly indicates a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: the first states the core function, the second gives usage context, and the third describes the return value. No redundant or filler wording. The purpose is front-loaded, making it easy for an agent to quickly grasp the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and a read-only annotation, the description covers everything an agent needs: what it lists, why to use it, and what it returns. There are no gaps that would leave an agent uncertain about invoking it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema imposes no burden on the description. The baseline for 0 parameters is 4 per the rubric. The description compensates by explaining what the result contains, which is sufficient given the lack of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List all sub-accounts (team members) for the main account.' It clarifies scope ('for the main account') and distinguishes from sibling tools like create_sub_account, update_sub_account, and delete_sub_account by focusing on the listing action. The parenthetical '(team members)' removes ambiguity about what a sub-account is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'Use this to see who has access and their template permissions.' It implies the purpose of auditing access. It doesn't explicitly mention alternatives or when not to use it, but given the tool has no parameters and is a straightforward list operation, this is adequate guidance. A slight enhancement would be noting it's the read-only option among sub-account tools.
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?
The description goes far beyond the annotations (destructiveHint: true) by disclosing the asynchronous provisioning behavior — the create response returns status 'active' but certificate fields are null until a few seconds later — and instructs the agent to re-read the template before concluding failure. It also details the NFC flag timing, stamp card hero requirements, and icon sourcing rules. This rich behavioral context directly aids correct invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured, with the main purpose front-loaded and subsequent details organized into thematic paragraphs (NFC, stamp cards, values, strip, icon, web link). Each section adds essential information for a complex tool. While lengthy, every part earns its place, and the structure aids scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 11 parameters, nested objects, and no output schema, the description covers the most critical and error-prone aspects: required vs optional fields, async provisioning, stamp card prerequisites, icon sourcing, and the value-filling rule. It provides enough detail for an agent to call create_template correctly without additional lookups, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial meaning beyond the schema. It explains the `pass` object in depth: stamp card special requirements (useStampCollection, stampCount, stamp, hero), the 'custom' fieldValue rule, Apple strip generation from hero, icon sourcing best practices, and webLink/webAppLabel semantics. It also carifies the `enableNFC` flag's effect on certificate entitlement. This goes well beyond baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear action: 'Create a new pass template.' The verb 'Create' and resource 'pass template' are unambiguous, and the description distinguishes it from siblings like list_templates and update_template by focusing solely on creation. It also lists required fields, which further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use this tool: to create a new pass template. It also provides post-call guidance by advising to re-read the template with get_template to verify certificate provisioning, and warns that the NFC flag must be set before creation. However, it does not explicitly contrast with alternatives like update_template, though the purpose is implied by the name and opening sentence.
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?
Annotations provide destructiveHint=true, but the description does not contradict it; it simply adds rich behavioral context beyond annotations: SSRF protection (refusing private/loopback IPs), max source size (10 MiB), accepted formats, transcoding to PNG when purpose is supplied, and generation of 1x/2x/3x variants. It also discloses the direct-use warning about URL provenance. This fully discloses behavior beyond what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core action and return value. The second paragraph is a crucial warning about URL usage, which, while verbose, directly prevents the most common failure. No sentence is redundant; it is detailed but appropriately organized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, this description is exceptionally complete. It explains the return value (file id and usage in templates), parameter behaviors (variants, transcoding), constraints (size, formats, SSRF), failure handling (404 guidance), and provides practical usage guidance. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful semantics beyond schema: for 'url' it specifies public HTTP(S), size limit, and SSRF refusal; for 'purpose' it explains that variants are generated and transcoding occurs. 'templateId' is succinctly described as scoping for organization. While not exhaustive for every edge case, it substantially enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Fetch', 'validate', 'store'), names the resource ('public image URL', 'Walletap-managed storage'), and explains the return value (file id). It clearly distinguishes from sibling tools like get_file, delete_file, and list_templates by describing the unique upload-from-URL operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is explicit guidance on when to use the tool (when you have a user-provided or fetched URL) and clear exclusions: 'Do not construct a plausible-looking asset URL from a brand name' and 'if the fetch reports 404, find a different one rather than retrying'. This directly addresses common failure modes and instructs the agent on appropriate alternatives (ask the user), leaving no ambiguity about invocation.
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?
The annotations only provide destructiveHint: true. The description adds extensive behavioral transparency: it discloses merge-patch semantics, the deep-merge behavior of `pass`, the wholesale replacement of `locations`, and the critical caveat that already-issued passes are not rebuilt on read. It also explains the consequences of omitting `hero` or `icon` (e.g., stamps not rendering, Walletap logo). This is far beyond what annotations provide and fully transparent about the mutation's effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Though long, every sentence earns its place. The description is front-loaded with the core update semantics, then organizes detail into labeled sections (STAMP CARDS, VALUES, APPLE STRIP, ICON, WEB LINK). It is structured to be scannable, with critical caveats called out in caps. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter tool with no output schema and a very low coverage, the description is remarkably complete. It covers the main behaviors, exceptions, and pitfalls for the most impactful fields. While not every parameter is individually elaborated, the guidance is sufficient to correctly update a template. The complexity of `pass` is thoroughly addressed, and the locations exception is explicitly flagged.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 18%, so the description carries the burden. It provides deep semantic detail for the most complex parameter, `pass`, including valid keys, image formats, stamp-card requirements, and value-filling behavior. It also explains the semantics of `locations`. However, parameters like `beacons`, `passPage`, `enrollForm`, and `cardSharing` are not described beyond the schema. Given the low coverage, the description compensates well for the key parameters but not exhaustively for all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('partial update'), the resource ('existing template'), and the core semantics (RFC 7396 merge-patch). It clearly distinguishes from siblings like create_template and delete_template, and even names the alternative for a different task (creating a new template). The phrase 'partial update' immediately signals what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: send only fields to change, with merge-patch semantics. It provides clear directives on how to handle `pass` (deep-merge), `locations` (replace wholesale), and gives concrete guidance for stamps, icons, apple strip, and web links. It also warns about already-issued passes. This is extensive usage guidance that goes far beyond a simple when/where.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/walletap/walletap-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server