1Lookup

by io.1lookup

Overview Discussions Admin

Server Details

Verify phone numbers, emails and IPs, and check remaining plan credits.

Ownership verified

Status: Healthy
Uptime: 90.9% over 61 days
OAuth: Works in Glama
Last Tested: 2026-10-20 20:49
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4/5.0

Scored 2026-10-19 23:00 across 6 tools

Disambiguation4/5

The three single-item tools (validate_phone, verify_email, ip_lookup) each target a distinct data type, and bulk_verify is a clear batch variant. However, bulk_verify fully overlaps with the three singles for the same operations, which could cause an agent to wonder when to batch versus call individually.

Naming Consistency4/5

All names follow a verb_noun pattern (bulk_verify, confirm_connection, get_account, ip_lookup, validate_phone, verify_email). Minor inconsistency: the same validation concept uses different verbs (verify_email vs validate_phone), but the overall structure is predictable.

Tool Count5/5

Six tools is well-scoped for a validation service: three per-type validators, one batch tool, plus account and connection utilities. Each tool clearly earns its place with no obvious filler.

Completeness5/5

The domain (phone/email/IP validation) is fully covered: single-item checks for each type, a batch operation, account/credit inspection, and connection confirmation. No obvious lifecycle operations are missing for a read-only lookup service.

Available Tools

6 tools

bulk_verifyBulk validate phones, emails, or IPsA

Read-onlyIdempotent

Inspect

Validate up to 50 phones, emails, or IPs in one call. Returns a per-item result array. Spends 1 credit per item.

ParametersJSON Schema

Name	Required	Description	Default
`type`	Yes	What kind of values to validate
`values`	Yes	Up to 50 values

Output Schema

ParametersJSON Schema

Name	Required	Description
`type`	Yes	What kind of values were validated
`total`	Yes	How many values were submitted
`failed`	Yes	How many did not
`results`	Yes	One entry per submitted value, in the order submitted
`succeeded`	Yes	How many returned a result

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely new context beyond that: the credit cost ('Spends 1 credit per item'), which is a material behavioral trait an agent cannot infer from 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.

Conciseness5/5

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

Three short sentences, no filler, with the batch scope and cost front-loaded. Every sentence carries distinct information (scale, return shape, billing).

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 an output schema present, the return format needn't be described, and the description still adds scale limits and cost. It leaves unaddressed what happens on partial validation failures or oversized input, which would round out a bulk mutation-adjacent tool operating on external data.

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% and the enum for 'type' is fully documented in the schema, so the baseline is 3. The description's 'up to 50' merely restates the schema's maxItems constraint and adds no format or semantic detail beyond it.

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 (validate) and resource (phones, emails, IPs) plus a concrete batch scope ('up to 50 ... in one call'), which separates it from single-item siblings like validate_phone and verify_email. It stops short of naming those siblings explicitly, so the differentiation is inferable rather than spelled out.

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

Usage Guidelines3/5

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

The phrase 'in one call' implies this is the efficient choice for multiple values, which is a mild usage signal. However, there is no explicit when-to-use vs when-to-use-a-single validator guidance and no stated exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

confirm_connectionConfirm the connectionA

Idempotent

Inspect

Confirms the 1Lookup connection works and records which AI assistant connected and when, so the user's 1Lookup API & MCP page can show it as connected. The first confirmation through a connection also tells the 1Lookup team that it works. Use it when the user asks to confirm, check or test their 1Lookup connection. Free, spends no credits. Idempotent: repeat calls simply refresh the record.

ParametersJSON Schema

Name	Required	Description	Default
`agent`	No	Your name in any form, e.g. claude, chatgpt, grok, cursor. Normalized to a short lowercase identifier and echoed back.

Output Schema

ParametersJSON Schema

Name	Required	Description
`agent`	Yes	The normalized assistant identifier that was recorded
`connected`	Yes	The connection works and was recorded
`connected_at`	Yes	ISO 8601 time of the first confirmation through this connection
`first_confirmation`	Yes	True when this call was the first confirmation for this connection

TDQS

A4.3/5.0

Behavior4/5

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

Adds real behavioral context beyond annotations: what the call records (assistant name + timestamp), the side effect of surfacing on the user's API/MCP page, and notifying the 1Lookup team on first confirmation. Idempotency is stated both in annotations and here. Slightly redundant on the idempotent point but otherwise rich.

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?

Front-loads what the tool does, then usage guidance, then cost/idempotency. Mostly tight, though the 'tells the 1Lookup team' detail is somewhat tangential and could be trimmed.

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?

