How do I use sipp-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@sipp-mcp-server Run a SIPp UAC scenario to sip:test@example.com" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

sipp-mcp-server

by randybritsch

Overview Schema Related Servers Score Discussions

JavaScript

Local

SIPp MCP Server

License: MIT Node.js Version MCP

A Model Context Protocol (MCP) server for interacting with SIPp, the SIP protocol testing tool.

Use SIPp testing capabilities directly from Claude Desktop, VS Code, or any MCP-compatible client!

Quick Start

Install from npm

npm install -g sipp-mcp-server

Or install from source

# Clone the repository
git clone https://github.com/randybritsch/sipp-mcp-server.git
cd sipp-mcp-server

# Install dependencies
npm install

# Build the project
npm run build

# Test with MCP Inspector
npx @modelcontextprotocol/inspector node build/index.js

Then configure in Claude Desktop or VS Code.

Related MCP server: dSIPRouter MCP Server

Features

This MCP server provides tools to:

Run SIPp Scenarios: Execute SIPp tests in UAC (client) or UAS (server) mode
Create Custom Scenarios: Generate custom XML scenario files for testing
Get Statistics: Parse and display SIPp test statistics
Check Version: Verify SIPp installation and version

Prerequisites

Node.js 16 or higher
SIPp installed and available in your PATH
- Download from: https://github.com/SIPp/sipp
- Or install via package manager:
  - Ubuntu/Debian: sudo apt-get install sipp
  - macOS: brew install sipp
  - Windows: Download binary from releases

Installation

If installed globally via npm, the server is automatically available as sipp-mcp-server.

If installed from source, use npm link to make it globally available, or reference the full path to build/index.js in your configuration.

Setup Instructions

Setup with Claude Desktop

Follow these steps to integrate the SIPp MCP server with Claude Desktop:

Step 1: Locate the Claude Desktop Configuration File

Open your Claude Desktop configuration file:

Windows:

# Open in notepad
notepad %APPDATA%\Claude\claude_desktop_config.json

# Or open in VS Code
code %APPDATA%\Claude\claude_desktop_config.json

macOS:

# Open in default editor
open ~/Library/Application\ Support/Claude/claude_desktop_config.json

# Or open in VS Code
code ~/Library/Application\ Support/Claude/claude_desktop_config.json

Step 2: Add the SIPp MCP Server Configuration

Add the following configuration to your claude_desktop_config.json file:

Using global npm installation (recommended):

{
  "mcpServers": {
    "sipp": {
      "command": "sipp-mcp-server"
    }
  }
}

Or using local installation:

Windows:

{
  "mcpServers": {
    "sipp": {
      "command": "node",
      "args": ["C:\\Users\\YOUR_USERNAME\\sipp-mcp-server\\build\\index.js"]
    }
  }
}

macOS/Linux:

{
  "mcpServers": {
    "sipp": {
      "command": "node",
      "args": ["/absolute/path/to/sipp-mcp-server/build/index.js"]
    }
  }
}

Important:

If using local installation, replace YOUR_USERNAME or the path with your actual absolute path
On Windows, use double backslashes (\\) in the JSON file
If you have other MCP servers, add the sipp entry to the existing mcpServers object

Step 3: Restart Claude Desktop

Completely quit Claude Desktop (not just close the window)
Relaunch Claude Desktop
The SIPp MCP server will start automatically

Step 4: Verify the Connection

Look for the MCP icon (🔌) in the bottom-right corner of the Claude chat input
Click the icon to see available tools
You should see the SIPp tools: run_sipp_scenario, create_sipp_scenario, get_sipp_statistics, and check_sipp_version

Step 5: Test the Server

Try asking Claude:

Check if SIPp is installed on my system

Claude should use the check_sipp_version tool to verify your SIPp installation.

Troubleshooting Claude Desktop

Server not appearing:

Check that Node.js is installed: node --version
Verify the path in your config file is correct and absolute
Check Claude Desktop logs:
- Windows: %APPDATA%\Claude\logs
- macOS: ~/Library/Logs/Claude

Permission errors:

Ensure the build/index.js file exists
Run npm run build again if needed

Setup with VS Code

The SIPp MCP server can be used with VS Code through GitHub Copilot's agent mode.

Step 1: Ensure Prerequisites

Install the GitHub Copilot extension
Ensure you have Copilot access with agent mode enabled
Make sure the project is built: npm run build

Step 2: Configure MCP in VS Code

Using global npm installation (recommended):

