VoidMob MCP
OfficialServer Quality Checklist
Latest release: v1.1.5
- Disambiguation5/5
Each tool targets a distinct resource and action, with clear ID conventions (ver_, ren_, ded_) and service-specific search tools. Overlapping actions like reuse_number vs re_rent_rental are differentiated by resource type. No two tools have ambiguous boundaries.
Naming Consistency5/5All tools follow a verb_noun pattern with consistent verbs for common actions: search_, purchase_, get_, list_, create_, delete_. Even multi-word actions like toggle_auto_renew and re_rent_rental maintain the pattern. No mixing of camelCase or inconsistent verb styles.
Tool Count4/5The 28 tools cover four distinct service domains (SMS, dedicated numbers, eSIMs, proxies) plus account and order management. While above the typical threshold, the count is justified by the breadth of the platform; no redundant tools exist. The proxy domain has 11 tools but each serves a unique management function.
Completeness4/5Core lifecycle operations are covered for each service: search, purchase, status, and resource-specific management (reuse, topup, rotate, etc.). Minor gaps include no explicit cancel for dedicated numbers/eSIMs and no edit for proxy lists, but workarounds are documented (toggle_auto_renew, delete+recreate). Overall, agents can complete intended workflows without dead ends.
Average 4/5 across 28 of 28 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 16 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 8 times in the last 30 days.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does not state that the operation is read-only, nor does it disclose any limitations, prerequisites, or return behavior beyond the act of listing.
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, compact sentence that immediately states the action and resource. It is front-loaded and contains no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema, no annotations), the description could be sufficient, but it omits crucial context about the parameter and behavioral details. It is not complete enough for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'proxy_id' parameter at all. The parameter name is self-explanatory, but the description fails to add any meaning about how it is used or what a shared proxy is in this context.
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 specific verb 'List' with a clear resource 'proxy lists' and adds a parenthetical clarification that distinguishes them from other proxy-related entities. This clearly differentiates it from sibling tools like create_proxy_list and delete_proxy_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description implies it is for viewing proxy lists, but it does not mention when not to use it or suggest relevant sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the action is to rotate the password and that new credentials are returned, but it does not disclose side effects such as whether existing sessions are invalidated, whether authorization is required, or whether there are any rate limits. This is minimal disclosure for a mutating 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 two concise sentences with no filler. It front-loads the primary action and follows with the return value, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and no output schema, the description is adequate: it conveys the operation and the output. However, it lacks contextual details about side effects or prerequisites, which would be expected for a mutating operation with no annotation support.
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 0% description coverage, and the description does not explicitly mention proxy_id. However, the parameter name 'proxy_id' is self-explanatory, and the description's reference to 'proxy gateway password' implies that proxy_id selects the target proxy. The description adds no further meaning, but the single parameter is clear enough to avoid confusion.
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 'Rotate' and the specific resource 'main proxy gateway password', making the tool's purpose explicit. It is also well-differentiated from sibling tools like rotate_proxy_ip (which rotates the IP) and renew_proxy (which renews the proxy), so there is no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It does not mention that this tool is for password rotation specifically, nor does it exclude cases where IP rotation or proxy renewal would be more appropriate. The usage context is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses one important behavioral trait (immediate credential invalidation), but does not mention whether the deletion is permanent, reversible, or if special permissions are required.
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, both purposeful: the first states the core action, the second adds an immediate consequence. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks essential context: no output schema, no annotations, and parameters are unnamed in terms of semantics. The agent is left guessing about what happens upon deletion and how to provide parameters correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and no parameter explanation in the description, the agent has no idea what 'proxy_id' and 'list_id' refer to or how they relate. The relationship between the two parameters is ambiguous.
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') and the resource ('a proxy list'), with an additional consequence that adds specificity. It distinguishes from sibling tools like create_proxy_list and list_proxy_lists.
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 context is clear: this tool is for deleting a proxy list. The phrase 'credentials stop working immediately' provides a usage hint (avoid if credentials are still needed), but no explicit alternatives or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the action (toggle auto-renewal) with no mention of side effects, permissions, idempotency, or return value. This is a mutation tool, and the description omits important operational context beyond the core action.
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 sentence, immediately states the action and resource types, and contains no filler. It is front-loaded with the verb and uses efficient language.
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 tool is simple with only two parameters and no output schema, but the description does not mention what happens after toggling (e.g., whether the new state is returned or a confirmation is given). Given the lack of annotations and output schema, the description is adequate for basic use but leaves minor gaps around the result of the operation.
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 50%: rental_id has a format hint, while auto_renew has no description. The tool description clarifies that rental_id accepts ren_xxx or ded_xxx, matching the schema, but does not add meaning to auto_renew beyond what the tool name and description already convey. The description partially compensates for the low 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 uses a specific verb ('Turn on/off') and clearly identifies the resource (auto-renewal for long-term rentals and dedicated numbers). It distinguishes itself from sibling tools, as no other sibling mentions auto-renewal toggling, making its 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly scopes the tool to long-term rentals (ren_xxx) and dedicated numbers (ded_xxx), giving clear context for when to use it. It does not mention exclusions or alternatives, but since no sibling tool offers this functionality, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions the prerequisite 'active eSIM' but omits critical details for a purchase operation: financial implications, error behavior on invalid product ID or inactive eSIM, idempotency, and side effects. This is a significant gap for a tool that likely charges money.
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 sentence with a clear conditional structure, front-loaded with the main action. No wasted words; every clause earns its place.
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 tool has no output schema and no annotations. The description covers both modes and the prerequisite but omits financial consequences, error cases, and return data. Given that this is a purchase tool, the missing context is notable, though the core behavior is sufficiently outlined.
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 0%, so the description must compensate. It explains that topup_product_id toggles between browse and purchase, and implies esim_id targets the active eSIM. This adds meaning beyond the raw schema, though esim_id semantics remain implicit.
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 dual purpose: browsing top-up products or purchasing a specific top-up, with the distinction based on the presence of topup_product_id. It specifies the resource (active eSIM) and differentiates from purchasing a new eSIM.
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 guidance on when to include topup_product_id (browse vs purchase), and implies use case for active eSIMs. It does not explicitly exclude alternatives but the context is clear enough for an agent to select this tool over purchase_esim or other 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?
With no annotations provided, the description must indicate behavior itself. The verb 'Read' clearly communicates a non-mutating, safe operation, and it enumerates the specific data returned (status, usage, gateway credentials). However, it does not disclose potential rate limits, authentication requirements, or whether any side effects exist (e.g., logging), but for a simple read operation this is acceptable.
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, front-loaded sentence of 11 words. It immediately states the action and then lists the key data items. Every word contributes value, with no repetition or filler.
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?
This is a simple tool with one parameter and no output schema, so the description does not need to explain return values in detail. It does mention the three types of data returned. However, it lacks any information about the parameter (proxy_id) and provides no usage guidance, which in the absence of annotations and schema descriptions leaves some gaps for an agent. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains one required parameter (proxy_id) with no description, and the schema description coverage is 0%. The tool description does not mention or explain this parameter at all. While the purpose implies the proxy_id identifies the proxy, it adds no explicit semantics, format, or context beyond the schema, so it fails to compensate for the lack of schema documentation.
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 specific verb ('Read') and clearly identifies the resource ('a proxy's status, usage, and gateway credentials'). It distinguishes itself from sibling tools by combining multiple data types in one call, which is unique among the proxy-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to fetch status/usage/credentials for a proxy, but provides no explicit when-to-use or when-not-to-use guidance compared to alternatives. There are no exclusions or alternative tool references, so it falls short of a 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the 202 Accepted response, status=provisioning, and the 1-2 minute activation delay, which is valuable context. It does not cover failure modes, costs, or required permissions, but the core async behavior is well conveyed.
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 concise, two sentences long, front-loaded with the main action, and includes only essential details. Every sentence adds value: the main action, the response status, and the polling workflow.
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 async workflow and the return status, which is good, but it fails to explain the only required parameter (plan_id) or any prerequisites like having an existing proxy plan or available funds. Given the low complexity (one param), this is a notable gap preventing full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the plan_id parameter at all. It does not mention that plan_id is required, how to obtain it, or what it represents. With only one parameter, the description should have provided at least a hint of its meaning, but it is entirely absent.
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 specific verb 'purchase' and resource 'proxy plan', clearly distinguishing it from sibling tools like get_proxy_status, renew_proxy, or rotate_proxy_ip. It unambiguously states 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?
The description provides explicit follow-up instructions to poll get_proxy_status until status becomes 'active', which is a clear usage workflow. It does not explicitly mention alternatives or when not to use the tool, but the purpose is so specific that differentiation is implicit from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key output (verification price, LTR tiers) and the US non-VoIP scope, which is useful. However, it does not explicitly state the operation is read-only, nor does it mention authentication, limitations, or error conditions, so transparency 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, front-loaded with the action and resource, and contains no filler words. Every clause earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search tool with no output schema, the description covers the essential components: what is searched, key output fields, and a scope constraint. It could mention pagination or response format, but these are not critical given the tool's simplicity, 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 already provides a 100% coverage description of the 'query' parameter as a substring filter (e.g., 'telegram'). The tool description adds no extra meaning for the parameter, so it matches the baseline for fully documented 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 specific verb ('search') and resource ('US non-VoIP SMS services'), making it clear what the tool does. It distinguishes from sibling tools like search_dedicated_countries, search_esim_plans, and search_proxies by explicitly scoping to non-VoIP SMS services in the US.
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 this tool is used for finding SMS verification services, but it does not explicitly state when to use it versus alternatives. No exclusions or situational guidance are provided, leaving the usage context to be inferred from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the return is an image and that clients may render it inline, which is useful behavioral detail. However, it does not mention potential error states (e.g., invalid eSIM ID), whether the QR is a one-time activation code, or any permission or state requirements.
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, front-loaded with the core purpose, and contains no filler. Every clause adds value: it states the action, the resource, the output type, and a practical rendering detail.
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 one-parameter tool with no output schema, the description covers the essential aspects: what it does, what it returns, and how the result is typically presented. Missing details like error handling are less critical here, but the description could still mention the nature of the eSIM ID for full clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain what esim_id refers to or how the agent should obtain it. The parameter name is somewhat self-explanatory, but the description adds no guidance beyond the schema, failing to compensate for the lack of schema descriptions.
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 starts with a specific verb ('Fetch') and resource ('activation QR code for an eSIM'), clearly distinguishing it from sibling tools like get_esim_status or topup_esim. It also states the output format ('as an image'), making its function 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 second sentence explains that most MCP clients render the image inline for direct scanning, which implies the tool is intended for obtaining a scannable QR code. It gives context on the output behavior but does not explicitly mention when to prefer this over alternatives or any prerequisites such as having an eSIM ID from a prior purchase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral disclosure. It mentions 'purchasing' (a financial transaction) and 'Quote-then-commit,' but does not explain how commit works, what the response contains, or any side effects. The quote-then-commit flow is ambiguous given only proxy_id is provided.
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 short sentences, front-loaded with the main purpose. Every word contributes meaning, and there is no redundant or filler content.
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?
For a simple one-parameter tool, the description covers the core purpose but leaves the quote-then-commit process undefined and does not describe the return value even though there is no output schema. An agent would be uncertain about the expected response or follow-up actions.
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?
The schema has one parameter (proxy_id) with zero description coverage. The description clarifies that the proxy is the one whose expiry is being extended, which gives semantic meaning beyond the raw schema. For a single, self-explanatory parameter, this is sufficient.
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 ('extend') and resource ('proxy's expiry') with the method ('purchasing another period'). It clearly distinguishes from siblings like topup_proxy or get_proxy_status by focusing on renewal through purchase.
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 implies usage: when you want to extend a proxy's expiry by buying more time. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to know when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It notes the create operation and the lack of an edit path, but does not disclose success/error responses, potential side effects, or whether the operation is synchronous. This is a partial gap, but the description still provides some context beyond the bare action.
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 purpose, and every sentence adds value. 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?
The tool has 11 parameters and no output schema, but the description captures the essential domain logic (geo-targeting modes and the no-edit workflow). It does not explain rotation modes or format options, but these are documented in the schema. The description is adequate for understanding the tool's purpose and main constraints.
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 already covers 73% of parameters with descriptions, including mutual exclusivity and valid values. The description reinforces the two input modes and the optional subfilters, but does not add new details about formats, defaults, or rotation behavior beyond what the schema offers. Baseline 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 the tool creates a new geo-targeted proxy list, using the verb 'create' and the resource 'proxy list', distinguishing it from sibling tools like list_proxy_lists and delete_proxy_list. The phrase 'geo-targeted' adds specificity about the list's purpose.
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 gives explicit guidance on when to use the tool (for creating) and when not to (editing existing lists), saying 'To edit an existing list, delete it and create a new one.' It also explains the two mutually exclusive input modes (single country vs. countries array), providing context for parameter selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It discloses the price-locking behavior ('fetches the live price and ties max_price_cents to it'), which is valuable, but it omits other key traits like reversibility, failure handling, or what the response contains. The unexplained mention of 'max_price_cents' (not in schema) is confusing and could mislead, preventing a higher score.
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: the first states the core action, the second explains the quote-then-commit mechanism. No redundant words or filler; every phrase earns its place.
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 tool with no annotations or output schema, the description covers the essential purchase flow and price guarantee. However, it lacks clarity on what happens after purchase (e.g., order confirmation, eSIM delivery), which is significant for a transactional tool, but given the simplicity, it is mostly 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 fully documents plan_id with 'prod_xxx from search_esim_plans', so baseline is 3. The description adds no extra parameter-level detail; its mention of max_price_cents is about an internal price cap, not an input parameter, and could even cause confusion about the parameter list.
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 'Purchase an eSIM plan' with a specific verb and resource, distinguishing it from siblings like search_esim_plans, get_esim_status, and topup_esim. The term 'Purchase' is unambiguous and directly contrasts with search/topup 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 'Quote-then-commit' phrase provides clear procedural context: the agent should first see a live price before committing. However, it does not explicitly name alternatives or exclusions such as when to prefer topup_esim or re-purchase scenarios, so it falls short of full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that results contain the full plan shape, including specific features, so the agent knows no additional details call is needed. This goes beyond the schema, but it does not mention pagination behavior, rate limits, or other side effects, which are not critical for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one well-structured sentence that front-loads the core purpose and then packs useful details about output shape. Every word earns its place, and the parenthetical list is concise yet informative. No redundancy or unnecessary padding.
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?
Given the tool has 8 optional parameters, no output schema, and no annotations, the description provides useful context about return values (full plan shape) but misses guidance on pagination (cursor), filter usage, sorting, or how to combine filters. It is functional but not complete for an agent to take full advantage of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 25% (query and country have descriptions). The tool description focuses entirely on output shape and does not add meaning to input parameters like has_5g, has_hotspot, min_data_gb, min_days, limit, or cursor. With low schema coverage, the description should compensate but fails to explain filters or pagination 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 'Search global eSIM data plans' with a specific verb and resource, and it distinguishes this tool from siblings like search_sms_services and search_dedicated_countries by focusing on eSIM plans. It also clarifies that results include the full plan shape, further differentiating it from any potential plan-details tool.
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 implies usage when searching for eSIM plans and explicitly notes that a separate plan-details tool is unnecessary. However, it does not explicitly state when this tool should be used versus alternatives like purchase_esim or get_esim_status, nor does it mention exclusions for other search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It explicitly discloses that this is a read operation and that it combines two API calls in parallel, which is useful behavioral context beyond a vague 'get status'. With no annotations, this partially covers safety and request structure, though it omits response format and error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, with the first front-loading the main purpose and the second adding endpoint detail. No wasted words.
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's simplicity—one required parameter and no output schema—the description covers the key returned categories and the combined-call behavior. It lacks detailed output/error information, but that is less critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter, esim_id, with no description, and schema description coverage is 0%. The description does not explain the parameter or its format; it only weakly implies it via 'an eSIM's'.
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 'Read' and clearly identifies the resource: an eSIM's current status, plan info, and data usage. Mentioning that it combines two endpoints (GET /v1/esims/:id + /usage) distinguishes it from sibling tools like get_esim_qr.
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 clearly states this tool is for reading eSIM status and usage, providing appropriate context for when to use it. It does not explicitly name alternatives or state when not to use it, but the sibling list makes alternatives obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses an important behavioral aspect: quote-then-commit pricing, ensuring 'you never pay above what you saw.' This adds meaningful context beyond the schema. However, it does not mention potential side effects or return behavior, but the pricing guarantee is significant.
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, each serving a purpose: stating the main action, explaining kinds, and providing an alternative plus pricing behavior. It is front-loaded with the core purpose and avoids unnecessary filler.
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 purpose, kinds, alternative, and pricing behavior, but lacks information about return values or error conditions. Since there's no output schema, the agent is left guessing what the response contains. The mention of max_price_cents not in the schema also creates a completeness gap, making it less reliable for full 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 description adds value by explaining the 'kind' parameter values (verification: single SMS/20min; rental: timed LTR) and implies duration usage. However, it references 'max_price_cents' which is not present in the input schema, creating confusion for an agent attempting to invoke the parameter. Schema already covers duration and service_id, so the description's net contribution is mixed.
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 tool's purpose: 'Rent a US non-VoIP phone number.' It immediately distinguishes between two kinds ('verification' vs 'rental') with specific meanings, and explicitly contrasts with purchase_dedicated_number for a different use case, making it distinct from siblings.
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 guidance: 'For a private all-services monthly number, use purchase_dedicated_number instead' gives an explicit alternative. It also explains when to use each kind (verification for single SMS/20min, rental for timed LTR), but could be more explicit about other exclusions. Overall, it gives solid context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It explains the core behavior (rotating to a new IP) and distinguishes dedicated vs shared behavior, but does not mention potential side effects (e.g., whether the old IP is invalidated, if there are fees, rate limits, or how quickly the rotation takes effect).
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 quickly addresses the shared-proxy exception with concrete alternatives. Every word earns its place; no 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 simple single-parameter tool with no output schema, the description covers the main use case and distinction from shared proxies. It lacks some nuance (e.g., prerequisites, consequences), but is largely complete for the tool's apparent complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not address the 'proxy_id' parameter at all. While the parameter name is somewhat self-explanatory, the description adds no guidance on how to obtain it, its format, or any related constraints, so it fails to compensate for the lack of 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 states the specific action ('Rotate a dedicated proxy to a new IP') and clearly distinguishes it from sibling tools by noting that shared proxies rotate per-request and pointing to alternatives (create_proxy_list / list_proxy_lists). This provides a precise verb+resource+scope.
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?
It explicitly states when to use the tool (for dedicated proxies) and when not to (shared proxies), naming the alternative tools to use instead. This gives clear decision-making guidance beyond what the schema provides.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses a useful behavioral trait: messages accumulate for the life of the number, making polling necessary. It also clarifies that parsed codes are included. It does not mention error handling, auth, or rate limits, but the core behavior is transparent.
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, front-loaded with the action and resource. Every sentence adds value: the first states what it reads, the second explains the polling behavior. No wasted words.
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 tool with one parameter and no output schema, the description is fairly complete. It indicates the return content (status and SMS messages, including parsed codes) and provides usage context. It falls short of 5 because it doesn't mention any error cases or caveats, but those are not critical for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The schema already documents number_id as 'ded_xxx from purchase_dedicated_number or list_orders.' The description adds no extra parameter semantics, but the schema fully covers the parameter meaning. No deduction 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 uses a specific verb ('Read') and clearly identifies the resource ('a dedicated number's status and received SMS messages'). It distinguishes this tool from sibling tools like get_rental or get_esim_status by focusing on dedicated numbers and SMS retrieval.
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 this tool: 'poll this tool after directing an SMS at it.' It also explains that messages keep arriving for the life of the number, implying a polling pattern. However, it does not explicitly mention when not to use it or name alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that ephemeral verifications are excluded, which is a critical behavioral limitation. It also states the tool returns both active and past orders across multiple resource types. Missing details like pagination or response format, but the disclosed exceptions and scope add significant value.
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. The first states the main purpose and scope; the second adds an important limitation. Every sentence serves a purpose, with no filler 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 a crowded sibling space and no output schema, the description successfully conveys the tool's broad scope and a key exclusion. It does not explicitly differentiate from targeted status tools like get_rental or get_esim_status, but the scope statement helps the agent infer when to use this umbrella listing. The lack of response format details is somewhat compensated by the clarity of the listing concept.
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 2 parameters: 'kind' with an enum and description, and 'limit' with only min/max/default. Description does not mention parameters, but it does enumerate the specific kinds covered, which aligns with the enum. With 50% schema coverage, the description adds some context for 'kind' but nothing for 'limit', leaving its semantics only partially clarified.
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 specific verb and resource: 'List the user's active and past orders across SMS rentals, dedicated numbers, eSIMs, and proxies.' It distinguishes the tool from siblings by enumerating the covered order types and explicitly excludes ephemeral verifications, clarifying its precise 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?
Provides a clear usage note that ephemeral verifications are NOT listable and directs the user to use the rental id as the handle for those. However, it does not explicitly name an alternative tool for those cases, so the guidance is more implicit than 'use X instead.' The sibling list does include get_rental, but that connection is not made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the quote-then-commit behavior with max_price_cents protection, the return format (ded_xxx id), and the follow-up polling action. This is valuable beyond the schema, though it omits edge cases like failure modes or refund policies.
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, front-loaded with the core purpose, followed by the unique behavioral selling point and return/next-step guidance. Every sentence earns its place with zero filler.
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 lack of annotations and output schema, this description does a good job explaining the purchase flow, output ID, and how to consume it. It doesn't cover every aspect (e.g., auto-renew behavior) but the schema handles auto_renew. The overall context is sufficiently complete for an agent to invoke 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?
The schema already documents both parameters (country and auto_renew) with descriptions, at 100% coverage. The description merely echoes 'in a country from search_dedicated_countries' which adds no new semantic meaning beyond the schema's parameter description. Baseline 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 opens with 'Buy a dedicated monthly number in a country' which is a specific verb+resource+scope. It also references search_dedicated_countries as the source and mentions returns 'ded_xxx id', clearly distinguishing it from sibling tools like get_dedicated_number (which reads SMS) and rent_number (rental).
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 clearly states that this tool is for buying dedicated numbers sourced from search_dedicated_countries, implying when to use it. However, it does not explicitly mention when not to use alternatives or list exclusions, so it falls short of full guidance with explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the cost ($0.50) and the two modes (free/paid) with their conditions, but does not reveal potential side effects such as whether the verification is consumed, if the number changes, or any failure modes when conditions are not met.
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 redundant information. It front-loads the primary action and then explains the free/paid conditions efficiently.
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 tool with no output schema and no annotations, the description covers the essential functionality and pricing. It lacks details about return values or error handling, but the low complexity and good schema coverage for rental_id make the description sufficiently complete.
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 50% with rental_id documented as 'ver_xxx from a verification' but paid lacking description. The description adds semantics by explaining that paid reuse costs $0.50 and is gated on allow_paid_reuse, and free reuse on allow_reuse, giving the 'paid' parameter meaningful context beyond its type/default.
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 specific verb ('Reuse') and resource ('completed/expired verification') with a clear outcome ('receive another SMS'). It distinguishes itself from sibling tools like rent_number and re_rent_rental by focusing on verification reuse rather than renting or re-renting a number.
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 clearly states when free reuse is available (allow_reuse true) and when paid reuse is available (allow_paid_reuse true), including the price. It provides clear context for usage but does not explicitly mention alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains the nature of plans (shared rotating IPs, billed by data), what results contain, and that region/city/ISP targeting happens elsewhere. This is strong behavioral context, though it does not mention rate limits or authentication requirements.
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 action, and every sentence adds value. It avoids redundancy and packs essential information into a compact structure.
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?
Even though there is no output schema, the description lists the exact result fields (plan id, location, data allowance, duration, price), which fully covers return value expectations. It also clarifies post-purchase configuration, making the tool's scope clear and complete for a search operation.
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% for both parameters, so the baseline is 3. The description adds context that results include data allowance, which relates to 'min_data_gb', but it does not provide additional parameter usage details beyond what the schema already offers.
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 'Search available mobile proxy plans' which is a specific verb+resource. It further distinguishes the tool from siblings by specifying 'shared rotating mobile IPs, billed by data', clearly separating it from SMS, eSIM, and dedicated country searches.
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 clearly implies this is the tool for searching mobile proxy plans and notes that targeting is configured later via 'create_proxy_list', giving a 'when not' clue. However, it does not explicitly name alternative sibling tools like 'search_sms_services', so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It discloses important refund behavior: potential refunds for ver_xxx and non-refundable for ren_xxx, and instructs to check the response. This goes beyond a generic 'cancel' statement, though it does not cover other behavioral aspects like irreversibility or timing.
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 very concise: a one-sentence purpose plus two short clarifying sentences. It is front-loaded with the actionable verb and resource, and every sentence provides relevant caveats. No unnecessary words or repetition.
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 one required parameter and no output schema, the description covers the core purpose, refund nuances, and advises checking the response. It does not describe the response structure or potential errors, but given the tool's simplicity, it is sufficiently complete for an agent to invoke 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?
The schema has one parameter (rental_id) with no description. The description adds meaning by indicating the identifier format (ver_xxx vs. ren_xxx), helping the agent understand valid inputs. This compensates for the 0% schema description coverage, although it does not fully describe the parameter's purpose.
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 starts with 'Cancel a rental,' which is a specific verb and resource, clearly distinguishing it from sibling tools like get_rental, rent_number, or re_rent_rental. It further scopes the tool by mentioning refund behavior for verification rentals (ver_xxx) vs. long-term rentals (ren_xxx).
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 useful context on when cancellation is refundable (ver_xxx with no message arrived) and when it is non-refundable (ren_xxx), guiding the agent in setting expectations. It stops short of explicitly saying 'use this instead of X' or listing alternative tools, but the context is clear enough for a cancellation operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the cascading behavior and how parameters affect results (e.g., country=US®ion=California -> cities). It does not describe output format or error cases, but for a read-only discovery tool, the key behavioral trait is well covered.
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, information-dense sentence with examples. It front-loads the purpose and then provides a compact cascade illustration. No wasted words.
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 3 optional params and no output schema, the description explains the cascade well. It does not specify the return shape or pagination, but the examples give enough context for an agent to infer the tool's behavior. Slight gap around what the final 'ISPs' output looks like.
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 only 33% (only country has a description). The description compensates by illustrating how all three parameters interact in the cascade (e.g., +city=Los%20Angeles -> ISPs), adding meaning beyond the schema. It falls short of fully specifying each parameter's possible values or formats.
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 verb+resource: 'Cascading geo discovery for proxy list targeting.' It distinguishes the tool from siblings by specifying a unique cascading behavior, and the examples clarify the exact purpose.
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 patterns ('No params -> countries; country=US -> regions...'), which serve as implicit when-to-use guidance. However, it does not explicitly mention when not to use or compare with alternatives like search_proxies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the timing behavior (SMS codes typically arrive 10-60s after rent_number) and the need for polling, which adds useful behavioral context beyond a simple read statement.
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?
Three sentences, front-loaded with the main purpose, followed by usage instructions and timing guidance. Every sentence is purposeful, with no redundancy or filler.
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 tool with one parameter and no output schema, the description covers purpose, usage, and polling behavior. It lacks explicit return format or error handling, but given the low complexity, it is adequately complete.
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% for rental_id, but the description adds essential meaning by instructing where to get the ID ('from rent_number') and explaining the format (ver_xxx/ren_xxx). This goes beyond the schema's terse description.
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 'Read a rental's current status and any messages received' with a specific verb and resource. It distinguishes this from sibling tools by referencing rent_number as the ID source and describing a read operation.
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?
Provides explicit usage context: 'Pass the ID you got from rent_number' and 'poll this tool until status changes' with a timing window. It does not explicitly mention when not to use or name alternatives, but the guidance is specific and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses key traits: only works on expired rentals, requires re_rent_available=true, re-uses the original duration, and uses the current price. It does not mention side effects like whether a new rental ID is created, but the core behavior is transparent.
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?
Three concise sentences. The first states the action, the second gives the precondition, and the third clarifies the duration behavior. No filler or redundancy; every sentence earns its place.
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?
The tool has one parameter, no output schema, and no annotations. The description covers the essential context: what it does, when it works, and what not to pass. It stops short of describing the return value or result details, but for a simple action tool this is acceptable, though it could be slightly more complete.
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% with rental_id already described as 'ren_xxx from an expired LTR with re_rent_available=true.' The description adds value by explaining why only one parameter is needed ('no duration argument') and clarifying the re-rent concept, which complements the schema rather than repeating it.
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 specific verb+resource: 'Re-rent the same number for another period at the current price.' It clearly distinguishes from sibling tools like rent_number (new rental) and reuse_number by focusing on an expired rental with re_rent_available=true.
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 explicit when-to-use conditions: only for an expired rental with re_rent_available=true and the provider has not released the number. It also states 'no duration argument' to clarify what not to pass. However, it does not explicitly name alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds meaningful context by defining dedicated numbers (private, receive SMS for ALL services, renew monthly, stay yours until cancelled) and mentions that the list includes personal monthly price and stock status. While it doesn't explicitly state that this is a read-only operation, the verb 'List' implies safety, and the added domain context goes beyond a minimal description.
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 main action, and the second sentence provides relevant background without unnecessary fluff. Every word earns its place.
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 zero-parameter list tool, the description is complete: it states what is listed (countries), the included fields (price, stock status), and gives domain context about dedicated numbers. There is no output schema, but the description gives enough for an agent to infer basic response expectations.
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 baseline is 4. The description doesn't need to explain any parameters, and the schema is empty. The description adds no parameter info, but none is required.
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 'List' and clearly identifies the resource: countries where dedicated numbers are offered. It also states the included details (monthly price, stock status), making it distinct from sibling tools like search_sms_services or purchase_dedicated_number.
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—when needing to see countries with dedicated numbers—and explains what a dedicated number is, which helps with scope. It does not explicitly mention alternatives or when not to use it, but the purpose is clear enough for an agent to make a basic choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses a quote-then-commit process and the pricing formula (per_gb * additional_gb). This goes beyond the schema and provides useful behavioral context, though it does not mention reversibility or permissions.
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, front-loaded with the primary purpose. Every clause adds value—purpose, process, and pricing—with no unnecessary filler.
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?
The description adequately covers the main aspects: what it does, how pricing works, and the quote-then-commit nature. No output schema exists, so return values are not required, but the description could mention prerequisites or side effects for even better completeness.
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 0%, so the description must compensate. It clearly explains the role of additional_gb in the pricing formula and implies how proxy_id is used ('shared proxy plan'). However, it does not explicitly define proxy_id, leaving it to inference.
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?
Clear verb+resource: 'Add more data to a shared proxy plan'. Differentiates from siblings like purchase_proxy or renew_proxy by specifying the action (add data) and the resource (shared proxy plan).
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?
States when to use: to add more data to a shared proxy plan. Does not explicitly mention alternatives or when not to use, but the context is clear enough for an agent to select this tool over purchase_proxy or renew_proxy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It conveys that this is a read-only operation by stating it retrieves account information, and adds useful context about rate limits and fund checking. It does not explicitly state 'no side effects' but the read-only nature is strongly implied.
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 function, followed by a concise usage note. No wasted words or repetition of schema details.
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?
Despite no output schema, the description clearly states what will be returned (id, balance, rate limits) and when to use the tool. Given its simple nature (no params), this is fully complete for an AI agent to understand and invoke 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?
The tool has zero parameters, so the description need not explain parameter meaning. The baseline of 4 applies as the description adds no parameter details, but none are 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 uses a specific verb ('Get') and clearly identifies the resource ('authenticated account'), listing the exact contents (id, USD wallet balance, per-endpoint-group rate limits). This distinguishes it from sibling tools which focus on SMS, rentals, proxies, and other operations.
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?
Explicitly provides a when-to-use directive: 'Use this before money-touching tool calls to confirm sufficient funds.' This gives clear contextual guidance and names the purpose relative to other tools, even though no specific alternatives are named.
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/voidmobcom/voidmob-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server