Sipflow

Official22 toolsLive

by cmendes0101 · Shell

SIP/VoIP/telecom grounding for AI agents: vendor docs, RFCs, STIR/SHAKEN, traces, configs.

Sipflow MCP (dev.sipflow/sipflow)

Sipflow is a hosted, read-only Model Context Protocol server that provides SIP/VoIP/telecom grounding for AI agents. It serves a curated corpus of vendor documentation, RFCs, STIR/SHAKEN materials, and trace/config analysis so answers can be cited with a verbatim source_url rather than relying on training-data recall.

🛠️ Key Features

Server name: dev.sipflow/sipflow
SIP/VoIP/telecom grounding for AI agents
~20 tools (toolCount: 22)
Curated corpus coverage: vendor docs across ~40 stacks, 60+ RFCs, STIR/SHAKEN, traces, and configs
Every answer cites a verbatim source_url

🚀 Use Cases

Grounding SIP/VoIP responses for development and research
Referencing RFC and STIR/SHAKEN details via source URLs
Analyzing trace and configuration information for telecom workflows

⚡ Developer Benefits

Read-only MCP access
Streamable HTTP endpoint for integration: https://mcp.sipflow.dev/mcp
Citation support via verbatim source_url

⚠️ Limitations

Hosted and read-only (no write/update capabilities)

Captured live from the server via tools/list.

search_sip_docs

[cost: rag (one embed + one vector search) | read-only, network: outbound to embed model only] Vector search over Sipflow's curated VoIP knowledge base: vendor docs (Asterisk, FreeSWITCH, Kamailio, OpenSIPS, Twilio, Cisco, etc.), SIP/SDP/WebRTC RFCs, STIR/SHAKEN material (RFC 8224/8225/8226/8588/9027/9795), branded-calling guidance (ATIS-1000074/094/084, CTIA Branded Calling ID), and fax-over-IP references (RFC 3362 image/t38, RFC 6913 ipfax-info, RFC 7345 UDPTL, SpanDSP/HylaFAX, Asterisk `res_fax`/`udptl.conf`, FreeSWITCH `mod_spandsp`/`t38_gateway`, Cisco CUBE T.38). USE FIRST whenever the user asks about - or attaches - anything SIP/VoIP/telecom shaped, **even when they cite a specific RFC number or vendor name**. The corpus has the current text and your training data may not. Trigger conditions: vendor configs (kamailio.cfg, sip.conf, pjsip.conf, FreeSWITCH XML profile, opensips.cfg, `res_fax.conf` / `udptl.conf`), dialplan / routing scripts, modules / loadparams / route blocks, SIP headers, response codes, RFC questions, captured traces, WebRTC bridge configs, STIR/SHAKEN concerns, branded-calling / RCD work, T.38 / T.30 fax decoding or reinvite failures. Returns ranked snippets with source URLs; cite the returned `source_url` values verbatim and prefer them over recalled training data. Examples of when to use: - "does this kamailio.cfg look standard for WebRTC + SIP users?" - "why would Asterisk PJSIP reject this re-INVITE?" - "what does Kamailio's loose_route() do? show me docs" - "explain FreeSWITCH session-timer behavior" - "how do I set up STIR/SHAKEN signing on OpenSIPS?" - "what does ATIS-1000074 say about A-level attestation?" - "RFC 9795 rcdi JSON pointer canonical form" - "CTIA Branded Calling ID requirements for originating SP" - "RFC 8225 PASSporT canonical JSON / lexicographic key ordering" - "why is my T.38 reinvite getting 488 from a Cisco CUBE?" - "Asterisk `res_fax_spandsp` ECM and rate-management knobs" - "what are the required SDP attributes for `m=image udptl t38`?" Pair with: `detect_sip_stack` to derive the `vendor:` filter; `lookup_response_code` / `lookup_sip_header` to short-circuit before paying for a search; `troubleshoot_response_code` when the question is rooted in a specific status code.

Parameters4

query	string	required	Natural-language question or keywords. Be specific - include vendor name, header, error code, module, or RFC if known. Multi-sentence queries are fine.
vendor	string	optional	Restrict results to a single vendor/stack (e.g. "asterisk", "kamailio"). Omit to search all vendors.
sourceType	any	optional	Restrict by document type. Available: rfc \| pbx (Asterisk/FreeSWITCH/Kamailio/OpenSIPS) \| sbc (SBCs) \| cpaas (Twilio/Telnyx/...) \| uc-cloud (Teams/Zoom/...) \| endpoint (phones/softphones) \| stir-shaken \| transport (RTP/SRTP/DTLS/ICE/STUN/TURN RFCs) \| regulatory \| observability.
limit	integer	optional	Maximum number of snippets to return (1-15).

Raw schema