Create .vscode/mcp.json in your workspace:

{
  "mcpServers": {
    "sipp": {
      "command": "sipp-mcp-server"
    }
  }
}

Or using local installation:

The MCP configuration file is already created at .vscode/mcp.json:

{
  "mcpServers": {
    "sipp": {
      "command": "node",
      "args": ["c:\\Users\\randy.britsch\\sipp-mcp-server\\build\\index.js"]
    }
  }
}

Update the path if your project is in a different location:

Open .vscode/mcp.json
Update the path in the args array to match your project location
Use double backslashes on Windows: c:\\Users\\...

Step 3: Alternative - User or Workspace Settings

You can also configure MCP servers in VS Code settings:

Option A: Workspace Settings (recommended for project-specific servers)

Open VS Code Command Palette (Ctrl+Shift+P or Cmd+Shift+P)
Type "Preferences: Open Workspace Settings (JSON)"
Add the MCP configuration:

{
  "mcp.servers": {
    "sipp": {
      "command": "node",
      "args": ["${workspaceFolder}/build/index.js"]
    }
  }
}

Option B: User Settings (for global access)

Open VS Code Command Palette (Ctrl+Shift+P or Cmd+Shift+P)
Type "Preferences: Open User Settings (JSON)"
Add the MCP configuration with absolute paths

Step 4: Enable and Use MCP Tools in Copilot

Open GitHub Copilot Chat panel (Ctrl+Alt+I or Cmd+Alt+I)
Start agent mode by typing @workspace or using the agent selector
The SIPp MCP tools will be available to the agent

Step 5: Test the Integration

In the Copilot Chat panel, try:

Use the SIPp tools to check if SIPp is installed

Or:

Create a basic SIPp scenario file named test.xml

Step 6: Using MCP Tools in Copilot Sessions

You can reference MCP tools in your conversations:

Check SIPp version: "Check if SIPp is installed"
Create scenarios: "Create a register scenario for testing SIP registration"
Run tests: "Run a SIPp UAC test with 10 calls to 192.168.1.100"
Get statistics: "Show me the statistics from sipp_output.csv"

Troubleshooting VS Code

MCP tools not appearing:

Verify the .vscode/mcp.json path is correct
Reload VS Code window (Ctrl+Shift+P → "Developer: Reload Window")
Check the Output panel (View → Output) and select "MCP" from the dropdown

Build issues:

# Rebuild the project
npm run build

# Verify the output file exists
ls build/index.js  # macOS/Linux
dir build\index.js  # Windows

Node.js not found:

Ensure Node.js is in your PATH
Restart VS Code after installing Node.js
Use absolute path to node: "command": "C:\\Program Files\\nodejs\\node.exe"

Testing with MCP Inspector

For development and debugging, use the MCP Inspector:

npx @modelcontextprotocol/inspector node build/index.js

This opens a web interface where you can:

View all available tools
Test tool inputs and outputs
See real-time request/response logs
Debug tool behavior

Available Tools

1. run_sipp_scenario

Execute a SIPp scenario for SIP protocol testing.

Parameters:

mode: "uac" (client) or "uas" (server)
remoteHost: Remote host IP (required for UAC mode)
remotePort: Remote port (default: 5060)
localPort: Local port to bind to
scenarioFile: Path to custom XML scenario file
callCount: Number of calls to make
callRate: Call rate in calls per second
duration: Maximum test duration in seconds
transport: "udp", "tcp", or "tls"
timeout: Global timeout in seconds

Example:

Run a UAC scenario with 10 calls to 192.168.1.100:5060

2. create_sipp_scenario

Create a custom SIPp XML scenario file.

Parameters:

filename: Name of the scenario file
scenarioType: "basic_call", "register", or "custom"
customXml: Custom XML content (for custom type)

Example:

Create a basic call scenario named test.xml

3. get_sipp_statistics

Parse and display statistics from SIPp CSV output files.

Parameters:

csvFile: Path to the SIPp statistics CSV file

4. check_sipp_version

Check if SIPp is installed and display version information.

Development

# Install dependencies
npm install

# Build the project
npm run build

# Watch mode for development
npm run dev

# Test with MCP Inspector
npx @modelcontextprotocol/inspector node build/index.js

Project Structure

sipp-mcp-server/
├── src/
│   └── index.ts          # Main server implementation
├── build/                # Compiled JavaScript output
├── package.json
├── tsconfig.json
└── README.md

Example Usage

Example 1: Check SIPp Installation

