Free: poll the incoming SMS code for a number bought via buy_phone_number, using the returned handle. Repeat until status is 'received'.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | The handle returned by buy_phone_number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral disclosure. It reveals that the tool is free and that it involves polling until a condition is met. However, it does not disclose potential timeout, maximum attempts, or what to do if the code never arrives. Given the simplicity, the disclosure is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence that perfectly conveys the tool's purpose and usage pattern. It is front-loaded with 'Free:' and immediately states the action. No redundant words or filler sentences are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, straightforward polling logic), the description is complete. It explains what to do, what input to use, and the termination condition. There is no missing information that would hinder an AI agent from correctly using the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single parameter (handle) with 100% coverage. The description adds context by linking the handle to buy_phone_number, but does not provide additional meaning beyond what the schema offers. Therefore, the description adds minimal value for parameter understanding, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool polls for an incoming SMS code using a handle from buy_phone_number, with a specific condition ('Repeat until status is received'). It uses a specific verb ('poll') and resource ('incoming SMS code'), and directly distinguishes itself from the sibling 'buy_phone_number' which purchases the number.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it should be used after buying a phone number via buy_phone_number, and the handle from that purchase is required. It also specifies a polling loop condition ('Repeat until status is received'). However, it does not explicitly mention when not to use it or list alternatives among siblings, though for this simple polling tool that is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Every tool targets a distinct action and domain: country-specific company checks (check_ch_company, check_fr_company, etc.), insolvency checks, crypto signals, x402 network tools, etc. Descriptions are detailed and make boundaries clear, with no two tools appearing to do the same thing.
Tool names follow very consistent patterns: 'check_<country>_<entity>' for registers, 'crypto_*' for crypto intelligence, 'x402_*' for x402 network functions, 'screen_*' for screening, and a few free-form names like 'verify_eu_vat' and 'lookup_lei' that still fit the verb_noun style. No mixing of conventions.
39 tools is high but justified by the broad scope: the server aggregates many country-specific checks, insolvency registers, crypto tools, x402 monitoring, and auxiliary functions (like phone number buying, LEI lookup). Each tool serves a clear purpose, and the count is not excessive given the coverage. A slight reduction could be possible by merging some country checks, but overall it's reasonable.
The server covers major European company registers (CH, UK, FR, NL, NO, PL, CZ, FI), insolvency checks (NL, FR), sanctions screening, VAT validation, crypto market intelligence, and x402 network tools. It acknowledges gaps (e.g., no German check) and provides fallback tools like 'screen_eu_supplier' and 'file_agent_want'. Minor missing pieces (e.g., Italian company check) keep it from a perfect 5.