How do I use SelfHeal MCP?

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., "@SelfHeal MCP wrap_call GET https://api.github.com/repos/user/repo with target github" 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.

SelfHeal MCP

by carsonroell-debug

Overview Schema Related Servers Score Discussions

TypeScript

Remote

SelfHeal MCP

npm License: MIT MCPize

Self-healing proxy for MCP servers. Wraps any MCP tool call with automatic retry, circuit breaker protection, and call observability.

Your AI agents stop breaking on flaky APIs.

One-click install: Install on MCPize | npx selfheal-mcp

Features

Retry with backoff — Exponential backoff + jitter on transient failures (5xx, timeouts, rate limits)
Circuit breaker — Per-target circuit breaker stops hammering dead services
Call metrics — Success rates, latency, error frequency, broken down by tool and target
Proxy mode — Wrap any existing MCP server transparently
Zero config — Works standalone out of the box, config file for proxy mode

Related MCP server: mcp-bastion

Quick Start

Standalone Mode

Add to your Claude Desktop / Claude Code config:

{
  "mcpServers": {
    "selfheal": {
      "command": "npx",
      "args": ["-y", "selfheal-mcp"]
    }
  }
}

Then use wrap_call to make any HTTP request with self-healing:

Use the wrap_call tool to GET https://api.example.com/data with target "example-api"

Proxy Mode

Create selfheal.config.json:

{
  "mode": "proxy",
  "targets": [
    {
      "name": "my-server",
      "transport": "streamable-http",
      "url": "https://my-mcp-server.com/mcp"
    }
  ]
}

{
  "mcpServers": {
    "selfheal": {
      "command": "npx",
      "args": ["-y", "selfheal-mcp"],
      "env": {
        "SELFHEAL_CONFIG": "/path/to/selfheal.config.json"
      }
    }
  }
}

All tools from my-server are re-exposed with self-healing built in.

Tools

Tool	Description
`wrap_call`	Execute HTTP call with retry + circuit breaker
`circuit_status`	Check health of any target
`circuit_reset`	Reset circuit breaker after fixing issues
`metrics`	Success rates, latency, top errors
`recent_errors`	Recent failures with full details

Proxy Mode Adds

Tool	Description
`selfheal_metrics`	Metrics for all proxied calls
`selfheal_circuits`	Circuit status for all targets
`selfheal_recent_errors`	Recent errors across all targets

Configuration

Environment Variables

Variable	Default	Description
`SELFHEAL_CONFIG`	`./selfheal.config.json`	Config file path
`SELFHEAL_MAX_RETRIES`	`3`	Max retry attempts
`SELFHEAL_BASE_DELAY_MS`	`1000`	Base delay for backoff
`SELFHEAL_MAX_DELAY_MS`	`30000`	Max delay cap
`SELFHEAL_CIRCUIT_THRESHOLD`	`5`	Failures before circuit opens
`SELFHEAL_CIRCUIT_COOLDOWN_MS`	`120000`	Cooldown before half-open test

How It Works

Agent → SelfHeal MCP → [Retry + Circuit Breaker] → Target API/MCP Server
                ↓
          Metrics Collector

Request arrives — Agent calls a tool
Circuit check — If target has failed too many times, reject immediately
Execute with retry — Try the call, retry on transient errors with exponential backoff
Record metrics — Log success/failure, duration, attempts
Update circuit — Track consecutive failures per target

Install

MCPize (Recommended)

One-click install with managed hosting: Install on MCPize

npm

npx selfheal-mcp

PyPI

Not applicable — this is a TypeScript server. For Python alternatives, see LeadEnrich MCP.

License

MIT — Built by Freedom Engineers

SiteHealth MCP — Full website health audit
LeadEnrich MCP — Waterfall lead enrichment

Available Tools

5 tools

circuit_resetReset Circuit BreakerA

Idempotent

Reset a circuit breaker back to closed (healthy). Use after fixing the underlying issue.

ParametersJSON Schema

Name	Required	Description	Default
`target`	No	Target to reset. Omit to reset all.

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare destructiveHint=false and idempotentHint=true. Description adds 'back to closed (healthy)' and usage timing, but no further behavioral details beyond what annotations imply.

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 sentences, no extraneous words. Purpose and usage stated upfront and efficiently.

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 reset tool with one optional parameter and no output, the description is complete: it explains the action, the corrected state, and proper usage timing.

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 3. Description does not add extra semantic meaning for the parameter beyond the schema's own description.

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 'Reset' and resource 'circuit breaker back to closed (healthy)', which is distinct from siblings like circuit_status (read) or metrics (read metrics).

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?

