Failure recovery for AI agents

Help your AI agents recover from failed tool calls.

RecoverMCP is an MCP server that tells your agent why a tool call failed, whether anything already happened, and what to do next: fix the request, retry safely, ask for approval, or stop.

Join the waitlist See how it works

In development. Early access opens soon.

Failed tool call 422 
create_invoice({
  customer: "cus_8124",
  amount: 4200
})
→ Error: missing required field
Recovery plan Ready 
{
  "cause": "missing_required_field",
  "field": "currency",
  "already_applied": false,
  "next_step": "fetch_value",
  "source": "customer.billing_profile",
  "retry": "safe_after_fix",
  "needs_approval": false
}
Simplified example response

The problem

Tool calls fail. Agents rarely know what to do next.

APIs return errors. Tokens expire. Rate limits are hit. Requests time out. A developer can read the error and work out the fix. An agent usually can’t, so it falls into one of three traps.

It retries the same mistake.

The agent sends the same request again, or guesses at new inputs. Each attempt costs time and tokens and fixes nothing.

It repeats an action that already worked.

A timeout doesn’t always mean failure. The invoice may already exist. Retrying creates a second one.

It gives up.

One fixable error stops a multi-step task. Someone has to look into it and start again by hand.

Today, every team building agents writes its own recovery logic, one tool at a time.

What RecoverMCP does

A clear answer every time a tool call fails.

When a tool call fails, your agent sends the failure to RecoverMCP. RecoverMCP answers five questions and returns the answers in a structured format the agent can act on.

  1. What failed?

    The exact operation and error.

  2. Why did it fail?

    The most likely cause, based on the error, the tool’s requirements and the current state.

  3. Did anything already happen?

    Whether the failed request still made a change before it failed.

  4. What should happen next?

    A specific recovery step.

  5. Is it safe to continue?

    Whether the agent can go ahead on its own, needs approval first, or should stop.

How it works

From failed call to next step in four steps.

  1. A tool call fails.

    Your agent sends RecoverMCP the request, the error, and any useful context.

  2. RecoverMCP diagnoses it.

    It sorts the failure into a known type: missing or invalid input, authentication or permission errors, rate limits, timeouts, resources that don’t exist, data that has changed, services that are down, or an action whose result is unclear. Where it can, it runs read-only checks to confirm the cause.

  3. RecoverMCP returns a plan.

    The plan tells the agent exactly what to do: correct the input, wait and retry, fetch fresh data, check whether the action already went through, ask a person for approval, or stop.

  4. The agent recovers and confirms.

    The agent follows the plan and checks the result. If the outcome still can’t be confirmed, RecoverMCP reports it as unknown instead of calling it a success.

The same error, handled two ways

Without RecoverMCP

  1. AgentCalls create_invoice.
  2. ToolError 422: missing required field.
  3. AgentSends the same request again.
  4. ToolSame error.
  5. AgentGuesses at the missing value.
  6. ToolNew error.

Result: The task fails, and someone has to step in.

With RecoverMCP

  1. AgentCalls create_invoice.
  2. ToolError 422: missing required field.
  3. AgentSends the failure to RecoverMCP.
  4. RecoverMCPFinds the missing field (currency) and where to get it: the customer’s billing record.
  5. AgentCorrects the request and sends it once more.
  6. ToolInvoice created.
  7. AgentConfirms the invoice exists and moves on.

Result: The task completes without guessing.

If the currency can’t be found in a reliable source, RecoverMCP tells the agent to ask the user. It never makes up a value. This example is simplified, and real results depend on the service and the information available.

Features

What your agent gets

Failure diagnosis

Explains what went wrong in terms the agent can act on, not just an HTTP status code.

Structured recovery plans

Machine-readable next steps that list what to change, what’s missing, and whether approval is needed.

Safe retry decisions

Separates failures worth retrying from ones that aren’t, and from ones that need a check first.

Duplicate protection

Checks whether a timed-out action already happened before the agent tries it again.

Respects permissions

Treats a permission error as a boundary. It never looks for a way around it.

Built on MCP

