MCP, skills or CLI? Put the safety boundary where the model cannot ignore it

An AI agent needed to inspect a production database on an IZZY project. We had two practical routes.

One was a skill-guided CLI workflow. It was convenient and loaded its detailed instructions only when needed. But in that environment, the shell, database program and available credentials created a broad execution path that included mutation-capable operations.

The other was an MCP server exposing a small set of read methods. It added tool definitions and infrastructure, but it gave the model fewer actions to call. We chose the constrained MCP route and added agent-harness hooks that rejected mutating actions on that path.

The lesson was not that MCP is secure and CLI is dangerous. It was more useful:

For production or hard-to-recover systems, pay for a smaller mechanically available capability surface. For disposable or easily restored state, optimise for simplicity.

The safety boundary should sit where the model cannot decide to ignore it.

Answer in 60 seconds

MCP, skills and CLI are not equivalent alternatives.

• MCP is a protocol through which a server can expose named tools with described inputs and outputs. A deliberately narrow server can make only a small set of operations available through that route.
• An agent skill is an on-demand package of instructions and resources. It can teach an agent when and how to use a tool, but the prose in the skill is not, by itself, an enforced permission boundary.
• A CLI or direct connection is an execution route. Its real authority depends on the programs, network, filesystem, credentials and downstream permissions reachable from the agent environment.
• Hooks and policy checks in the agent harness can reject operations deterministically before execution. They strengthen a route, but only the route they actually intercept.

Use a skill plus CLI when the state is local, disposable or reliably recoverable and the simpler workflow is worth the broader surface. Use a narrow MCP server or another constrained API when the agent touches production data, customer systems or actions whose failure is expensive.

Often the best design is hybrid: the skill explains the procedure; the constrained tool performs the action.

In this article

1. MCP, skills and CLI solve different layers
2. The production database decision
3. The same choice appears in every operational tool
4. What each route is genuinely good at
5. Do not choose on context cost alone
6. Choose by consequence and recoverability
7. Map the complete capability path
8. Build the boundary so it fails closed

1. MCP, skills and CLI solve different layers

The comparison becomes confusing when all three are treated as interchangeable tool formats.

They sit at different points in the system:

The current MCP tools specification defines discoverable tools with names, descriptions and JSON schemas. It also requires servers to validate inputs and implement access controls. The protocol gives a server a structured way to expose capabilities; it does not make every MCP server least-privileged by default.

The Agent Skills implementation guide uses progressive disclosure. The model sees skill names and descriptions at session start, loads the full SKILL.md when a skill is activated and loads referenced resources as needed. That can make skills economical for specialised procedures. It does not convert an instruction such as “never run DELETE” into a permission the runtime must obey.

A skill can invoke a carefully sandboxed script. An MCP server can expose an unrestricted shell. A CLI can run with a read-only identity. The label does not settle the risk; the complete path does.

2. The production database decision

The IZZY project did not begin as an abstract protocol evaluation. The task was to let an agent retrieve information from a production database without giving that agent a convenient way to change the data.

Route A: skill plus CLI

The skill could have described the approved workflow:

1. inspect the schema;
2. generate a read query;
3. run it with the database CLI;
4. format the result;
5. never insert, update, delete or alter anything.

That was simple and context-efficient. The detailed procedure would load only when relevant.

But the actual environment still gave the agent a shell path to a database program with broader capabilities. “Never mutate data” would have remained an instruction inside the same decision-making system that generated the command. If the model misunderstood the task, followed malicious retrieved content or simply chose an unexpected command, the instruction was not the final authority.

Route B: constrained MCP tools plus harness hooks

The selected route exposed concrete read methods. No generic SQL executor or shell escape hatch was presented through that MCP surface. Hooks in the agent harness inspected the configured path and rejected mutating actions before execution.

Credentials were kept in .env rather than placed in chat, prompts or normal tool arguments and results. This reduced unnecessary model exposure, but it was not treated as magic isolation. If an agent can read arbitrary files, inspect process environments, invoke an unrestricted shell or reach verbose logs, an environment variable may still be accessible. OWASP notes that environment variables can be visible to processes and may appear in logs or system dumps.

The useful distinction looked like this:

This is one first-hand project decision, not a benchmark or proof that every MCP implementation is safer. The public account does not specify the database-native role configuration. A robust production design should still minimise the downstream identity, because MCP methods and harness hooks are defence-in-depth around that authority, not replacements for it.

The choice reduced the model’s mutation capability through the configured agent path. It did not make the database safe against every other client, credential, bug or administrator.

3. The same choice appears in every operational tool

The database makes the contrast easy to see, but the architecture question is generic:

Is the agent receiving a small set of purpose-built capabilities, or a general execution surface accompanied by instructions?

