Skip to main content
Glama

Sipflow

by dev.sipflow

Validate / classify a phone number (E.164 + NANP)

validate_e164_number
Read-only

[cost: free (pure CPU, no network) | read-only]

Parse a phone number, normalize to E.164, and classify it. International coverage is via libphonenumber-js (every country, line type when known). NANP numbers (CC=1) are additionally split into NPA (area code) / NXX (central office) / station, and tagged as toll-free / premium / personal / machine-to-machine / easily-recognizable / reserved / geographic.

Use when validating From / P-Asserted-Identity / SHAKEN orig.tn, deciding whether an outbound call needs full attestation, or sanity-checking caller ID format.

Pair with: lint_sip_request to validate that PASSporT orig.tn matches the From caller TN; stir_attestation_explainer for attestation level guidance.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
numberYesPhone number in any common form. E.164 (+CCNNN…) is preferred; 10-digit US numbers are accepted as a convenience.

TDQS

A4.5/5.0
Behavior5/5

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

The annotation readOnlyHint=true is reinforced and expanded with additional behavioral context: free CPU-only cost, no network, libphonenumber-js international coverage, NANP splitting and tagging categories. This goes well beyond the annotation and fully discloses the tool's behavior.

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?

The description is front-loaded with cost/read-only info and flows logically through purpose, use cases, and related tools. It is slightly longer than necessary, but every sentence adds value and it remains well-structured.

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?

Given a single-param tool with no output schema, the description provides substantial context: input formats, classification output categories, and use cases. It does not explicitly describe the return type or error behavior, which is a minor gap, but overall it is quite complete.

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% (the `number` parameter is fully documented). The description does not add new parameter semantics beyond the schema, but it reiterates the input format. Baseline of 3 is appropriate given high schema coverage.

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?

The description clearly states the tool's purpose with a specific verb ('Parse', 'normalize', 'classify') and resource (phone number in E.164 and NANP). It differentiates from sibling tools by emphasizing NANP-specific classification and its use in SIP/SHAKEN contexts.

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?

Explicitly states when to use the tool (validating From/P-Asserted-Identity/SHAKEN orig.tn, deciding attestation needs, sanity-checking caller ID) and pairs it with related tools (lint_sip_request, stir_attestation_explainer), providing clear alternatives and complementarity.

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

All Sipflow toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation4/5

Most tools have clearly distinct purposes. The only notable overlap is between detect_sip_stack and detect_sip_vendor_from_config, which could cause confusion. Otherwise, each tool covers a unique aspect of SIP debugging.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., compare_sdp_offer_answer, detect_sip_stack, validate_stir_shaken_identity). No mixing of styles.

Tool Count4/5

22 tools is slightly above the typical 3-15 range, but each tool serves a specific and necessary function for comprehensive SIP debugging. The count is justified by the server's broad scope.

Completeness4/5

The tool set covers a wide range of SIP debugging tasks: parsing, diffing, DNS, STIR validation, config review, codec comparison, etc. Minor gaps exist (e.g., no dedicated RTP analysis tool), but core workflows are well-supported.

Resources