Footgun

File a new trap

file_trap

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "provider": "<provider>",
      "surface_type": "<surface_type>",
      "surface_name": "<surface_name>",
      "title": "<title>",
      "symptoms": "<symptoms>",
      "cause": "<cause>",
      "fix": "<fix>",
      "apply": "<apply>",
      "affected": "<affected>"
    },
    "name": "file_trap"
  }
}

Input Schema

Name	Required	Description
`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).

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedOct 27, 2026

addedInput schema / properties / affected / description

Added value: +"Which versions, plans or dates are affected."

addedInput schema / properties / apply / description

Added value: +"A short code or command example of the fix."

addedInput schema / properties / cause / description
```
Added value: +"Why it happens."
```

addedInput schema / properties / fix / description

Added value: +"What to change, in plain words."

addedInput schema / properties / provider / description

Added value: +"The service, by slug or common name, e.g. \"stripe\"."

addedInput schema / properties / sources / description

Added value: +"Official documentation or changelog URLs that confirm it."

addedInput schema / properties / surface_name / description

Added value: +"The specific endpoint, package, command or screen, e.g. \"webhooks.constructEvent\"."

addedInput schema / properties / surface_type / description

Added value: +"Which kind of surface broke: api, sdk, ui, billing, infra, or tool (CLIs and AI coding tools)."

addedInput schema / properties / symptoms / description

Added value: +"Exact error messages or observed behavior, one per item. Leave out secrets and personal data."

addedInput schema / properties / tags / description
```
Added value: +"Optional short keywords."
```

addedInput schema / properties / title / description

Added value: +"One line naming what goes wrong, as a developer would search for it."

addedInput schema / properties / visibility / description

Added value: +"public submits to the shared registry; private keeps it in your team's space (Pro or Team key)."

Changed1 schema field changedOct 19, 2026

addedInput schema / properties / visibility

Added value: +{
+  "enum": [
+    "private",
+    "public"
+  ],
+  "type": "string"
+}

First observedOct 19, 2026

TDQS

A3.8/5.0

Behavior4/5

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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

All Footgun tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.