“Read” is not automatically low-risk. A read capability may expose confidential data, cross tenant boundaries, return more rows than needed or run an expensive query. But separating observation from mutation removes one class of consequence and gives the remaining risks a clearer shape.

This is why OWASP’s AI Agent Security Cheat Sheet recommends minimum tools, per-tool permission scoping and explicit authorisation for sensitive operations. It also warns against unrestricted wildcard access and relying solely on model output for authorisation decisions.

4. What each route is genuinely good at

There is no useful universal winner. Each route buys something different.

MCP: a declared and reusable tool contract

A well-designed MCP server can provide:

• a small list of named operations;
• structured input schemas and, where useful, structured outputs;
• one place to validate parameters and filter results;
• consistent logging and error handling;
• portability across clients that support the protocol;
• remote authorisation flows when the deployment needs them.

Those benefits make MCP attractive when several agents or clients need the same controlled capability. The server becomes a maintained product boundary rather than a prompt convention.

The costs are real:

• another component to build, deploy, patch and observe;
• authentication, network and lifecycle complexity;
• tool metadata that may consume model context, depending on the client and how it presents tools;
• a new high-value service if it aggregates access;
• false confidence if a “read” tool accepts arbitrary expressions, the handler is flawed or another broad tool bypasses it.

MCP’s HTTP authorisation specification is optional and transport-specific; stdio implementations normally retrieve credentials from their environment. OAuth support is not proof that the downstream resource, action and data scope is correct.

Skills plus CLI: low-friction procedure over existing tools

A skill-guided CLI route is often the fastest way to reuse a mature toolchain. It can provide:

• on-demand instructions rather than a large always-active procedure;
• familiar commands engineers can reproduce outside the agent;
• easy composition of local utilities;
• minimal integration code;
• a strong fit for temporary, local and developer-owned work.

The central limitation is not that “a CLI can do everything”. Many CLIs are narrow, and every CLI only does what its program and identity allow. The problem appears when the agent also has a general shell, mutation-capable programs, broad credentials and a network path to valuable systems.

In that situation, the skill describes the safe route while the environment still contains unsafe alternatives. The runtime needs another boundary: sandboxing, command allowlists, a proxy, restricted credentials, harness hooks or a purpose-built wrapper.

Direct access: a path, not a control model

“Direct” can mean a native database driver, a cloud SDK, an HTTP API or a CLI talking to the target without an MCP broker. It can still be carefully constrained. A direct database connection using a purpose-specific read identity and an isolated worker may be safer than a badly designed MCP server exposing arbitrary SQL.

The architecture review should therefore ask what direct access bypasses. Does it bypass central validation, result filtering, attribution or revocation? Or does a downstream policy already enforce those controls adequately?

Hooks: useful enforcement with a precise scope

Hooks in an agent harness can reject a tool call, command or parameter pattern before execution. Unlike a prose instruction, a deterministic hook does not need the model to agree.

But a hook is only as strong as its interception point. If the agent can reach the same target through another shell, plugin, network client or credential, the hook is not the boundary for that alternative path. Hooks should fail closed, produce reviewable denials and be tested against bypasses - not merely the expected command syntax.

5. Do not choose on context cost alone

Context overhead matters. Tool names, descriptions and schemas have a cost, especially when a client exposes many of them to the model. Skills use progressive disclosure precisely to avoid loading every full procedure at startup.

But neither “MCP always bloats context” nor “CLI is always cheaper” is a reliable architecture rule.

The MCP protocol does not dictate one model-context strategy; implementations are free to present tools through different interface patterns. A client can filter tools, load them dynamically or route them through a smaller discovery layer. Conversely, a CLI workflow can spend substantial context and tokens reading help, recovering from errors and interpreting unstructured output.

A current controlled MCP-versus-CLI preprint found that cost comparisons were unstable across seven agent scaffoldings, five models and one software task. The scaffolding had the dominant effect. Because the study covers one task and is a preprint, it should not be generalised into a universal performance ranking.

Measure the route in your own harness on representative tasks:

• context added before the task begins;
• tool calls and retries;
• task completion verified in the target system;
• latency and compute cost;
• failed actions and their cost;
• engineering and operational overhead;
• the consequence of one boundary failure.

For a production database, we accepted context and infrastructure overhead because it bought a smaller exposed capability surface. For a local database that could be dropped and recreated, we would be much less interested in paying that cost.

6. Choose by consequence and recoverability

Start with the worst action the configured path can complete, not with the interface label.

The UK NCSC’s current agentic-AI cyber-risk guidance makes the same proportionality point at system level: more autonomy and greater potential impact require stronger controls. It explicitly advises against relying on prompting alone and asks operators to consider sandbox, network, credentials, data, monitoring and emergency shutdown together.

