All nodes/Integrations/Files
File Tool
Gives an AI Agent file tools (fs_glob, fs_read, fs_write). Works on this workspace's own store by default; set 'Connection source' to 'External connection' to point it at a store wired into the 'file_store' port. Read-only by default — tick fs_write to let the model create and overwrite files.
Type in the graph: file_tool
Tool
Try it
Minimal working workflow
- Execute + Data
- Extension
- LLM
- Memory
- Execute + Data + Streaming
Runs as pasted
When to use it
Use this node when the model, not the graph author, decides which file to open: going through a folder of reports, finding the right export from a description, keeping notes as the conversation goes. When the path is known in advance, the deterministic File Read, File Write and File Glob are cheaper and more predictable — their result does not depend on how the model read the task. For tabular work (load a CSV, filter, aggregate) there is a separate DataFrame Tool.
How it works
The node is not a step in the flow: it has no execution input. It is wired with an extension
wire into the extensions port of AI Agent and gives the model up
to three tools: fs_glob (list paths), fs_read (read a file) and fs_write (create or
overwrite). Only the first two are on by default — write access is granted with a deliberate
tick.
The store is chosen the same way as on the regular file nodes: the workspace’s own store by
default, or whatever is wired into the file_store port in “External connection” mode.
A tool failure is returned to the model as text with an error code, not raised as a node
failure. The turn continues: the model sees “file not found” and can try another path. A
binary file read through fs_read is attached to the conversation, and that needs a
connection-backed store — a binary file from the built-in workspace store cannot be shown to
the model.
Common mistakes
- Ticking
fs_writejust in case. With it on, the model can overwrite any file inside the root without asking. If writing is needed, narrow the area with the Subfolder field. - Expecting Subfolder to narrow an external disk. The field applies to “From the run context” mode only; a wired config node owns its own, wider root.
- Assuming a disabled tool is only roughly unavailable. It is exactly unavailable: a call under a guessed name is rejected rather than executed.
- One tool node for several agents. Only the agent the wire reaches sees the tools; a second agent needs its own node.
- Expecting an execution output. There is none — the node cannot be placed in a chain of steps.
Inputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
File storefile_store | Datadata | — | shown when connection_source ≠ "auto" |
Outputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
tool_out | Extensionlink_extension | — |
Configuration
| Field | Type | Default | Description |
|---|---|---|---|
Enabled toolsenabled_tools | array<string> | ["fs_glob","fs_read"] | Tools the agent may call on the connected store. fs_write lets the model create and overwrite files — grant it deliberately. A tool name saved by an older version that no longer exists is kept but shows no checkbox. |
Connection sourceconnection_source | string | auto | Where this node gets its connection. 'From the run context' uses what the platform already knows (the Telegram bot this workflow is deployed to / this workspace's own file store) and needs no wiring. 'External connection' shows the resource port so a config node can be wired into it. Options: |
Subfolderstore_subfolder | string | "" | Optional folder inside this workspace's store to treat as the root, e.g. `reports` or `sessions/{{ variables.session_id }}`. Blank = the store root. supports templates shown when connection_source = auto |