FileForge

Overview Schema Source Related Servers Discussions Admin

fileforge_export_action

Write stored results or SQL query output to CSV, JSON, Markdown, HAR, or ZIP files to hand data to another tool; saves only in FileForge's exports folder.

Instructions

Write stored results or SQL query output to a file in formats such as CSV, JSON, Markdown, HAR or ZIP. Use this to hand data to another tool. Use fileforge_result_action or fileforge_sql_action to read data without creating a file. Writes only to FileForge's exports folder, and a filename you reuse replaces that file.

Input Schema

Name	Required	Description	Default
`ref`	No	Ref of a stored result.
`query`	No	SQL SELECT whose rows to export.
`action`	Yes	What to do. Required parameters are in brackets. result (ref): Export a stored result ref to a file. query (query): Run a SQL query and export results to a file.
`format`	No	Output format.	csv
`filename`	No	Output filename.

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.

Changed6 schema fields changedv0.3.0Nov 5, 2026

changedInput schema / properties / action / description

Previous value: -"The action to perform. Available actions: result: Export a stored result ref to a file. query: Run a SQL query and export results to a file."New value: +"What to do. Required parameters are in brackets. result (ref): Export a stored result ref to a file. query (query): Run a SQL query and export results to a file."

addedInput schema / properties / filename / description
```
Added value: +"Output filename."
```
addedInput schema / properties / format / description
```
Added value: +"Output format."
```
addedInput schema / properties / query / description
```
Added value: +"SQL SELECT whose rows to export."
```
addedInput schema / properties / ref / description
```
Added value: +"Ref of a stored result."
```

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.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), and the description adds two things annotations cannot: writes are sandboxed to FileForge's exports folder, and reusing a filename silently replaces that file. The overwrite disclosure is the most important behavioral detail here. It stops short of saying whether the overwrite is confirmed or what happens on an invalid path, keeping it from 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.

Conciseness5/5

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

Three short sentences, ordered purpose → use case → routing to alternatives → behavioral caveats. Every sentence carries information an agent needs, and the scope/overwrite caveat is placed last where it reads as a warning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and annotations cover the safety surface. For a 5-parameter write tool the description covers purpose, alternatives, write scope, and overwrite semantics — everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents ref, query, action, format, and filename, giving a baseline of 3. The description goes beyond it by explaining the consequence of a parameter choice ('a filename you reuse replaces that file'), which is real semantic value rather than repetition. The format list in the prose is only a partial subset of the nine enum values, but the schema carries the full list.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Write stored results or SQL query output to a file') and enumerates concrete output formats, so the agent knows exactly what the tool produces. It also explicitly distinguishes itself from the two read-only siblings by name, which is rare and valuable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a positive use case ('hand data to another tool') and a negative one with named alternatives ('fileforge_result_action or fileforge_sql_action to read data without creating a file'). The agent can decide between export and read without opening any schema.

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