Explicitly says 'Use after fixing the underlying issue', providing clear context for when to use. Does not explicitly state when not to use, but the guidance is sufficient.

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

circuit_statusCircuit Breaker StatusA

Read-only

Check the health status of a target. Returns circuit state, failure count, and cooldown.

ParametersJSON Schema

Name	Required	Description	Default
`target`	No	Target to check. Omit to see all targets.

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, indicating no side effects. The description adds value by explicitly listing returned data (circuit state, failure count, cooldown), providing behavioral context beyond the annotation. No contradiction.

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, front-loaded sentence with no wasted words. Every element (action, inputs, outputs) is present and immediately scannable.

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 read-only check with one optional parameter, the description is adequate. However, it omits usage guidelines and differentiation from sibling tools, which would be needed for full completeness in a multi-tool context. Output schema not required.

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 a clear description for the single parameter 'target'. The tool description does not add additional semantic meaning beyond the schema, so baseline 3 is appropriate.

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?

Clear verb-resource pair: 'Check the health status of a target.' Specifies return fields (circuit state, failure count, cooldown), distinguishing it from sibling tools like circuit_reset (write) and metrics (broader health).

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 explicit guidance on when to use this tool versus alternatives like circuit_reset or metrics. The parameter hint 'Omit to see all targets' is the only usage direction, but no exclusions or context for choosing among siblings.

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

metricsCall MetricsA

Read-only

Get observability metrics — success rates, latency, top errors, breakdown by tool and target.

ParametersJSON Schema

Name	Required	Description	Default
`windowMinutes`	No	Time window in minutes (default: 60)

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, consistent with description. Description adds detail on returned metrics (success rates, latency, top errors, breakdown) but does not disclose rate limits, data freshness, or other behavioral traits. Acceptable given annotation coverage.

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?

Extremely concise single sentence with front-loaded verb and resource. No wasted words, efficiently conveys purpose.

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?

Adequately covers purpose and output for a simple read-only tool. Lists specific metric categories and breakdown dimensions. No output schema requires explanation of return structure, which is sufficiently hinted. Slight gap: no mention of whether data is historical or real-time.

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 fully describes the sole parameter (windowMinutes) with type, default, and description. Tool description adds no additional parameter semantics. Baseline 3 at 100% schema 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?

Description uses specific verb 'Get' and resource 'observability metrics', listing concrete metric types (success rates, latency, top errors, breakdown by tool and target). Clearly distinguishes from siblings like recent_errors (specific errors) and circuit_status (circuit breaker state).

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 explicit guidance on when to use this tool versus siblings. Description only states what it does, leaving the agent to infer when to prefer it over recent_errors or circuit_status.

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

recent_errorsRecent ErrorsA

Read-only

Get the most recent failed calls with full error details and retry logs.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Number of errors to return (default: 20)

TDQS

A4/5.0

Behavior3/5

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

Annotations already mark this as readOnlyHint=true. The description adds that it returns 'full error details and retry logs', which is valuable context beyond the annotation but does not elaborate on behavior like pagination or rate limits.

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?

A single, concise sentence with no filler. Every word contributes to the understanding of the tool's purpose and output.

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?

For a simple read-only tool with one optional parameter and no output schema, the description adequately conveys what the tool returns (error details and retry logs). However, it could hint at the structure of the output or mention that errors are from a specific timeframe.

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 coverage is 100% for the single parameter 'limit'. The description adds explicit mention of the default value (20), which is not in the schema, providing extra meaning beyond parameter names.

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 'Get' and clearly identifies the resource as 'most recent failed calls' with 'full error details and retry logs'. It distinguishes itself from siblings like 'metrics' or 'circuit_status' by focusing on error specifics.

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 for retrieving recent failed calls, but provides no explicit guidance on when to use this tool versus alternatives like 'metrics' (error counts) or 'circuit_status' (breaker state). No when-not-to-use or exclusion criteria.

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

wrap_callSelf-Healing Function CallA

Execute a function call with retry, circuit breaker, and metrics. Pass a target name and the function will be retried on transient failures. Use this to wrap any unreliable external call.

ParametersJSON Schema

