[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 p...
Risk signalsAccepts URL/endpoint input (url) · Admin/system-level operation
Part of the Sipflow server.
Free to start. No card required.
AI agents call fetch_sipflow_share to retrieve information from Sipflow without modifying any data. This is common in research, monitoring, and reporting workflows where the agent needs context before taking action. Because read operations don't change state, they are generally safe to allow without restrictions -- but you may still want rate limits to control API costs.
Even though fetch_sipflow_share only reads data, uncontrolled read access can leak sensitive information or rack up API costs. An agent caught in a retry loop could make thousands of calls per minute. A rate limit gives you a safety net without blocking legitimate use.
Read-only tools are safe to allow by default. No rate limit needed unless you want to control costs.
{
"version": "1",
"default": "deny",
"tools": {
"fetch_sipflow_share": {}
}
}See the full Sipflow policy for all 22 tools.
These attack patterns abuse exactly the kind of access fetch_sipflow_share gives an agent. Each links to the full case and the policy that stops it:
Other read tools across the catalogue. The same approach applies to each: allow, with a rate cap to control cost.
[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.. It is categorised as a Read tool in the Sipflow MCP Server, which means it retrieves data without modifying state.
Register the Sipflow MCP server in PolicyLayer and add a rule for fetch_sipflow_share: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Sipflow. Nothing to install.
fetch_sipflow_share is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the fetch_sipflow_share rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for fetch_sipflow_share. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
fetch_sipflow_share is provided by the Sipflow MCP server (https://mcp.sipflow.dev/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Deterministic rules across all 22 Sipflow tools. Per-identity grants. Full audit log. Live in minutes. Nothing to install.
Free to start. No card required.
4,600+ MCP servers and 31,000+ tools scanned and risk-classified.