{
  "type": "object",
  "properties": {
    "query": {
      "type": "string",
      "minLength": 1,
      "maxLength": 2000,
      "description": "Natural-language question or keywords. Be specific - include vendor name, header, error code, module, or RFC if known. Multi-sentence queries are fine."
    },
    "vendor": {
      "type": "string",
      "enum": [
        "asterisk",
        "freeswitch",
        "kamailio",
        "opensips",
        "freepbx",
        "yate",
        "cisco-cube",
        "ribbon",
        "oracle-acme",
        "audiocodes",
        "cisco-cucm",
        "avaya",
        "mitel",
        "metaswitch",
        "3cx",
        "nec",
        "twilio",
        "telnyx",
        "bandwidth",
        "bandwidth-bxf",
        "vonage",
        "plivo",
        "signalwire",
        "aws-chime",
        "didww",
        "voxbone",
        "genband",
        "cisco-bts",
        "teams",
        "zoom-phone",
        "ringcentral",
        "webex-calling",
        "eight-by-eight",
        "polycom",
        "yealink",
        "cisco-phone",
        "grandstream",
        "snom",
        "linphone",
        "microsip",
        "bria",
        "zoiper",
        "jssip",
        "sip-js",
        "stir-shaken"
      ],
      "description": "Restrict results to a single vendor/stack (e.g. \"asterisk\", \"kamailio\"). Omit to search all vendors."
    },
    "sourceType": {
      "anyOf": [
        {
          "type": "string",
          "enum": [
            "rfc",
            "pbx",
            "sbc",
            "cpaas",
            "uc-cloud",
            "endpoint",
            "stir-shaken",
            "transport",
            "regulatory",
            "observability"
          ]
        },
        {
          "type": "array",
          "items": {
            "type": "string",
            "enum": [
              "rfc",
              "pbx",
              "sbc",
              "cpaas",
              "uc-cloud",
              "endpoint",
              "stir-shaken",
              "transport",
              "regulatory",
              "observability"
            ]
          }
        }
      ],
      "description": "Restrict by document type. Available: rfc | pbx (Asterisk/FreeSWITCH/Kamailio/OpenSIPS) | sbc (SBCs) | cpaas (Twilio/Telnyx/...) | uc-cloud (Teams/Zoom/...) | endpoint (phones/softphones) | stir-shaken | transport (RTP/SRTP/DTLS/ICE/STUN/TURN RFCs) | regulatory | observability."
    },
    "limit": {
      "type": "integer",
      "minimum": 1,
      "maximum": 15,
      "default": 5,
      "description": "Maximum number of snippets to return (1-15)."
    }
  },
  "required": [
    "query"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

lookup_response_code

[cost: free (pure CPU, no network) | read-only] Instant static lookup of a SIP response code (100-699). Returns name, RFC anchor, category, description, common operator-flavored causes, and known vendor-specific reason-phrase variants (e.g. OpenSIPS emits 484 'Invalid FROM' on From-header parse failure). USE FIRST when the user pastes or asks about any 3-digit SIP code - sub-millisecond, no API cost. Pair with: `troubleshoot_response_code` for vendor-specific RAG hits beyond the static entry; `lint_sip_request` when the code is 4xx and the user has the offending request; `stir_attestation_explainer` for STIR-shaped codes (428/436/437/438/608); `validate_stir_shaken_identity` when the code is 438 and they have the JWS.

Parameters1

code

integer

required

SIP response code (e.g. 488 for Not Acceptable Here).

Raw schema

{
  "type": "object",
  "properties": {
    "code": {
      "type": "integer",
      "minimum": 100,
      "maximum": 699,
      "description": "SIP response code (e.g. 488 for Not Acceptable Here)."
    }
  },
  "required": [
    "code"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

lookup_sip_header

[cost: free (pure CPU, no network) | read-only] Instant lookup of a SIP header by canonical or compact form (e.g. "Via" / "v", "Diversion", "P-Asserted-Identity", "Identity", "Session-Expires"). Returns canonical form, compact alias, RFC anchor, where it appears (request / response / both), cardinality (exactly-one / at-most-one / one-or-more / any), allowed/forbidden URI parameters with RFC citations, short description, and related headers. USE FIRST when the user asks about a specific header they saw in a trace - sub-millisecond, no API cost. The cardinality + paramRules fields surface failure modes (e.g. two From: headers, ;tag= on P-Asserted-Identity) without needing a RAG round-trip. Pair with: `lint_sip_request` to mechanically check a real request against these rules; `search_sip_docs` for vendor-specific or 3GPP P-headers not in the bundled registry.

Parameters1

name

string

required

Header name (canonical, e.g. "Via", or compact, e.g. "v"). Case-insensitive.

Raw schema

{
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "minLength": 1,
      "maxLength": 64,
      "description": "Header name (canonical, e.g. \"Via\", or compact, e.g. \"v\"). Case-insensitive."
    }
  },
  "required": [
    "name"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

detect_sip_stack

[cost: free (pure CPU, no network) | read-only] Identify the SIP product behind a piece of input. Works on both: - a SIP trace (User-Agent / Server headers from PCAP/sngrep/syslog), and - a vendor config blob (kamailio.cfg, sip.conf, pjsip.conf, FreeSWITCH XML, opensips.cfg) detected via structural signatures (loadmodule, route blocks, [transport-*] sections, <profile name=>, etc.). Returns a vendor slug (e.g. "kamailio", "freeswitch", "asterisk", "twilio", "cisco-cube") aligned with the `vendor` filter on `search_sip_docs`, so you can pipe the output of this tool directly into a follow-up doc search. Pair with: `search_sip_docs(vendor=<slug>, ...)` for grounded vendor docs; `review_sip_config` when the input is a config and you also want extracted modules + risk flags; `troubleshoot_response_code(vendorHint=<slug>, ...)` when chasing a status code.

Parameters3

text	string	required	Raw SIP trace text OR a vendor config blob.
kind	string	optional	What the input is. "trace" looks at SIP headers only, "config" runs vendor-config heuristics, "auto" tries trace first then falls back to config detection.
filenameHint	string	optional	Optional filename (e.g. "kamailio.cfg", "pjsip.conf"). Strongly improves config-mode detection when supplied.

Raw schema

{
  "type": "object",
  "properties": {
    "text": {
      "type": "string",
      "minLength": 1,
      "maxLength": 2000000,
      "description": "Raw SIP trace text OR a vendor config blob."
    },
    "kind": {
      "type": "string",
      "enum": [
        "auto",
        "trace",
        "config"
      ],
      "default": "auto",
      "description": "What the input is. \"trace\" looks at SIP headers only, \"config\" runs vendor-config heuristics, \"auto\" tries trace first then falls back to config detection."
    },
    "filenameHint": {
      "type": "string",
      "maxLength": 200,
      "description": "Optional filename (e.g. \"kamailio.cfg\", \"pjsip.conf\"). Strongly improves config-mode detection when supplied."
    }
  },
  "required": [
    "text"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

detect_sip_vendor_from_config

[cost: free (pure CPU, no network) | read-only] Heuristic-only sibling of `detect_sip_stack`, scoped to vendor configs. Returns the matched vendor slug, a confidence level, and the structural signals that fired (loadmodule syntax, route blocks, profile elements, etc.). Use this when the user asks 'what is this config?' or attaches a SIP config file. Detect-only - does not extract directives or flag risks. Pair with: `review_sip_config` for the structured outline + risk flags; `search_sip_docs(vendor=<slug>, ...)` to ground each directive.

Parameters2

text	string	required	Config blob (UTF-8 plaintext).
filenameHint	string	optional	Optional filename ("kamailio.cfg", "pjsip.conf", "sofia/external.xml") to bias detection.

Raw schema

{
  "type": "object",
  "properties": {
    "text": {
      "type": "string",
      "minLength": 1,
      "maxLength": 2000000,
      "description": "Config blob (UTF-8 plaintext)."
    },
    "filenameHint": {
      "type": "string",
      "maxLength": 200,
      "description": "Optional filename (\"kamailio.cfg\", \"pjsip.conf\", \"sofia/external.xml\") to bias detection."
    }
  },
  "required": [
    "text"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

minimize_sip_trace

[cost: free (pure CPU, no network) | read-only, no persistence] Reduce a raw SIP trace to a compact form suitable for sending to an LLM. Preserves SDP bodies and routing/auth/dialog headers; prunes well-known noise (User-Agent, Server, Allow, Accept-*, Date, P-* informational, etc.). Expected input format: raw SIP messages separated by blank lines, each starting with a request line (`INVITE sip:...@... SIP/2.0`) or status line (`SIP/2.0 200 OK`). PCAP-decoded text from sngrep / ngrep / tcpdump / tshark, syslog with SIP body, sipflow's own export format, or a hand-pasted INVITE/200 dialog all work. Annotation lines like `# [timestamp] sender -> receiver` or ngrep-style `U <ip>:<port> -> <ip>:<port>` between blocks are tolerated. Safe to run on production traces - the input is processed in-memory and is not persisted or sent off-server. Pair with: `detect_sip_stack` to identify the vendor, then `search_sip_docs(vendor=...)` for vendor-grounded analysis; `render_sip_ladder` to visualize the trace as a Mermaid call-flow ladder; `lint_sip_request` / `parse_sip_message` to mechanically validate any single message in the trace.

Parameters2

text	string	required	Raw SIP trace text. Multiple messages may be concatenated.
maxBytes	integer	optional	Truncate the minimized output if it exceeds this many bytes (default 200000, matches Sipflow's analyze pipeline).

Raw schema

{
  "type": "object",
  "properties": {
    "text": {
      "type": "string",
      "minLength": 1,
      "maxLength": 2000000,
      "description": "Raw SIP trace text. Multiple messages may be concatenated."
    },
    "maxBytes": {
      "type": "integer",
      "minimum": 1024,
      "maximum": 2000000,
      "default": 200000,
      "description": "Truncate the minimized output if it exceeds this many bytes (default 200000, matches Sipflow's analyze pipeline)."
    }
  },
  "required": [
    "text"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

render_sip_ladder

[cost: free (pure CPU, no network) | read-only] Parse a raw SIP trace (PCAP-decoded text, sngrep export, syslog, or pasted INVITE/200 dialog) and emit a Mermaid `sequenceDiagram` block visualizing the call flow. Most chat hosts (Claude, ChatGPT, Cursor, GitHub) render Mermaid inline. Lane keying: by default participants are keyed by IP, not `ip:port`, so an endpoint that sends from an ephemeral source port and listens on 5060 collapses into one column. Multi-port IPs list their ports in the participant label (e.g. `10.0.0.1 :5060,:53412`) and arrows touching them get a `(:srcPort→:dstPort)` suffix. Pass `groupByIp: false` to restore the legacy one-column-per-`ip:port` layout. Lane labeling: aliases are matched against (in order) `${ip}:${port}` from message source/dest, then bare `${ip}`, then top-Via host, then Contact host. The most-specific match wins. When no alias matches the renderer falls back to the peer's address rather than emitting `unknown:5060`. Pair with: `minimize_sip_trace` first to compact a noisy trace; `diff_sip_messages` when two adjacent INVITEs in the ladder differ unexpectedly; `lint_sip_request` to validate a single message you pulled from the ladder.

Parameters11

text	string	required	Raw SIP trace text. Multiple messages may be concatenated.
callId	string	optional	Render only this Call-ID. Required when the trace contains multiple calls; otherwise the only call is used.
compact	boolean	optional	Drop OPTIONS keepalives and retransmissions. Hidden counts are summarized in a `Note over` line.
includeTiming	boolean	optional	Append `+Nms` (delta from previous arrow) to each arrow label.
maxMessages	integer	optional	Hard cap on rendered arrows. Extra messages produce a truncation note. Hard ceiling is 200.
aliases	object	optional	Friendly lane labels. Match order: exact "ip:port" → bare "ip" → top-Via host (with or without port) → Contact host (with or without port). Most-specific match wins; otherwise the lane is labeled with its raw "ip:port" (never "unknown"). Example: `{"192.0.2.10:5060":"Alice","203.0.113.50":"Carrier"}`.
groupRetransmits	boolean	optional	Collapse adjacent identical retransmissions on the same direction into a single arrow + `Note over: xN over Tms`. Independent of `compact` (which drops them entirely).
highlightFailures	boolean	optional	Bold the first non-1xx final response per request leg (CSeq) so the failure jumps out in the ladder.
splitOnNewBranch	boolean	optional	Emit a `--- failover to <ip[:port]> ---` separator before any request sent to a previously-unseen destination. Useful when the trace fails over between gateway IPs.
groupByIp	boolean	optional	Collapse multiple ports on the same IP into one participant lane (default). Set to `false` to fall back to the legacy one-column-per-`ip:port` layout when you specifically need port-level granularity in the rendered Mermaid.
correlationHeaders	array	optional	Header names to use for cross-leg call correlation (value-equality). When provided, calls sharing the same value for any listed header are merged into one ladder. Example: `["X-ACME-Session-ID","X-ACME-Call-ID"]`.

Raw schema

{
  "type": "object",
  "properties": {
    "text": {
      "type": "string",
      "minLength": 1,
      "maxLength": 2000000,
      "description": "Raw SIP trace text. Multiple messages may be concatenated."
    },
    "callId": {
      "type": "string",
      "description": "Render only this Call-ID. Required when the trace contains multiple calls; otherwise the only call is used."
    },
    "compact": {
      "type": "boolean",
      "default": false,
      "description": "Drop OPTIONS keepalives and retransmissions. Hidden counts are summarized in a `Note over` line."
    },
    "includeTiming": {
      "type": "boolean",
      "default": false,
      "description": "Append `+Nms` (delta from previous arrow) to each arrow label."
    },
    "maxMessages": {
      "type": "integer",
      "minimum": 1,
      "maximum": 200,
      "default": 60,
      "description": "Hard cap on rendered arrows. Extra messages produce a truncation note. Hard ceiling is 200."
    },
    "aliases": {
      "type": "object",
      "additionalProperties": {
        "type": "string"
      },
      "description": "Friendly lane labels. Match order: exact \"ip:port\" → bare \"ip\" → top-Via host (with or without port) → Contact host (with or without port). Most-specific match wins; otherwise the lane is labeled with its raw \"ip:port\" (never \"unknown\"). Example: `{\"192.0.2.10:5060\":\"Alice\",\"203.0.113.50\":\"Carrier\"}`."
    },
    "groupRetransmits": {
      "type": "boolean",
      "default": true,
      "description": "Collapse adjacent identical retransmissions on the same direction into a single arrow + `Note over: xN over Tms`. Independent of `compact` (which drops them entirely)."
    },
    "highlightFailures": {
      "type": "boolean",
      "default": true,
      "description": "Bold the first non-1xx final response per request leg (CSeq) so the failure jumps out in the ladder."
    },
    "splitOnNewBranch": {
      "type": "boolean",
      "default": false,
      "description": "Emit a `--- failover to <ip[:port]> ---` separator before any request sent to a previously-unseen destination. Useful when the trace fails over between gateway IPs."
    },
    "groupByIp": {
      "type": "boolean",
      "default": true,
      "description": "Collapse multiple ports on the same IP into one participant lane (default). Set to `false` to fall back to the legacy one-column-per-`ip:port` layout when you specifically need port-level granularity in the rendered Mermaid."
    },
    "correlationHeaders": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "Header names to use for cross-leg call correlation (value-equality). When provided, calls sharing the same value for any listed header are merged into one ladder. Example: `[\"X-ACME-Session-ID\",\"X-ACME-Call-ID\"]`."
    }
  },
  "required": [
    "text"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

sip_ladder_example

[cost: free (pure CPU, no network) | read-only] Return a hand-curated SIP scenario as a Mermaid `sequenceDiagram` plus a bullet list of step-by-step explanations with RFC references. Use this when the user asks 'show me what X looks like' and you don't have a real trace handy. Available scenarios: basic-call, auth-challenge, cancel-before-answer, early-media, hold-resume, refer-blind, proxy-with-record-route, shaken-attested-invite, bye-glare, redirect-302. Pair with: `search_sip_docs` for vendor-specific quirks of the scenario; `render_sip_ladder` if the user does have a real trace.

Parameters4

scenario	string	required	Which scenario to render. Valid ids: basic-call, auth-challenge, cancel-before-answer, early-media, hold-resume, refer-blind, proxy-with-record-route, shaken-attested-invite, bye-glare, redirect-302.
actorNames	object	optional	Override the default actor display names (Alice/Bob/Proxy). Maps to the first/second/third lane in left-to-right order.
includeExplanation	boolean	optional	Append a bulleted Notes section with RFC references for each step.
verbose	boolean	optional	Also include the scenario's long Markdown explanation. Useful when the LLM is going to teach the user; off by default to keep responses small.

Raw schema

{
  "type": "object",
  "properties": {
    "scenario": {
      "type": "string",
      "enum": [
        "basic-call",
        "auth-challenge",
        "cancel-before-answer",
        "early-media",
        "hold-resume",
        "refer-blind",
        "proxy-with-record-route",
        "shaken-attested-invite",
        "bye-glare",
        "redirect-302"
      ],
      "description": "Which scenario to render. Valid ids: basic-call, auth-challenge, cancel-before-answer, early-media, hold-resume, refer-blind, proxy-with-record-route, shaken-attested-invite, bye-glare, redirect-302."
    },
    "actorNames": {
      "type": "object",
      "properties": {
        "uac": {
          "type": "string"
        },
        "uas": {
          "type": "string"
        },
        "proxy": {
          "type": "string"
        }
      },
      "additionalProperties": false,
      "description": "Override the default actor display names (Alice/Bob/Proxy). Maps to the first/second/third lane in left-to-right order."
    },
    "includeExplanation": {
      "type": "boolean",
      "default": true,
      "description": "Append a bulleted **Notes** section with RFC references for each step."
    },
    "verbose": {
      "type": "boolean",
      "default": false,
      "description": "Also include the scenario's long Markdown explanation. Useful when the LLM is going to teach the user; off by default to keep responses small."
    }
  },
  "required": [
    "scenario"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

lint_sip_request

[cost: free (pure CPU, no network) | read-only, no persistence] Run RFC 3261 / RFC 3325 / RFC 8224 / RFC 8225 / CTIA BCID compliance checks on a single raw SIP request (typically an INVITE) and return a list of findings. Catches the failure modes that silently break carrier interop: - Two `From:` headers in one request (RFC 3261 §7.3 / §20.20). - Missing CRLF between consecutive header lines (RFC 3261 §7.3). - `;tag=` (or any other) parameter on P-Asserted-Identity / P-Preferred-Identity (RFC 3325 §9.1). - PASSporT `orig.tn` not matching the From caller TN (RFC 8224 §5). - PASSporT `dest.tn` not matching the To callee TN (RFC 8224 §5). - Non-canonical TN inside a PASSporT claim (RFC 8225 §5.2.1). - Branded display name in From with no `ppt=rcd` Identity header (CTIA BCID §5). Use FIRST when chasing 422 / 400 Bad Request / 484 Invalid FROM on a single INVITE - these usually have a structural cause this tool catches mechanically. Pair with: `parse_sip_message` for purely structural checks on any SIP message (responses included); `validate_stir_shaken_identity` for the cryptographic verdict on Identity headers; `search_sip_docs({ sourceType: 'stir-shaken', ... })` to ground the explanation in RFC text.

Parameters1

text

string

required

Raw SIP request text. Should start with the request line (e.g. `INVITE sip:...@... SIP/2.0`). Headers must be CRLF or LF separated.

Raw schema

{
  "type": "object",
  "properties": {
    "text": {
      "type": "string",
      "minLength": 1,
      "maxLength": 64000,
      "description": "Raw SIP request text. Should start with the request line (e.g. `INVITE sip:...@... SIP/2.0`). Headers must be CRLF or LF separated."
    }
  },
  "required": [
    "text"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

parse_sip_message

[cost: free (pure CPU, no network) | read-only, no persistence] Parse a single raw SIP message (request OR response) and return a structured view: start line (method/status), every header in order with line numbers, body, duplicate-header counts, and a list of structural flags the parser noticed (`missing-crlf`, `tag-on-pai`, `tag-on-ppi`, `invalid-folding`, `duplicate-single-instance`, `content-length-mismatch`). Use FIRST when the user pastes a single INVITE / 200 / NOTIFY and asks 'what does this look like to a parser?' or 'is this even valid?'. The output makes header-level bugs (two `From:` headers, `;tag=` on PAI/PPI, missing CRLF between headers, broken Identity folding) obvious without an LLM having to scan visually. Pair with: `lint_sip_request` for the full RFC compliance suite (request only); `diff_sip_messages` to compare two parsed messages structurally; `validate_stir_shaken_identity` if the message carries an Identity header.

Parameters1

text

string

required

Raw SIP message text. Should start with a request line (`INVITE sip:...@... SIP/2.0`) or status line (`SIP/2.0 200 OK`). Headers must be CRLF or LF separated.

Raw schema

{
  "type": "object",
  "properties": {
    "text": {
      "type": "string",
      "minLength": 1,
      "maxLength": 64000,
      "description": "Raw SIP message text. Should start with a request line (`INVITE sip:...@... SIP/2.0`) or status line (`SIP/2.0 200 OK`). Headers must be CRLF or LF separated."
    }
  },
  "required": [
    "text"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

diff_sip_messages

[cost: free (pure CPU, no network) | read-only, no persistence] Take two SIP messages (typically the same request observed at two adjacent hops - e.g. the INVITE leaving FreeSWITCH and the INVITE arriving at Kamailio) and surface a structured per-header diff: `added`, `removed`, `mutated` (with old/new value), `duplicated` (single header → many), `de-duplicated`, `whitespace-only-change`, `parameter-reorder` (Via params, From tag), and `body-changed`. SDP bodies on both sides are delegated to `compareSdp` for codec / DTLS / ICE diffs. Use FIRST when the user has two captures or two log lines that should be carrying the same message and wants to know what an intermediate proxy / SBC / B2BUA changed. Far more reliable than visual inspection. Pair with: `parse_sip_message` to inspect either side in isolation; `lint_sip_request` if the diff reveals the downstream side became malformed; `search_sip_docs(vendor=<intermediate>)` once you know which hop's behavior is the source of the change.

Parameters4

before	string	required	SIP message as observed at the upstream hop (e.g. what FreeSWITCH believes it sent).
after	string	required	SIP message as observed at the downstream hop (e.g. what Kamailio believes it received).
labelBefore	string	optional	Display label for the upstream side. Default "before".
labelAfter	string	optional	Display label for the downstream side. Default "after".

Raw schema

{
  "type": "object",
  "properties": {
    "before": {
      "type": "string",
      "minLength": 1,
      "maxLength": 64000,
      "description": "SIP message as observed at the *upstream* hop (e.g. what FreeSWITCH believes it sent)."
    },
    "after": {
      "type": "string",
      "minLength": 1,
      "maxLength": 64000,
      "description": "SIP message as observed at the *downstream* hop (e.g. what Kamailio believes it received)."
    },
    "labelBefore": {
      "type": "string",
      "maxLength": 80,
      "default": "before",
      "description": "Display label for the upstream side. Default \"before\"."
    },
    "labelAfter": {
      "type": "string",
      "maxLength": 80,
      "default": "after",
      "description": "Display label for the downstream side. Default \"after\"."
    }
  },
  "required": [
    "before",
    "after"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

review_sip_config

[cost: free (pure CPU, no network) | read-only] Use this when the user asks 'review my config' or attaches a kamailio.cfg, sip.conf, pjsip.conf, FreeSWITCH XML profile, opensips.cfg, `res_fax.conf` / `udptl.conf` / `spandsp.conf` (fax-relay tuning), or a SIP-shaped source file from a repo. This tool: 1. Detects the vendor from filename + structural signatures (loadmodule, route blocks, [transport-*] sections, <profile name=>, KEMI calls). 2. Extracts a structured outline: loaded modules, modparams, listen lines, route blocks, profiles, gateways, dialplan extensions. 3. Surfaces risk flags - e.g. websocket loaded without TLS, nathelper without rtpengine, chan_sip used in modern Asterisk, AND the Kamailio/OpenSIPS lump-vs-subst race (`subst('/^From:.../...')` colliding with `KSR.hdr.append/remove` or `uac_replace_*` or `append_hf/remove_hf` on the same header - corrupts the buffer at serialization). 4. Returns a list of `suggestedQueries` for `search_sip_docs` so you can ground the actual review in vendor docs. Pair with: one or more `search_sip_docs` calls (cite returned `source_url` values verbatim instead of recalling vendor behavior from memory); `webrtc_sip_checklist` when the config is a WebRTC ↔ SIP bridge.

Parameters3

text	string	required	The full config blob (or a representative excerpt). UTF-8 plaintext.
filenameHint	string	optional	Optional filename or path (e.g. "kamailio.cfg", "etc/asterisk/pjsip.conf", "sofia/external.xml"). Strongly improves vendor detection.
vendorHint	string	optional	Skip auto-detection and force a specific vendor. Use when the heuristics return low confidence or the wrong vendor.

Raw schema

{
  "type": "object",
  "properties": {
    "text": {
      "type": "string",
      "minLength": 1,
      "maxLength": 2000000,
      "description": "The full config blob (or a representative excerpt). UTF-8 plaintext."
    },
    "filenameHint": {
      "type": "string",
      "maxLength": 200,
      "description": "Optional filename or path (e.g. \"kamailio.cfg\", \"etc/asterisk/pjsip.conf\", \"sofia/external.xml\"). Strongly improves vendor detection."
    },
    "vendorHint": {
      "type": "string",
      "enum": [
        "asterisk",
        "freeswitch",
        "kamailio",
        "opensips",
        "freepbx",
        "yate",
        "cisco-cube",
        "ribbon",
        "oracle-acme",
        "audiocodes",
        "cisco-cucm",
        "avaya",
        "mitel",
        "metaswitch",
        "3cx",
        "nec",
        "twilio",
        "telnyx",
        "bandwidth",
        "bandwidth-bxf",
        "vonage",
        "plivo",
        "signalwire",
        "aws-chime",
        "didww",
        "voxbone",
        "genband",
        "cisco-bts",
        "teams",
        "zoom-phone",
        "ringcentral",
        "webex-calling",
        "eight-by-eight",
        "polycom",
        "yealink",
        "cisco-phone",
        "grandstream",
        "snom",
        "linphone",
        "microsip",
        "bria",
        "zoiper",
        "jssip",
        "sip-js",
        "stir-shaken"
      ],
      "description": "Skip auto-detection and force a specific vendor. Use when the heuristics return low confidence or the wrong vendor."
    }
  },
  "required": [
    "text"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

webrtc_sip_checklist

[cost: free (pure CPU, no network) | read-only] Return a curated checklist of WebRTC ↔ SIP requirements (WSS transport, ICE gathering, DTLS-SRTP fingerprint, rtcp-mux + BUNDLE, media relay / rtpengine, STUN/TURN, secure-context Origin allowlist, Opus codec, session-timer behavior across the bridge, STIR/SHAKEN signing). When `configText` is supplied, each item is marked as 'looks present' or 'check needed' based on simple regex signals. Use when the user is building a WebRTC ↔ SIP bridge or troubleshooting one (no media, one-way audio, ICE failures). Pair with: `review_sip_config` for the full structured outline; `search_sip_docs(vendor=...)` to ground each unchecked item in vendor docs; `parse_sdp` / `compare_sdp_offer_answer` when the bug is in SDP negotiation.

Parameters3

vendor	string	optional	Vendor slug. Omit and supply `configText` to auto-detect.
configText	string	optional	Optional config blob. When supplied, items with matching signals are marked as present; vendor is auto-detected if not supplied.
filenameHint	string	optional	Optional filename ("kamailio.cfg", etc.) to bias auto-detection.

Raw schema

{
  "type": "object",
  "properties": {
    "vendor": {
      "type": "string",
      "enum": [
        "asterisk",
        "freeswitch",
        "kamailio",
        "opensips",
        "freepbx",
        "yate",
        "cisco-cube",
        "ribbon",
        "oracle-acme",
        "audiocodes",
        "cisco-cucm",
        "avaya",
        "mitel",
        "metaswitch",
        "3cx",
        "nec",
        "twilio",
        "telnyx",
        "bandwidth",
        "bandwidth-bxf",
        "vonage",
        "plivo",
        "signalwire",
        "aws-chime",
        "didww",
        "voxbone",
        "genband",
        "cisco-bts",
        "teams",
        "zoom-phone",
        "ringcentral",
        "webex-calling",
        "eight-by-eight",
        "polycom",
        "yealink",
        "cisco-phone",
        "grandstream",
        "snom",
        "linphone",
        "microsip",
        "bria",
        "zoiper",
        "jssip",
        "sip-js",
        "stir-shaken"
      ],
      "description": "Vendor slug. Omit and supply `configText` to auto-detect."
    },
    "configText": {
      "type": "string",
      "maxLength": 2000000,
      "description": "Optional config blob. When supplied, items with matching signals are marked as present; vendor is auto-detected if not supplied."
    },
    "filenameHint": {
      "type": "string",
      "maxLength": 200,
      "description": "Optional filename (\"kamailio.cfg\", etc.) to bias auto-detection."
    }
  },
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

parse_sdp

[cost: free (pure CPU, no network) | read-only] Parse a Session Description Protocol body and return a structured view: origin, session, timing, per-media codecs (rtpmap + fmtp), direction, DTLS setup + fingerprint, ICE credentials + candidates, rtcp-mux, BUNDLE groups, fax-relay (`m=image udptl t38` plus the `a=T38Fax*` attribute family), and crypto attributes. Useful for debugging WebRTC ↔ SIP interop (codec negotiation, DTLS-SRTP fingerprints, ICE candidate gathering, bundle alignment), and for inspecting fax negotiation (T.38 reinvite SDP, `T38FaxMaxBuffer`/`T38FaxUdpEC`/`T38FaxRateManagement`) without an LLM having to re-derive the SDP grammar each call. Pair with: `compare_sdp_offer_answer` when the user has both halves of the negotiation (including T.30→T.38 reinvites); `webrtc_sip_checklist` for the bridge-config angle.

Parameters1

sdp

string

required

SDP body - the section after the empty line in an INVITE/200/UPDATE.

Raw schema

{
  "type": "object",
  "properties": {
    "sdp": {
      "type": "string",
      "minLength": 1,
      "maxLength": 65536,
      "description": "SDP body - the section after the empty line in an INVITE/200/UPDATE."
    }
  },
  "required": [
    "sdp"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

compare_sdp_offer_answer

[cost: free (pure CPU, no network) | read-only] Diff a SIP/SDP offer and answer and surface the issues that actually break calls in practice: codec intersection per m-line, direction compatibility (sendrecv ↔ recvonly), DTLS setup-role conflicts (active+active / passive+passive), rtcp-mux / BUNDLE asymmetry, missing DTLS fingerprints when DTLS-SRTP is negotiated, ICE asymmetry, and fax reinvite mismatches (e.g. offer `m=image udptl t38` answered with audio-only, or `T38FaxVersion` / `T38FaxMaxBuffer` / `T38FaxRateManagement` drift). Use when the user has both halves of a negotiation and is debugging 488 Not Acceptable Here, no-audio, one-way-audio, or a failed T.38 reinvite (488 / 415 / 606 on a `m=image` offer). Pair with: `parse_sdp` to inspect either side in isolation; `search_sip_docs(vendor=...)` to ground vendor-specific fixes (FreeSWITCH `mod_spandsp`, Cisco CUBE `fax protocol t38`); `lookup_response_code(488)` for the static SIP-side context.

Parameters2

offer	string	required	SDP offer body.
answer	string	required	SDP answer body.

Raw schema

{
  "type": "object",
  "properties": {
    "offer": {
      "type": "string",
      "minLength": 1,
      "maxLength": 65536,
      "description": "SDP offer body."
    },
    "answer": {
      "type": "string",
      "minLength": 1,
      "maxLength": 65536,
      "description": "SDP answer body."
    }
  },
  "required": [
    "offer",
    "answer"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

validate_stir_shaken_identity

[cost: external_io (HTTPS fetch of the x5u cert) | read-only] Verify a SIP `Identity:` JWS (RFC 8224 / SHAKEN). Fetches the x5u certificate, parses it, verifies the ES256 signature against the cert's public key, and optionally validates the RCD icon hash (RFC 9795). The icon-hash check accepts both `payload.rcdi["/icn"]` (RFC 9795 §6.1 spec form) and the legacy `payload.rcdi["icn"]` form deployed in the wild - the legacy form raises a warning unless `strictRfc9795: true` (then it fails). Returns per-check pass/fail/warning with details - useful for diagnosing 438 Invalid Identity Header rejections, expired certs, and tampered PASSporTs. Pair with: `stir_attestation_explainer` for the human-readable A/B/C interpretation; `lookup_response_code(438)` for the SIP-side context; `lint_sip_request` for non-cryptographic structural checks on the host INVITE.

Parameters8

infoUrl	string	optional	Cert URL from the SIP Identity header `info=` param (or the JWT `x5u`). If omitted, signature verification is skipped.
headerB64	string	required	Base64url-encoded JWS protected header (the first dot-separated segment).
payloadB64	string	required	Base64url-encoded JWS payload (the second segment).
signatureB64	string	required	Base64url-encoded ES256 signature (the third segment, raw R\|\|S, 64 bytes).
iconUrl	string	optional	RCD icon URL - `payload.rcd.icn`. Omit if no Rich Call Data icon.
expectedIconHash	string	optional	Pre-extracted icon hash, e.g. `sha256-XYZ` (RFC 9795 §6.1 form `<algorithm>-<base64>`). Pass this OR `rcdi`.
rcdi	object	optional	Full `payload.rcdi` claim. The validator looks up `/icn` first (RFC 9795 §6.1 spec form), then falls back to the legacy `icn` key (still seen in the wild). A legacy hit produces a `rcdi-pointer-form` warning unless `strictRfc9795: true` (then it fails).
strictRfc9795	boolean	optional	When true, reject the legacy `rcdi['icn']` key as a hard failure rather than warning. Default false.

Raw schema

{
  "type": "object",
  "properties": {
    "infoUrl": {
      "type": "string",
      "format": "uri",
      "description": "Cert URL from the SIP Identity header `info=` param (or the JWT `x5u`). If omitted, signature verification is skipped."
    },
    "headerB64": {
      "type": "string",
      "minLength": 1,
      "description": "Base64url-encoded JWS protected header (the first dot-separated segment)."
    },
    "payloadB64": {
      "type": "string",
      "minLength": 1,
      "description": "Base64url-encoded JWS payload (the second segment)."
    },
    "signatureB64": {
      "type": "string",
      "minLength": 1,
      "description": "Base64url-encoded ES256 signature (the third segment, raw R||S, 64 bytes)."
    },
    "iconUrl": {
      "type": "string",
      "format": "uri",
      "description": "RCD icon URL - `payload.rcd.icn`. Omit if no Rich Call Data icon."
    },
    "expectedIconHash": {
      "type": "string",
      "description": "Pre-extracted icon hash, e.g. `sha256-XYZ` (RFC 9795 §6.1 form `<algorithm>-<base64>`). Pass this OR `rcdi`."
    },
    "rcdi": {
      "type": "object",
      "additionalProperties": {
        "type": "string"
      },
      "description": "Full `payload.rcdi` claim. The validator looks up `/icn` first (RFC 9795 §6.1 spec form), then falls back to the legacy `icn` key (still seen in the wild). A legacy hit produces a `rcdi-pointer-form` warning unless `strictRfc9795: true` (then it fails)."
    },
    "strictRfc9795": {
      "type": "boolean",
      "description": "When true, reject the legacy `rcdi['icn']` key as a hard failure rather than warning. Default false."
    }
  },
  "required": [
    "headerB64",
    "payloadB64",
    "signatureB64"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

stir_attestation_explainer

[cost: free (pure CPU, no network) | read-only] Static explainer for STIR/SHAKEN: maps attestation levels (A / B / C per RFC 8588) to plain-English requirements + common scenarios, and SIP codes commonly emitted by signing/verification (428 / 436 / 437 / 438 / 608) to their RFC anchors and operator causes. Provide either `attestation` (A/B/C) or `code` (e.g. 438). Pair with: `validate_stir_shaken_identity` when the user has the JWS segments and wants the cryptographic verdict; `search_sip_docs({ sourceType: 'stir-shaken', ... })` for ATIS / CTIA / RFC depth.

Parameters2

attestation	string	optional	Attestation level: "A" Full / "B" Partial / "C" Gateway.
code	integer	optional	SIP response code commonly seen in STIR/SHAKEN flows (428, 436, 437, 438, 608).

Raw schema

{
  "type": "object",
  "properties": {
    "attestation": {
      "type": "string",
      "enum": [
        "A",
        "B",
        "C"
      ],
      "description": "Attestation level: \"A\" Full / \"B\" Partial / \"C\" Gateway."
    },
    "code": {
      "type": "integer",
      "minimum": 100,
      "maximum": 699,
      "description": "SIP response code commonly seen in STIR/SHAKEN flows (428, 436, 437, 438, 608)."
    }
  },
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

validate_e164_number

[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.

Parameters1

number

string

required

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

Raw schema

{
  "type": "object",
  "properties": {
    "number": {
      "type": "string",
      "minLength": 1,
      "maxLength": 64,
      "description": "Phone number in any common form. E.164 (+CCNNN…) is preferred; 10-digit US numbers are accepted as a convenience."
    }
  },
  "required": [
    "number"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

troubleshoot_response_code

[cost: rag (one embed + one vector search) | read-only, network: outbound to embed model only | rate-limited per IP] Like `lookup_response_code` but augmented: returns the static RFC entry PLUS the top vendor-specific RAG hits for the exact code (and any free-text context the user pasted). When the static entry carries known vendor-specific reason-phrase variants (e.g. 484 + opensips → 'Invalid FROM' from `parse_from.c`), those phrases are folded into the embed query so the right vendor docs surface. Use when the user asks 'why did <vendor> reject this with <code>?' and you want vendor-grounded common causes, not just the RFC text. Especially helpful for fax-rejection paths - 488 / 415 / 606 on a T.38 reinvite (`m=image udptl t38`) is one of the most common 488 variants and the tool surfaces FreeSWITCH `mod_spandsp` / Cisco CUBE / AudioCodes T.38 docs alongside the RFC text. Pair with: `lookup_response_code` first (cheaper); `lint_sip_request` when the code is 4xx and they have the offending request; `compare_sdp_offer_answer` for 488/415 caused by a T.38 reinvite SDP mismatch; `validate_stir_shaken_identity` when the code is 438; `stir_attestation_explainer` for STIR-shaped codes (428/436/437/438/608); `dns_diagnose_sip_target` when the code is 503 / 408 and routing is suspect.

Parameters3

code	integer	required	SIP response code (e.g. 488, 503, 438).
vendorHint	string	optional	Vendor slug to filter the RAG search (e.g. "kamailio", "freeswitch", "twilio"). Strongly recommended.
context	string	optional	Optional free-text context: a snippet of the trace, the Reason header, the Warning header, or a one-line description of what the user was trying to do.

Raw schema

{
  "type": "object",
  "properties": {
    "code": {
      "type": "integer",
      "minimum": 100,
      "maximum": 699,
      "description": "SIP response code (e.g. 488, 503, 438)."
    },
    "vendorHint": {
      "type": "string",
      "enum": [
        "asterisk",
        "freeswitch",
        "kamailio",
        "opensips",
        "freepbx",
        "yate",
        "cisco-cube",
        "ribbon",
        "oracle-acme",
        "audiocodes",
        "cisco-cucm",
        "avaya",
        "mitel",
        "metaswitch",
        "3cx",
        "nec",
        "twilio",
        "telnyx",
        "bandwidth",
        "bandwidth-bxf",
        "vonage",
        "plivo",
        "signalwire",
        "aws-chime",
        "didww",
        "voxbone",
        "genband",
        "cisco-bts",
        "teams",
        "zoom-phone",
        "ringcentral",
        "webex-calling",
        "eight-by-eight",
        "polycom",
        "yealink",
        "cisco-phone",
        "grandstream",
        "snom",
        "linphone",
        "microsip",
        "bria",
        "zoiper",
        "jssip",
        "sip-js",
        "stir-shaken"
      ],
      "description": "Vendor slug to filter the RAG search (e.g. \"kamailio\", \"freeswitch\", \"twilio\"). Strongly recommended."
    },
    "context": {
      "type": "string",
      "maxLength": 8000,
      "description": "Optional free-text context: a snippet of the trace, the Reason header, the Warning header, or a one-line description of what the user was trying to do."
    }
  },
  "required": [
    "code"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

dns_diagnose_sip_target

[cost: external_io (DNS via Cloudflare + Google; TLS handshake + a SIP OPTIONS keepalive to public targets when applicable) | read-only | rate-limited per IP: 10/min, 200/day] Walk DNS the same way a SIP UA does (RFC 3263 §4.1): NAPTR → SRV → A/AAAA. Given a SIP URI ("sip:example.com"), bare hostname ("example.com"), or "host:port" string, return the records that exist and the resolution ladder a UA would try. When the queried target uses TLS (`sips:` URI, `transport=tls/wss`, or any `_sips._tcp` SRV record), the tool also performs a TLS handshake against each resolved sips target and reports the negotiated TLS version + cipher, the leaf certificate's subject / issuer / SANs / validity, the chain length and whether it validates against Node's default trust store, plus two cert-domain checks: RFC 5922 §7.2 strict (cert must cover the original SIP domain) and a lenient SAN match against the SRV target hostname. SIP liveness: DNS resolving and a TLS handshake succeeding do NOT prove the endpoint actually speaks SIP - a load-balanced node can accept TCP/TLS yet black-hole SIP. So the tool ALSO sends a real SIP OPTIONS keepalive to each resolved public IP across the relevant transports (UDP/TCP on 5060, TLS on 5061 / SRV port) and reports per-IP answered / timeout / refused. Any SIP response (even 405/403/404) proves the stack is alive on that IP. When a name resolves to multiple IPs it is treated as a load-balancer fan-out and each IP is probed individually, with a warning about the known failure modes of fronting stateful SIP/RTP with a cloud L4 LB (AWS NLB/ALB etc.): cross-zone-off targets that black-hole, the ~120s UDP idle timeout, and per-5-tuple hashing splitting signaling from media. Egress safety: - Per-IP rate limited. - Hostnames that resolve only to RFC 1918 / loopback / link-local / documentation / multicast space are refused (SSRF guard). - Walk depth capped to prevent runaway NAPTR / CNAME chains. - TLS probes capped at 6 (host, port, ip) tuples per call, 5 s handshake timeout each, public-IP only (we connect to the resolved IP, not the hostname, so the system resolver cannot redirect us into private space). - SIP OPTIONS probes capped at 6 (ip, transport) tuples per call, 3 s timeout each, public-IP only; the request carries no SDP/body and an unroutable Via, and only the response status line is captured. Use to diagnose: - "carrier doesn't answer" / "wrong port" / "TLS instead of UDP" routing puzzles - "DNS looks healthy but calls fail" - per-IP SIP OPTIONS surfaces nodes that resolve and accept the transport but never answer SIP (the decisive step for load-balanced / multi-IP targets) - "carrier rejects our target because no SRV is published" - when A/AAAA resolves but SRV is missing the tool synthesises a copy-pasteable suggested zone-record block pointing at the resolved canonical hostname - "TLS handshake works but cert isn't valid for the SIP domain" - RFC 5922 §7.2 compliance is checked separately from generic chain validation, since the SAN must cover the *original* SIP domain (not the SRV-redirected target) ACL caveat: a SIP OPTIONS timeout can also mean the target authorizes inbound SIP by source IP whitelist on the trunk (Twilio, Telnyx, Bandwidth, …; see https://www.twilio.com/docs/sip-trunking/api/ipaccesscontrollist-resource) and is dropping our probe because our egress IP is not on the ACL. An `answered` result is conclusive (the node speaks SIP); a `timeout` is suggestive, not proof of a dead node - confirm reachability from the SBC itself. Pair with: `troubleshoot_response_code` when 503 / 408 / 480 are involved; `search_sip_docs(vendor=...)` for carrier-specific routing docs.

Parameters2

target	string	required	SIP URI ("sip:example.com"), "example.com:5060", or bare hostname ("example.com"). Userinfo is stripped before lookup.
transport	string	optional	Transport hint. "any" surfaces all NAPTR services; specific transports filter the SRV walk to that service.

Raw schema

{
  "type": "object",
  "properties": {
    "target": {
      "type": "string",
      "minLength": 1,
      "maxLength": 256,
      "description": "SIP URI (\"sip:example.com\"), \"example.com:5060\", or bare hostname (\"example.com\"). Userinfo is stripped before lookup."
    },
    "transport": {
      "type": "string",
      "enum": [
        "any",
        "udp",
        "tcp",
        "tls",
        "ws",
        "wss"
      ],
      "default": "any",
      "description": "Transport hint. \"any\" surfaces all NAPTR services; specific transports filter the SRV walk to that service."
    }
  },
  "required": [
    "target"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

fetch_sipflow_share

[cost: external_io (Mongo + S3 fetch on the Sipflow backend) | read-only, no persistence | rate limit: shared with the public share endpoint] Given a Sipflow share URL (https://sipflow.dev/share/<token>, or any sipflow.dev subdomain that serves /share/<token>), load the shared SIP trace AND any prior AI analysis attached to it in a single round trip. Use this whenever a user pastes a `/share/<token>` URL: the tool fetches the redacted trace text, the AI executive summary / root-cause / remediation steps (if present), and metadata (vendor, filename, source format, pseudonymized flag), so the agent can review the trace alongside the user's own configs without manual download + paste. In addition to the AI output, the response includes rule-based diagnostics: detected issues (severity-tagged SIP/SDP/media problems with RFC references), WebRTC signal checklist scores, multi-leg call correlation (Session-ID grouping), and detected SIP stacks (User-Agent/Server header values). These diagnostics are computed at share-creation time; for older shares without persisted diagnostics, the tool parses the trace on the fly. When the share includes media quality data (from PCAP-sourced captures), the response includes per-call MOS/jitter/loss summaries in the text output and full `mediaQuality` stats in `structuredContent`. If `hasRawCapture` is true, the sharer included their original PCAP for full RTP playback on the web UI - this raw binary is not returned to agents. Privacy: the share endpoint deliberately strips the original `problem` and `architecture` fields the sharer typed in (those may contain customer-internal context). This tool returns the same public projection - only the trace, the AI output, diagnostics, and basic metadata. Traces are pseudonymized by default (phone numbers / IPs / Call-IDs replaced with consistent fakes); the `pseudonymized` field tells you whether the sharer opted to keep raw values. Trace bytes are capped at 200kB (matching the budget the Sipflow AI worker uses). For very large captures the response sets `trace.truncated=true` - pair with `minimize_sip_trace` to compact further before passing to your own LLM, or with `render_sip_ladder` to visualize the call flow. Pair with: `review_sip_config` to compare the shared trace against the user's own kamailio.cfg / pjsip.conf / FreeSWITCH XML; `render_sip_ladder` to draw the shared call flow inline; `minimize_sip_trace` if `trace.truncated` is true; `troubleshoot_response_code` for any failing transactions surfaced in the AI analysis.

Parameters1

url

string

required

Full Sipflow share URL. Example: "https://sipflow.dev/share/eyJqb2JJZCI6Ii4uLiJ9.abc123". The path must be /share/<token>; /api/share/... endpoints are not accepted.

Raw schema

{
  "type": "object",
  "properties": {
    "url": {
      "type": "string",
      "minLength": 1,
      "maxLength": 2048,
      "description": "Full Sipflow share URL. Example: \"https://sipflow.dev/share/eyJqb2JJZCI6Ii4uLiJ9.abc123\". The path must be /share/<token>; /api/share/... endpoints are not accepted."
    }
  },
  "required": [
    "url"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

submit_sipflow_feedback

[cost: write (single MongoDB row) | rate-limited per IP: 3/min, 20/day] Send the Sipflow team feedback when something doesn't work, a vendor or RFC isn't covered, or a tool produced a wrong/incomplete answer. Categories: - docs_gap: search_sip_docs returned nothing useful, vendor missing, coverage incomplete - tool_bug: a tool errored, returned garbage, or behaved unexpectedly on a real input - wrong_answer: the answer it produced was incorrect for the SIP/VoIP question asked - feature_request: a new tool, dataset, or behavior the user wants - general: anything else PRIVACY CONTRACT (MUST FOLLOW): 1. Use this tool only when the user explicitly asks to send feedback, OR when you have completed the user's primary task and there is a clear, actionable gap worth reporting. 2. ALWAYS show the user the exact `summary` + `details` + other fields you plan to send and wait for an explicit yes before calling this tool. Set `userConsent: true` only after that confirmation. 3. NEVER include raw SIP traces, INVITE/REGISTER bodies, SDP, phone numbers, IP addresses, Call-IDs, or any other PII. Summarize in your own words instead. The server runs a sanitizer as a backstop, but you are the first line of defense. 4. The `contact` field is optional and may only be filled when the user explicitly provides an email and asks you to include it. 5. The `traceExcerpt` field is optional and accepts a sanitized SIP message text block (Via/From/To/Call-ID, optional minimal SDP) the user explicitly approved attaching. Pipe `minimize_sip_trace` output here, NEVER raw INVITE / REGISTER bodies or full pcap text. Phone numbers, IPs, and emails are scrubbed server-side as a backstop; the agent must still summarize / minimize first. The same `userConsent: true` covers both the text fields and the excerpt - if the user wants the excerpt included you must show it to them before sending. The tool returns a ticket id (fb_xxxxxxxx) and stores one anonymous row keyed by your daily-rotating IP hash (no raw IP, no account). Rate-limited at 3/min and 20/day per IP hash.

Parameters9

category	string	required	Bucket. Use docs_gap for missing RAG coverage, tool_bug for broken behavior, wrong_answer for incorrect output, feature_request for new asks, general for anything else.
summary	string	required	Short one-line description of the feedback. Will be shown to humans triaging. PII-free.
details	string	optional	Longer description: what the user was trying to do, what happened, what they expected. PII-free.
relatedTool	string	optional	Name of the Sipflow MCP tool the feedback relates to, if any (e.g. `search_sip_docs`, `troubleshoot_response_code`).
relatedQuery	string	optional	The search query / question that failed or returned poor results. PII-free.
vendorOrTopic	string	optional	Vendor slug, RFC number, or topic the feedback relates to (e.g. 'freeswitch', 'RFC 3261', 'fax-over-IP').
contact	string	optional	Optional email the user can be reached at. Only include when the user explicitly provides one and asks you to attach it.
traceExcerpt	string	optional	Optional sanitized SIP message text the user explicitly approved attaching. Use the output of `minimize_sip_trace` (or a hand-scrubbed Via/From/To/Call-ID/CSeq block, optionally with minimal SDP). NEVER paste raw INVITE / REGISTER bodies, full pcap text, or anything containing phone numbers / IPs / Call-IDs you have not already redacted. The server runs a backstop sanitizer that redacts phones, IPs, and emails. Hard cap 32 kB.
userConsent	boolean	required	MUST be true. Set this only after you have shown the user the exact payload above (including any `traceExcerpt`) and they have confirmed they want it sent.

Raw schema

{
  "type": "object",
  "properties": {
    "category": {
      "type": "string",
      "enum": [
        "docs_gap",
        "tool_bug",
        "wrong_answer",
        "feature_request",
        "general"
      ],
      "description": "Bucket. Use docs_gap for missing RAG coverage, tool_bug for broken behavior, wrong_answer for incorrect output, feature_request for new asks, general for anything else."
    },
    "summary": {
      "type": "string",
      "minLength": 1,
      "maxLength": 500,
      "description": "Short one-line description of the feedback. Will be shown to humans triaging. PII-free."
    },
    "details": {
      "type": "string",
      "maxLength": 4000,
      "description": "Longer description: what the user was trying to do, what happened, what they expected. PII-free."
    },
    "relatedTool": {
      "type": "string",
      "maxLength": 200,
      "description": "Name of the Sipflow MCP tool the feedback relates to, if any (e.g. `search_sip_docs`, `troubleshoot_response_code`)."
    },
    "relatedQuery": {
      "type": "string",
      "maxLength": 200,
      "description": "The search query / question that failed or returned poor results. PII-free."
    },
    "vendorOrTopic": {
      "type": "string",
      "maxLength": 200,
      "description": "Vendor slug, RFC number, or topic the feedback relates to (e.g. 'freeswitch', 'RFC 3261', 'fax-over-IP')."
    },
    "contact": {
      "type": "string",
      "maxLength": 200,
      "description": "Optional email the user can be reached at. Only include when the user explicitly provides one and asks you to attach it."
    },
    "traceExcerpt": {
      "type": "string",
      "maxLength": 32000,
      "description": "Optional sanitized SIP message text the user explicitly approved attaching. Use the output of `minimize_sip_trace` (or a hand-scrubbed Via/From/To/Call-ID/CSeq block, optionally with minimal SDP). NEVER paste raw INVITE / REGISTER bodies, full pcap text, or anything containing phone numbers / IPs / Call-IDs you have not already redacted. The server runs a backstop sanitizer that redacts phones, IPs, and emails. Hard cap 32 kB."
    },
    "userConsent": {
      "type": "boolean",
      "const": true,
      "description": "MUST be true. Set this only after you have shown the user the exact payload above (including any `traceExcerpt`) and they have confirmed they want it sent."
    }
  },
  "required": [
    "category",
    "summary",
    "userConsent"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

README.md6 KBView on GitHub

Sipflow MCP

SIP/VoIP/telecom grounding for AI agents. Vendor docs across ~40 stacks, 60+ RFCs, STIR/SHAKEN, trace and config analysis - every answer cites a verbatim source_url.

Sipflow is a hosted, read-only Model Context Protocol server. It gives your editor or agent ~20 tools that ground SIP/VoIP answers in a curated corpus instead of training-data recall.

Live endpoint: https://mcp.sipflow.dev/mcp (Streamable HTTP)
Web app: https://www.sipflow.dev
Install page (one-click + all clients): https://www.sipflow.dev/tools/mcp

Install

Cursor (one-click)

Install Sipflow in Cursor

Or from the Cursor Marketplace. This repo also ships as a Cursor plugin with a bundled Skill and Rule (see What's in this repo below).

Cursor (manual) - `~/.cursor/mcp.json`

json

{
  "mcpServers": {
    "sipflow": { "url": "https://mcp.sipflow.dev/mcp" }
  }
}

VS Code - `.vscode/mcp.json` or user `settings.json`

json

{
  "servers": {
    "sipflow": {
      "type": "http",
      "url": "https://mcp.sipflow.dev/mcp"
    }
  }
}

Requires VS Code 1.99+ with the GitHub Copilot extension.

Claude Desktop - `claude_desktop_config.json`

Claude Desktop is stdio-only, so use the mcp-remote shim:

json

{
  "mcpServers": {
    "sipflow": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.sipflow.dev/mcp"]
    }
  }
}

Claude Code (CLI)

bash

claude mcp add --transport http sipflow https://mcp.sipflow.dev/mcp

Codex CLI - `~/.codex/config.toml`

toml

[mcp_servers.sipflow]
url = "https://mcp.sipflow.dev/mcp"

Cline - Settings -> MCP Servers -> Edit JSON

json

{
  "mcpServers": {
    "sipflow": { "url": "https://mcp.sipflow.dev/mcp" }
  }
}

Continue - `~/.continue/config.yaml`

yaml

mcpServers:
  - name: sipflow
    transport:
      type: streamable-http
      url: https://mcp.sipflow.dev/mcp

Windsurf - `~/.codeium/windsurf/mcp_config.json`

json

{
  "mcpServers": {
    "sipflow": {
      "serverUrl": "https://mcp.sipflow.dev/mcp"
    }
  }
}

Goose - `~/.config/goose/config.yaml`

yaml

extensions:
  sipflow:
    type: http
    uri: https://mcp.sipflow.dev/mcp
    enabled: true

Generic / curl smoke-test

bash

curl -sS -X POST https://mcp.sipflow.dev/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

What's in this repo

File / Folder	Marketplace	Purpose
`server.json`	Official MCP Registry	Canonical server descriptor. PulseMCP auto-ingests from here.
`smithery.yaml`	Smithery	Remote HTTP listing.
`.cursor-plugin/plugin.json`	Cursor Marketplace	Plugin manifest.
`mcp.json`	Cursor plugin auto-discovery	Points the plugin at the remote endpoint.
`skills/sip-debugger/`	Cursor plugin	"When to use Sipflow" playbook surfaced as `/sip-debugger`.
`rules/sip-grounding.mdc`	Cursor plugin	Auto-attaches when editing `.pcap`, kamailio/opensips/freeswitch/asterisk configs, dialplans, `.sdp`.
`assets/logo.svg`	All	Logo.

The Cursor-specific files (.cursor-plugin/, mcp.json, skills/, rules/) are silently ignored by non-Cursor marketplaces - they only parse their own manifest.

Tool catalog

All tools are read-only. The only outbound IO is dns_diagnose_sip_target (DNS + TLS handshake) and validate_stir_shaken_identity (cert fetch).

Discovery / grounding - search_sip_docs, lookup_response_code, lookup_sip_header

Detection - detect_sip_stack, detect_sip_vendor_from_config

Traces - minimize_sip_trace, render_sip_ladder, sip_ladder_example, lint_sip_request, parse_sip_message, diff_sip_messages

Config review - review_sip_config, webrtc_sip_checklist

SDP - parse_sdp, compare_sdp_offer_answer

STIR/SHAKEN - validate_stir_shaken_identity, stir_attestation_explainer

Telecom - validate_e164_number, troubleshoot_response_code

Network - dns_diagnose_sip_target (rate-limited)

Share hydration - fetch_sipflow_share for sipflow.dev/share/<token> URLs

Resource - sipflow://docs/{vendor}/{id} for a single corpus chunk

Corpus coverage

~40 vendor stacks: Kamailio, OpenSIPS, FreeSWITCH, Asterisk (PJSIP + chan_sip), SIP.js, JsSIP, FreePBX, 3CX, OpenSER, Twilio, Cisco, ...
60+ RFCs: SIP, SDP, RTP, WebRTC core
STIR/SHAKEN: RFC 8224/8225/8226/8588/9027/9795
Branded calling: ATIS-1000074, ATIS-1000094, ATIS-1000084, CTIA BCID

Local development (Cursor plugin)

Test the plugin locally by symlinking this repo into Cursor's local plugin folder:

bash

ln -s "$PWD" ~/.cursor/plugins/local/sipflow

Run Developer: Reload Window in Cursor. You should see:

sipflow server in Settings -> Features -> Model Context Protocol
sip-debugger skill under Settings -> Rules (Agent Decides)
sip-grounding rule under Settings -> Rules

Submitting updates

When the MCP server changes, bump version in three places to keep registries in sync:

server.json -> Official MCP Registry
.cursor-plugin/plugin.json -> Cursor Marketplace
The hosted server's serverInfo.version

Then re-run mcp-publisher publish for the Official Registry. Cursor, Smithery, and Glama auto-track the default branch.

License

MIT - see LICENSE.

Install

Tools (22)

search_sip_docslookup_response_codelookup_sip_headerdetect_sip_stackdetect_sip_vendor_from_configminimize_sip_tracerender_sip_laddersip_ladder_example

Remote endpoint

Streamable HTTP

Hosted server - connect over the network, no local install.

url

https://mcp.sipflow.dev/mcp

Add to VS Code Add to Cursor

claude_desktop_config.json

json

{
  "mcpServers": {
    "sipflow": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.sipflow.dev/mcp"
      ]
    }
  }
}

Desktop config is stdio-only; this bridges via mcp-remote. Native remote: Settings > Connectors.

Sipflow MCP (dev.sipflow/sipflow)

🛠️ Key Features

🚀 Use Cases

⚡ Developer Benefits

⚠️ Limitations

search_sip_docs

lookup_response_code

lookup_sip_header

detect_sip_stack

detect_sip_vendor_from_config

minimize_sip_trace

render_sip_ladder

sip_ladder_example

lint_sip_request

parse_sip_message

diff_sip_messages

review_sip_config

webrtc_sip_checklist

parse_sdp

compare_sdp_offer_answer

validate_stir_shaken_identity

stir_attestation_explainer

validate_e164_number

troubleshoot_response_code

dns_diagnose_sip_target

fetch_sipflow_share

submit_sipflow_feedback

Sipflow MCP

Install

Cursor (one-click)

Cursor (manual) - ~/.cursor/mcp.json

VS Code - .vscode/mcp.json or user settings.json

Claude Desktop - claude_desktop_config.json

Claude Code (CLI)

Codex CLI - ~/.codex/config.toml

Cline - Settings -> MCP Servers -> Edit JSON

Continue - ~/.continue/config.yaml

Windsurf - ~/.codeium/windsurf/mcp_config.json

Goose - ~/.config/goose/config.yaml

Generic / curl smoke-test

What's in this repo

Tool catalog

Corpus coverage

Local development (Cursor plugin)

Submitting updates

License

Install

Remote endpoint

Related servers

Cursor (manual) - `~/.cursor/mcp.json`

VS Code - `.vscode/mcp.json` or user `settings.json`

Claude Desktop - `claude_desktop_config.json`

Codex CLI - `~/.codex/config.toml`

Continue - `~/.continue/config.yaml`

Windsurf - `~/.codeium/windsurf/mcp_config.json`

Goose - `~/.config/goose/config.yaml`