Key facts
| Tool transports | Typed function calls or Model Context Protocol servers |
| Local capabilities | Filesystem, database, CLI, browser and internal APIs |
| Isolation | Sandboxed processes with scoped credentials and no ambient secrets |
| Hybrid pattern | Keep sensitive data local and send only necessary context to the model |
| Egress | Restrict outbound network access from tool processes |
| MCP | Open protocol for exposing tools and resources to models |
| Status | Function calling is live; file and batch endpoints are coming soon |
| Models | 30+ models behind one API, cloud or on-prem endpoints |
TL;DR
- Local tools give agents real capability on your machine and network.
- Expose them as typed functions or MCP servers with clear descriptions.
- Sandbox execution: scoped credentials, no ambient secrets, limited egress.
- Use hybrid routing so sensitive data never leaves your boundary unnecessarily.
- Log every local action; local execution is where blast radius grows.
How it works, step by step
- List the local resources the agent genuinely needs: files, databases, CLIs or services.
- Choose typed function definitions for your own code or MCP for reusable, standard tools.
- Run tools in a sandbox with a scoped identity and no inherited environment secrets.
- Limit filesystem paths, database rows and network egress to what the task requires.
- Decide per workflow what data must stay local and what context the model needs.
- Return compact, structured tool results and log arguments and outcomes.
- Test with malicious inputs, especially files and web content the agent may read.
Try it yourself
Open the MCP server config generator →
What local tools unlock
Cloud-only agents are limited to what an API exposes. Local tools connect the model to the environment where work actually happens: reading project files, querying an internal database, running a build, driving a browser or calling a service on a private network. For developer tooling, operations and data work, that is the difference between an assistant and a colleague.
The trade-off is trust. A local tool runs with real privileges on a real machine, so the design question is not whether to allow local tools but how to bound them: which paths, which tables, which commands, which network destinations, and with what identity.
MCP versus typed functions
Typed function definitions are the simplest path for tools you own: define the schema, implement the handler, validate arguments and execute. Model Context Protocol is useful when you want reusable tool servers that multiple agents and clients can share, or when the tools already exist in the MCP ecosystem.
- Typed functions: maximum control, minimal dependencies, best for bespoke internal actions.
- MCP servers: standard interface, reusable across clients, good for common resources.
- Both: fine. Keep one registry so permissions and audit are consistent regardless of transport.
Whichever transport you use, the permission checks, argument validation and logging belong in one place, not scattered across tool implementations.
Security for local execution
The threat model on a local machine is different: an agent that can read files can read secrets, and one that can run shell commands can do almost anything. Sandbox the process, drop privileges, mount only the directories the task needs, remove credentials from the environment, and restrict egress to an allowlist.
Assume any content the agent reads may try to steer it — project files, downloaded pages, database rows. Keep instructions and data separated, enforce permissions outside the model, and log every local call. On Plugsky, function calling is live, so a cloud model can drive locally executed tools while sensitive data stays on your infrastructure; deployment can also move on-prem or air-gapped. 30+ models are available on one API key, with plans on the live pricing page.
Honest comparison
| Concern | Naive local tools | Sandboxed local tools | Cloud-only tools |
|---|---|---|---|
| Filesystem access | Whole disk | Explicit paths only | None |
| Credentials | Inherited from environment | Scoped, injected per call | Provider-managed |
| Network | Full egress | Allowlisted destinations | Provider-managed |
| Blast radius | Whole machine | Task-scoped process | Vendor boundary |
| Data location | Stays local | Stays local | Leaves your network |
Frequently asked questions
What is MCP?
The Model Context Protocol is an open standard for exposing tools and resources to models through a common interface, so clients and agents can reuse tool servers instead of bespoke integrations.
Can an agent run shell commands?
It can, inside a sandbox with a scoped identity, an allowlist of commands, no ambient credentials and a hard timeout. Never give an agent unrestricted shell access on a production host.
How do I keep sensitive data local?
Route the model call to an endpoint in your network where the data resides, or pre-process locally and send only the minimum context needed to the model.
Do local tools work with cloud models?
Yes. The model produces tool calls; execution happens wherever your tool process runs. That split is what makes hybrid local-cloud agents practical.
How do I stop prompt injection through local files?
Treat file and database content as untrusted data, never as instructions. Enforce permissions outside the model and validate every action at the tool boundary.
What belongs in a tool registry?
Tool name, owner, schema version, permission scope, risk tier and audit requirements, kept consistent across function and MCP transports.
Can this run air-gapped?
Yes. Plugsky supports on-prem and air-gapped deployment, so the model endpoint and local tools can both live inside an isolated network.