Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ProxyPI POST https://api.example.com/users {"name":"John"}"
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.
Self-healing API proxy MCP for Cursor, Claude Code, or any MCP-compatible client. Send any REST request — if it fails, ProxyPI reads the error, diagnoses the problem using Claude, patches the request, and retries. Successful fixes are remembered and applied instantly next time, without calling Claude.
Related MCP server: mcp-proxy
You: proxypi_request → POST https://api.example.com/users
ProxyPI: try → fail → diagnose (Claude) → patch → retry → rememberNext time the same error occurs on the same host and path, the fix is applied from memory instantly — no Claude call needed.
npx proxypinpx proxypiAdd to .cursor/mcp.json (project root or ~/.cursor/mcp.json):
{
"mcpServers": {
"proxypi": {
"command": "npx",
"args": ["-y", "proxypi"],
"env": {
"ANTHROPIC_API_KEY": "your-api-key-here"
}
}
}
}Restart Cursor. Four tools: proxypi_request, proxypi_history, proxypi_replay, proxypi_clear.
Tool | Description |
| Send any REST request — auto-heals on failure |
| View past fixes, filter by API host |
| Re-run a stored fix to verify it still works |
| Wipe all healing records from memory |
Error | What ProxyPI does |
| Fixes Authorization header format (Bearer vs Basic vs token prefix) |
| Fixes body field names, types, or missing required fields |
| Corrects schema mismatches, enum values, date formats |
| Fixes URL path, API version prefix, trailing slashes |
| Switches to the correct HTTP method |
Memory: Fixes stored in ~/.proxypi/memory.json
Env: ANTHROPIC_API_KEY required (only when using healing — server starts without it)
Local dev: cp .env.example .env, add key, then npm run dev
Tests: npm test
MIT · GitHub
Clear all stored healing records from memory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states the destructive action 'Clear all stored healing records' and the scope 'all', but it does not explicitly warn that this is irreversible or that it permanently deletes all data. The core behavior is transparent, but safety-critical context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no superfluous words. It front-loads the verb 'Clear' and immediately specifies the object and scope, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description adequately covers the core action and its scope. It lacks an explicit irreversibility warning, but given the simplicity of 'clear all', the description is largely complete for an agent to understand what the tool does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty with 100% coverage, so parameter semantics are not applicable. Per the rubric, the baseline for zero-parameter tools is 4, and the description correctly avoids inventing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Clear' and identifies the resource as 'all stored healing records from memory', making the tool's purpose immediately clear. This distinguishes it from siblings like proxypi_request, proxypi_history, and proxypi_replay, which imply different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description only states the action, with no mention of scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the history of auto-healed API requests. Optionally filter by API host.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Filter by API host, e.g. 'api.github.com'. Leave empty to see all. | |
| limit | No | Number of records to show |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. 'Show' clearly indicates a read-only operation, and the reference to 'history' implies non-destructive behavior. It adds useful context about 'auto-healed' requests, though it doesn't enumerate side effects—unnecessary for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action, and no filler. 'Show the history of auto-healed API requests' directly states the purpose, and the optional filter clause is concise without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only history tool with two well-documented schema parameters, the description gives sufficient context to understand purpose and invocation. It does not specify return format, but no output schema exists, and the user can infer typical history output. The limit parameter is not mentioned in the description, but it is fully documented in the schema, so the agent can still use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions optional host filtering, which is redundant with the schema's host description, and it does not add meaning to the limit parameter. The schema itself provides adequate parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows the history of auto-healed API requests with a specific verb ('Show') and resource. The sibling names (proxypi_request, replay, clear) imply different operations, and 'history' distinguishes this from making/replaying/clearing requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: viewing past auto-healed requests, with optional host filtering. However, there is no explicit when-to-use guidance or mention of alternatives among the sibling tools. The description does not say when this should be used instead of replay or clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replay a previously healed request. Useful for testing that a fix still works after an API update.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | API host to replay, e.g. 'api.github.com' | |
| index | No | Index of the record to replay (0 = most recent) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not explain what 'replay' entails operationally—whether it modifies state, requires authentication, or has side effects. The description lacks transparency about the tool's internal behavior, which is a significant gap given no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action and purpose. Every word contributes meaning—no filler or redundancy. It is concise, efficient, and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no annotations), the description provides a basic understanding of what the tool does and a use case. However, it omits important context such as what a 'healed request' is, how replaying works in relation to the API, and what the response contains. The description is adequate but incomplete for a tool without annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters with clear descriptions for 'host' and 'index'. The tool description adds no additional parameter information, but since the schema already provides thorough semantics, the baseline score of 3 is appropriate. The description does not override or enrich the schema's parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Replay') and the resource ('a previously healed request'), which is specific and distinct from the sibling tools like proxypi_request or proxypi_history. However, it does not explicitly differentiate from these alternatives, relying on the verb and context to imply uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a specific use case: 'testing that a fix still works after an API update.' This implies when to use the tool but provides no explicit guidance on when not to use it or how it compares to proxypi_request, proxypi_history, or proxypi_clear. The usage context is clear but not comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a request to any REST API. If the request fails, ProxyPI diagnoses the error, patches the request using Claude, and retries automatically — up to 3 times. Learned fixes are remembered and applied instantly next time without calling Claude.
Examples:
POST https://api.stripe.com/v1/customers with a body
Any REST endpoint with headers, body, or query params
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL of the API endpoint | |
| body | No | Request body (for POST/PUT/PATCH) | |
| method | No | HTTP method | GET |
| params | No | Query string parameters | |
| headers | No | Request headers, e.g. { Authorization: 'Bearer token' } |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals key behaviors: automatic retry up to 3 times, error diagnosis and patching using Claude, and caching of learned fixes. This goes beyond a simple 'make request' description, though it does not detail return formats or side effects like authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-structured. It starts with the core purpose, then explains the retry behavior, and provides actionable examples. Every sentence adds value without any redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The combination of schema coverage and description is nearly complete for a request dispatch tool. It lacks an explicit statement about the return value (e.g., response body/status), but given the tool's straightforward nature and the retry details included, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 5 parameters with descriptions, so the baseline is 3. The description does not add anything beyond the schema; it merely restates that headers, body, and query params are supported through examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Send a request to any REST API.' It includes examples and distinguishes itself from sibling tools (history, replay, clear) by focusing on the core request functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('Any REST endpoint') and includes examples for GET and POST requests. However, it does not explicitly mention alternatives or exclusions, though the sibling tools are obviously different in nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0proxypi_clearproxypi_historyproxypi_replayproxypi_requestScored across 4 tools
Each tool serves a distinct purpose: send a request, view history, replay a healed request, and clear records. No overlap or ambiguity between them.
All tool names follow the consistent pattern 'proxypi_' prefix plus a simple action verb (request, history, replay, clear), using lowercase snake_case throughout.
With 4 tools, the set is compact and well-scoped for a proxy request healer. Each tool earns its place without redundancy or bloat.
The tool surface fully covers the request-healing lifecycle: sending, reviewing history, replaying, and clearing records. There are no obvious dead ends or missing operations for the stated domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-native mock API server with MCP. Create REST/SOAP mocks from Claude, Cursor, or Windsurf.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
MCP-native AI SRE: ask what's broken in production, get a reviewed GitHub fix PR.