MCP, Agent Skills and sandboxes

An agent needs a tool, a way of working, and a safe place to execute. Those are three different things.

MCP, Agent Skills, and sandboxes are often discussed as if they compete for the same layer. They do not.

MCP connects the agent to capabilities. Agent Skills package reusable instructions and resources. A sandbox constrains what execution can touch.

You may need one of them. A serious agent workflow often needs all three.

The short version

Layer	The question it answers	Typical example
MCP	What external capability can the agent call?	Search a CRM, create a ticket, register a domain
Agent Skill	How should the agent perform this kind of task?	Follow a release checklist, format an audit report, reconcile an uncertain result
Sandbox	Where may code run, and what may it access?	Write only inside a workspace, block the network, hide credentials

The boundaries matter because each layer can look like the others from inside a chat.

The agent “uses a skill.” The skill invokes a script. The script calls a tool. The tool changes a remote system. The whole sequence appears as one action to the user, but the trust and failure model changes at every step.

MCP gives the agent a capability boundary

The Model Context Protocol gives hosts and servers a standard way to expose tools, resources, prompts, and related capabilities. A client can discover a server’s tools and call them using defined schemas rather than a custom integration for every service (MCP specification).

Think of MCP as the interface to an external capability.

An MCP server might expose:

search_tickets
create_invoice
deploy_service
check_domain_availability
register_domain

The tool contract should say what arguments the operation accepts and what it returns. Authentication identifies the caller and scopes access. The application still decides whether the proposed action is permitted.

MCP does not tell the agent the whole workflow unless the server’s tools and descriptions encode it. It does not make a team’s operating procedure reusable across unrelated clients. It also does not automatically isolate local code execution.

Those are different jobs.

Agent Skills package a way of working

Agent Skills are folders containing a required SKILL.md file and optional scripts, references, templates, and other resources. The open format is designed to load progressively: an agent first sees a skill’s name and description, then loads the full instructions when a task matches, and reads or runs additional resources as needed (Agent Skills overview).

Think of a skill as a portable operating procedure for the agent.

A release skill might tell the agent to:

Read the changelog and migration notes.
Run the repository’s test commands.
Compare generated API schemas.
Draft release notes using a template.
Stop if a breaking change lacks approval.

The skill may include a script that gathers commit metadata and a reference file with the organization’s release policy.

That is more useful than pasting the same instructions into every prompt. It is also inspectable and versionable. GitHub describes skills in similar terms: reusable folders of instructions, scripts, and resources that an agent loads for specialized tasks (GitHub Agent Skills documentation).

A skill is not necessarily a remote service. It may call MCP tools, built-in tools, local scripts, or no tools at all.

And a skill is not a security boundary.

Instructions can tell an agent not to read a directory. A sandbox can make the directory unreachable.

Skills can travel over MCP without becoming tools

The separation between MCP and Agent Skills does not mean they are disconnected.

The official io.modelcontextprotocol/skills extension, finalized in September 2026, defines how an MCP server can publish Agent Skills alongside its other capabilities. It adds skills/list and skills/get, while individual skill files are read as MCP resources. The extension leaves the skill format itself to the Agent Skills specification (Skills extension specification).

That solves a distribution problem. A server can ship detailed workflow guidance with the tools it exposes, and a compatible host can discover that guidance without a separate manual installation.

It does not turn the skill into a tool.

The tool still performs an operation. The skill still provides instructions and resources that influence how the agent works. MCP is the transport for both in this case, but their roles and trust models remain different.

The distinction becomes more important when the skill came from a remote server. The extension treats remote skill content as untrusted model input and a prompt-injection surface. It requires hosts to preserve the skill’s origin, prevent silent name shadowing, and avoid implicit host-side code execution or permission grants. An allowed-tools field from a remote skill is a request for access, not authority to receive it.

Support is also a compatibility question. The extension is final, but client and SDK adoption remains uneven. Test the clients you claim to support rather than assuming every MCP host can consume remotely served skills.

A sandbox constrains execution

A sandbox is an execution environment with enforced limits on files, network access, credentials, processes, or system capabilities.

Think of it as the boundary around what running code can affect.

Depending on the implementation, a sandbox may provide:

a dedicated temporary filesystem
read-only or read-write path rules
blocked or allowlisted network access
masked credentials
process and system-call restrictions
resource and time limits
isolation from the user’s machine or from other sessions

GitHub’s local sandbox documentation provides a concrete example. Its controls include filesystem permissions, network policy, credential handling, subprocess policy, and per-command exceptions. The same documentation is careful to describe local sandboxing as lighter-weight isolation than a separate virtual machine or container (GitHub local sandboxing).

That qualification matters. “Sandboxed” is not a universal strength rating.

When evaluating a sandbox, ask:

Is execution local or remote?
Is the whole agent isolated, or only child processes?
Which files are readable and writable?
Can code reach the public internet or private network?
How are credentials injected or withheld?
Are local MCP servers inside the same boundary?
Can a user or model bypass the policy?
What persists after the session ends?

A sandbox reduces the blast radius of code execution. It does not decide whether a remote API call is authorized, and it does not teach the agent how to perform the task correctly.

The same workflow can use all three

Consider an agent preparing and publishing a software release.

The Agent Skill contains the team’s release procedure, validation commands, changelog format, and stopping conditions.

The sandbox provides a checked-out repository, permits writes inside that workspace, blocks unrelated filesystem paths, and restricts outbound network access.

MCP servers provide access to the issue tracker, package registry, deployment service, and change-management system.

The flow might look like this:

