A Model Context Protocol (MCP) server for interacting with Gremlin's reliability management APIs.
This MCP server provides access to Gremlin's reliability testing and management capabilities, including:
- Service reliability management and monitoring
- Service dependency tracking
- Reliability experiments and testing
- Reliability reporting
- Usage and pricing reports
- Client (agent) and attack summaries
- Node.js 18 or higher
- A valid Gremlin API key
Go to Claude Settings > Developer and add the following to your claude_desktop_config.json:
{
"mcpServers": {
"gremlin": {
"command": "npx",
"args": ["-y", "@gremlin/mcp-server"],
"env": {
"GREMLIN_API_KEY": "your_gremlin_api_key_here"
}
}
}
}Add the following to your MCP settings:
{
"servers": {
"gremlin": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@gremlin/mcp-server"],
"env": {
"GREMLIN_API_KEY": "${input:gremlin-api-key}"
}
}
},
"inputs": [
{
"type": "promptString",
"id": "gremlin-api-key",
"description": "Gremlin API Key",
"password": true
}
]
}Lists all available reliability management (RM) services with their descriptions, scores, and targeting information.
Retrieves dependencies for a specific service.
- Parameters:
teamId(required),serviceId(required)
Gets status checks configured for a service.
- Parameters:
teamId(required),serviceId(required)
Lists identified risks associated with a service.
- Parameters:
teamId(required),serviceId(required)
Generates a reliability report for a service on a specific date.
- Parameters:
teamId(required),serviceId(required),date(optional, defaults to today, format: YYYY-MM-DD)
Retrieves recent reliability experiments for a service.
- Parameters:
teamId(required),serviceId(required),dependencyId(optional),testId(optional),limit(optional, default: 100)
Fetches the pricing usage report for the company over a specified date range. Returns usage broken down by tracking period including active agents, targetable applications, and unique targets by type.
- Parameters:
startDate(required, yyyy-mm-dd),endDate(required, yyyy-mm-dd),trackingPeriod(optional:Daily,Weekly, orMonthly, defaults to the company's configured period)
Loads the client (agent) summary for a team over a specified time period. Shows agent activity and status.
- Parameters:
teamId(required),start(required, yyyy-mm-dd),end(required, yyyy-mm-dd),period(required:MONTHS,WEEKS, orDAYS)
Loads the attack summary for a team over a specified time period. Shows attack activity and results.
- Parameters:
teamId(required),start(required, yyyy-mm-dd),end(required, yyyy-mm-dd),period(required:MONTHS,WEEKS, orDAYS)
Gets recent reliability tests for a team.
- Parameters:
teamId(required),pageSize(optional, default: 5),pageToken(optional)
Retrieves the current test suite for a team or all teams.
- Parameters:
teamId(optional)
- All date parameters should use YYYY-MM-DD format
- Team and service IDs are required for most service-specific operations
- Optional parameters have sensible defaults where applicable
- List all services:
"What reliability management services are available?"
- Identify Critical Dependency for Coverage:
"I'm trying to find which are my most critical dependencies. Can you pull all my RM services, identify shared dependencies, ignoring ignored dependencies, create a list of them and then use the policy reports to understand what my coverage currently is for these dependencies. Finally; I want you to create a quick page with some graphics to help me understand the state of the world"
- Identify gaps in Scheduling:
"I think my schedule for tests is misconfigured for my RM services. I think this because I'm seeing a lot of expired policy evaluations in my RM Reports. It takes about 6 weeks to expire a policy evaluation and I should be testing every week. Now given my scheduling window it's possible that I'm not running every test every week, but across 6 weeks it seems less likely. Now, it's expected that for policy evaluations on a dependency which is marked as a SPOF it's expected for the policy evaluation to get to EXPIRED state. So can you go check all my RM services and figure out how many policy evaluations (excluding those on ignored or SPOF dependencies) are expired as a percentage of total? I'd like to see that on a per service basis"
Ensure your GREMLIN_API_KEY is valid and has the necessary permissions. The server will exit immediately with an error message if the key is missing.
Check your MCP client's logs for error output from the server process. For Claude Desktop:
less ~/Library/Logs/Claude/mcp-server-gremlin.log
If you have multiple Node.js versions on your PATH, you may need to specify it explicitly:
{
"mcpServers": {
"gremlin": {
"command": "npx",
"args": ["-y", "@gremlin/mcp-server"],
"env": {
"GREMLIN_API_KEY": "your_gremlin_api_key_here",
"PATH": "/path/to/node/bin:/usr/local/bin:/usr/bin:/bin"
}
}
}
}git clone git@github.com:gremlin/mcp.git gremlin-mcp
cd gremlin-mcp
makeTests run against the live Gremlin API. Create a .env file with your key:
GREMLIN_API_KEY=your_gremlin_api_key_here
Then run:
env $(cat .env | xargs) make testNote: Running tests requires Node.js 20.19+ or 22.12+ (vitest 4.x dependency).
make inspectormake publishFor issues or questions, please create a support ticket or contact support.