lookup_phone_networkResolve an African phone number to its mobile network operator from the number's prefix. Accepts local or international format. Useful for routing a mobile-money payout to the right provider or validating a number before sending an OTP.
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes | Phone number, local (08031234567) or international (+2348031234567). |
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 resolution is based on the number's prefix and that local/international formats are accepted. However, it does not state the output format, error behavior, or whether the operation is read-only (though 'resolve' implies it). The lack of any annotation makes these disclosures more important, but the description still offers some meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every clause adds value. It is concise without sacrificing clarity.
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?
For a single-parameter lookup with no output schema, the description is largely complete: it explains the input format, the resolution mechanism, and common use cases. The only missing piece is an explicit statement of the return value (e.g., operator name), but 'mobile network operator' strongly implies it. Overall, adequate for an agent to use the tool correctly in most scenarios.
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?
Schema description coverage is 100%, and the phone parameter description already explains local/international format. The description adds the algorithm detail 'from the number's prefix', which is mildly useful but not essential. It does not compensate significantly beyond the schema, so the baseline 3 is appropriate.
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 uses the specific verb 'Resolve' with a clear resource: 'African phone number to its mobile network operator'. It explicitly distinguishes itself from sibling tools like lookup_bank and resolve_nuban, which handle bank-related lookups.
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 use cases: 'routing a mobile-money payout to the right provider' and 'validating a number before sending an OTP'. While it doesn't explicitly mention alternatives or when not to use the tool, the context is strong enough for an agent to decide. A brief mention of when to use lookup_bank instead would have been helpful, but not necessary.
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.
Each tool targets a distinct data type: currency, holidays, banks (list vs lookup), phone network, and NUBAN account resolution. Even the two bank tools are clearly separated by purpose—listing all institutions vs resolving one from an identifier. No tool overlaps meaningfully with another.
All tool names follow a uniform verb_noun snake_case pattern (get_, list_, lookup_, resolve_), making the action and resource immediately clear. The convention is applied consistently across all six tools.
With six tools, the server sits comfortably in the ideal 3-15 range. Each tool covers a distinct reference data need without bloat or redundancy, making the count well-scoped for the stated purpose.
The set covers core African financial reference data—currencies, holidays, banks, mobile networks, and NUBAN validation. However, there is no tool to list supported countries or all currencies, which would be a natural complement to the country-based lookups. This is a minor gap that agents can work around.