How do I use incident-lab?

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., "@incident-lab Investigate inc_job_failed" 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.

incident-lab

by harvestmoonpete

Overview Schema Related Servers Score Discussions

TypeScript

Local

MCP Incident Lab

A standalone TypeScript MCP server for investigating synthetic payment incidents. It does not grant an agent a database, a shell, or an unscoped log dump. It never calls a paid LLM API.

The data is fixture-backed. Nothing here is a live payment system.

Why this exists

Agents are useful during incidents only if their tools are narrower than the blast radius of a mistake. This project makes that boundary testable: the model can list incidents, inspect one payment, read bounded logs, and retry a failed job after an explicit confirmation. It cannot invent SQL, grep the whole disk, or retry a job that is not failed.

flowchart LR
  Agent -->|"MCP tools"| Server
  Server --> Fixtures["Seeded incidents"]
  Server --> Audit["Audit trail"]
  Agent -.->|"cannot"| SQL["Arbitrary SQL"]
  Agent -.->|"cannot"| Shell["Shell / filesystem"]
  Agent -.->|"cannot"| Unscoped["Unscoped log search"]

Related MCP server: stuck-order-mcp

What it demonstrates

Three seeded scenarios: a failed job, a duplicate client request, and an unhealthy dependency.
Read-only tools: list_incidents, get_payment, list_job_attempts, search_logs.
One mutating tool: retry_job, which requires confirm: true, a written reason, and always writes an audit event.
Deterministic tests that diagnose each scenario from tool output alone.

Trust boundary

Allowed	Not allowed
Look up one payment by `pay_…` id	Arbitrary SQL, wildcards, or table scans
List attempts for one job or payment	Shell commands or file reads
Search logs for one incident or payment, optional substring, max 25 lines	Regex, glob, or searching all logs at once
Retry a failed job after confirmation	Retrying succeeded or pending jobs

Read-only is the default. retry_job is the exception, and it is gated.

Likely agent failure modes

This server does not make the agent correct. It only limits the damage.

The agent can still retry the wrong failed job.
The agent can treat a duplicate request as a failed charge unless it reads the logs. The tools will refuse that retry because the job succeeded.
The agent can try to “fix” an unhealthy dependency by retrying. The tools refuse that too: the job is pending, not failed, and Redis is down.

Those refusals are the point. The audit trail records accepted and rejected retries.

Quick start

npm install
npm test
npm run demo

npm run demo walks all three scenarios without an LLM.

To inspect the tools in a UI:

npm run inspector

Connect, then call list_incidents.

Cursor

Add this to MCP settings, with the project path substituted:

{
  "mcpServers": {
    "incident-lab": {
      "command": "npx",
      "args": ["tsx", "src/server.ts"],
      "cwd": "/absolute/path/to/mcp-incident-lab"
    }
  }
}

Log to stderr only. stdout is the MCP protocol.

Seeded scenarios

Failed job (inc_job_failed): payment still pending, three processor timeouts, retries exhausted. retry_job is accepted.
Duplicate request (inc_duplicate): one processed payment, logs show the second request was suppressed. retry_job is rejected.
Unhealthy dependency (inc_unhealthy_dep): Redis connection refused, job still pending with zero attempts. retry_job is rejected.

Failure model and tradeoffs

This is a teaching lab, not an on-call platform. Fixtures are in-memory and reset per process. There is no authentication, no real log store, and no adapter to Payment Reliability Lab in the MVP.

A production incident MCP would still keep the same shape: named lookups, hard caps, an explicit mutate-with-reason path, and an audit log. It would not expose a generic query tool and hope the model is careful.

Development

npm test
npm run build
npm run dev

Available Tools

5 tools

get_paymentA

Fetch one synthetic payment by id (pay_…). Read-only. Does not accept SQL or wildcards.

ParametersJSON Schema

Name	Required	Description	Default
`paymentId`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description carries the behavioral disclosure burden. It explicitly states that the operation is read-only and that SQL/wildcards are not accepted, which is meaningful safety and input-behavior context. It does not describe not-found or error behavior, but for a simple get-by-id tool this is a minor gap.

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?

Two terse sentences with the core action front-loaded. Every clause adds value: fetching by id, read-only safety, and input restrictions. There is no fluff or redundancy.

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?

For a low-complexity tool with one required parameter and no output schema, the description plus the schema pattern are sufficient for an agent to invoke it correctly. The read-only and no-wildcard notes prevent common misuse, and no additional context is necessary.

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?

