Skip to main content
Glama
Omnidim

@omnidim-ai/mcp-server

by Omnidim
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

searchPhoneNumbers

Read-only

Find available phone numbers to buy in a region from the OmniDimension number shop. Filter by carrier and pattern; flat regional rental price and validity appear in results.

Instructions

Search the OmniDimension number shop for phone numbers available to buy in a region. Price and validity are flat per region, so every result shows the same monthly_rental_usd and validity_days, and that is the exact amount a purchase will charge.

A region can have more than one carrier, each stocking different number series. Pass the carrier you want; the response names the carrier its results came from, and that is the carrier a purchase has to pass.

(Tags: Phone numbers)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage of results to return.
limitNoResults per page.
regionYesRegion to search in. `IN` and `US` both serve numbers. Which regions answer is configuration, so a region with no carrier enabled returns `404 not_available` rather than an empty list.
carrierNoWhich carrier's stock to search: carriers in a region do not sell the same numbers. Required where a region has more than one carrier; omitting it there returns `409 carrier_required` naming the region's carriers and what each one stocks.
patternNoDigits or prefix to match within the number.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.14.0
    • changedInput schema / properties / carrier / description
      Previous value: -"Which carrier's stock to search: carriers in a region do not sell\nthe same numbers. Always required, even where a region holds one,\nand omitting it returns `409 carrier_required` naming that\nregion's carriers and what each one stocks.\n"New value: +"Which carrier's stock to search: carriers in a region do not sell\nthe same numbers. Required where a region has more than one\ncarrier; omitting it there returns `409 carrier_required` naming\nthe region's carriers and what each one stocks.\n"
    • changedInput schema / required
      Previous value: -[
-  "region",
-  "carrier"
-]New value: +[
+  "region"
+]
  2. Changed1 schema field changedv0.13.1
    • changedInput schema / properties / carrier / description
      Previous value: -"Which carrier to use. **Always required** in a region that has\none, however few it holds, so that adding a carrier is never a\nbreaking change.\n\nRegion `IN` has two: `carrier-1` stocks landline numbers (city\ncodes 11, 12 and 80), `carrier-2-new` stocks mobile numbers (94\nand 79 series). Region `US` has one: `carrier-us`, US local\nnumbers by area code.\n\nOmitting it returns `409 carrier_required` listing the carriers\nwith what each one stocks, so an integration can discover them at\nruntime rather than hard-coding this list.\n"New value: +"Which carrier's stock to search: carriers in a region do not sell\nthe same numbers. Always required, even where a region holds one,\nand omitting it returns `409 carrier_required` naming that\nregion's carriers and what each one stocks.\n"
  3. Changed3 schema fields changedv0.13.0
    • addedInput schema / properties / carrier
      Added value: +{
+  "description": "Which carrier to use. **Always required** in a region that has\none, however few it holds, so that adding a carrier is never a\nbreaking change.\n\nRegion `IN` has two: `carrier-1` stocks landline numbers (city\ncodes 11, 12 and 80), `carrier-2-new` stocks mobile numbers (94\nand 79 series). Region `US` has one: `carrier-us`, US local\nnumbers by area code.\n\nOmitting it returns `409 carrier_required` listing the carriers\nwith what each one stocks, so an integration can discover them at\nruntime rather than hard-coding this list.\n",
+  "type": "string"
+}
    • changedInput schema / properties / region / description
      Previous value: -"Region to search in."New value: +"Region to search in. `IN` and `US` both serve numbers. Which\nregions answer is configuration, so a region with no carrier\nenabled returns `404 not_available` rather than an empty list.\n"
    • changedInput schema / required
      Previous value: -[
-  "region"
-]New value: +[
+  "region",
+  "carrier"
+]
  4. Addedv0.10.1

TDQS

A4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true and openWorldHint=false. The description adds genuine behavioral context beyond that: pricing and validity are flat per region, results carry monthly_rental_usd/validity_days, and the carrier in the response is the one a purchase must reuse. It does not cover pagination behavior or result ordering.

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?

Three short, front-loaded paragraphs: purpose first, then pricing behavior, then the carrier constraint. The parenthetical '(Tags: Phone numbers)' is dead weight, but the rest earns its place.

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

Completeness4/5

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

With no output schema, the description helpfully names the key return fields (monthly_rental_usd, validity_days) and the carrier attribution. Error conditions (404 not_available, 409 carrier_required) live in the schema rather than the description, so the picture is complete when read together, though the description alone does not surface them.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: why carrier matters (carriers stock different number series) and why the returned carrier must be reused at purchase time. It adds no extra detail on pattern or pagination, which the schema already handles.

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

Purpose4/5

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

States a specific verb and resource: searching the number shop for numbers 'available to buy in a region'. The purchase-oriented framing implicitly separates it from the sibling listPhoneNumbers (owned numbers), but no sibling is named explicitly, so it falls short of a 5.

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?

Gives a clear conditional rule for the carrier parameter ('Pass the carrier you want' where a region has multiple carriers) and ties the search to a downstream purchase by stating the purchase must pass the carrier the results came from. It never names an alternative tool or an explicit when-not-to-use, 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.

Deploy Server

Other Tools