Ask Claude or Copilot:

Check if SIPp is installed and show me the version

Expected behavior:

The check_sipp_version tool will be invoked
You'll see SIPp version information or an error if not installed

Example 2: Create a Basic Call Scenario

Ask Claude or Copilot:

Create a basic SIPp call scenario file named my_test.xml

Expected behavior:

The create_sipp_scenario tool will be invoked
A file named my_test.xml will be created with a basic UAC call flow
The file contents will be displayed

Example 3: Run a Simple UAC Test

Ask Claude or Copilot:

Run a SIPp UAC test with 5 calls to 192.168.1.100 at a rate of 1 call per second

Expected behavior:

The run_sipp_scenario tool will be invoked with:
- mode: "uac"
- remoteHost: "192.168.1.100"
- callCount: 5
- callRate: 1
SIPp will execute the test
Results and statistics will be shown

Example 4: Run a UAS (Server) Test

Ask Claude or Copilot:

Start SIPp in server mode on port 5060

Expected behavior:

The run_sipp_scenario tool will be invoked with:
- mode: "uas"
- localPort: 5060
SIPp will listen for incoming SIP calls

Example 5: Create and Use a REGISTER Scenario

Ask Claude or Copilot:

Create a REGISTER scenario file named register_test.xml, then run it against 192.168.1.100 with 10 registrations

Expected behavior:

First, create_sipp_scenario creates the file
Then, run_sipp_scenario executes it
You'll see the registration test results

Example 6: Advanced Test with Custom Parameters

Ask Claude or Copilot:

Run a SIPp test against 10.0.0.50:5080 using TCP transport, with 100 calls at 10 calls per second, maximum duration of 60 seconds

Expected behavior:

The run_sipp_scenario tool will be invoked with:
- mode: "uac"
- remoteHost: "10.0.0.50"
- remotePort: 5080
- transport: "tcp"
- callCount: 100
- callRate: 10
- duration: 60

Example 7: Analyze Test Results

Ask Claude or Copilot:

Show me the statistics from the last SIPp test in sipp_output.csv

Expected behavior:

The get_sipp_statistics tool will be invoked
CSV contents will be parsed and displayed
You can ask follow-up questions about the results

Troubleshooting

SIPp not found

Make sure SIPp is installed and in your PATH:

sipp -v

If not installed, follow the installation instructions for your platform.

Permission Issues

On Linux/macOS, you may need to run SIPp with appropriate permissions for binding to ports below 1024.

Connection Issues

Verify the remote host is reachable
Check firewall settings
Ensure the SIP port (default 5060) is not blocked
Try using different transport protocols (UDP, TCP, TLS)

Resources

Contributing

Contributions are welcome! Here's how you can help:

Reporting Issues

Use the GitHub issue tracker
Check existing issues before creating a new one
Include SIPp version, Node.js version, and OS details
Provide clear steps to reproduce any bugs

Submitting Pull Requests

Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Make your changes
Run tests and build: npm run build
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request

Development Guidelines

Follow existing code style and TypeScript conventions
Add appropriate error handling
Update README.md if adding new features
Test with MCP Inspector before submitting

Community

Questions? Open a GitHub Discussion
Bug Reports: Use GitHub Issues
MCP Community: Join the MCP Discord

Roadmap

Add support for more SIPp scenario templates
Implement real-time statistics monitoring
Add SIPp pcap file analysis tools
Support for distributed SIPp testing
Web-based scenario editor

License

This project is licensed under the MIT License - see the LICENSE file for details.

Acknowledgments

SIPp Project - The excellent SIP testing tool
Model Context Protocol - The protocol specification
Anthropic - For Claude and MCP support

Made with ❤️ for the SIP testing community

Available Tools

4 tools

check_sipp_versionA

Check if SIPp is installed and display version information

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided. Description only states the action without disclosing behavioral traits like side effects (none expected), error behavior if SIPp missing, or output format. With no annotations, description carries full burden and falls short.

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?

Single sentence, front-loaded with verb and resource, no unnecessary words. Earns its place with zero waste.

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 zero parameters and no output schema, description is mostly complete for a simple check tool. Could mention error behavior or that version is returned, but overall sufficient.

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?

No parameters, so baseline 4 applies. The schema has 100% coverage with 0 parameters, and description adds no parameter info (none needed).

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?

Description uses a specific verb ('check') and resource ('SIPp installed and version'), clearly distinguishing it from siblings like create_sipp_scenario or run_sipp_scenario.

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?

