{"slug": "when-you-need-an-mcp-server-and-when-you-don-t", "title": "When You Need an MCP Server and When You Don't", "summary": "A new engineering paper argues that not every missing agent capability requires a Model Context Protocol (MCP) server, proposing a 'minimum sufficient integration principle' that favors the least complex mechanism—such as persistent instructions, Agent Skills, existing CLIs, or MCP servers—based on required capability, reliability, security, portability, and control. The paper notes MCP servers are justified for reusable access to live data or controlled actions across a protocol boundary, while skills suffice for repeatable workflows using existing tools, and warns that both MCP and skills carry security and operational risks.", "body_md": "Disclosure: These views are my own and do not represent my current or any former employers.\n\n## Executive summary\n\nNot every missing agent capability is a protocol problem.\n\nModel Context Protocol (MCP) has become a common answer to a growing number of agent integration questions. When an assistant must query a database, read a design file, create an issue, inspect an incident, or call an internal API, the proposal often arrives quickly: build an MCP server.\n\nAgent Skills offer another route for release procedures, reports, repository reviews, and domain standards. Teams package the required knowledge as a skill.\n\nBoth are useful in the right place, while many tasks need neither.\n\nMCP is a protocol for exchanging context and exposing structured capabilities. An MCP server can provide tools, resources, and prompts to an AI application. It creates a client-server boundary with discovery, schemas, transport, authorisation, and an operational lifecycle.[1][2]\n\nAn Agent Skill is a directory containing instructions and optional scripts, references, templates, and other resources. Skills package procedural knowledge and load when an agent decides they are relevant. They can guide an agent to use existing tools, run bundled code, or combine several capabilities into a repeatable workflow.[4][5]\n\nSkills can include executable code, and MCP servers can provide prompt templates. Action versus instruction is therefore an unreliable dividing line. The useful distinction is where the capability lives, how it is shared, and where control is enforced.\n\nThis paper proposes a minimum sufficient integration principle:\n\nUse the least complex mechanism that provides the required capability, reliability, security, portability, and control.\n\nThat mechanism may be:\n\n- a persistent instruction for a rule that applies broadly;\n- a skill for a repeatable workflow using capabilities the agent already has;\n- an existing CLI, library, native connector, or small script;\n- an MCP server for reusable access to live data or controlled actions across an explicit protocol boundary.\n\nAn MCP server is usually justified when the agent needs current information or actions from an external system and the interface will be reused across hosts or teams. Structured discovery and typed inputs can improve safety or usability, while a named production owner operates the service and its credential, permission, validation, and audit controls.\n\nA skill is usually sufficient when the missing element is procedure. The agent already has the tools it needs, but it needs domain instructions, examples, templates, scripts, or a reliable order of operations. A skill can capture how an organisation reviews a pull request, prepares an incident brief, checks a release, or produces a standard artifact without introducing a new service.\n\nAn existing tool is often the better answer when the operation already has a\nmature interface. Teaching an agent to use `git`\n\n, `kubectl`\n\n, a vendor CLI, or a\nwell-supported native connector may create less risk than wrapping each command\nin another protocol layer.\n\nMCP also carries a tax. A server introduces availability, latency, authentication, authorisation, schema design, version compatibility, observability, incident response, and supply-chain concerns. Official MCP security guidance covers confused-deputy attacks, token audience validation, forbidden token passthrough, redirect handling, and server-side request forgery.[11][12] Research has also shown that tool descriptions can affect agent performance and that malicious tool metadata can influence agent behaviour.[13][14]\n\nSkills carry a smaller infrastructure burden, but they are not risk free. A skill may contain stale instructions, hidden dependencies, scripts with broad permissions, or malicious content. GitHub and Anthropic both advise users to inspect skills and install them only from trusted sources.[5][8]\n\nThe practical decision is whether the proposed mechanism places capability, knowledge, and control in the right layer without creating an unnecessary system to operate.\n\n## 1. The category mistake\n\nMCP and Agent Skills are often discussed as competing ways to extend an agent. That comparison is attractive because both can make an assistant appear more capable, but it conflates separate layers.\n\nMCP defines communication between an AI application and a server. The current architecture uses a host, a client connection for each server, JSON-RPC messages, capability discovery, and local or remote transports. Servers can expose tools for actions, resources for context, and prompts for reusable interaction templates.[1][2]\n\nAgent Skills package material an agent can load from a filesystem or managed\nenvironment. The open specification requires a `SKILL.md`\n\nfile with a name,\ndescription, and instructions. A skill may also include executable scripts,\nreference material, and assets. Implementations use progressive disclosure:\nlightweight metadata is available for discovery, while detailed instructions\nand resources load only when needed.[4][5]\n\nMCP primarily creates an interface boundary, while a skill packages knowledge and workflow.\n\nThe mechanisms overlap without becoming interchangeable. An MCP server may provide a prompt that teaches a user how to invoke its tools. A skill may include a script that calls an external API or direct an agent to tools supplied by several MCP servers. GitHub's own documentation demonstrates this pattern with a skill that guides Copilot through GitHub Actions investigation using GitHub MCP tools.[8]\n\nConsider a production release:\n\n- a repository instruction states that production history must never be rewritten;\n- a skill describes the organisation's release checklist, evidence, and rollback expectations;\n`git`\n\nand the build system perform local deterministic operations;- a native GitHub integration or MCP server reads pull requests and workflow results;\n- a deployment service enforces environment permissions and records the release.\n\nDescribing the entire arrangement as either an MCP integration or a skill hides the design decisions that matter.\n\nThe first task is to identify the missing layer. Does the agent lack a rule, a procedure, an executable capability, access to current external state, or an enforced control boundary? The answer determines the appropriate mechanism.\n\n## 2. Four ways to extend an agent\n\nA useful design starts with four choices rather than a binary comparison.\n\n| Mechanism | What it provides | Typical scope | What it does not provide by itself |\n|---|---|---|---|\n| Instructions | Persistent rules and background context | Repository, workspace, user, or organisation | A new executable capability or live external data |\n| Agent Skill | On-demand procedure, examples, scripts, templates, and references | A repeatable task or domain | A server-enforced authorisation boundary |\n| Native tool, CLI, library, or script | Direct execution of an existing capability | Local environment or product integration | Cross-client discovery and a standard agent protocol |\n| MCP server | Discoverable tools, resources, and prompts over a client-server protocol | Reusable local or remote integration | A correct workflow, trustworthy implementation, or complete security model |\n\n### Instructions\n\nInstructions are appropriate when guidance applies to most or all tasks in a scope. Coding conventions, required tests, prohibited operations, repository structure, and writing preferences belong here.\n\nGitHub distinguishes this from skills directly. Its documentation recommends custom instructions for simple guidance relevant to almost every task and skills for detailed guidance that should load only when relevant.[8]\n\nAn instruction should not become a skill merely because a skill directory is available. If every task needs the same rule, on-demand discovery adds little.\n\n### Agent Skills\n\nA skill is appropriate when a recognisable task benefits from a reusable playbook. It can contain:\n\n- steps and decision points;\n- examples of good and bad outputs;\n- templates and schemas;\n- domain references;\n- validation scripts;\n- deterministic transformation code;\n- guidance for using existing tools.\n\nThe skill does not have to be passive. Anthropic, GitHub, and the Agent Skills specification all describe skills that include executable scripts.[4][5][8] The important question is what authority those scripts use. In most implementations, they inherit the execution environment and permissions made available by the host. The skill itself is not an independent authorisation service.\n\n### Native tools, CLIs, libraries, and small scripts\n\nAgents increasingly operate in environments that already contain capable tools. A shell, filesystem API, browser driver, cloud CLI, database client, or software library may already expose the required operation.\n\nUsing that interface directly has advantages:\n\n- operators already understand it;\n- documentation and troubleshooting practices exist;\n- authentication may already be configured;\n- scripts can be tested without an agent;\n- no additional service must be deployed;\n- failure behaviour is often familiar.\n\nA skill can teach the agent how to use the tool safely. This combination is frequently sufficient.\n\n### MCP servers\n\nAn MCP server is appropriate when a capability benefits from a standard, discoverable interface for AI clients. Tools define inputs and outputs, resources expose addressable data, and prompts offer parameterised templates. Servers may run locally over standard input and output or remotely over Streamable HTTP.[1][2]\n\nOpenAI describes the boundary plainly: an MCP server is optional, and an integration that only provides instructions and resources can consist of skills alone. It recommends MCP when a plugin must read live information, take actions, or integrate with another service.[3]\n\nThat is a useful starting point, but live access alone does not automatically justify a custom server. A supported native connector or existing CLI may already provide the capability with less operational cost.\n\n## 3. When a skill is enough\n\nA skill is usually enough when the agent can already reach everything required to complete the task.\n\nThe missing capability is procedural. The agent needs to know:\n\n- which sources to inspect;\n- which sequence to follow;\n- what evidence to preserve;\n- which checks are mandatory;\n- how to handle common exceptions;\n- what the final artifact should contain.\n\nExamples include:\n\n- reviewing a pull request against organisation-specific reliability rules;\n- preparing an incident brief from logs and records already available in the environment;\n- converting a document with an installed library;\n- applying a house style to technical writing;\n- following a repository's release and rollback process;\n- generating a standard architecture decision record;\n- checking that a migration includes required safety evidence.\n\nA practical test is to remove the skill mentally. Could a competent operator still complete the task using tools already present in the environment? If the answer is yes, and the recurring problem is consistency or domain knowledge, a skill is a strong candidate.\n\nSkills are also useful when content should evolve with a repository. A repository skill can be versioned, reviewed, tested, and changed alongside the system it describes. This is valuable for procedures that differ between projects.\n\nProgressive disclosure is another advantage. Agent Skills implementations typically load a small name and description for discovery, then load the full instructions and supporting material only when activated.[4][5][9] A large operational handbook does not need to occupy the context window for an unrelated task.\n\nProgressive disclosure does not change the control boundary. Approval, environment, and recipient rules may all appear in a skill, but only an external system can record approval, reject production access, or constrain which recipients an API accepts.\n\nUse a skill to teach a workflow. Do not use instructions as a substitute for a control that must survive model error, prompt injection, or deliberate misuse.\n\n## 4. When an MCP server is justified\n\nAn MCP server becomes useful when the integration needs an explicit capability boundary rather than another set of instructions.\n\n### The agent needs current external state\n\nStatic references cannot answer questions whose truth changes continuously. Incident status, customer records, deployment state, current issues, calendar availability, inventory, and service health require live retrieval.\n\nAn MCP resource or tool can expose that state through a documented interface. This can be more reliable than teaching an agent to scrape a web page or parse human-oriented command output.\n\n### The agent needs controlled external actions\n\nCreating an issue, updating a record, sending a message, scheduling an event, or initiating a workflow requires authority outside the local agent environment.\n\nAn MCP server can validate inputs, map the caller to permissions, apply business rules, limit scope, and produce an audit record. These controls are valuable only if implemented by the server or downstream system. The protocol does not create them automatically.\n\n### Multiple hosts need the same capability\n\nThe value of a standard interface grows when several clients need the same integration. A remote MCP server can provide a common surface to Copilot, Claude, Codex, Gemini, or internal agent hosts where those products support the required protocol features.\n\nWithout a common boundary, each host may acquire a separate script, plugin, or credential flow. MCP can reduce that duplication.\n\nCross-client reuse should be demonstrated rather than assumed. Hosts differ in transport support, approval interfaces, extensions, resource handling, and enterprise policy. A protocol-compatible server is not automatically behaviourally identical in every host.\n\n### Discovery and schemas materially improve use\n\nMCP tools publish names, descriptions, and input schemas. Clients can discover available capabilities and models can form structured calls.[1][2]\n\nSchema and discovery features help when:\n\n- the capability set changes;\n- arguments require validation;\n- natural-language shell construction is unsafe;\n- several related operations need consistent naming;\n- results benefit from structured content;\n- client developers should not maintain custom adapters.\n\nTyped input validates shape rather than intent. A perfectly valid request can still target the wrong account, environment, or record, so server validation must include domain rules where consequences matter.\n\n### Credentials and policy belong outside the agent\n\nA server can hold or obtain credentials without placing them in skill files or prompts. It can enforce token audience, scopes, rate limits, tenant boundaries, and action policy.\n\nThe current MCP authorisation specification requires servers to validate that tokens were issued for them and forbids passing an inbound client token directly to an upstream service.[12] This is an architectural responsibility, not a configuration detail.\n\n### A production owner exists\n\nAn MCP server is software infrastructure. Someone must own:\n\n- availability and latency;\n- authentication and authorisation;\n- schema and version changes;\n- dependency upgrades;\n- logs, metrics, and traces;\n- abuse controls and rate limits;\n- incident response;\n- data retention and privacy;\n- deprecation and client migration.\n\nWithout such ownership, the proposed server becomes an unmanaged dependency rather than a finished integration.\n\n## 5. When neither MCP nor a skill is the right answer\n\nThe availability of extension mechanisms does not make ordinary engineering obsolete.\n\n### Use the existing CLI\n\nIf an agent already has shell access and the official CLI is mature, a new MCP wrapper may only duplicate commands and error handling.\n\n`git status`\n\n, a targeted test command, a cloud deployment query, or a package\nmanager operation may be clearer through the established interface. A short\nskill can describe the safe workflow if the sequence is specialised.\n\nBuild an MCP wrapper when it adds something material, such as safer typed arguments, restricted operations, shared remote access, central authorisation, or results designed for agent consumption. Protocol conversion alone creates no value.\n\n### Use a library\n\nDeterministic application logic should normally remain deterministic code. If a service needs to validate a schema, transform a file, calculate a checksum, or apply a business rule, a library may be the correct abstraction.\n\nMaking every function an agent-discoverable tool can reduce reliability by moving ordinary control flow into model choice.\n\n### Use a small script\n\nA local script is often sufficient for a narrow transformation or report. It can be tested directly, committed with the project, and invoked by a person, automation, or a skill.\n\nIf the script later needs cross-client discovery, remote execution, separate credentials, and a stable service contract, it may become a candidate for MCP. Starting with a script preserves that option without paying the server cost on day one.\n\n### Use a native integration\n\nMany agent products provide built-in tools or supported connectors. These may offer better consent, identity, user interface, and support than a custom MCP server.\n\nThe decision should compare the proposed server with the best existing integration, not with no integration at all.\n\n### Use an ordinary user interface\n\nSome workflows remain easier and safer through a purpose-built interface. High-stakes actions may require forms, previews, comparison views, or specialist review that a conversational tool call does not present well.\n\nAn agent can prepare the information without becoming the execution path.\n\n## 6. The integration tax\n\nEvery extension creates work, so the smallest adequate mechanism deserves preference.\n\n### The MCP tax\n\nAn MCP server introduces several forms of cost.\n\nOperational cost includes deployment, process lifecycle, network access, capacity, timeouts, retries, dependency failures, and on-call ownership. A remote server becomes part of the availability path for every workflow that depends on it.\n\nInterface cost includes tool naming, descriptions, schemas, output design, version compatibility, error contracts, and deprecation. These details affect model behaviour and belong to the operational interface.\n\nHasan and colleagues examined 856 tools across 103 MCP servers and reported that 97.1% of tool descriptions contained at least one issue under their rubric. Improving descriptions increased median task success in their experiments, but also increased execution steps and caused regressions in some cases.[13] These findings place tool metadata inside the operational interface, where it needs testing and evaluation rather than a single assumed template.\n\nSecurity cost includes server provenance, package dependencies, credentials, OAuth flows, token storage, scopes, tenant separation, outbound network access, and tool-result handling.\n\nOfficial MCP guidance documents confused-deputy risks, token passthrough, server-side request forgery, redirect validation, and consent requirements. [11][12] The official registry verifies namespace ownership and hosts metadata, but delegates package scanning to underlying registries and downstream aggregators. A registry entry is not a security assessment of the server code.[15]\n\nResearch on tool poisoning adds another concern. The MCPTox benchmark used 45 live servers and 353 tools to construct malicious metadata cases across 20 agent settings. It found substantial susceptibility in the tested systems. [14] This was a benchmark, not a measured production incident rate. It still shows why tool names, descriptions, schemas, and updates must be treated as untrusted supply-chain input.\n\nGovernance cost includes deciding which servers are approved, who may install them, how permissions are reviewed, how definitions are pinned or updated, and how tool calls are audited. GitHub notes that enterprise MCP use can be controlled by policy and recommends OAuth, minimum permissions, connection review, and activity monitoring.[10]\n\n### The skill tax\n\nSkills avoid much of the service lifecycle, but they introduce other risks.\n\nSkill discovery depends on names and descriptions, so vague or overlapping triggers can load the wrong procedure. Instructions may also become stale as the underlying system changes, and client implementations can interpret the same skill differently.\n\nBundled scripts inherit the host's available permissions and dependency risks. Reference material can contain prompt injection, while network instructions may direct an agent to an untrusted destination.\n\nGitHub warns that community skills are not verified and may contain malicious scripts or hidden instructions. It specifically warns against pre-approving shell access without reviewing the skill and its referenced files.[8] Anthropic similarly recommends installing skills only from trusted sources and auditing bundled code, dependencies, resources, and network instructions.[5]\n\nA skill therefore needs:\n\n- a named maintainer;\n- a reviewed source;\n- version control or pinned provenance;\n- tests against representative tasks;\n- clear required tools and permissions;\n- a process for updating procedures;\n- safe failure behaviour;\n- removal when the workflow no longer applies.\n\nThe skill tax is usually smaller than the MCP tax, but it still requires ownership and review.\n\n## 7. A decision framework\n\nThe following sequence helps identify the minimum sufficient integration.\n\n### Step 1: Is the requirement a broad rule?\n\nIf the guidance should apply to nearly every task in a repository or organisation, use instructions.\n\nExamples include coding standards, prohibited operations, required disclosure, or the location of key documentation.\n\n### Step 2: Does the required capability already exist?\n\nCheck the host's built-in tools, approved connectors, installed CLIs, libraries, and APIs.\n\nIf the agent can already perform the operation safely, do not build a new server merely to rename it.\n\n### Step 3: Is the missing element a repeatable procedure?\n\nIf the challenge is sequence, context, examples, templates, or domain judgement, use a skill.\n\nThe skill may call existing tools, including MCP tools.\n\n### Step 4: Does the workflow require live external state or action?\n\nPrefer a supported native integration where it meets the need. If none exists, compare a direct script or API client with an MCP server.\n\n### Step 5: Is a protocol boundary materially valuable?\n\nMCP becomes a stronger choice when the answer to several of these questions is yes:\n\n- Will more than one host or team use the capability?\n- Do clients need to discover changing tools or resources?\n- Will typed schemas prevent meaningful classes of error?\n- Must credentials remain behind a service boundary?\n- Must authorisation, tenant scope, or policy be enforced centrally?\n- Does the capability need a stable remote endpoint?\n- Is an auditable tool call preferable to free-form shell construction?\n\n### Step 6: Can the organisation operate it?\n\nIdentify the owner, service-level expectations, monitoring, support path, security review, upgrade process, and retirement plan.\n\nIf these do not exist, choose a smaller mechanism or delay deployment.\n\n### Step 7: Where must correctness be enforced?\n\nInstructions and skills influence model behaviour. They are useful controls, but they are not deterministic security boundaries.\n\nEnforce permissions, irreversible-action checks, spending limits, recipient restrictions, and regulated policy in code or downstream services.\n\nThe decision matrix below summarises the usual fit.\n\n| Requirement | Instructions | Skill | Native tool or script | MCP server |\n|---|---|---|---|---|\n| Rule applies to most tasks | Strong | Weak | None | None |\n| Repeatable domain workflow | Limited | Strong | Supporting role | Supporting role |\n| Deterministic local transformation | Weak | Orchestrates | Strong | Usually unnecessary |\n| Live external data | None | Orchestrates | Strong for narrow use | Strong for reusable integration |\n| External write action | None | Orchestrates | Strong for narrow use | Strong when governed and shared |\n| Cross-host discovery | None | Partial and implementation-dependent | Weak | Strong |\n| Central credential boundary | None | None by itself | Possible | Strong when implemented correctly |\n| Server-side authorisation and audit | None | None by itself | Possible | Strong when implemented correctly |\n| Lowest operational burden | Strong | Strong | Usually strong | Weakest |\n\nChoose according to the requirement and operating context.\n\n## 8. Worked scenarios\n\n### Repository release process\n\nThe repository already has `git`\n\n, a package manager, tests, and a deployment\nCLI. The team needs the agent to follow a standard sequence, preserve evidence,\nand stop when rollback conditions are not met.\n\nUse repository instructions for universal prohibitions and a skill for the release workflow. Use the existing tools for execution.\n\nAdd MCP only if the workflow must reach an external release-control system that lacks a suitable native integration, or if several agent hosts need a common, centrally governed release interface.\n\n### Incident briefing across several systems\n\nAn agent must gather current alerts, service health, recent changes, customer cases, and incident-channel decisions.\n\nLive external state is central. Native connectors or MCP servers are appropriate for each system. A skill can define the briefing workflow, evidence hierarchy, uncertainty handling, and output template.\n\nHere MCP and a skill complement each other: the servers expose capabilities, while the skill explains how to use them responsibly.\n\n### Document conversion\n\nAn agent must convert Markdown to PDF using an installed browser or document library and apply an organisation template.\n\nUse a skill with a local script or existing CLI. An MCP server adds little unless conversion is a shared remote service with central templates, restricted data handling, capacity management, and multiple clients.\n\n### Data warehouse access\n\nOne engineer needs an agent to run read-only queries against a development warehouse through an existing authenticated CLI.\n\nStart with the CLI and a skill that provides query safety rules and result formatting.\n\nAn MCP server becomes more attractive when many clients need the integration, schemas should be discoverable, credentials must remain central, tenant and table access need server enforcement, and queries require consistent audit.\n\n### Browser testing\n\nA coding agent already has Playwright installed and can execute a repository's test suite.\n\nUse the existing test runner, with a skill describing accessibility checks, failure triage, screenshots, and reporting where the team needs a shared procedure.\n\nUse a Playwright MCP server when interactive browser capabilities must be discoverable across agent hosts or the host lacks a suitable native browser tool. Do not add a server solely because the same library can be exposed through MCP.\n\n### Mailbox or calendar briefing\n\nThe agent needs current, authenticated access to private messages and calendar events.\n\nThis requires a connector or service boundary. An MCP server can be appropriate if it implements delegated authorisation, scope, tenant controls, and audit. A skill can define how to prepare the briefing and which categories deserve attention.\n\nThe workflow description must not become the only policy boundary. The service should limit which mailboxes, actions, recipients, and time ranges are available.\n\n### Static policy assistant\n\nThe organisation wants an agent to answer questions from a small, versioned set of policies stored in the repository.\n\nUse references in a skill or ordinary repository documentation. No live server is required.\n\nIf policies move to a changing system of record with access controls, revision history, and many client applications, an MCP resource interface may become appropriate.\n\n### Kubernetes operations\n\nThe agent can use an existing `kubectl`\n\ncontext.\n\nA skill may describe safe diagnostic commands, but cluster RBAC and admission policy must enforce production restrictions.\n\nAn MCP server may add value if it exposes a restricted diagnostic surface,\nnormalises results, prevents arbitrary command construction, and serves\nseveral clients. A server that simply forwards unrestricted `kubectl`\n\ncommands\nadds another layer without reducing authority.\n\n## 9. Portability across tools\n\nThe Agent Skills specification is an open standard supported by multiple products. Portability is real at the file-format level, but runtime behaviour still varies.\n\nGitHub Copilot supports project and personal skills across several directory locations and can make bundled scripts available to the agent.[7][8] Gemini CLI uses discovery tiers, activation consent, and workspace or user locations.[9] Anthropic describes filesystem-based progressive disclosure and code execution in Claude environments.[5][16] OpenAI describes skills as the workflow layer around MCP tools and allows skills to operate without a server when only instructions and resources are needed.[6]\n\nThese systems do not necessarily provide identical:\n\n- trigger selection;\n- precedence rules;\n- approval prompts;\n- sandboxing;\n- network access;\n- tool names;\n- pre-approved permissions;\n- script runtimes;\n- error handling;\n- organisational distribution.\n\nMCP support also varies by host. A server may be protocol compatible while the client lacks a particular transport, extension, resource interface, approval experience, or enterprise policy.\n\nThe durable design should therefore separate:\n\n- the portable skill content;\n- host-specific installation and permissions;\n- the MCP protocol contract;\n- client-specific behaviour and user experience.\n\nBecause product matrices age quickly, architecture and control boundaries should carry the main argument. Exact support belongs in a dated implementation snapshot.\n\n## 10. Counterarguments\n\n### MCP SDKs make servers cheap to build\n\nSDKs reduce protocol implementation effort. They do not remove service ownership, authentication, security review, testing, monitoring, dependency management, or client compatibility.\n\nA prototype can be cheap while the production lifecycle remains expensive. The benefit becomes easier to justify as reuse, control, and integration complexity grow.\n\n### Skills are only prompts in folders\n\nSkills go beyond ordinary prompt files by combining progressive disclosure, references, templates, assets, executable scripts, and substantial domain workflows.[4][5]\n\nThey still rely on the host's tools and permissions. A skill does not become a remote system of record or independent policy service because it contains code.\n\n### CLIs are difficult for models to use reliably\n\nModels can struggle with human-oriented output, inconsistent flags, and broad command surfaces.\n\nAn MCP wrapper may improve the interface by exposing a smaller set of typed, validated operations. The improvement should be measured against direct tool use. If the wrapper preserves every command and arbitrary argument, it may not have reduced the risk.\n\n### Standardisation is worth adopting early\n\nEarly adoption can create useful organisational learning and reduce later integration fragmentation.\n\nIt can also create a large estate of experimental servers with weak ownership. A standard interface does not make every capability worthy of becoming a service.\n\n### Building both provides the best experience\n\nThe combination can be appropriate when an MCP server exposes reliable capabilities and a skill provides the domain workflow around them.\n\nBuilding both should follow two separate requirements, not a desire to use both mechanisms. Each needs an owner, tests, permission design, and a reason to exist.\n\n## 11. Limitations\n\nThe agent-tool ecosystem is changing quickly. Product support, directory locations, protocol versions, transports, and security controls will continue to change.\n\nThis paper does not measure the total cost of MCP servers against skills across organisations. That cost depends on existing infrastructure, compliance, identity systems, client diversity, and operational maturity.\n\nThe worked scenarios are architectural examples rather than universal prescriptions. A local MCP server can be the right choice for one team, while a native connector may be better for another.\n\nThe security research cited includes preprints and controlled benchmarks. It supports threat modelling, not claims about production attack prevalence.\n\nChoosing the correct extension mechanism does not ensure that an agent will use it correctly. Evaluation, least privilege, human review, and deterministic enforcement remain necessary where errors have material consequences.\n\n## Conclusion\n\nMCP gives AI applications a standard way to discover and use external capabilities. Agent Skills package the knowledge required for repeatable work, while existing tools continue to solve many execution problems directly.\n\nThe design error is starting with the mechanism.\n\nStart with the missing capability and decide whether the problem is a rule, procedure, executable operation, live external state, or enforceable service boundary. The smallest mechanism that satisfies the requirement is usually the best starting point.\n\nBroad rules belong in instructions, reusable procedures in skills, and established operations in existing tools. MCP earns its place when interoperability, live access, shared discovery, and server-side control justify a service that someone is prepared to operate. Some workflows will combine these layers.\n\nA mature architecture adds the required capability without creating an unnecessary source of failure.\n\n## Appendix A: MCP eligibility checklist\n\nBefore building an MCP server, record:\n\n- the external system or capability being exposed;\n- why existing host tools, connectors, CLIs, or libraries are insufficient;\n- whether data must be live and how fresh it must be;\n- the read and write operations required;\n- the clients and teams expected to reuse the interface;\n- the schemas, validation, and domain rules the server will enforce;\n- the authentication and authorisation design;\n- token audience, scope, tenant, and credential-storage boundaries;\n- approval requirements for consequential actions;\n- audit, logging, and evidence requirements;\n- availability, latency, timeout, and rate-limit expectations;\n- the named service owner and support path;\n- package, registry, and update provenance;\n- testing against prompt injection, malicious metadata, and unsafe arguments;\n- versioning, deprecation, and retirement plans.\n\nIf most of the value is procedural rather than infrastructural, write a skill first.\n\n## Appendix B: Skill checklist\n\nBefore publishing a skill, record:\n\n- the user goal and trigger conditions;\n- why persistent instructions are not sufficient;\n- the tools and permissions it expects;\n- every bundled script, dependency, reference, and network destination;\n- representative success and failure cases;\n- how outputs will be validated;\n- how the skill behaves when required information is missing;\n- which host-specific assumptions it makes;\n- the maintainer, source, version, and update process;\n- whether shell or other powerful tools are pre-approved;\n- how users can inspect and remove it.\n\nIf the skill needs to hold credentials or enforce access policy, move that responsibility to an appropriate service boundary.\n\n## Appendix C: Product support snapshot\n\nSnapshot date: 27 August 2026.\n\n| Product or standard | Skills position | MCP position | Important implementation note |\n|---|---|---|---|\n| Agent Skills specification | Defines `SKILL.md` , optional scripts, references, assets, and progressive disclosure |\nNot applicable | `allowed-tools` remains experimental and support can vary |\n| Anthropic Claude | Skills package filesystem-based expertise and executable resources | MCP connects external tools and software | Skill execution and network behaviour depend on the Claude environment |\n| GitHub Copilot | Supports project and personal skills across Copilot products | MCP extends access to external data, APIs, and tools | Community skills are not verified; powerful tool pre-approval requires care |\n| OpenAI ChatGPT and Codex | Skills define workflows and may work without MCP | MCP provides live information and controlled actions | OpenAI explicitly describes the two mechanisms as complementary |\n| Gemini CLI | Skills provide on-demand expertise with activation consent | MCP support is configured separately | Discovery tiers and precedence affect which skill is loaded |\n\nThis table is descriptive, not a compatibility guarantee. Consult current product documentation before implementation.\n\n## About the author\n\nJason Doyle writes about reliable software, observability, incident leadership,\nand applied AI. He publishes at [jasondoyle.ie](https://jasondoyle.ie) and can\nbe contacted at [[email protected]](/cdn-cgi/l/email-protection#6704080913060413270d0614080903081e0b02490e02).\n\n## References\n\n- Model Context Protocol,\n*Architecture overview*, protocol documentation version 2026-07-28,[https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture](https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture). - Model Context Protocol,\n*Understanding MCP servers*, protocol documentation version 2026-07-28,[https://modelcontextprotocol.io/docs/2026-07-28/learn/server-concepts](https://modelcontextprotocol.io/docs/2026-07-28/learn/server-concepts). - OpenAI,\n*MCP server*, OpenAI Developers,[https://developers.openai.com/plugins/concepts/mcp-server](https://developers.openai.com/plugins/concepts/mcp-server). - Agent Skills,\n*Specification*,[https://agentskills.io/specification](https://agentskills.io/specification). - Anthropic,\n*Equipping agents for the real world with Agent Skills*, updated 18 December 2025,[https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills). - OpenAI,\n*Skills*, OpenAI Developers,[https://developers.openai.com/plugins/concepts/skills](https://developers.openai.com/plugins/concepts/skills). - GitHub Docs,\n*About agent skills*,[https://docs.github.com/en/copilot/concepts/agents/about-agent-skills](https://docs.github.com/en/copilot/concepts/agents/about-agent-skills). - GitHub Docs,\n*Adding agent skills for GitHub Copilot*,[https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/add-skills](https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/add-skills). - Gemini CLI,\n*Agent Skills*,[https://geminicli.com/docs/cli/skills.md](https://geminicli.com/docs/cli/skills.md). - GitHub Docs,\n*Enhancing GitHub Copilot agent mode with MCP*,[https://docs.github.com/en/copilot/tutorials/enhance-agent-mode-with-mcp](https://docs.github.com/en/copilot/tutorials/enhance-agent-mode-with-mcp). - Model Context Protocol,\n*Security Best Practices*, protocol documentation version 2026-07-28,[https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices). - Model Context Protocol,\n*Authorization Security Considerations*, specification version 2026-07-28,[https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations). - Mohammed Mehedi Hasan, Hao Li, Gopi Krishnan Rajbahadur, Bram Adams, and\nAhmed E. Hassan,\n*Model Context Protocol (MCP) Tool Descriptions Are Smelly! Towards Improving AI Agent Efficiency with Augmented MCP Tool Descriptions*, arXiv:2602.14878, version 3, 31 May 2026,[https://arxiv.org/abs/2602.14878](https://arxiv.org/abs/2602.14878). - Zhiqiang Wang et al.,\n*MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers*, arXiv:2508.14925, 19 August 2025,[https://arxiv.org/abs/2508.14925](https://arxiv.org/abs/2508.14925). - Model Context Protocol,\n*The MCP Registry*,[https://modelcontextprotocol.io/registry/about](https://modelcontextprotocol.io/registry/about). - Anthropic,\n*Agent Skills*, Claude Platform documentation,[https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview).", "url": "https://wpnews.pro/news/when-you-need-an-mcp-server-and-when-you-don-t", "canonical_source": "https://jasondoyle.ie/whitepapers/when-you-need-an-mcp-server/", "published_at": "2026-08-28 05:43:08+00:00", "updated_at": "2026-08-28 06:18:19.353171+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-infrastructure", "ai-safety", "developer-tools"], "entities": ["Model Context Protocol (MCP)", "Agent Skills", "GitHub", "Anthropic"], "alternates": {"html": "https://wpnews.pro/news/when-you-need-an-mcp-server-and-when-you-don-t", "markdown": "https://wpnews.pro/news/when-you-need-an-mcp-server-and-when-you-don-t.md", "text": "https://wpnews.pro/news/when-you-need-an-mcp-server-and-when-you-don-t.txt", "jsonld": "https://wpnews.pro/news/when-you-need-an-mcp-server-and-when-you-don-t.jsonld"}}