Schema description coverage is 0%, so the description must compensate. It explains that the paymentId parameter is a pay_… id and clarifies that it is not a SQL expression or wildcard, adding practical meaning beyond the raw regex pattern in 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 verb, resource, and retrieval method: fetch exactly one synthetic payment by its pay_… id. It also differentiates itself from search/list siblings by explicitly noting it does not accept SQL or wildcards.

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 'by id' phrasing and the explicit rejection of SQL/wildcards signal exact-match retrieval rather than search-style querying, which helps distinguish it from search_logs. However, it does not explicitly name alternative tools or provide an exhaustive when-to-use/when-not-to-use breakdown.

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

list_incidentsA

List seeded synthetic payment incidents. Read-only. No filters; the catalog is small on purpose.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of disclosing behavior. It explicitly states 'read-only' and notes the data is synthetic and seeded, which sets expectations about data type and side effects. It does not describe the return shape, but for a simple parameterless list operation this is reasonable disclosure.

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?

Two short sentences with no filler. The main action is front-loaded, and the read-only and no-filter constraints are stated immediately afterward. Every word adds value, and the structure is easy to parse.

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?

For a simple list tool with zero parameters and no output schema, the description is complete enough for an agent to invoke it correctly. It communicates what is listed, the nature of the data, the lack of filters, and the read-only safety profile.

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?

There are zero parameters, so the schema already fully covers parameter semantics. The description reinforces this by explicitly stating 'No filters,' which prevents an agent from assuming hidden query options. This matches the baseline of 4 for a no-parameter tool.

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 uses a specific verb ('List') and clearly identifies the resource as 'seeded synthetic payment incidents.' It also reinforces the scope with 'No filters' and 'catalog is small on purpose,' which distinguishes it from sibling tools like search_logs and retry_job without ambiguity.

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 clearly states the tool is read-only and takes no filters, making it obvious this is for fetching the full small catalog of seeded incidents. It does not explicitly name alternative tools, but the context strongly implies the appropriate usage and signals that filtering is not supported here.

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

list_job_attemptsA

List settlement-job attempts for one jobId or paymentId. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`jobId`	No
`paymentId`	No

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the behavioral burden. It explicitly says 'Read-only,' which is a useful safety signal, but it does not disclose what happens when both parameters are provided, neither is provided, or whether the response is paginated. The read-only claim is meaningful but minimal.

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 focused sentence plus a short read-only qualifier. Every word adds value, and the core behavior is stated up front without filler or redundancy.

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

Completeness3/5

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

For a simple two-parameter list tool the description is mostly adequate, but the missing output schema and sparse annotation coverage leave room for ambiguity about required parameter combinations and return shape. An agent could call it without knowing whether both jobId and paymentId may be supplied.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the schema's lack of parameter documentation. It names both jobId and paymentId and indicates they are alternative filters via 'one ... or,' but it does not clarify whether exactly one is required, what each identifier refers to beyond its pattern, or how the two interact.

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 uses a specific verb and resource: 'List settlement-job attempts' and scopes it to 'one jobId or paymentId'. This clearly distinguishes it from siblings like retry_job or get_payment by focusing on a read-only list of attempts rather than a mutation or a single payment lookup.

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 states when to use the tool: when you have a jobId or paymentId and need to see settlement-job attempts. It does not explicitly name excluded alternatives or conditions for choosing siblings, but the context is clear enough for straightforward routing.

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

retry_jobA

The only mutating tool. Re-enqueues a failed job. Requires confirm=true and a written reason. Writes an audit event even when rejected.

ParametersJSON Schema

Name	Required	Description	Default
`jobId`	Yes
`reason`	Yes
`confirm`	Yes

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries full responsibility, and it does well: it discloses mutation, the confirm/audit behavior, and that an audit event is written even on rejection. It does not mention permissions, idempotency, or success/failure return behavior, leaving some side-effect transparency gaps.

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 extremely tight: three or four short clauses, each adding a distinct fact, and the most important differentiator ('only mutating tool') is front-loaded. There is no filler or repetition of schema constraints.

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

Completeness3/5

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

It covers purpose, the required confirmation/reason workflow, and the audit side effect, which is solid for a small tool. Yet with no output schema and no annotation coverage, it omits return value/error behavior and does not clarify how jobId identifies a failed job, so an agent still has unresolved operational questions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but it only paraphrases confirm=true and 'written reason' from the schema. It never explains what jobId refers to or clarifies the meaning/format of reason beyond the schema's minLength/maxLength constraints, providing little added value for parameter understanding.

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 states the exact action ('Re-enqueues a failed job') with a specific resource, and the opening 'only mutating tool' distinguishes it from the read-style sibling tools (list_incidents, get_payment, etc.). No ambiguity remains about what this tool does.

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?

It clearly signals that this is the mutating option among read-only siblings, which points an agent to use it when a retry action is needed rather than a query. However, it does not explicitly name alternatives or describe when-not-to-use conditions (e.g., after investigating with list_job_attempts), so it stops short of full routing guidance.

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

search_logsA