Output schema exists, so return values needn't be explained. Description covers purpose, trigger, cost, and idempotency. A note on whether auth/connection setup is prerequisite would complete it, but the core guidance is present.

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 coverage is 100%, and the single 'agent' parameter is fully documented in the schema (format, normalization, echo behavior). The description adds nothing about the parameter, so the 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?

Names a specific action (confirms the 1Lookup connection) plus the side effect (records which AI assistant connected and when). This is clearly distinguishable from siblings like verify_email, validate_phone, or ip_lookup.

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

Usage Guidelines5/5

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

Explicit trigger condition: 'Use it when the user asks to confirm, check or test their 1Lookup connection.' Also states the cost (free, no credits) and idempotency, giving the agent enough to decide against alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_accountGet account plan and creditsA

Read-onlyIdempotent

Inspect

Get which 1Lookup account is connected, its plan, and its remaining credits. Free, spends no credits. Useful before a large run.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`user`	No	The signed-in user, so the assistant can say which account it is using
`usage`	No	Lookups and credits consumed, this period and all time
`tokens`	Yes	Credit balances, including total_available
`organization`	Yes	The organization the credits belong to, by name
`subscription`	No	Current plan, or null when there is no Stripe subscription

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description adds genuinely new behavioral context: the call is free and consumes no credits, which matters for an agent deciding whether to check before a costly run. Good value beyond structured fields, though it doesn't discuss response specifics (covered by the output schema).

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

Conciseness5/5

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

Three short sentences, front-loaded with what it returns, followed by cost and intended timing. No filler.

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?

Zero parameters, full annotation coverage, and an output schema that documents return values. Combined with the description's cost and timing guidance, an agent has everything needed to call it correctly.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 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 three concrete resources: connected account identity, plan, and remaining credits. This is clearly distinguishable from siblings like bulk_verify and verify_email, which perform lookups rather than account introspection.

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 situational cue — 'Useful before a large run' — telling the agent when to call it. It stops short of naming explicit alternatives or stating when NOT to call it, so it falls just below the top band.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ip_lookupLook up IP addressA

Read-onlyIdempotent

Inspect

Look up an IP address: geolocation, connection type, and proxy/VPN/Tor/datacenter flags with a fraud/risk score. Spends 1 credit.

ParametersJSON Schema

Name	Required	Description	Default
`ip`	Yes	IPv4 or IPv6 address

Output Schema

ParametersJSON Schema

Name	Required	Description
`request`	Yes	What was looked up
`insights`	No	The detailed findings, grouped by theme
`metadata`	No	What the call cost
`classification`	No	Categorical verdicts, e.g. line type or deliverability status
`recommendations`	No	Suggested action, with a plain-language summary
`risk_assessment`	No	Fraud and risk scoring for this value

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds a genuinely useful non-structured fact — it costs 1 credit per call — which lets an agent budget or batch instead of looping. It stops short of noting failure modes (e.g., what happens on an unresolvable or private IP), so it is not a 5.

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

Conciseness5/5

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

One sentence plus a short cost clause, zero filler, and the highest-value information (what you get back) is front-loaded. Every clause carries content.

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?

The tool is simple (one param, output schema present, full annotation coverage) and the description covers purpose, returned data shape at a high level, and cost. What is missing is minor: error behavior for invalid/private IPs and a pointer to bulk_verify for multi-IP lookups.

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?

There is a single required parameter with 100% schema description coverage, so the schema already documents "IPv4 or IPv6 address" fully. The description adds nothing about the parameter — no format examples, no mention of whether private/reserved ranges are accepted — so the 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 ("Look up an IP address") and immediately enumerates the returned data classes (geolocation, connection type, proxy/VPN/Tor/datacenter flags, fraud/risk score), which cleanly separates it from siblings like verify_email and validate_phone. An agent can tell what this does without opening the schema.

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

Usage Guidelines3/5

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

Usage is only implied by the resource name — an agent infers it should call this when it has an IP to enrich. There is no guidance on when to prefer bulk_verify for multiple IPs, no note on invalid/malformed input handling, and no statement of when this is inappropriate. The credit-cost note is the only usage-relevant signal.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_phoneValidate phone numberA

Read-onlyIdempotent

Inspect

Validate a phone number: checks whether it is real and active, and returns line type, carrier, Do Not Call status, and a risk level. Spends 1 credit.

ParametersJSON Schema