User goal
  -> Agent Skill selects the release procedure
  -> Sandbox runs tests and generates artifacts
  -> MCP reads approved issues and deployment status
  -> Policy asks for release approval
  -> MCP publishes and records the release
  -> Skill formats the final report

Each layer has a different failure.

If MCP fails, the agent may lose access to an external capability or receive an uncertain remote result.

If the skill fails, the agent may follow the wrong sequence, omit a check, or format the output incorrectly.

If the sandbox fails, code may reach files, networks, or credentials outside its intended boundary.

Calling all three “tools” hides the part you need to debug.

MCP and sandboxes meet at local execution

The boundary becomes especially important with local MCP servers.

A remote MCP server runs in someone else’s environment. Your agent sends requests to it, and your controls focus on authentication, authorization, data handling, and the tool contract.

A local MCP server may be a process launched on the user’s machine. It can inherit the user’s filesystem access, environment variables, credentials, and network reach unless the host constrains it.

Some agent products place local MCP subprocesses inside their sandbox policy. Others do not. GitHub, for example, documents a configurable subprocess policy and notes that remote MCP servers are not sandboxed by the local sandbox because they do not run locally (GitHub sandbox configuration).

Do not assume that “the agent is sandboxed” automatically means every MCP server it can reach is sandboxed too.

Map the process boundary:

Agent host
├── Built-in file tools
├── Sandboxed shell process
│   └── Local MCP server A
├── Unsandboxed local MCP server B
└── Remote MCP server C

The diagram will differ by client. That is the point. You need the real one.

Skills can contain code, which changes their risk

A plain instruction file and a skill containing executable scripts are not the same supply-chain object.

The Agent Skills format explicitly allows optional scripts and other bundled resources (Agent Skills specification). That makes skills powerful. It also means installation and execution policy matter.

Before adopting a third-party skill, inspect:

the full SKILL.md, not only its name and description
bundled scripts and binary assets
referenced files and external URLs
commands it asks the agent to run
tools and credentials it expects
update and versioning behavior
whether its instructions can conflict with your policies

Run skill scripts with the least access they need. Pin or review updates. Keep credentials outside the skill folder. Treat generated commands and downloaded dependencies as code, not as harmless context.

A sandbox helps contain that code. It does not make unreviewed code trustworthy.

Tool access is not workflow authority

MCP can expose a delete_record tool. A skill can say when deletion belongs in the procedure. A sandbox can limit local execution.

None of those facts alone proves that this deletion is authorized.

For consequential actions, add an application policy check that binds:

the authenticated principal
the target resource
the proposed action
the approved constraints
the relevant time or workflow state

The policy should sit at or before the action boundary. Do not rely on a sentence in a skill as the only control. Do not rely on a sandbox to stop a permitted network call to a remote tool. Do not treat OAuth login as blanket approval for every tool covered by the token.

This separation is useful because controls remain valid when the model changes.

The skill can improve. The client can upgrade. The sandbox implementation can move from local to cloud. The business rule still evaluates the action itself.

Choose the layer by the problem

Use MCP when the problem is repeated integration with external tools or data.

Use an Agent Skill when the problem is repeated procedure, specialized knowledge, templates, or task-specific instructions.

Use a sandbox when the problem is limiting the effects of code and processes.

Some examples make the choice clearer.

Need	Best starting layer	Why
Let several clients query the same CRM	MCP	Standard external capability interface
Make every release follow the same checklist	Agent Skill	Reusable procedure and resources
Run an unknown repository’s test suite	Sandbox	Constrain filesystem, network, and process access
Generate a report from CRM data	Skill + MCP	Procedure plus external data access
Modify a repo and open an issue	Sandbox + MCP	Local execution plus remote action
Run a full release workflow	All three	Procedure, constrained execution, external systems

Do not add every layer by habit. A deterministic service-to-service job may need an API and ordinary code, not a language model, skill, and MCP server. A writing rubric may need only a skill. A local data transform may need a sandbox but no MCP.

Architecture gets better when each component has a named reason to exist.

Test the boundaries, not only the happy path

An end-to-end test should show which layer stopped the action.

Test at least these cases:

The skill activates for the intended task and stays inactive for unrelated work.
Required references and scripts are present at the expected version.
The sandbox denies an out-of-scope file write.
The sandbox blocks or controls an unapproved network destination.
MCP tool discovery returns the expected schema.
Missing scope produces a useful authorization path.
A dangerous tool requires the intended policy or user approval.
A remote timeout produces an uncertain result, not an automatic retry.
Logs connect the skill, local execution, MCP call, principal, and result.

The last test is easy to skip. It is also the one that makes incident review possible.

Three layers, three promises

MCP promises a common way to describe and call capabilities.

Agent Skills promise a portable way to package instructions and task resources.

Sandboxes promise enforced limits around execution.

Those promises complement one another, but they are not interchangeable.

The useful design question is not which one wins.

It is whether the agent knows how to work, can reach what it needs, and cannot reach what it does not.

Frequently asked questions

Can an Agent Skill replace an MCP server?

Only when the task does not need the server’s external capability. A skill can describe how to call an API or use a tool, but it is not itself a standard remote tool interface.

Does MCP run tools in a sandbox?

Not by definition. The host or execution platform decides how local processes run. Remote MCP servers run in their own environment and need their own security controls.

Is a SKILL.md file safe because it is only Markdown?

No. Its instructions can direct an agent to run commands or use tools, and a skill may bundle scripts and other resources. Review the complete package and constrain execution.

Do I need all three for every agent?

No. Choose each layer for a concrete requirement. Use all three when the workflow needs external capabilities, reusable procedure, and constrained execution.

MCP, Agent Skills and sandboxes: which problem does each solve?