Skip to main content
Glama

Search DID coverage

search_coverage
Read-onlyIdempotent

List DID Groups the authenticated customer can purchase, optionally filtered by country, city and/or number type. country_iso is an ISO 3166-1 alpha-2 code (e.g. CA, US, GB); city is a city name in English (fuzzy-matched, so spacing/hyphens are ignored; only local groups have cities); did_group_type is the number type (Local, National, Mobile, Toll-free, Shared Cost, Global). Each DID Group has one or more Stock Keeping Units (SKUs) at different included-channel tiers and prices. For each group returns: sku_id (pass THIS to buy_did — NOT group_id), group_id, DID Group area name, group type, country ISO code, dialing prefix, supported features (voice, voice_out, t38, sms, sms_out, a2p, p2p, emergency, cnam_out), needs_registration (true = the group requires address registration), restrictions (the group's service-restrictions text, when any — buying a DID from the group means accepting them), available quantity, back_orderable (present and true when the group is API-connected: buy_did purchases it even at 0 available quantity — back-ordering is on by default, see its allow_back_ordering argument — and the numbers are provisioned after the order), and per SKU: setup/monthly price with its currency (all amounts are in USD), included channels with a human label ("2 channels included" / "no channels (metered)") and billing_type (bundled = channels included, metered = 0 channels, pay-per-minute until capacity is attached). Filter by features to keep only groups supporting ALL listed features (e.g. ["sms"] for SMS-capable numbers, ["emergency"] for emergency-calling support).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
npaNoNANPA area code (3 digits). Narrows the selection to a specific area code — mainly for countries with structured numbering plans, such as the United States and Canada. Combine with nxx for an exact NPA-NXX prefix.
nxxNoNANPA exchange code (3 digits) — requires npa; narrows the selection to the exact NPA-NXX number prefix.
cityNoCity name in English (DIDWW stores city names in English). Fuzzy-matched — "Los Angeles", "Los-Angeles" and "los angeles" all match. Only local groups have cities — do NOT put a number type (e.g. "Mobile") here; use did_group_type.
pageNoPage number (default 1).
regionNoState / administrative region name in English (case-insensitive substring), e.g. "California". Narrows the selection within countries that have sub-national divisions, such as the United States, Canada and the United Kingdom.
featuresNoKeep only groups supporting ALL listed features: voice = inbound calls, voice_out = outbound calls, t38 = fax, sms = inbound SMS, sms_out = outbound SMS, a2p/p2p = outbound SMS kinds, emergency = emergency calling (e.g. 911/112), cnam_out = outbound caller-name delivery.
area_nameNoFinds groups for a specific area or locality by name fragment (case-insensitive). The area name is the group's label: a city or locality for geographic groups, or a service area like "Toll-free", "Mobile", "National", "Shared Cost" or "Global" for non-geographic ones (use did_group_type to filter by number type instead).
page_sizeNoResults per page (default 50, max 200).
country_isoNoISO 3166-1 alpha-2 country code, e.g. CA, US, GB (case-insensitive).
is_availableNoFilter by immediate purchasability: true = only groups you can buy right now (free DIDs in stock OR API-connected back-orderable groups); false = only groups with neither. Omit to list both.
did_group_typeNoFilter by number type.
prefix_containsNoFinds DID groups matching the entered number prefix — a digit fragment of the full international prefix (country code + area code), e.g. "1212" for US +1 212 groups.
needs_registrationNoFilter by whether the DID Group requires address registration: false = no registration needed.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent, but the description adds substantial behavior: back_orderable semantics (API-connected groups purchasable at 0 quantity, back-ordering default on, provisioned after order), needs_registration meaning, restrictions implying acceptance on purchase, and cross-references buy_did's allow_back_ordering argument. This is rich context beyond structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and filter semantics are front-loaded, and the long return-field enumeration earns its place since there is no output schema. It is dense and runs as one block sentence, which slightly hurts readability but wastes little.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 13 params, no output schema, and a complex pricing/stocking domain, the description compensates by enumerating every returned field and its meaning, plus back-order and registration behavior. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter. Description restates country_iso, city, did_group_type and features semantics largely as the schema already does, adding only the feature-filter example. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List DID Groups the authenticated customer can purchase') with scope and optional filters, and names the downstream sibling buy_did so the agent can place it in the purchase flow. It is clearly distinguishable from list_dids/get_did.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is clear (browse purchasable groups before buying, pass sku_id to buy_did). It even warns 'pass THIS to buy_did — NOT group_id.' It does not explicitly state when NOT to use it versus siblings like list_dids, so it falls 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources