Skip to main content
Glama

Sipflow

by dev.sipflow

Render a SIP trace as a Mermaid call-flow ladder

render_sip_ladder
Read-only

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesRaw SIP trace text. Multiple messages may be concatenated.
callIdNoRender only this Call-ID. Required when the trace contains multiple calls; otherwise the only call is used.
aliasesNoFriendly 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"}`.
compactNoDrop OPTIONS keepalives and retransmissions. Hidden counts are summarized in a `Note over` line.
groupByIpNoCollapse 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.
maxMessagesNoHard cap on rendered arrows. Extra messages produce a truncation note. Hard ceiling is 200.
includeTimingNoAppend `+Nms` (delta from previous arrow) to each arrow label.
groupRetransmitsNoCollapse adjacent identical retransmissions on the same direction into a single arrow + `Note over: xN over Tms`. Independent of `compact` (which drops them entirely).
splitOnNewBranchNoEmit a `--- failover to <ip[:port]> ---` separator before any request sent to a previously-unseen destination. Useful when the trace fails over between gateway IPs.
highlightFailuresNoBold the first non-1xx final response per request leg (CSeq) so the failure jumps out in the ladder.
correlationHeadersNoHeader 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"]`.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true; the description reinforces this with '[cost: free (pure CPU, no network) | read-only]'. Beyond annotations, it discloses rich behavioral details: lane keying by IP (not ip:port), merging ephemeral ports, port suffix notation, alias matching precedence order, fallback to peer address rather than 'unknown:5060', truncation notes, hidden-count summarizing in compact mode, and failover separators. No contradictions with annotations.

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?

The description is long but every sentence serves a purpose: cost/read-only, core function, rendering compatibility, lane keying rules, alias matching, and sibling-tool usage. It is logically structured with clear sections and front-loads the primary action. Despite its length, there is 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?

Given the tool's complexity (11 params, no output schema), the description covers output format ('Mermaid sequenceDiagram block'), input parsing sources, edge-case behaviors (multi-port, aliases, truncation), and when to use related tools. It provides a thorough operational picture without needing an output schema to clarify results.

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%, so baseline is 3. Parameters already have detailed descriptions in the schema (e.g., groupByIp, compact, aliases). The main description adds some high-level context such as the alias matching order and groupByIp rationale, but largely repeats what the schema already captures. It does not significantly elevate parameter understanding beyond the schema.

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 function: 'Parse a raw SIP trace... and emit a Mermaid sequenceDiagram block visualizing the call flow.' It uses a specific verb ('Parse') and resource ('SIP trace' → 'Mermaid ladder'). It distinguishes itself from siblings through the 'Pair with' section naming related tools and their different purposes.

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?

The 'Pair with' paragraph gives explicit guidance on when to use alternative tools: '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.' It also specifies when to change default behavior, e.g., 'Pass groupByIp: false to restore the legacy layout when you specifically need port-level granularity.'

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