Three ways to extend an agent: MCP servers, skills or plain CLIs

An agent can only do what it can reach. Three mechanisms now carry most of that reach: MCP servers, which expose typed tools over a protocol; skills, which package instructions and sometimes scripts that the agent loads when a task calls for them; and plain command-line tools, which the agent runs through a shell. Teams often argue about them as if they were competing standards. They are better understood as three answers to three different questions, and each one moves authority to a different place. This guide covers what each is, when it fits, what it does to permissions, and how to combine them without quietly widening what the agent may do.

Three mechanisms, three different things

MCP. The Model Context Protocol is an open protocol for connecting AI applications to external tools and data. A server declares tools, each with a name, a description and an input schema, and can also offer resources and prompt templates. A client, such as a coding agent or a desktop assistant, discovers those tools and calls them when the model asks. Servers run locally over standard input and output, or remotely over HTTP. The specification lives at modelcontextprotocol.io; for the concepts, start with what MCP is.

Skills. A skill is a folder containing a SKILL.md file: a short name and description at the top, instructions below, and optionally scripts, templates or reference files beside it. The agent keeps only the description in view until a task matches, then reads the rest. Skills carry know-how: how your team writes a database migration, the steps of a release, the structure of a weekly report. More in what agent skills are.

CLIs. A command-line tool is any program the agent can invoke through its shell tool: git, gh, kubectl, a cloud provider's CLI, jq, or your own scripts. The agent writes a command, reads the text output and chains tools together, much as a developer would.

A rough shorthand: MCP is an interface, a skill is a manual, and a CLI is a tool already lying on the bench.

When each one fits

Two practical costs shape the choice. The first is context. In many clients, every connected MCP server places its tool definitions in the model's context whether or not the task needs them; connect a dozen servers and the agent spends attention on descriptions it will never use. Skills are designed to load lazily. CLIs cost nothing until they are called, though the agent may need to read --help first. The second is output. MCP tools can return structured content; CLIs return text, which can be long and noisy. Flags such as --json and a limit on rows make CLI output far easier for a model to use.

Where authority lives in each case

This is the part teams skip. The mechanism you choose decides where the agent's permissions actually come from, and therefore where you have to restrict them.

• MCP: authority comes from the credentials the server holds and from the client's approval settings. A server running with an administrator token can do anything that token allows, however modest its tool descriptions sound. Descriptions are also input to the model, so a compromised or careless server can smuggle instructions into them. Remote servers add a network boundary and an authorization flow of their own; remote vs local MCP servers covers that trade-off.
• Skills: a skill grants nothing by itself. It is text. But it steers what the agent attempts, and any script bundled with it runs with whatever permissions the agent's shell already has. A community skill is instructions and code from a stranger; review it as you would a dependency, as described in reviewing community skills before you install them.
• CLIs: a CLI inherits the environment it runs in: logged-in sessions, cloud profiles, SSH keys, tokens in dotfiles. If your terminal is signed in to production, so is the agent. Command allowlists in the harness are the main control, and they are blunter than they look: permitting git also permits git push --force.

Combining them without widening authority

Real setups mix all three. These patterns hold up:

1. Skill plus CLI. The skill explains how to use a CLI: which subcommands only read, which flags are mandatory, what never to run. The harness allowlist enforces it. The skill describes the rule; the allowlist is the rule. Turning a CLI into an agent skill walks through the packaging.
2. Skill plus MCP. The skill sequences several MCP tools into a procedure, for example: read the ticket, search the docs, draft a reply, stop for review.
3. MCP in front of a CLI. When a CLI is too powerful to hand over, wrap a few of its operations as narrow MCP tools, such as deployment_status and list_releases, instead of granting the shell. The narrowing is the point.
4. One path per consequential action. If the same action is reachable through a CLI with your personal credentials and through an MCP tool with a scoped token, the weaker control is the one that counts. Close the extra path.

A small example of the first pattern. The skill:

---
name: release-notes
description: Draft release notes from merged pull requests. Use when asked to prepare notes for a release.
---
1. List merged pull requests since the last tag with
   gh pr list --state merged --json number,title,labels
2. Group them by label. Put unlabeled ones under Needs a label; do not guess.
3. Write the draft to RELEASE_NOTES.draft.md. Never create a tag or a release.

And the policy that actually enforces it, written as plain pseudo-configuration rather than any one tool's syntax:

allow: gh pr list, gh pr view, git log, git diff
ask:   git push, gh pr create
deny:  gh release create, gh repo delete

A decision sequence you can apply

1. Can a CLI you already trust do it, under a low-privilege profile? Start there, behind an allowlist.
2. Does the work need judgment or a house procedure? Write a short skill that points at existing tools instead of duplicating them.
3. Does it need per-user authorization, a shared service or strict argument checks? Use or build an MCP server, and begin with read-only tools.
4. Does the action send, delete, export, schedule or spend? Put a human decision in front of it, whichever mechanism carries it.

How GoCux handles tools, skills and MCP

GoCux draws the same lines. Its customer CLI keeps ownership of the tools and permissions on your own machine. MCP tools run inside your local compatible client; GoCux does not offer a hosted MCP endpoint, recommends beginning with read-only access, and treats a configured server as available rather than as approved for every task. The MCP quickstart shows the setup.

When GoCux picks the skills a work order needs, a skill still counts as instructions, never as a permission. If an agent proposes changes to its own instructions, the change is held for review before it takes effect. Seven classes of consequential action, including sending things out, deleting, exporting data and putting another agent to work, wait for a decision from someone on the team. The agent skills docs and the note on connecting tools without widening authority go into detail.

Checklist before you give an agent a new capability

• You know which credential each path uses, and it is the narrowest one that works.
• Read-only tools come first; write tools are added one at a time, on purpose.
• Community skills and MCP servers are reviewed like dependencies, with versions pinned.
• Every rule a skill describes is also enforced by an allowlist or an approval setting.
• Each consequential action has exactly one path, and that path waits for a decision.
• Logs show which tool ran, with which arguments, on whose behalf.
• Tool descriptions, skill text and command output are treated as input that can be wrong or hostile.