No explicit when-to-use or when-not-to-use guidance. Usage is implied by sibling tool names, but the description does not state that this should be used before other SIPp operations or what to do if not installed.

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

create_sipp_scenarioB

Create a custom SIPp XML scenario file for testing

ParametersJSON Schema

Name	Required	Description
`filename`	Yes	Name of the scenario file (e.g., 'my_scenario.xml')
`scenarioType`	Yes	Type of scenario template
`customXml`	No	Custom XML content (required if scenarioType is 'custom')

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It only says 'Create' but does not disclose whether it overwrites existing files, validates XML, what happens on error, or if it is idempotent. This leaves significant behavioral ambiguity.

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 a single, efficient sentence capturing the core function. It could benefit from a second sentence clarifying behavior or return value, but it is appropriately brief given the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description should explain what the tool returns or the side effect. It does not mention results, file location, or confirmation. For a creation tool with three parameters, the description is incomplete.

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 each parameter documented. The description adds no extra meaning beyond what the schema already provides. A baseline score of 3 is appropriate since the description does not compensate further.

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 action ('Create') and the resource ('custom SIPp XML scenario file') with context ('for testing'). It distinguishes from sibling tools which check version, get statistics, and run scenarios, making it obvious this tool is for creation.

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?

No guidance is provided on when to use this tool versus alternatives like editing an existing scenario or using other tools. There is no mention of prerequisites, when to choose custom vs. basic_call, or any exclusions.

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

get_sipp_statisticsB

Parse and display statistics from SIPp CSV output files

ParametersJSON Schema

Name	Required	Description	Default
`csvFile`	Yes	Path to the SIPp statistics CSV file

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only states 'Parse and display statistics,' which is minimal and does not disclose error handling, output format, or potential side effects.

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 a single, well-structured sentence with no unnecessary words, effectively conveying the tool's function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description lacks details about return values, prerequisites (e.g., SIPp installed), or behavior when the CSV file is missing or malformed, making it incomplete.

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% with one parameter already described as 'Path to the SIPp statistics CSV file.' The tool description adds no additional meaning beyond what the schema provides, meeting the baseline for high 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 verb 'Parse and display' and the resource 'statistics from SIPp CSV output files', distinguishing it from sibling tools like check_sipp_version and run_sipp_scenario.

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 description implies usage when handling SIPp CSV files, but does not explicitly state when to use or not use this tool versus alternatives, leaving it to the agent to infer.

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

run_sipp_scenarioA

Execute a SIPp scenario for SIP protocol testing. Can run as UAC (client) or UAS (server) with custom scenarios.

ParametersJSON Schema

Name	Required	Description
`mode`	Yes	Mode: 'uac' for client, 'uas' for server
`remoteHost`	No	Remote host IP address (required for UAC mode)
`remotePort`	No	Remote port (default: 5060)
`localPort`	No	Local port to bind to (default: 5060)
`scenarioFile`	No	Path to custom XML scenario file
`callCount`	No	Number of calls to make (default: 1)
`callRate`	No	Call rate in calls per second
`duration`	No	Maximum test duration in seconds
`transport`	No	Transport protocol (default: udp)
`timeout`	No	Global timeout in seconds

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only mentions 'execute' without disclosing behavioral traits like blocking/asynchronous behavior, resource usage, side effects on system, or failure modes. This is insufficient.

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 concise (two sentences) and front-loaded with the purpose. However, it lacks structure (e.g., bullet points) and is missing a title. It is appropriately sized but could be slightly more organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 10 parameters and no output schema, the description should cover return values or outcomes of execution. It does not mention what the tool returns (e.g., success/failure, statistics). It is incomplete for a complex tool.

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. The description adds some context by mentioning UAC/UAS (corresponding to 'mode'), but does not elaborate on other parameters beyond schema. It adds marginal value.

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 executes a SIPp scenario for SIP testing, specifies roles (UAC/UAS), and mentions custom scenarios. It distinguishes well from siblings: check_sipp_version, create_sipp_scenario, get_sipp_statistics.

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?

The description gives clear context for usage (UAC/UAS, custom scenarios), but does not explicitly state when to avoid this tool or provide alternative guidance. However, the sibling tool names make the distinctions evident.

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. Dates show when Glama detected each change.