The choice can change as the workflow matures. A CLI may be the right route while proving a task on disposable state. Once the same workflow reaches production, multiple users or customer data, the smallest viable execution surface may justify a server or wrapper.

7. Map the complete capability path

Before choosing MCP, a skill or CLI, draw one path from user intent to business consequence.

We use an Agent Capability Path with seven fields:

The artefact is small enough for an architecture review and concrete enough to test. It also exposes false boundaries.

If “do not delete” appears only under Instruction layer, the deletion rule is advisory. If the credential can be read by the same unrestricted shell the hook is meant to control, the credential boundary is weak. If a read tool can return an entire customer table, the result boundary remains broad even though integrity is protected.

For continuing access, connect this decision to the wider AI-agent permission lifecycle. For consequential actions, use the capability-contract and product-control model. This article owns the path-selection decision; those guides own the ongoing access and autonomy controls around it. If the agent needs production-shaped data rather than live production access, snapshots, replicas and controlled retrieval can remove the question altogether.

8. Build the boundary so it fails closed

Once the path is visible, implement the smallest route that can complete the task.

1. Separate allowed, prohibited and approval-gated actions

Do not write “database access” or “manage the CMS”. Name operations: inspect these schemas, read these records, prepare this draft, publish this exact revision, or delete nothing.

2. Remove generic escape hatches from high-consequence paths

A server with three read methods plus execute_any_command is not a narrow surface. Look for shell tools, arbitrary code execution, generic SQL, unrestricted HTTP clients, filesystem traversal and inherited credentials that recreate the broader path.

3. Restrict the downstream identity too

The target system should reject authority the agent does not need. A narrow interface around a broad administrative credential creates avoidable single-layer dependence.

4. Keep secrets out of prompts, arguments, results and ordinary logs

Use the secret mechanism appropriate to the deployment, minimise which process can retrieve it, rotate it and test revocation. .env may be a practical local configuration method; it is not a substitute for process isolation or a managed secret boundary when consequences justify one.

5. Add deterministic validation outside the model

Validate tool names, parameters, resource scope, operation class, row or object limits and approval state. Harness hooks can reject disallowed calls; server handlers, proxies and downstream systems should enforce the rules closest to the consequence.

6. Constrain results as well as actions

Limit fields, records, time range, response size and sensitive values. Treat tool results and retrieved content as untrusted input before they re-enter model context.

7. Preserve attributable evidence

Record the requesting identity, agent version, attempted action, target, policy decision and result without recording credentials or unnecessary sensitive data. A model transcript alone is not a complete audit trail.

8. Test denials and bypasses

Attempt prohibited operations through alternate syntax and alternate available tools. Test malformed parameters, encoded commands, indirect requests, large outputs, retries, timeouts and a missing policy service. The safe failure state is a refusal, not silent fallback to the broad route.

9. Test the stop path

Know which server, token, process, network route, queued job and session must stop. Revocation is incomplete if the agent can continue through an inherited credential or another client.

Conclusion: the interface is not the safety boundary

MCP can expose a narrow capability surface. It can also expose an unrestricted one. A skill can make a complex CLI workflow efficient and repeatable. It cannot, through prose alone, remove commands and credentials from the agent’s environment.

Choose the architecture from the consequence backwards.

If state is disposable and recovery is trivial, skill plus CLI may be exactly right. If the agent reaches production or hard-to-recover systems, reduce what is mechanically callable, remove alternate routes and enforce the same decision at more than one layer.

The practical hybrid is often the strongest: use a skill to load the right procedure when needed, and a narrow MCP tool or service to execute only the capabilities that procedure is allowed to request.

Frequently asked questions

Sources, method and limitations

Primary technical and official sources checked on 28 August 2026:

• Model Context Protocol: tools
• Model Context Protocol: authorisation
• Agent Skills: adding skills support
• Agent Skills specification
• OWASP AI Agent Security Cheat Sheet
• OWASP Secrets Management Cheat Sheet
• UK NCSC: managing the cyber risk of agentic AI
• Alier Forment et al.: controlled MCP/CLI comparison, preprint

The production-database example is a de-identified first-hand IZZY project account. No client outcome, incident or comparative performance result is claimed. The public account does not specify the database-native role configuration.

Current practitioner comparisons were used only to test crowding and terminology, not as neutral proof of security or demand. No search-volume estimate was available, and no universal token, latency or success-rate conclusion is made.

This article provides general product and engineering guidance. It is not a penetration test, database-security review, compliance assessment or legal opinion. Production credentials, personal or confidential data, write access and high-impact actions require review against the actual architecture by appropriately qualified owners.