Search log lines for one incidentId or paymentId. Optional substring query (max 80 chars). Max 25 lines. No regex, glob, or unscoped search.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	No
`paymentId`	No
`incidentId`	No

TDQS

A3.6/5.0

Behavior4/5

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

With no annotations, the description carries the burden of behavioral disclosure. It meaningfully adds constraints beyond the schema: searching must be scoped by an ID, substring queries are optional, results are capped at 25 lines, and regex/glob/unscoped searches are unsupported. It does not describe output shape or error behavior, but what it shares is substantive.

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 very compact and front-loaded with the core purpose. Every sentence adds relevant information and there is no filler or repetition of schema details.

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

Completeness3/5

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

The definition covers scope and operational constraints well, but some context is missing: no guidance on sibling tool selection, no output/return semantics, and no explicit statement that at least one ID is required despite the schema listing no required fields. The phrase 'one incidentId or paymentId' partially covers this, but ambiguity remains for an agent.

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?

Schema description coverage is 0%, so the description must compensate. It effectively explains the semantic role of all four parameters: incidentId/paymentId are the required scoping IDs, query is the optional substring, and limit corresponds to the 25-line cap. It does not explicitly map 'limit' by name, but the meaning is clear enough.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Search') and resource ('log lines'), and clearly scopes the tool to one incidentId or paymentId. It is easy to distinguish from sibling tools like list_incidents or get_payment by resource type, even though no sibling is named explicitly.

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?

There is no guidance on when to prefer this tool over list_incidents, get_payment, list_job_attempts, or retry_job. The description provides constraints (no regex, no glob, no unscoped search) but no alternatives, exclusions, or selection criteria.

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

Install Server

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

TDQS

A4.2/5.0

Disambiguation5/5

Each tool targets a distinct resource and action: incidents, payments, job attempts, logs, and retries. No two tools appear to do the same thing, and their scopes are clearly separated by entity and read-only vs. mutating behavior.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: list_incidents, get_payment, list_job_attempts, search_logs, retry_job. The verbs are predictable and match the tool's behavior, so an agent can infer the purpose from the name alone.

Tool Count5/5

Five tools is well-scoped for an incident-lab server focused on investigating synthetic payment incidents and retrying failed jobs. Each tool earns its place, and the count is not bloated or too thin for the stated purpose.

Completeness4/5

The tool set covers the likely investigation workflow: list incidents, inspect payment details, examine job attempts, search logs, and retry a failed job. A dedicated get_incident tool is absent, but list_incidents explicitly says the catalog is small, so this is a minor gap rather than a blocking one.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

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

Agent Rescue Desk Production Triage A
app.netlify.agent-rescue-desk
Read-only triage for n8n, MCP, webhook, and AI agent workflow production failures.
Monitoring Observability
32
a2areplayreceipt-mcp
com.clauxel.a2areplayreceipt
Remote MCP for A2A failure replay MCP, structured receipts, audit logs, and reviewer-ready evidence.
Observability Monitoring Testing & QA Tools
2
Second Eyes Agent Workflow Services C
io.github.This-Is-Hellgate
Workflow diagnostics, capability routing, and x402 settlement for MCP-compatible agents.
Security Version Control Payments & Billing
112
KrystalView Analytics A
io.github.KrystalView
Read-only MCP access to sessions, funnels, campaigns, errors, live visitors, and anomalies.
Monitoring Observability
132

Related MCP Servers

Claude Ops Investigator
Monitoring Observability
Randhir123
F
license
Not graded
quality
B
maintenance
Enables read-only Kubernetes incident investigation through MCP tools for listing pods, describing resources, fetching logs, and searching runbooks.
Updated 2 months ago (2026-07-16 13:28 UTC)
1
stuck-order-mcp
Finance Payments & Billing
SafalBhandari12
F
license
Not graded
quality
B
maintenance
MCP server for investigating payment/webhook drift, classifying order status mismatches, detecting duplicate charges, and escalating findings for human review. It is read-only for payment state and does not automatically retry or correct transactions.
Updated a month ago (2026-08-07 15:44 UTC)
Payment Reconciliation Copilot
Finance Customer Support
shivanshshekhar11
F
license
Not graded
quality
B
maintenance
Enables read-only investigation of payment transactions by building normalized timelines, detecting anomalies like duplicate charges and stuck refunds, and creating diagnostic escalations for human review. Never executes or modifies payment actions.
Updated a month ago (2026-08-04 07:19 UTC)
Nibble
Monitoring Observability
Talia04
F
license
Not graded
quality
C
maintenance
Enables AI agents to investigate production incidents by exposing service health, logs, and deployment data through MCP tools.
Updated 25 days ago (2026-08-10 07:50 UTC)
10

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/harvestmoonpete/mcp-incident-lab'

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