FileForge

Overview Schema Source Related Servers Discussions Admin

fileforge_api_action

Discover captured REST and GraphQL API calls, find OpenAPI specs, and export them as curl, Postman, or MSW mocks from a running DevTools session.

Instructions

Work with the API calls a page makes: discover REST and GraphQL requests, find OpenAPI specs, and export them as curl, Postman or MSW mocks. Reads a running DevTools session, so call start_session on fileforge_devtools_action first or results are empty. Exports replace a file of the same name and can include captured auth headers, so review them before sharing. Needs the extension.

Input Schema

Name	Required	Description	Default
`store`	No	Save the result in ~/.fileforge and return a ref.
`tabId`	No	Tab ID, or "active" for the active tab.	active
`action`	Yes	What to do. Required parameters are in brackets. discover: List the API calls captured in a tab, grouped by path, method or status and by domain. Stores the result by default. get_graphql_operations: List the GraphQL requests captured in a tab. Stores the result by default. find_openapi_specs: Send HEAD requests to common OpenAPI and Swagger paths on the tab's origin and list the ones found. export_curl: Write the captured API calls to a shell file as curl commands. export_postman: Write the captured API calls to a Postman collection file. generate_msw_mocks: Write the captured API calls to a file of MSW mock handlers.
`groupBy`	No	Field to group API calls by.	route
`filename`	No	Output filename.
`includeBodies`	No	Include response bodies.

Output Schema

Name	Required	Description
`ok`	Yes	False if the action failed or a check did not pass.
`ref`	No	Stored result ID, for fileforge_result_action.
`data`	No	The result. Its shape depends on the action.
`meta`	No	Tool, action and context.
`error`	No	Failure code and message.
`warnings`	No	Notes about a call that still ran.

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.3.0Nov 5, 2026

changedInput schema / properties / action / description

Previous value: -"The API action to perform."New value: +"What to do. Required parameters are in brackets. discover: List the API calls captured in a tab, grouped by path, method or status and by domain. Stores the result by default. get_graphql_operations: List the GraphQL requests captured in a tab. Stores the result by default. find_openapi_specs: Send HEAD requests to common OpenAPI and Swagger paths on the tab's origin and list the ones found. export_curl: Write the captured API calls to a shell file as curl commands. export_postman: Write the captured API calls to a Postman collection file. generate_msw_mocks: Write the captured API calls to a file of MSW mock handlers."

removedInput schema / properties / export

Removed value: -{
-  "items": {
-    "enum": [
-      "markdown",
-      "postman",
-      "msw"
-    ],
-    "type": "string"
-  },
-  "type": "array"
-}

addedInput schema / properties / filename / description
```
Added value: +"Output filename."
```

removedInput schema / properties / filter

Removed value: -{
-  "type": "object"
-}

addedInput schema / properties / groupBy / description
```
Added value: +"Field to group API calls by."
```
addedInput schema / properties / includeBodies / description
```
Added value: +"Include response bodies."
```

addedInput schema / properties / store / description

Added value: +"Save the result in ~/.fileforge and return a ref."

addedInput schema / properties / tabId / description

Added value: +"Tab ID, or \"active\" for the active tab."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "description": "query_* actions return their modules as extra top-level fields.",
+  "properties": {
+    "data": {
+      "description": "The result. Its shape depends on the action."
+    },
+    "error": {
+      "description": "Failure code and message."
+    },
+    "meta": {
+      "description": "Tool, action and context."
+    },
+    "ok": {
+      "description": "False if the action failed or a check did not pass.",
+      "type": "boolean"
+    },
+    "ref": {
+      "description": "Stored result ID, for fileforge_result_action."
+    },
+    "warnings": {
+      "description": "Notes about a call that still ran."
+    }
+  },
+  "required": [
+    "ok"
+  ],
+  "type": "object"
+}

First observedv0.2.1Nov 5, 2026

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, it discloses that a running DevTools session is required, that exports overwrite a file of the same name, and that exported artifacts can contain captured auth headers and should be reviewed. Those are real side effects and security considerations an agent would not learn from readOnlyHint=false / openWorldHint=true. It stops short of describing how much data discovery returns or throttling from the HEAD probing in find_openapi_specs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with capability then prerequisite then risk. Every sentence carries distinct information — scope, dependency, and side-effect warning — with no repetition of the schema.

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?

With an output schema present, the description does not need to explain return values, and it covers the two things the schema cannot: the session prerequisite and the overwrite/auth-header hazards. Minor gap: it does not clarify that the export actions require a filename or what happens when one is omitted.

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% and the action enum already documents each mode in detail, so the baseline of 3 applies. The description adds no per-parameter meaning beyond restating that multiple export modes exist; filename, store, tabId and groupBy semantics are left entirely to 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?

The description names the specific resource (the API calls a page makes) and enumerates the concrete operations: REST/GraphQL discovery, OpenAPI spec lookup, and curl/Postman/MSW export. That is enough to separate it from siblings like fileforge_devtools_action or fileforge_export_action, though the generic opener 'Work with the API calls' is weaker than the specifics that follow.

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?

It gives an explicit prerequisite chain: start_session on fileforge_devtools_action first, plus 'Needs the extension,' and explains the consequence of skipping it ('results are empty'). What is missing is guidance on when to pick this tool over fileforge_devtools_action for raw network inspection, or over fileforge_export_action for generic export.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.