About traplens
traplens gives coding agents access to verified, dated records of API failures, for checking known issues before development or searching from error text. It also supports submitting resolved failures and confirming whether existing records remain valid.
Key features
- 01Look up traps by provider
- 02Search matching traps from error text
- 03Submit a trap after fixing a failure
- 04Confirm whether a trap still applies
- 05Review symptoms, causes, fixes, and examples
Use cases
- 01Check known pitfalls before coding against a third-party API
- 02Find similar failures from an error message
- 03Record a failure and its fix after resolution
- 04Verify whether a known failure still occurs
MCP support
It exposes the upstream Footgun MCP server's tool list locally, forwards tool calls upstream, and returns results unchanged.
Configuration
Local server config is the same for every client. Copy it into your client’s MCP config file.
Tools
4Saved tool list · updated 1w ago
| Parameter | Type | Required | Description |
|---|---|---|---|
| context | string | No | Optional one-line description of the task, e.g. "verify webhook signatures in Next.js". Ranks the most relevant traps first. |
| surface | string | No | Optional part of the service you are working on, e.g. "webhooks" or "image generation". Ranks matching traps first; never filters others out. |
| provider | string | Yes | The service, by slug or common name, e.g. "stripe", "supabase", "github-actions", "openai api". |
| include_stale | boolean | No | Also return traps not re-checked recently. Default false. |
Details
From the project READMEtraplens
traplens gives a coding agent a memory for other people's API breakages. Before writing code against a third-party service, look up that provider and get back up to ten verified, dated failure modes, each with its symptoms, its cause, a fix, a code example, and the date it was last checked. When a call fails instead, paste the error text and search for traps whose symptoms match it. After a failure has been fixed, file a new trap so the next agent does not lose the same hours, and after hitting or avoiding a known trap, confirm whether it is still true.
The bridge keeps no trap data of its own. It serves the upstream Footgun server's tool list locally, exactly as captured from the live endpoint, and forwards each tool call upstream, returning the result untouched.
Tools
lookup_traps— traps for a provider. Required:provider(slug or common name, e.g."stripe"). Optional:surface(part of the service, ranks matches first only),context(one-line task description), andinclude_stale.search_traps— traps matching error text. Required:error_text(4 to 4000 characters; known key and secret formats are redacted before matching). Optional:providerandinclude_stale.file_trap— draft a trap after a failure was fixed. Required:provider,surface_type(one ofapi,sdk,ui,billing,infra,tool),surface_name,title,symptoms,cause,fix,apply, andaffected. Optional:sources,tags, andvisibility(privateby default,publicto submit to the shared registry).confirm_trap— record whether a trap is still true. Required:trap_idandstill_true. Optional:hours_lostandversion_seen.
Configuration
FOOTGUN_MCP_URL(optional) — override the upstream endpoint. Defaults tohttps://getfootgun.com/api/mcp. (The override hook is this rebuild's own labelled reconstruction.)FOOTGUN_API_KEY(optional) — when set, every upstream request carries anAuthorization: Bearer <key>header. When it is not set, no key header is sent. (The header name is pinned by the registry record; the Bearer scheme and this forwarding are labelled reconstructions — the original surface was captured keyless.)
Forwarding mechanics
On the first tool call the client opens a streamable
HTTP session with the upstream: a JSON-RPC initialize
request (protocolVersion 2025-03-26, clientInfo name
traplens), then a notifications/initialized
notification, then the tools/call request carrying
the caller's arguments unchanged. When the upstream
answers initialize with an Mcp-Session-Id header,
that value rides on every later request of the session,
which is reused for the life of the process. Replies
may arrive as plain JSON or as server-sent events;
both are read.
Successful upstream results pass through verbatim,
including any isError flag the upstream sets.
Failures — a JSON-RPC error, a non-2xx status, an
unreadable response, or a request that cannot be
completed — come back as an isError result whose
text starts with traplens error: (this rendering is
this rebuild's own labelled reconstruction).
CLI
Each tool is also a subcommand taking one JSON argument string:
npx @reneturcios/traplens lookup_traps '{"provider":"stripe"}'
npx @reneturcios/traplens search_traps '{"error_text":"No such payment_method"}'
npx @reneturcios/traplens confirm_trap '{"trap_id":"fg-0158","still_true":true}'
npx @reneturcios/traplens --version
Exit codes: 0 on success, 1 on an isError
result, 2 on a usage error.
MCP server
npx -y @reneturcios/traplens mcp
MCP client config:
{
"mcpServers": {
"traplens": {
"command": "npx",
"args": ["-y", "@reneturcios/traplens", "mcp"]
}
}
}
Docker
docker run -i ghcr.io/cloudcorprecords/traplens
docker run --rm ghcr.io/cloudcorprecords/traplens --version
The container's default command is mcp, so the first
form is a stdio MCP server; any other arguments reach
the CLI normally.
Development
npm install
npm run build
npm test
npm run dev
The test suite runs entirely against a stubbed JSON-RPC upstream — no live network calls.
License
MIT — see LICENSE.
Comments
New to MCP?
From what the protocol is to installing your first server, these answers cover most first questions.
An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.