Let an agent use Vortex tools
4 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
- Follow the resource-ID workflow
- Audit and troubleshoot
- A practical read-first workflow
- Vortex MCP settings reference
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.
An authorized read or specifically scoped change runs directly through native tools in Auto; do not insert an extra confirmation step. Supervised and Auto-edit ask before changes, and Plan is read-only. Read-only SSH tools reject ambiguous writes. Known mass-destructive SQL and shell commands and FTP operations targeting protected root paths remain blocked. For external MCP clients, Confirm routine changes too controls whether routine changes require confirmation; the external agent's own mode does not replace this Vortex setting.
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. Review the returned resource identity and query scope. SELECT id, title FROM articles WHERE status = 'draft' LIMIT 10 is a read and does not need approval. Open the captured result in Vortex to compare it with the table browser. Enable another module only when the task needs it.
For a change, state the exact destination and intended scope. In Auto, a specific operation such as UPDATE articles SET status = 'published' WHERE id = 42 or uploading one named file can run directly when authorized. A scoped DELETE or DDL statement such as CREATE TABLE is likewise not subject to a blanket confirmation rule. Whole-table SQL changes without an outer WHERE and mass destructive operations remain blocked. The read-only SSH tool rejects commands it cannot establish as read-only; use the remote execution tool for an authorized change. Do not assume arbitrary SQL functions are safe just because a statement has a WHERE clause. Supervised and Auto-edit ask before changes; Plan is read-only. External MCP clients follow Confirm routine changes too. 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.
Vortex MCP settings reference
| Control | Effect / default |
|---|---|
| Allow external apps to use Vortex | Starts/stops access for external local clients. Off by default. Agents inside Vortex already use their supported tools. |
| Confirm routine changes too | Controls whether routine changes made by external MCP clients ask for confirmation. When off, authorized routine scoped changes can run directly. SQL, shell and FTP root-path guards still apply; this switch does not turn them off. |
| Server status / Refresh MCP status | Shows current endpoint/running/error state and re-reads it. |
| Active tools / Modules / Clients | Counts the exposed capabilities and detected clients. These are not token balances. |
| Exposed modules switches | Controls which groups of tools external clients can discover/call. Clients may need to refresh their tool list. |
| Client setup controls | Configures a supported external client to connect to Vortex. Inspect the exact target before applying a configuration. |
| Connection URL / Copy | Copies the endpoint for manual setup. |
| Show / Hide / Copy auth token | Displays or copies the credential for this connection. Hiding it affects display only. |
| Saved approvals / Ask again for a tool | Removes a remembered approval so the relevant tool asks again. It does not undo previous calls. |
| Activity / audit entries | Displays available call evidence, tool names and client information. Inspect it when a request appears to affect the wrong resource. |
Open a saved resource using its actual returned ID, then try a read through the client. If a tool is absent, check the module switch and client discovery before changing credentials. See agent permissions.