Find phone numbers that spell a word, toll free or local, with status, price and history.
Scored across 6 tools
The tools mostly target distinct tasks: checking one number, searching by spelled word, finding numbers by business category, viewing toll-free history, requesting a vendor-held number, and setting a watch. There is some potential overlap between check_number and number_history, and between find_business_numbers and search_vanity_numbers, but the descriptions clearly differentiate single-number lookup, history lookup, word-based search, and category-based search.
All names use snake_case and most follow a verb_noun pattern: check_number, find_business_numbers, request_vendor_number, search_vanity_numbers, watch_number. The main exception is number_history, which is a noun phrase rather than a verb-led action, but the set remains highly readable and predictable.
Six tools is well-scoped for a vanity phone number research and request service. Each tool earns its place by covering a distinct part of the workflow: search, check, history, request, and watch.
The surface covers number discovery, status/price checking, history, vendor requests, and monitoring, which are the core research workflows. The notable gap is that there is no direct purchase, reservation, or order tool; instead, several tools link users to VanityNumbers.com to finish, which is a workable but minor dead end.
Check one US or Canadian phone number, toll free or local, by digits or by its spelling (877-393-7552 or 877-EYES-LLC). Use it when someone asks whether a number is available, what it costs, or what it is today. Returns its status (available, backorder, rent to own, with another vendor, in use, or for a local number the phone company first given its block, when, and the company that has it today, with each company's page on NewLocalNumbers.com), its price when it has one, and links to its history and to finish on VanityNumbers.com. When the number spells a word, it also names the word and lists numbers like it that can be ordered.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Optional: the person's email, if they have a confirmed notification with VanityNumbers.com. The lookup is then connected to their notifications, so their emails' suggestions fit what they're looking for, and a local number's answer also says whether it's in use today, from their own, larger allowance of lookups. | ||
| number | Yes | A 10-digit number or a vanity spelling, like 877-393-7552 or 877-EYES-LLC. |
| Name | Required | Description |
|---|---|---|
| kind | Yes | |
| note | No | |
| page | Yes | |
| as_of | No | |
| label | Yes | |
| price | No | |
| since | No | |
| state | No | |
| today | No | |
| number | Yes | |
| spells | No | |
| status | Yes | |
| carrier | No | |
| contact | No | |
| held_by | No | |
| meaning | Yes | |
| summary | No | |
| site_page | No | |
| watch_hint | No | |
| data_source | No | |
| deeper_page | No | |
| carrier_page | No | |
| history_page | No | |
| matching_site | No | |
| data_source_url | No | |
| numbers_like_it | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes further by enumerating the possible statuses returned (available, backorder, rent to own, with another vendor, in use, or block-holder detail) and noting price and links. The return-state explanation is genuinely useful, though the garbled phrasing of the local-number case weakens it.
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 core purpose is front-loaded, but the second and third sentences are run-on and tangled — 'or for a local number the phone company first given its block, when, and the company that has it today' is barely parseable. Substantial length is spent re-describing return values that an output schema already covers.
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?
With annotations handling safety and an output schema handling return structure, the description covers what an agent needs to invoke it: accepted input forms, when to choose it, and what answers look like. Only the missing sibling routing keeps it from full completeness.
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 coverage is 100% and the schema already documents both the 10-digit/vanity spelling format and the email parameter's effect on notifications and lookup allowance. The description's format example ('877-393-7552 or 877-EYES-LLC') merely restates the schema, adding no new semantics.
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?
States a specific verb and resource with explicit scope: 'Check one US or Canadian phone number, toll free or local,' and shows both accepted input forms. It does not name any sibling tool, so the agent gets no direct disambiguation from search_vanity_numbers, number_history, or watch_number, but the 'one number' scope is clear enough to infer separation.
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?
'Use it when someone asks whether a number is available, what it costs, or what it is today' gives concrete triggering intents. It stops short of exclusions or pointing to alternatives — e.g., nothing says to use search_vanity_numbers instead when the user has no specific number in mind.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find toll free numbers for a type of business, like PLUMBING, DENTIST or LAWYER: the best ones available now (from 1800AVAILABLE.com) and recently disconnected ones that can be requested, up to 10 of each. Use it when someone wants to browse numbers for their kind of business rather than one word. Returns each number's price, and links to its page and to the category's page to see more.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Optional: the person's email, if they have a confirmed notification with VanityNumbers.com. The lookup is then connected to their notifications, so their emails' suggestions fit what they're looking for. | ||
| business | Yes | The kind of business, one word of 3 to 15 letters, like PLUMBING, DENTIST or LAWYER. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| as_of | No | |
| contact | No | |
| summary | No | |
| business | Yes | |
| category | No | |
| available | No | |
| more_page | Yes | |
| disconnected | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, non-open-world behavior, so the bar is lower. The description still adds real context beyond them: the data source (1800AVAILABLE.com), two result cohorts (currently available 'best' vs. recently disconnected and requestable), and a hard cap of 'up to 10 of each.'
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?
Front-loaded with verb+resource before the usage condition, and each clause carries information (examples, cap, return contents). Slightly long and appositive-heavy, but no wasted sentences.
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?
An output schema exists, so return-value explanation isn't required, yet the description helpfully notes price and page/category links. Scope, trigger, result cohorts, and limits are covered; only edge behavior (e.g., no results for a category, use of the email context) is left unstated.
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%, so both parameters are already documented and the baseline is 3. The description restates the business examples already present in the schema and says nothing about the optional email parameter's effect, so it adds no meaning beyond the structured fields.
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?
Specific verb+resource: 'Find toll free numbers for a type of business,' with concrete examples (PLUMBING, DENTIST, LAWYER). It also implicitly distinguishes itself from sibling search_vanity_numbers by scoping to a business category 'rather than one word,' so an agent can route correctly without opening either schema.
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?
States an explicit trigger: 'Use it when someone wants to browse numbers for their kind of business rather than one word.' That contrast effectively selects this tool over single-word searching, though no sibling is named by title and no exclusion for the other four tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
See a toll free number's history from Resporgs.com: which RespOrgs (the companies that manage toll free numbers) have held it and when, and its status in each span, from the toll free registry's records. Use it when someone asks who had a toll free number before, or how long it has been with its current company. Returns the current holder, each earlier span, newest first, and a link to the number's page on Resporgs.com.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Optional: the person's email, if they have a confirmed notification with VanityNumbers.com. The lookup is then connected to their notifications, so their emails' suggestions fit what they're looking for. | ||
| number | Yes | A toll free number, by digits or spelling, like 800-356-9377 or 1-800-FLOWERS. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| page | Yes | |
| as_of | No | |
| label | Yes | |
| number | Yes | |
| source | No | |
| contact | No | |
| current | No | |
| history | No | |
| summary | No | |
| data_through | No | |
| earlier_spans | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds real behavioral context beyond that: data comes from the toll free registry's records, spans are returned newest first, and a Resporgs.com link is included.
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?
One tight paragraph, front-loaded with the resource and output shape, then the use case, then return details. Slightly redundant with the title's 'who has held a toll free number', but nothing is wasted.
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?
With a full output schema and complete annotations, the description only needs to establish purpose and usage, which it does. The remaining gap is sibling disambiguation among the five other number tools.
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%, so both parameters (number formats, and the optional email/notification linkage) are documented in the schema itself. The description adds no parameter-level detail, so the baseline 3 applies.
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?
States a specific verb and resource ('see a toll free number's history') and enumerates exactly what is returned: RespOrgs that held it, time spans, and status per span. The registry/Resporgs.com sourcing distinguishes it from siblings like check_number (current status) or search_vanity_numbers.
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?
Gives clear triggering conditions ('who had a toll free number before', 'how long it has been with its current company'). It stops short of naming an alternative tool or a when-not condition, e.g. pointing to check_number for current-owner questions, which would matter given six siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pass along a person's request for a toll free number held by another vanity number vendor, the kind check_number and the searches show as with another vendor, with no list price. Use it when the person asks to request that number and gives their name and email. Bill Quimby at VanityNumbers.com reviews each request by hand to confirm it's available and what it would cost, and answers by email, usually within a day; it costs nothing to ask. Returns whether it was sent and what happens next. It can't buy or reserve the number.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The person's name, for Bill's reply. | |
| Yes | The person's email address. Bill answers there. | ||
| number | Yes | The toll free number, by digits or spelling, like 844-393-2273 or 844-EYE-CARE. | |
| message | No | Optional: anything the person wants Bill to know, like what the business does. |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| label | Yes | |
| number | Yes | |
| status | Yes | |
| contact | No | |
| meaning | Yes | |
| summary | No | |
| what_next | Yes | |
| request_id | No | |
| request_page | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare it is a non-destructive, idempotent, openWorld write, but the description adds behavior they cannot convey: a human (Bill) manually verifies availability and price, replies by email typically within a day, the request is free, and the tool 'can't buy or reserve the number.' That limitation and the cost/timeline disclosure are exactly the context an agent needs before promising anything to a user.
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?
Front-loaded with the action and its condition, then the human-review/timeline/cost expectations and the explicit limitation. Every sentence earns its place, though the opening sentence is dense and slightly hard to parse on first read.
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?
An output schema exists, so return values need not be explained, and the description still notes it 'returns whether it was sent and what happens next.' Combined with the caveat that it cannot buy or reserve, an agent has everything needed to call and set expectations.
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 coverage is 100%, so the schema already documents name, email, number, and the optional message. The description reinforces the identity of the 'number' (vendor-held, no list price) but adds no format, validation, or mapping detail beyond what the schema supplies. Baseline 3 is appropriate when the schema carries the parameter burden.
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?
States a specific verb and resource ('Pass along a person's request for a toll free number held by another vanity number vendor') and disambiguates the resource by tying it to what 'check_number and the searches show as with another vendor, with no list price.' An agent can distinguish this from the sibling search/check tools without opening any schema.
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?
Gives an explicit trigger: 'Use it when the person asks to request that number and gives their name and email.' It also implicitly routes away from check_number and the search tools by naming them as the tools that surface vendor-held numbers rather than acting on them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a new phone number for a business that spells a word, like 1-800-PLUMBER: toll free (800, 888, 877, 866, 855, 844, 833) or local in a state. Use it when someone wants a memorable or vanity number, an 800 or toll free number, or a number that spells their business name or what they do; give it that word (PLUMBER, BAKERY). Returns the word in all seven toll free area codes with each one's status and price, a recommended pick, close versions available for $49, local numbers in a state when one is given, the word's business category pages, and links to finish on VanityNumbers.com. It doesn't look up an existing business's phone number.
| Name | Required | Description | Default |
|---|---|---|---|
| word | Yes | The word or number, 3 to 15 letters or digits, like PLUMBER. | |
| No | Optional: the person's email, if they have a confirmed notification with VanityNumbers.com. The lookup is then connected to their notifications, so their emails' suggestions fit what they're looking for. | ||
| state | No | Optional: a two-letter state or province for local numbers, like TX (CA_N or CA_S for California). |
| Name | Required | Description |
|---|---|---|
| note | No | |
| word | Yes | |
| as_of | No | |
| local | No | |
| contact | No | |
| summary | No | |
| category | No | |
| tollfree | No | |
| more_page | Yes | |
| smart_pick | No | |
| tollfree_note | No | |
| close_versions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a safe, idempotent, read-only lookup, so the bar is lower. The description adds real value beyond that: it discloses the response shape (all seven toll free codes with status and price, a recommended pick, $49 close versions, local results, category pages, finish links) and an explicit negative capability ('doesn't look up an existing business's phone number').
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?
Purpose is front-loaded in the first clause, followed by usage and exclusions, so the structure is sound. It is a single dense run-on paragraph and the enumeration of return contents is somewhat list-heavy, but almost every sentence carries information.
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?
Covers purpose, when-to-use, a when-not, and return expectations in one place. Since an output schema exists, the return-value detail is bonus rather than a necessity, and nothing an agent needs to invoke this read-only lookup correctly is missing.
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%, so all three parameters are already documented in the schema, and the baseline of 3 applies. The description reinforces 'word' with examples (PLUMBER, BAKERY) and refers to the state case, but never mentions the 'email' parameter, so it adds only modest meaning over the schema.
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?
States a specific verb and resource (find a phone number that spells a word) with concrete scope (toll free in seven area codes or local in a state). It also explicitly distinguishes itself from the business-lookup sibling by stating 'It doesn't look up an existing business's phone number.' An agent can route correctly without opening any schema.
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?
Gives explicit triggers ('when someone wants a memorable or vanity number... a number that spells their business name') and one clear exclusion for existing business numbers. It stops short of naming the actual sibling tools as alternatives, so it lands just below the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set up a notification about a toll free or local phone number for a person who wants an email when it changes: a number they want that someone has today, or a local number whose block no phone company has been given yet. Use it when the person asks to be told about a number and gives their email address. VanityNumbers.com emails them a link to confirm, and nothing starts until they click it. Then they get what we have on it now. A toll free number is followed with the same 7 digits in all 7 toll free area codes; a local number with every version of it in its state, a check each month of whether it's still in use, and, if no phone company has its block yet, when our data shows one was given it. After that they get an email on the 15th when it or a related number has changed, and every three months to say the notification is still on. Returns whether the confirm email went out. It can't buy or reserve a number.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional: the person's first name, for the emails. | |
| Yes | The person's email address. The confirm email and the notifications go there. | ||
| number | Yes | The number to be notified about, by digits or spelling, like 844-758-6237, 844-PLUMBER or 512-758-6237. |
| Name | Required | Description |
|---|---|---|
| kind | Yes | |
| page | Yes | |
| label | Yes | |
| scope | No | |
| number | Yes | |
| status | Yes | |
| contact | No | |
| summary | No | |
| what_next | Yes | |
| request_page | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Far exceeds the annotations: it discloses the double opt-in flow ("nothing starts until they click it"), what the watcher receives, monthly liveness checks, the 15th-of-month change emails, quarterly confirmation emails, and the exact follow semantics for toll free vs local numbers. This is exactly the behavioral context annotations cannot carry.
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 content is relevant but delivered as a single sprawling run-on sentence chain with multiple colons and nested clauses, making it hard to parse. Front-loading is decent but the phrasing ("a number they want that someone has today") is needlessly convoluted.
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?
An output schema exists, yet the description still notes what the call returns, and it fully covers the confirmation lifecycle, cadence of notifications, and the tool's limits. Nothing an agent needs to call this correctly is missing.
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 coverage is 100%, so all three parameters are already documented, giving a baseline of 3. The description adds useful meaning for the number value (toll free variants tracked across all 7 area codes, local variants across the state) but says nothing about the name parameter beyond the schema.
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 opening states a specific verb and resource ("Set up a notification about a toll free or local phone number") and explains the two scenarios it covers. It also carves out scope with "It can't buy or reserve a number," implicitly separating it from request_vendor_number, though it never names a sibling directly.
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?
"Use it when the person asks to be told about a number and gives their email address" gives a clear triggering condition, and the negative "can't buy or reserve" rules out the purchase path. No sibling is named as an alternative, so the routing is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_number4 fields changedOutput schema / $defs / LikeNumberAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "category": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Category"
+ },
+ "digits": {
+ "title": "Digits",
+ "type": "string"
+ },
+ "number": {
+ "title": "Number",
+ "type": "string"
+ },
+ "page": {
+ "title": "Page",
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "digits",
+ "page"
+ ],
+ "title": "LikeNumber",
+ "type": "object"
+}Output schema / $defs / LikeTierAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "more_page": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "More Page"
+ },
+ "numbers": {
+ "default": [],
+ "items": {
+ "$ref": "#/$defs/LikeNumber"
+ },
+ "title": "Numbers",
+ "type": "array"
+ },
+ "title": {
+ "title": "Title",
+ "type": "string"
+ }
+ },
+ "required": [
+ "title"
+ ],
+ "title": "LikeTier",
+ "type": "object"
+}Output schema / $defs / NumbersLikeItAdded value: +{
+ "additionalProperties": false,
+ "description": "LocalVanityNumbers.com's own numbers like a checked local number, closest first (Bill 10-22).",
+ "properties": {
+ "category": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Category"
+ },
+ "page": {
+ "title": "Page",
+ "type": "string"
+ },
+ "price": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Price"
+ },
+ "tiers": {
+ "default": [],
+ "items": {
+ "$ref": "#/$defs/LikeTier"
+ },
+ "title": "Tiers",
+ "type": "array"
+ },
+ "word": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Word"
+ }
+ },
+ "required": [
+ "page"
+ ],
+ "title": "NumbersLikeIt",
+ "type": "object"
+}Output schema / properties / numbers_like_itAdded value: +{
+ "anyOf": [
+ {
+ "$ref": "#/$defs/NumbersLikeIt"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}check_number1 field changedOutput schema / properties / site_pageAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Site Page"
+}check_number2 fields changedInput schema / properties / email / descriptionPrevious value: -"Optional: the person's email, if they have a confirmed watch with VanityNumbers.com. The lookup is then connected to their watch, so its emails' suggestions fit what they're looking for, and a local number's answer also says whether it's in use today, from their own, larger allowance of lookups."New value: +"Optional: the person's email, if they have a confirmed notification with VanityNumbers.com. The lookup is then connected to their notifications, so their emails' suggestions fit what they're looking for, and a local number's answer also says whether it's in use today, from their own, larger allowance of lookups."Output schema / properties / watch_hintAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Watch Hint"
+}find_business_numbers1 field changedInput schema / properties / email / descriptionPrevious value: -"Optional: the person's email, if they have a confirmed watch with VanityNumbers.com. The lookup is then connected to their watch, so its emails' suggestions fit what they're looking for."New value: +"Optional: the person's email, if they have a confirmed notification with VanityNumbers.com. The lookup is then connected to their notifications, so their emails' suggestions fit what they're looking for."find_new_local_numbersnumber_history1 field changedInput schema / properties / email / descriptionPrevious value: -"Optional: the person's email, if they have a confirmed watch with VanityNumbers.com. The lookup is then connected to their watch, so its emails' suggestions fit what they're looking for."New value: +"Optional: the person's email, if they have a confirmed notification with VanityNumbers.com. The lookup is then connected to their notifications, so their emails' suggestions fit what they're looking for."search_vanity_numbers1 field changedInput schema / properties / email / descriptionPrevious value: -"Optional: the person's email, if they have a confirmed watch with VanityNumbers.com. The lookup is then connected to their watch, so its emails' suggestions fit what they're looking for."New value: +"Optional: the person's email, if they have a confirmed notification with VanityNumbers.com. The lookup is then connected to their notifications, so their emails' suggestions fit what they're looking for."watch_number2 fields changedInput schema / properties / email / descriptionPrevious value: -"The person's email address. The confirm email and the watch emails go there."New value: +"The person's email address. The confirm email and the notifications go there."Input schema / properties / number / descriptionPrevious value: -"The number to watch, by digits or spelling, like 844-758-6237, 844-PLUMBER or 512-758-6237."New value: +"The number to be notified about, by digits or spelling, like 844-758-6237, 844-PLUMBER or 512-758-6237."check_number3 fields changedOutput schema / $defs / SpellOptionAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "label": {
+ "title": "Label",
+ "type": "string"
+ },
+ "nearby": {
+ "default": false,
+ "title": "Nearby",
+ "type": "boolean"
+ },
+ "number": {
+ "title": "Number",
+ "type": "string"
+ },
+ "page": {
+ "title": "Page",
+ "type": "string"
+ },
+ "price": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Price"
+ }
+ },
+ "required": [
+ "label",
+ "number",
+ "page"
+ ],
+ "title": "SpellOption",
+ "type": "object"
+}Output schema / $defs / SpellsAdded value: +{
+ "additionalProperties": false,
+ "description": "What a checked number spells, and numbers like it to get (Bill 10-19).",
+ "properties": {
+ "category": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Category"
+ },
+ "category_page": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Category Page"
+ },
+ "local": {
+ "default": [],
+ "items": {
+ "$ref": "#/$defs/SpellOption"
+ },
+ "title": "Local",
+ "type": "array"
+ },
+ "more_page": {
+ "title": "More Page",
+ "type": "string"
+ },
+ "toll_free": {
+ "default": [],
+ "items": {
+ "$ref": "#/$defs/SpellOption"
+ },
+ "title": "Toll Free",
+ "type": "array"
+ },
+ "word": {
+ "title": "Word",
+ "type": "string"
+ }
+ },
+ "required": [
+ "word",
+ "more_page"
+ ],
+ "title": "Spells",
+ "type": "object"
+}Output schema / properties / spellsAdded value: +{
+ "anyOf": [
+ {
+ "$ref": "#/$defs/Spells"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}find_business_numbers1 field changedOutput schema / properties / disconnectedAdded value: +{
+ "default": [],
+ "items": {
+ "$ref": "#/$defs/BizNumber"
+ },
+ "title": "Disconnected",
+ "type": "array"
+}check_number3 fields changedOutput schema / $defs / TodayCarrier / properties / activity_levelAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Activity Level"
+}Output schema / $defs / TodayCarrier / properties / activity_scoreRemoved value: -{
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "title": "Activity Score"
-}Output schema / $defs / TodayCarrier / properties / activity_whyAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Activity Why"
+}find_business_numbers4 fields changedOutput schema / $defs / BizNumber / properties / frees_upRemoved value: -{
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "title": "Frees Up"
-}Output schema / $defs / Category / properties / disconnects_pageRemoved value: -{
- "title": "Disconnects Page",
- "type": "string"
-}Output schema / $defs / Category / requiredPrevious value: -[
- "label",
- "best_available_page",
- "disconnects_page"
-]New value: +[
+ "label",
+ "best_available_page"
+]Output schema / properties / disconnectedRemoved value: -{
- "default": [],
- "items": {
- "$ref": "#/$defs/BizNumber"
- },
- "title": "Disconnected",
- "type": "array"
-}search_vanity_numbers2 fields changedOutput schema / $defs / Category / properties / disconnects_pageRemoved value: -{
- "title": "Disconnects Page",
- "type": "string"
-}Output schema / $defs / Category / requiredPrevious value: -[
- "label",
- "best_available_page",
- "disconnects_page"
-]New value: +[
+ "label",
+ "best_available_page"
+]check_number3 fields changedInput schema / properties / email / descriptionPrevious value: -"Optional: the person's email, if they have a confirmed watch with VanityNumbers.com. A local number's answer then also says whether it's in use today, from their own, larger allowance of lookups. The email is used for nothing else."New value: +"Optional: the person's email, if they have a confirmed watch with VanityNumbers.com. The lookup is then connected to their watch, so its emails' suggestions fit what they're looking for, and a local number's answer also says whether it's in use today, from their own, larger allowance of lookups."Output schema / properties / data_sourceAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Data Source"
+}Output schema / properties / data_source_urlAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Data Source Url"
+}find_business_numbers1 field changedInput schema / properties / emailAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional: the person's email, if they have a confirmed watch with VanityNumbers.com. The lookup is then connected to their watch, so its emails' suggestions fit what they're looking for.",
+ "title": "Email"
+}find_new_local_numbers3 fields changedInput schema / properties / emailAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional: the person's email, if they have a confirmed watch with VanityNumbers.com. The lookup is then connected to their watch, so its emails' suggestions fit what they're looking for.",
+ "title": "Email"
+}Output schema / properties / data_sourceAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Data Source"
+}Output schema / properties / data_source_urlAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Data Source Url"
+}number_history1 field changedInput schema / properties / emailAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional: the person's email, if they have a confirmed watch with VanityNumbers.com. The lookup is then connected to their watch, so its emails' suggestions fit what they're looking for.",
+ "title": "Email"
+}search_vanity_numbers1 field changedInput schema / properties / emailAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional: the person's email, if they have a confirmed watch with VanityNumbers.com. The lookup is then connected to their watch, so its emails' suggestions fit what they're looking for.",
+ "title": "Email"
+}check_number4 fields changedInput schema / properties / emailAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional: the person's email, if they have a confirmed watch with VanityNumbers.com. A local number's answer then also says whether it's in use today, from their own, larger allowance of lookups. The email is used for nothing else.",
+ "title": "Email"
+}Output schema / $defs / TodayCarrier / properties / activityAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Activity"
+}Output schema / $defs / TodayCarrier / properties / activity_scoreAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Activity Score"
+}Output schema / $defs / TodayCarrier / properties / noteAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Note"
+}watch_numbercheck_number3 fields changedOutput schema / $defs / TodayCarrierAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "carrier": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Carrier"
+ },
+ "detail": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Detail"
+ },
+ "headline": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Headline"
+ },
+ "how": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "How"
+ },
+ "moved": {
+ "default": false,
+ "title": "Moved",
+ "type": "boolean"
+ },
+ "page": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Page"
+ }
+ },
+ "title": "TodayCarrier",
+ "type": "object"
+}Output schema / properties / deeper_pageAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Deeper Page"
+}Output schema / properties / todayAdded value: +{
+ "anyOf": [
+ {
+ "$ref": "#/$defs/TodayCarrier"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}search_vanity_numbers1 field changedOutput schema / $defs / Local / properties / deeper_pageAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Deeper Page"
+}check_numberfind_business_numbersfind_new_local_numbersnumber_historyrequest_vendor_numbersearch_vanity_numbersSearch US local phone numbers for sale by city, area code, word, pattern or price.
Search a national directory of 1-800 / toll-free / vanity-number businesses and services.
North American telephone numbering data: carriers, rate centers, OCNs, and number history.
Phone number validation and carrier lookup for 243 countries. 1,000 free lookups a month.
Add one secure layer between your agents and this server.