Dated, verified API breakages for coding agents, plus a local scan for them in your existing code.
Scored across 4 tools
lookup_traps and search_traps both retrieve traps and could be confused, but the descriptions explicitly state the trigger for each (before writing code vs. after an error), which mostly resolves the overlap. confirm_trap and file_trap are clearly distinct write/feedback operations.
All four tools follow a verb_noun pattern (confirm_trap, file_trap, lookup_traps, search_traps). The only blemish is singular 'trap' in the write tools versus plural 'traps' in the read tools.
Four tools is lean but well matched to a narrow domain: two read paths, one write, one feedback. Each tool earns its place, though the surface is close to the thin side.
Read (lookup/search), create (file), and vote (confirm) are covered, but there is no get-by-id to retrieve a specific trap after discovery, and no way to edit, withdraw, or retract a filed trap despite filing being framed as a 'draft'.
After you hit or avoid a trap returned by lookup_traps or search_traps, record whether it is still true. Confirmations raise a trap's trust score and disputes lower it; several disputes send it back for review. One vote per trap per 30 days. Needs a free API key.
| Name | Required | Description | Default |
|---|---|---|---|
| trap_id | Yes | The trap id from a lookup or search result, e.g. "fg-0158". | |
| hours_lost | No | Optional hours the trap cost before the fix was found. | |
| still_true | Yes | true if the trap happened as described, false if it no longer happens. | |
| version_seen | No | Optional SDK, API or tool version where you saw it, e.g. "stripe-node 22.3.0". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing consequences (confirmations raise trust score, disputes lower it, several disputes send a trap back for review), a rate limit (one vote per trap per 30 days), and an auth requirement (free API key). No contradiction with readOnlyHint=false/destructiveHint=false.
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?
Four short sentences, front-loaded with the trigger and action, then the consequences, then the limits. Nothing is padded or repeated from the schema.
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?
With no output schema, the description covers the side effects an agent needs to expect (trust score movement, review escalation) and the auth/rate constraints. It does not say what the call returns or what happens when voting again inside the 30-day window, a minor gap for a mutation tool.
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 coverage is 100%, so all four parameters are already documented, including the example format for trap_id and version_seen. The description only reinforces still_true via 'hit or avoid' and adds no syntax or format detail beyond the schema, so baseline 3 applies.
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?
Specific verb ('record whether it is still true') plus resource ('a trap returned by lookup_traps or search_traps'), with the effect named. It is clearly distinguishable from lookup_traps/search_traps, which only retrieve traps.
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 trigger is explicit: use it after you hit or avoid a trap returned by lookup_traps or search_traps, and it names those siblings as the source of the trap_id. It does not state when NOT to use it, but the prerequisite and timing are unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draft a trap after a failure was fixed. Private by default with a Pro or Team key. Public filings are checked automatically against official sources and published only when an official source confirms them. A reviewer can still act on any filing. Citing the provider's official documentation or changelog in sources helps. No API key needed. Set visibility to public to submit to the public registry.
| Name | Required | Description | Default |
|---|---|---|---|
| fix | Yes | What to change, in plain words. | |
| tags | No | Optional short keywords. | |
| apply | Yes | A short code or command example of the fix. | |
| cause | Yes | Why it happens. | |
| title | Yes | One line naming what goes wrong, as a developer would search for it. | |
| sources | No | Official documentation or changelog URLs that confirm it. | |
| affected | Yes | Which versions, plans or dates are affected. | |
| provider | Yes | The service, by slug or common name, e.g. "stripe". | |
| symptoms | Yes | Exact error messages or observed behavior, one per item. Leave out secrets and personal data. | |
| visibility | No | public submits to the shared registry; private keeps it in your team's space (Pro or Team key). | |
| surface_name | Yes | The specific endpoint, package, command or screen, e.g. "webhooks.constructEvent". | |
| surface_type | Yes | Which kind of surface broke: api, sdk, ui, billing, infra, or tool (CLIs and AI coding tools). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false) by disclosing defaults (private), the moderation pipeline for public filings, the fact that reviewers can still act on any filing, and key requirements. The auth statements are slightly muddled: "Private by default with a Pro or Team key" next to "No API key needed" requires the reader to infer that the latter applies only to public filings.
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 core action is front-loaded and there is no filler, but the definition is a string of six short clipped sentences and the key/auth sentences sit apart from each other, making the private-vs-public credential story harder to parse than necessary.
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 12-parameter, 9-required write tool with no output schema, it covers when to file, the privacy model, the moderation outcome for public filings, and credential expectations. It leaves open what the call returns (draft identifier, filing status) and whether a draft can be edited or confirmed afterward via confirm_trap.
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 every parameter is already documented in the schema, including visibility and sources. The description repeats visibility semantics and adds a soft recommendation to cite official docs in sources, but contributes no syntax, formatting, or length guidance beyond the schema.
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?
States a specific verb and resource: "Draft a trap after a failure was fixed," which is clearly a create-new-entry action distinct from confirm_trap (act on existing) and lookup_traps/search_traps (read). It does not explicitly name those siblings, so differentiation is inferred rather than stated.
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?
Gives a clear trigger condition ("after a failure was fixed") and explains the private/public decision path, including that public submissions are checked against official sources before publishing. It stops short of naming when to use confirm_trap or search_traps instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call before writing code against a third-party API, platform, or AI tool. Returns up to 10 verified, dated failure modes for that provider, each with symptoms, cause, fix, a code example and the date it was last checked. Use search_traps instead when you already have an error message.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional one-line description of the task, e.g. "verify webhook signatures in Next.js". Ranks the most relevant traps first. | |
| surface | 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 | Yes | The service, by slug or common name, e.g. "stripe", "supabase", "github-actions", "openai api". | |
| include_stale | No | Also return traps not re-checked recently. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-open-world. The description adds substantive context: result cap of 10, curation/verification ('verified, dated'), the fields returned (symptoms, cause, fix, code example, last-checked date), and the existence of staleness handling. It does not say what happens when the provider is unknown or no traps match, which is the main remaining gap.
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?
Three tight sentences, front-loaded with the trigger, then the return contract, then the sibling disambiguation. No filler or repetition of the title.
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?
No output schema exists, and the description compensates by describing the returned fields and the 10-item cap, which is what an agent needs to consume results. Minor omission: no guidance on empty results or unknown provider slugs.
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% and the four parameters are documented with examples and ranking behavior, so the schema does the heavy lifting. The description adds nothing parameter-specific (no mention of slug format, ranking, or include_stale), so baseline 3 applies.
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?
States a specific verb and resource ('look up traps for a provider') and immediately distinguishes itself from the sibling search_traps by input type (provider vs. error message). An agent can route between them without opening either schema.
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?
Gives an explicit trigger ('Call before writing code against a third-party API, platform, or AI tool') and names the alternative with its selecting condition ('Use search_traps instead when you already have an error message'). Both when-to-use and when-not-to-use are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call when a call to a third-party service fails or behaves unexpectedly. Paste the error text. Returns up to 5 verified traps whose symptoms match it, closest first, each with cause and fix. Returns nothing when no trap matches closely. Use lookup_traps instead before writing code.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Optional service slug or name to search within, e.g. "stripe". Omit to search every provider. | |
| error_text | Yes | The error message or unexpected output, as shown. Known key and secret formats are redacted before matching. | |
| include_stale | No | Also match traps not re-checked recently. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: a capped result count of 5, closest-first ordering, cause/fix payload shape, and the fact that an empty result is a normal outcome rather than an error. It stops short of noting cost or latency, so not a 5.
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?
Four short sentences, front-loaded with the trigger, then the return contract, then the alternative. Every sentence carries distinct information and none restates the name or title.
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?
No output schema exists, yet the description fully covers the return shape, ordering, cap, and empty-result case, and it routes to the correct sibling. An agent has everything needed to decide to call it and interpret the response.
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 error_text, provider, and include_stale are already documented with examples and defaults. The description adds only the matching intent ('whose symptoms match it'), which is helpful framing but not new per-parameter semantics. Baseline 3 is appropriate.
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?
States a specific verb and resource (search traps by error text) and describes exactly what comes back: up to 5 verified traps whose symptoms match, closest first, each with cause and fix. It also names the sibling lookup_traps, so an agent can distinguish it without opening either schema.
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?
Gives an explicit trigger (a third-party call fails or behaves unexpectedly), an explicit alternative for a different situation (use lookup_traps instead before writing code), and the no-match condition. The when/when-not routing is fully spelled out.
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.
confirm_trap4 fields changedInput schema / properties / hours_lost / descriptionAdded value: +"Optional hours the trap cost before the fix was found."Input schema / properties / still_true / descriptionAdded value: +"true if the trap happened as described, false if it no longer happens."Input schema / properties / trap_id / descriptionAdded value: +"The trap id from a lookup or search result, e.g. \"fg-0158\"."Input schema / properties / version_seen / descriptionAdded value: +"Optional SDK, API or tool version where you saw it, e.g. \"stripe-node 22.3.0\"."file_trap12 fields changedInput schema / properties / affected / descriptionAdded value: +"Which versions, plans or dates are affected."Input schema / properties / apply / descriptionAdded value: +"A short code or command example of the fix."Input schema / properties / cause / descriptionAdded value: +"Why it happens."Input schema / properties / fix / descriptionAdded value: +"What to change, in plain words."Input schema / properties / provider / descriptionAdded value: +"The service, by slug or common name, e.g. \"stripe\"."Input schema / properties / sources / descriptionAdded value: +"Official documentation or changelog URLs that confirm it."Input schema / properties / surface_name / descriptionAdded value: +"The specific endpoint, package, command or screen, e.g. \"webhooks.constructEvent\"."Input schema / properties / surface_type / descriptionAdded value: +"Which kind of surface broke: api, sdk, ui, billing, infra, or tool (CLIs and AI coding tools)."Input schema / properties / symptoms / descriptionAdded value: +"Exact error messages or observed behavior, one per item. Leave out secrets and personal data."Input schema / properties / tags / descriptionAdded value: +"Optional short keywords."Input schema / properties / title / descriptionAdded value: +"One line naming what goes wrong, as a developer would search for it."Input schema / properties / visibility / descriptionAdded value: +"public submits to the shared registry; private keeps it in your team's space (Pro or Team key)."lookup_traps4 fields changedInput schema / properties / context / descriptionAdded value: +"Optional one-line description of the task, e.g. \"verify webhook signatures in Next.js\". Ranks the most relevant traps first."Input schema / properties / include_stale / descriptionAdded value: +"Also return traps not re-checked recently. Default false."Input schema / properties / provider / descriptionAdded value: +"The service, by slug or common name, e.g. \"stripe\", \"supabase\", \"github-actions\", \"openai api\"."Input schema / properties / surface / descriptionAdded value: +"Optional part of the service you are working on, e.g. \"webhooks\" or \"image generation\". Ranks matching traps first; never filters others out."search_traps3 fields changedInput schema / properties / error_text / descriptionAdded value: +"The error message or unexpected output, as shown. Known key and secret formats are redacted before matching."Input schema / properties / include_stale / descriptionAdded value: +"Also match traps not re-checked recently. Default false."Input schema / properties / provider / descriptionAdded value: +"Optional service slug or name to search within, e.g. \"stripe\". Omit to search every provider."file_trap1 field changedInput schema / properties / visibilityAdded value: +{
+ "enum": [
+ "private",
+ "public"
+ ],
+ "type": "string"
+}confirm_trapfile_traplookup_trapssearch_trapsFind retiring AI models and outdated API SDKs in your code, with dates, replacements and guides.
What broke since your version, for 60 popular APIs/SDKs. Free quick check; full reports via x402.
Change intelligence for coding agents: sourced breaking changes for npm, PyPI, and Rust packages.
Changelogs for coding agents: versions, breaking changes, migrations. Free changelog-to-JSON.
Add one secure layer between your agents and this server.