Recovery tools appear as standard MCP tools, so any compatible agent can call them.

Recovery history Planned

See which failures happen most, which get resolved, and what they cost.

Use cases

Where it helps

Anywhere an agent changes data in another system.

Coding and DevOps agents

Failure
A deployment fails because its target configuration changed.
Recovery
RecoverMCP has the agent fetch the current configuration and reconcile the difference before trying again.

Customer support agents

Failure
A customer record update fails because someone else edited it first.
Recovery
The agent is told to fetch the latest version and re-check its change.

Billing and finance agents

Failure
An invoice request times out.
Recovery
Before any retry, RecoverMCP has the agent check whether the invoice was already created.

Ecommerce and operations agents

Failure
An inventory update conflicts with a change from another system.
Recovery
The agent gets the current stock level before going further.

Safety

Recovery should never make things worse.

RecoverMCP follows seven rules.

  1. Check before retrying.

    If a failed action might have gone through, confirm first.

  2. Respect permissions.

    Never work around a permission error with other credentials or tools.

  3. Never make up data.

    Missing values come from a trusted source or from the user.

  4. Prefer known rules to guesses.

    Use service-specific rules and verified checks wherever possible.

  5. Limit automatic actions.

    Retries are capped, steps have timeouts, and sensitive actions need approval.

  6. Say when it’s unsure.

    If the outcome is unclear, report it as unknown.

  7. Protect sensitive data.

    Use the least access needed, hide secrets, and keep as little data as possible.

Developers

How you’ll use it

RecoverMCP runs as an MCP server alongside your agent’s other tools.

  1. Add RecoverMCP to your agent’s MCP configuration.

    Your agent gets a set of recovery tools.

  2. Choose the tools you want covered.

    Start with the services where failures cost you the most. Each one needs a recovery adapter or enough tool metadata.

  3. Call RecoverMCP when a tool fails.

    Your agent, or a proxy in front of your tools, sends the failure details. RecoverMCP only sees failures you send to it.

Recovery tools

ToolWhat it does
diagnose_failureFinds the likely cause of a failed tool call.
inspect_preconditionsChecks current state and missing requirements with safe, read-only checks.
propose_recoveryReturns a structured recovery plan.
check_side_effectChecks whether an unclear action already took effect.
execute_recoveryRuns recovery steps you have explicitly allowed.
get_recovery_statusReturns the status and result of a recovery attempt.

Tool names and schemas are early and may change. Full documentation comes with early access.

FAQ

Common questions

Is RecoverMCP available today?

Not yet. We’re building the first version now. Join the waitlist to get early access when it opens.

How is this different from a retry library?

A retry library repeats the same request under set conditions. RecoverMCP first works out why the request failed, whether it already took effect, and whether it needs changing. Then it decides whether a retry makes sense at all.

How is it different from LangGraph, Temporal, or other workflow frameworks?

Those tools handle orchestration, state and retries. RecoverMCP focuses on one job: deciding the right next step after an external tool fails. It works alongside them.

Does it replace my monitoring or observability tools?

No. Monitoring tools show engineers what went wrong after the fact. RecoverMCP helps the agent decide what to do while the task is still running.

Does it fix every error?

No. Some errors can be fixed with verified information. Others need new permissions, a person’s approval, or a change in another system. When the agent can’t safely recover on its own, RecoverMCP says so.

Can it cause duplicate actions?

It’s built to prevent them by checking whether an action already happened before any retry. That check depends on what the service supports, so no recovery tool can guarantee exactly-once execution with every third-party service.

Does it work with every MCP server?

Not automatically. Good recovery needs details about each service. We’ll add integrations over time, starting with the most requested.

Does it require a specific AI model?

No. RecoverMCP works through standard MCP tools, so it works with any compatible agent.

Will it be open source? What will it cost?

Neither is decided yet. We expect to offer a free option for developers and usage-based pricing for hosted features.

Get early access

We’re building RecoverMCP with teams that run agents against real systems. Join the list for early access, and help decide which integrations come first.

We’ll only email you about RecoverMCP. No spam.