Let an agent use Vortex tools

3 minute read · Chats & Local Agents

Let a supported local external agent use saved developer resources through Vortex. Credentials are resolved by Vortex rather than pasted into the agent’s resource list.

Expose only the tools you intend to use

Open Share Vortex tools in MCP settings and inspect the server state and supported local client setup. Choose the modules the external agent should discover: Terminal, Database, Files, API, Mail, Signals and Documentation. Disabling a module removes its tools from that exposed surface.

Connect the supported local agent through the setup flow while preserving its unrelated configuration. Start with resource discovery: the agent should receive useful names and IDs, not passwords. An authorized operation resolves the saved credential inside Vortex's privileged process.

Follow the resource-ID workflow

Ask the agent to discover the relevant saved resource, inspect it by its returned ID and perform the exact allowed task. For example, discover the local Small Stories database, read its schema and query a few fictional article titles. Opening the returned result link in Vortex lets you inspect the capture without executing the query again.

A request to read data does not authorize changing it. Read-only SSH tools reject ambiguous writes; mutating tools have their declared routine/always-confirm policies. An external agent's own permissive mode does not remove those native boundaries.

Audit and troubleshoot

Check the enabled modules, routine approval preferences and available audit information when a tool is missing or denied. A disabled module, unknown resource ID, locked Vault and disconnected target are different causes. Avoid solving a missing read tool by granting every module access.

Documentation tools search guides and read one by slug. Project tools operate within the project scope of their conversation; enabling MCP does not grant an external client unrestricted filesystem access. External tools for chats describes the opposite MCP direction.

A practical read-first workflow

Enable Database and Documentation, then ask the external agent to discover the saved development connection and read the table structure. Inspect the returned resource identity before approving a query. Open the captured result in Vortex to compare it with the table browser. Enable another module only when the task needs it.

For a write, state the exact destination and intended change. A read permission is not a blanket grant to run SQL mutations, upload files, send HTTP requests or execute a remote command. Review the tool's own confirmation in addition to the agent's execution mode. Credentials are resolved for the operation rather than included in a resource listing, but query results and downloaded files can still contain sensitive values.

Use Documentation search when a tool or workflow is unfamiliar, then read the relevant guide by slug. Retain the captured result and final state so you can distinguish an attempted operation from a verified outcome.

Related guides: tools for chats, linked tasks.

Updated Sep 13, 2026 · Need a hand?