Name	Required	Description	Default
`phone`	Yes	Phone number in E.164 or national format
`country`	No	Optional ISO country code, e.g. US

Output Schema

ParametersJSON Schema

Name	Required	Description
`request`	Yes	What was looked up
`insights`	No	The detailed findings, grouped by theme
`metadata`	No	What the call cost
`classification`	No	Categorical verdicts, e.g. line type or deliverability status
`recommendations`	No	Suggested action, with a plain-language summary
`risk_assessment`	No	Fraud and risk scoring for this value

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety bar is low. The description adds genuinely new behavioral context by disclosing cost ('Spends 1 credit'), which an agent needs to decide whether to call this versus a bulk path, though it says nothing about rate limits or auth.

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

Conciseness5/5

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

A single front-loaded sentence covers purpose and output, followed by a three-word cost disclosure. No filler, no restatement of the title, and the most decision-relevant facts come first.

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 an output schema present, the description needn't explain return values, and annotations cover the safety profile; the credit cost is the key missing-in-annotations detail and it is present. The only gap is the lack of routing guidance against bulk_verify.

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% with only two well-documented parameters, so the schema carries the parameter semantics. The description adds no format guidance (e.g. accepted national formats) beyond what E.164/national and the ISO country example already provide.

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?

The description names a specific verb and resource ('Validate a phone number') and enumerates what the validation covers: real/active status, line type, carrier, DNC status, and risk level. It does not differentiate itself from the sibling bulk_verify, 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 Guidelines2/5

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

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as bulk_verify for multiple numbers. The only implicit signal is the singular 'a phone number', which an agent must infer means one-at-a-time use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_emailVerify email addressA

Read-onlyIdempotent

Inspect

Verify an email address: checks that it exists and is deliverable, and flags disposable, role-based, and risky addresses. Spends 1 credit.

ParametersJSON Schema

Name	Required	Description	Default
`email`	Yes	Email address to verify

Output Schema

ParametersJSON Schema

Name	Required	Description
`request`	Yes	What was looked up
`insights`	No	The detailed findings, grouped by theme
`metadata`	No	What the call cost
`classification`	No	Categorical verdicts, e.g. line type or deliverability status
`recommendations`	No	Suggested action, with a plain-language summary
`risk_assessment`	No	Fraud and risk scoring for this value

TDQS

A3.6/5.0

Behavior4/5

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

The annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds two traits annotations cannot express: a concrete cost of 1 credit and the substantive return semantics (existence, deliverability, risk flags), which is exactly the kind of context that helps an agent decide whether the call is worth making.

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

Conciseness5/5

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

A single compact sentence front-loads the action and enumerates the outcomes, followed by a short cost clause. Nothing is redundant and no sentence fails to earn 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 an output schema present, the description need not enumerate return fields, and it correctly avoids that. It covers the cost dimension and the output categories; the only real gap is the absence of guidance on the sibling alternative, which is a usage rather than completeness issue.

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?

There is a single parameter with 100% schema description coverage, so the schema already documents the input fully. The description adds no format, normalization, or validation detail about the email string beyond what the schema provides, making the baseline of 3 appropriate.

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 (verify) and resource (email address) and goes further by describing what the check actually determines: existence, deliverability, and flagging of disposable/role-based/risky addresses. It does not explicitly name the sibling bulk_verify as the multi-address alternative, so sibling differentiation is only implied by the singular phrasing.

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

Usage Guidelines2/5

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

There is no explicit when-to-use or when-not-to-use guidance. The description does not tell the agent to prefer bulk_verify for multiple addresses or to reserve this call for single-address checks, so routing between verify_email and bulk_verify is left to inference. The credit cost hint is a constraint rather than usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesOct 1, 2026

Changedget_account3 fields changed

removedOutput schema / properties / api_key

Removed value: -{
-  "additionalProperties": {},
-  "description": "Usage for the calling API key, empty for MCP callers",
-  "type": "object"
-}

changedOutput schema / properties / organization / description

Previous value: -"The organization the credits belong to"New value: +"The organization the credits belong to, by name"

changedOutput schema / properties / user / description

Previous value: -"The signed-in user"New value: +"The signed-in user, so the assistant can say which account it is using"

Changedip_lookup6 fields changed

changedOutput schema / properties / metadata / description

Previous value: -"Call metadata, including credit cost"New value: +"What the call cost"

removedOutput schema / properties / metadata / properties / cache_hit

Removed value: -{
-  "description": "True when served from a recent identical lookup",
-  "type": "boolean"
-}

changedOutput schema / properties / request / description