Name	Required	Description
`target`	Yes	Identifier for the target service (used for circuit breaker tracking)
`description`	Yes	Human-readable description of what this call does
`url`	No	URL to call (for HTTP targets)
`method`	No	HTTP method (default: GET)
`headers`	No	HTTP headers
`body`	No	Request body (for POST/PUT/PATCH)
`timeoutMs`	No	Timeout per attempt in ms (default: 30000)

TDQS

A3.9/5.0

Behavior3/5

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

Since no annotations are provided, the description carries full burden. It mentions retry and circuit breaker but lacks details on number of retries, backoff strategy, circuit breaker thresholds, or return behavior. This leaves gaps for an agent to predict exact behavior.

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?

Three short, front-loaded sentences convey the tool's purpose, behavior, and usage without waste. Each sentence adds value.

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?

With 7 parameters, no annotations, and no output schema, the description is insufficient. It fails to explain return values, retry count, circuit breaker details, or what happens on success/failure. More detail is needed for full completeness.

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%, so baseline is 3. The description only adds general context ('pass a target name') without explaining parameter meaning beyond the schema. It doesn't compensate for the lack of detail in the schema descriptions.

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 core function: wrapping a call with retry, circuit breaker, and metrics. It distinguishes from siblings like circuit_reset and metrics by showing this tool actually executes the unreliable call.

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 explicitly advises to 'use this to wrap any unreliable external call,' giving clear context. However, it does not specify when not to use it or compare with alternatives, which would provide stronger guidance.

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.

5 tool updatesv0.1.1Jun 21, 2026
- First observedcircuit_reset
- First observedcircuit_status
- First observedmetrics
- First observedrecent_errors
- First observedwrap_call

Install Server

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

TDQS

A3.9/5.0

Disambiguation5/5

Each tool has a clear, distinct purpose. circuit_reset and circuit_status are for circuit breaker state management, metrics for system observability, recent_errors for error inspection, and wrap_call for executing calls with resilience. There is no overlap or ambiguity between them.

Naming Consistency3/5

The naming uses snake_case but mixes patterns: some tools start with a noun (circuit_*), some with an adjective (recent_errors), and one with a verb (wrap_call). While readable, the lack of a consistent verb_noun or noun_verb pattern reduces predictability.

Tool Count4/5

With 5 tools, the server covers the essential resilience operations without being bloated. The number is appropriate for a focused self-healing utility, though a few additional tools (e.g., for configuration) could be added without harm.

Completeness4/5

The tool set covers the core lifecycle of circuit breakers, error tracking, and metrics. However, it lacks configuration tools for setting circuit breaker parameters or managing targets, which might be needed for full autonomy.

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

clawmerchants-mcp-gateway A
io.github.danielxri
MCP Gateway: wrap any MCP server with cold-start retries, uptime SLA, and per-execution MPP billing.
Agent Orchestration Cloud Platforms Developer Tools
22
Occludra — MCP Gateway (AI Security Gateway)
ai.occludra
Security & DLP proxy for MCP: tool-poisoning scans, PII redaction on tool args/results. Beta.
Security Agent Orchestration
1
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
UnboxAPI — Hospitality Reservation MCP Server
io.github.founder-OmniPA
REST-to-MCP for UK hospitality. Safety proxy: circuit-breakers, rate limits, whitelists. Apache 2.0.
Travel & Transportation E-commerce & Retail
2

Related MCP Servers

proxy-mcp
Agent Orchestration Developer Tools
Rixmerz
F
license
A
quality
D
maintenance
Universal MCP proxy server that discovers, searches, and executes tools across all configured MCP servers from a single entry point.
Updated 7 months ago (2026-02-19 14:32 UTC)
7
-
mcp-bastion
Security
Gowthaman90
A
license
A
quality
A
maintenance
A reliability & security proxy for the Model Context Protocol (MCP) that provides self-healing connections, runtime tool-security, and compliance-mapped audit trails.
Updated 6 days ago (2026-08-31 03:38 UTC)
5
103
6
Apache 2.0
SafeNode MCP Gateway
Security
sp3ak
A
license
A
quality
A
maintenance
An MCP proxy that enforces policy on every tool call, blocking or flagging actions before they reach downstream MCP servers.
Updated 24 days ago (2026-08-13 07:44 UTC)
1
47
MIT
sovereign-mcp-gateway
Security Agent Orchestration Developer Tools
mattijsmoens
F
license
Not graded
quality
A
maintenance
Acts as a gating proxy for MCP servers, merging tools and applying policy, verification, and audit layers.
Updated 13 days ago (2026-08-25 01:08 UTC)
-

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/carsonroell-debug/selfheal-mcp'

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