4 tool updatesv1.0.0Jun 15, 2026
- First observedcheck_sipp_version
- First observedcreate_sipp_scenario
- First observedget_sipp_statistics
- First observedrun_sipp_scenario

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct aspect of SIPp testing: version check, scenario creation, execution, and statistics parsing. No overlap in purpose.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern: check_sipp_version, create_sipp_scenario, get_sipp_statistics, run_sipp_scenario.

Tool Count5/5

4 tools is well-scoped for a SIPp testing server, covering the core workflow without unnecessary bloat.

Completeness4/5

Covers the main operations: check, create, run, and analyze. Minor gaps like scenario deletion or listing, but the core testing loop is complete.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

ToughTongue AIOAuth
com.toughtongueai
Create voice-agent scenarios, pull session analytics, place SIP calls, schedule meeting bots.
Speech Processing Communication Agent Orchestration
27
octoperfOAuthDeprecated
io.github.OctoPerf
Drive OctoPerf load testing from any AI agent: import, edit, validate, run scenarios, read metrics.
Testing & QA Tools Monitoring
2
Speko AIOAuth
ai.speko
Manage Speko voice-AI agents, sessions, calls, phone numbers, knowledge bases, evals, and docs.
Speech Processing Text-to-Speech AI & Machine Learning
2
FlowstepOAuth
ai.flowstep
Generate, inspect, and manage Flowstep UI designs directly from your AI assistant.
Design Tools Developer Tools
2

Related MCP Servers

OpenSIPS MCP Serverofficial
Command Line Monitoring Networking & Infrastructure
OpenSIPS
A
license
B
quality
D
maintenance
AI-powered control plane for OpenSIPS SIP servers, enabling natural-language operations and CLI-based management for configuration, migration, monitoring, and diagnostics.
Updated 4 months ago (2026-04-28 12:01 UTC)
100
10
Apache 2.0
dSIPRouter MCP Serverofficial
Networking & Infrastructure Monitoring
dOpensource
A
license
Not graded
quality
C
maintenance
Enables AI assistants to manage dSIPRouter operations such as endpoint groups, carrier groups, inbound mappings, and call data retrieval through natural language.
Updated 4 months ago (2026-05-08 07:54 UTC)
Apache 2.0
Wireshark MCP
Networking & Infrastructure Monitoring
andsopwn
F
license
C
quality
C
maintenance
Enables LLMs to capture, analyze, and summarize network traffic using Wireshark CLI tools, supporting live capture, pcap analysis, and LLM-oriented summaries.
Updated 3 months ago (2026-06-13 15:52 UTC)
76
-
PJSUA MCP Server
Communication Testing & QA Tools
Yevhenii-Yatchenko
F
license
Not graded
quality
D
maintenance
Manages multiple SIP user agents (phones) with full control over calls, registration, and media, plus a scenario engine for multi-step SIP flows.
Updated 4 months ago (2026-04-29 23:26 UTC)
1
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/randybritsch/sipp-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

SIPp MCP Server

Quick Start

Install from npm

Or install from source

Features

Prerequisites

Installation

Setup Instructions

Setup with Claude Desktop

Step 1: Locate the Claude Desktop Configuration File

Step 2: Add the SIPp MCP Server Configuration

Step 3: Restart Claude Desktop

Step 4: Verify the Connection

Step 5: Test the Server

Troubleshooting Claude Desktop

Setup with VS Code

Step 1: Ensure Prerequisites

Step 2: Configure MCP in VS Code

Step 3: Alternative - User or Workspace Settings

Step 4: Enable and Use MCP Tools in Copilot

Step 5: Test the Integration

Step 6: Using MCP Tools in Copilot Sessions

Troubleshooting VS Code

Testing with MCP Inspector

Available Tools

1. run_sipp_scenario

2. create_sipp_scenario

3. get_sipp_statistics

4. check_sipp_version

Development

Project Structure

Example Usage

Example 1: Check SIPp Installation

Example 2: Create a Basic Call Scenario

Example 3: Run a Simple UAC Test

Example 4: Run a UAS (Server) Test

Example 5: Create and Use a REGISTER Scenario

Example 6: Advanced Test with Custom Parameters

Example 7: Analyze Test Results

Troubleshooting

SIPp not found

Permission Issues

Connection Issues

Resources

Contributing

Reporting Issues

Submitting Pull Requests

Development Guidelines

Community

Roadmap

License

Acknowledgments

Available Tools

TDQS

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

OpenSIPS MCP Serverofficial

dSIPRouter MCP Serverofficial

Wireshark MCP

PJSUA MCP Server

Latest Blog Posts

MCP directory API