Previous value: -"What was looked up, and when"New value: +"What was looked up"

removedOutput schema / properties / request / properties / id

Removed value: -{
-  "description": "Unique id for this lookup",
-  "type": "string"
-}

removedOutput schema / properties / request / properties / timestamp

Removed value: -{
-  "description": "ISO 8601 time the lookup ran",
-  "type": "string"
-}

changedOutput schema / properties / request / required

Previous value: -[
-  "id",
-  "type",
-  "input",
-  "timestamp"
-]New value: +[
+  "type",
+  "input"
+]

Changedvalidate_phone6 fields changed

changedOutput schema / properties / metadata / description

Previous value: -"Call metadata, including credit cost"New value: +"What the call cost"

removedOutput schema / properties / metadata / properties / cache_hit

Removed value: -{
-  "description": "True when served from a recent identical lookup",
-  "type": "boolean"
-}

changedOutput schema / properties / request / description

Previous value: -"What was looked up, and when"New value: +"What was looked up"

removedOutput schema / properties / request / properties / id

Removed value: -{
-  "description": "Unique id for this lookup",
-  "type": "string"
-}

removedOutput schema / properties / request / properties / timestamp

Removed value: -{
-  "description": "ISO 8601 time the lookup ran",
-  "type": "string"
-}

changedOutput schema / properties / request / required

Previous value: -[
-  "id",
-  "type",
-  "input",
-  "timestamp"
-]New value: +[
+  "type",
+  "input"
+]

Changedverify_email6 fields changed

changedOutput schema / properties / metadata / description

Previous value: -"Call metadata, including credit cost"New value: +"What the call cost"

removedOutput schema / properties / metadata / properties / cache_hit

Removed value: -{
-  "description": "True when served from a recent identical lookup",
-  "type": "boolean"
-}

changedOutput schema / properties / request / description

Previous value: -"What was looked up, and when"New value: +"What was looked up"

removedOutput schema / properties / request / properties / id

Removed value: -{
-  "description": "Unique id for this lookup",
-  "type": "string"
-}

removedOutput schema / properties / request / properties / timestamp

Removed value: -{
-  "description": "ISO 8601 time the lookup ran",
-  "type": "string"
-}

changedOutput schema / properties / request / required

Previous value: -[
-  "id",
-  "type",
-  "input",
-  "timestamp"
-]New value: +[
+  "type",
+  "input"
+]

1 tool updateSep 10, 2026
- Addedconfirm_connection
5 tool updatesAug 31, 2026
- First observedbulk_verify
- First observedget_account
- First observedip_lookup
- First observedvalidate_phone
- First observedverify_email

Related MCP Connectors

Verified.net A
net.verified
Verify emails, validate phone numbers, look up carriers and score IP addresses.
Email Security
111
MobileValidate
com.mobilevalidate
Check phone numbers (WhatsApp, Telegram, carrier, spam reputation) and e-mail addresses.
Email Security
1
GBG Loqate - Reach A
io.github.gbgplc
Verify addresses, email addresses, and phone numbers with confidence scores.
Customer Data Platforms CRM
1122
emailverifier.devOAuth
io.github.usamaejaz
Verify emails and domains for routing, disposable providers, role accounts, and SMTP risk.
Email Security
1

Related MCP Servers

unpublished
API Testing App Automation
timdoes
A
license
Not graded
quality
A
maintenance
unpublished
Updated 2 months ago (2026-08-29 22:46 UTC)
MIT
ContactLint MCP server
Email Security Developer Tools
zksyncer
A
license
Not graded
quality
C
maintenance
Enables agents to validate email addresses and phone numbers before saving or using them, including syntax, DNS/MX checks, disposable domains, role addresses, typo suggestions, and phone number formats. Supports bulk email validation for up to 50 addresses in a single call.
Updated 3 days ago (2026-10-17 19:58 UTC)
MIT
mxprobe
Email Marketing
andrewchmr
A
license
A
quality
A
maintenance
Enables AI agents to verify email addresses and receive a 'send', 'hold', or 'kill' verdict with the reason, while also managing signup and credits programmatically.
Updated a month ago (2026-09-23 10:09 UTC)
5
2
MIT
veriphone
Communication
pipeworx-io
A
license
Not graded
quality
B
maintenance
Enables validating phone numbers (validity, line type, carrier, region, country, and canonical formats) and checking Veriphone API credits and quota through MCP tools.
Updated 24 days ago (2026-09-26 22:16 UTC)
10 npm
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?