# When You Need an MCP Server and When You Really Don't ## A decision framework for protocols, agent skills, native tools and simple automation Author: Jason Doyle First published: 27 August 2026 > Disclosure: These views are my own and do not represent my current or any former employers. ## Executive summary Not every missing agent capability is a protocol problem. Model 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. Agent Skills offer another route for release procedures, reports, repository reviews, and domain standards. Teams package the required knowledge as a skill. Both are useful in the right place, while many tasks need neither. MCP 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\] An 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\] Skills 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. This paper proposes a minimum sufficient integration principle: Use the least complex mechanism that provides the required capability, reliability, security, portability, and control. That mechanism may be: 1. a persistent instruction for a rule that applies broadly; 2. a skill for a repeatable workflow using capabilities the agent already has; 3. an existing CLI, library, native connector, or small script; 4. an MCP server for reusable access to live data or controlled actions across an explicit protocol boundary. An 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. A 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. An existing tool is often the better answer when the operation already has a mature interface. Teaching an agent to use `git`, `kubectl`, a vendor CLI, or a well-supported native connector may create less risk than wrapping each command in another protocol layer. MCP 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\] Skills 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\] The practical decision is whether the proposed mechanism places capability, knowledge, and control in the right layer without creating an unnecessary system to operate. ## 1. The category mistake MCP 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. MCP 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\] Agent Skills package material an agent can load from a filesystem or managed environment. The open specification requires a `SKILL.md` file with a name, description, and instructions. A skill may also include executable scripts, reference material, and assets. Implementations use progressive disclosure: lightweight metadata is available for discovery, while detailed instructions and resources load only when needed.\[4\]\[5\] MCP primarily creates an interface boundary, while a skill packages knowledge and workflow. The 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\] Consider a production release: - a repository instruction states that production history must never be rewritten; - a skill describes the organisation's release checklist, evidence, and rollback expectations; - `git` and the build system perform local deterministic operations; - a native GitHub integration or MCP server reads pull requests and workflow results; - a deployment service enforces environment permissions and records the release. Describing the entire arrangement as either an MCP integration or a skill hides the design decisions that matter. The 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. ## 2. Four ways to extend an agent A useful design starts with four choices rather than a binary comparison. | Mechanism | What it provides | Typical scope | What it does not provide by itself | | --- | --- | --- | --- | | Instructions | Persistent rules and background context | Repository, workspace, user, or organisation | A new executable capability or live external data | | Agent Skill | On-demand procedure, examples, scripts, templates, and references | A repeatable task or domain | A server-enforced authorisation boundary | | 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 | | 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 | ### Instructions Instructions 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. GitHub 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\] An 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. ### Agent Skills A skill is appropriate when a recognisable task benefits from a reusable playbook. It can contain: - steps and decision points; - examples of good and bad outputs; - templates and schemas; - domain references; - validation scripts; - deterministic transformation code; - guidance for using existing tools. The 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. ### Native tools, CLIs, libraries, and small scripts Agents 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. Using that interface directly has advantages: - operators already understand it; - documentation and troubleshooting practices exist; - authentication may already be configured; - scripts can be tested without an agent; - no additional service must be deployed; - failure behaviour is often familiar. A skill can teach the agent how to use the tool safely. This combination is frequently sufficient. ### MCP servers An 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\] OpenAI 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\] That 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. ## 3. When a skill is enough A skill is usually enough when the agent can already reach everything required to complete the task. The missing capability is procedural. The agent needs to know: - which sources to inspect; - which sequence to follow; - what evidence to preserve; - which checks are mandatory; - how to handle common exceptions; - what the final artifact should contain. Examples include: - reviewing a pull request against organisation-specific reliability rules; - preparing an incident brief from logs and records already available in the environment; - converting a document with an installed library; - applying a house style to technical writing; - following a repository's release and rollback process; - generating a standard architecture decision record; - checking that a migration includes required safety evidence. A 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. Skills 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. Progressive 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. Progressive 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. Use 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. ## 4. When an MCP server is justified An MCP server becomes useful when the integration needs an explicit capability boundary rather than another set of instructions. ### The agent needs current external state Static 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. An 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. ### The agent needs controlled external actions Creating an issue, updating a record, sending a message, scheduling an event, or initiating a workflow requires authority outside the local agent environment. An 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. ### Multiple hosts need the same capability The 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. Without a common boundary, each host may acquire a separate script, plugin, or credential flow. MCP can reduce that duplication. Cross-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. ### Discovery and schemas materially improve use MCP tools publish names, descriptions, and input schemas. Clients can discover available capabilities and models can form structured calls.\[1\]\[2\] Schema and discovery features help when: - the capability set changes; - arguments require validation; - natural-language shell construction is unsafe; - several related operations need consistent naming; - results benefit from structured content; - client developers should not maintain custom adapters. Typed 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. ### Credentials and policy belong outside the agent A 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. The 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. ### A production owner exists An MCP server is software infrastructure. Someone must own: - availability and latency; - authentication and authorisation; - schema and version changes; - dependency upgrades; - logs, metrics, and traces; - abuse controls and rate limits; - incident response; - data retention and privacy; - deprecation and client migration. Without such ownership, the proposed server becomes an unmanaged dependency rather than a finished integration. ## 5. When neither MCP nor a skill is the right answer The availability of extension mechanisms does not make ordinary engineering obsolete. ### Use the existing CLI If an agent already has shell access and the official CLI is mature, a new MCP wrapper may only duplicate commands and error handling. `git status`, a targeted test command, a cloud deployment query, or a package manager operation may be clearer through the established interface. A short skill can describe the safe workflow if the sequence is specialised. Build 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. ### Use a library Deterministic 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. Making every function an agent-discoverable tool can reduce reliability by moving ordinary control flow into model choice. ### Use a small script A 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. If 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. ### Use a native integration Many agent products provide built-in tools or supported connectors. These may offer better consent, identity, user interface, and support than a custom MCP server. The decision should compare the proposed server with the best existing integration, not with no integration at all. ### Use an ordinary user interface Some 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. An agent can prepare the information without becoming the execution path. ## 6. The integration tax Every extension creates work, so the smallest adequate mechanism deserves preference. ### The MCP tax An MCP server introduces several forms of cost. Operational 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. Interface 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. Hasan 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. Security cost includes server provenance, package dependencies, credentials, OAuth flows, token storage, scopes, tenant separation, outbound network access, and tool-result handling. Official 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\] Research 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. Governance 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\] ### The skill tax Skills avoid much of the service lifecycle, but they introduce other risks. Skill 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. Bundled 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. GitHub 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\] A skill therefore needs: - a named maintainer; - a reviewed source; - version control or pinned provenance; - tests against representative tasks; - clear required tools and permissions; - a process for updating procedures; - safe failure behaviour; - removal when the workflow no longer applies. The skill tax is usually smaller than the MCP tax, but it still requires ownership and review. ## 7. A decision framework The following sequence helps identify the minimum sufficient integration. ### Step 1: Is the requirement a broad rule? If the guidance should apply to nearly every task in a repository or organisation, use instructions. Examples include coding standards, prohibited operations, required disclosure, or the location of key documentation. ### Step 2: Does the required capability already exist? Check the host's built-in tools, approved connectors, installed CLIs, libraries, and APIs. If the agent can already perform the operation safely, do not build a new server merely to rename it. ### Step 3: Is the missing element a repeatable procedure? If the challenge is sequence, context, examples, templates, or domain judgement, use a skill. The skill may call existing tools, including MCP tools. ### Step 4: Does the workflow require live external state or action? Prefer a supported native integration where it meets the need. If none exists, compare a direct script or API client with an MCP server. ### Step 5: Is a protocol boundary materially valuable? MCP becomes a stronger choice when the answer to several of these questions is yes: - Will more than one host or team use the capability? - Do clients need to discover changing tools or resources? - Will typed schemas prevent meaningful classes of error? - Must credentials remain behind a service boundary? - Must authorisation, tenant scope, or policy be enforced centrally? - Does the capability need a stable remote endpoint? - Is an auditable tool call preferable to free-form shell construction? ### Step 6: Can the organisation operate it? Identify the owner, service-level expectations, monitoring, support path, security review, upgrade process, and retirement plan. If these do not exist, choose a smaller mechanism or delay deployment. ### Step 7: Where must correctness be enforced? Instructions and skills influence model behaviour. They are useful controls, but they are not deterministic security boundaries. Enforce permissions, irreversible-action checks, spending limits, recipient restrictions, and regulated policy in code or downstream services. The decision matrix below summarises the usual fit. | Requirement | Instructions | Skill | Native tool or script | MCP server | | --- | --- | --- | --- | --- | | Rule applies to most tasks | Strong | Weak | None | None | | Repeatable domain workflow | Limited | Strong | Supporting role | Supporting role | | Deterministic local transformation | Weak | Orchestrates | Strong | Usually unnecessary | | Live external data | None | Orchestrates | Strong for narrow use | Strong for reusable integration | | External write action | None | Orchestrates | Strong for narrow use | Strong when governed and shared | | Cross-host discovery | None | Partial and implementation-dependent | Weak | Strong | | Central credential boundary | None | None by itself | Possible | Strong when implemented correctly | | Server-side authorisation and audit | None | None by itself | Possible | Strong when implemented correctly | | Lowest operational burden | Strong | Strong | Usually strong | Weakest | Choose according to the requirement and operating context. ## 8. Worked scenarios ### Repository release process The repository already has `git`, a package manager, tests, and a deployment CLI. The team needs the agent to follow a standard sequence, preserve evidence, and stop when rollback conditions are not met. Use repository instructions for universal prohibitions and a skill for the release workflow. Use the existing tools for execution. Add 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. ### Incident briefing across several systems An agent must gather current alerts, service health, recent changes, customer cases, and incident-channel decisions. Live 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. Here MCP and a skill complement each other: the servers expose capabilities, while the skill explains how to use them responsibly. ### Document conversion An agent must convert Markdown to PDF using an installed browser or document library and apply an organisation template. Use 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. ### Data warehouse access One engineer needs an agent to run read-only queries against a development warehouse through an existing authenticated CLI. Start with the CLI and a skill that provides query safety rules and result formatting. An 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. ### Browser testing A coding agent already has Playwright installed and can execute a repository's test suite. Use the existing test runner, with a skill describing accessibility checks, failure triage, screenshots, and reporting where the team needs a shared procedure. Use 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. ### Mailbox or calendar briefing The agent needs current, authenticated access to private messages and calendar events. This 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. The workflow description must not become the only policy boundary. The service should limit which mailboxes, actions, recipients, and time ranges are available. ### Static policy assistant The organisation wants an agent to answer questions from a small, versioned set of policies stored in the repository. Use references in a skill or ordinary repository documentation. No live server is required. If policies move to a changing system of record with access controls, revision history, and many client applications, an MCP resource interface may become appropriate. ### Kubernetes operations The agent can use an existing `kubectl` context. A skill may describe safe diagnostic commands, but cluster RBAC and admission policy must enforce production restrictions. An MCP server may add value if it exposes a restricted diagnostic surface, normalises results, prevents arbitrary command construction, and serves several clients. A server that simply forwards unrestricted `kubectl` commands adds another layer without reducing authority. ## 9. Portability across tools The Agent Skills specification is an open standard supported by multiple products. Portability is real at the file-format level, but runtime behaviour still varies. GitHub 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\] These systems do not necessarily provide identical: - trigger selection; - precedence rules; - approval prompts; - sandboxing; - network access; - tool names; - pre-approved permissions; - script runtimes; - error handling; - organisational distribution. MCP 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. The durable design should therefore separate: 1. the portable skill content; 2. host-specific installation and permissions; 3. the MCP protocol contract; 4. client-specific behaviour and user experience. Because product matrices age quickly, architecture and control boundaries should carry the main argument. Exact support belongs in a dated implementation snapshot. ## 10. Counterarguments ### MCP SDKs make servers cheap to build SDKs reduce protocol implementation effort. They do not remove service ownership, authentication, security review, testing, monitoring, dependency management, or client compatibility. A prototype can be cheap while the production lifecycle remains expensive. The benefit becomes easier to justify as reuse, control, and integration complexity grow. ### Skills are only prompts in folders Skills go beyond ordinary prompt files by combining progressive disclosure, references, templates, assets, executable scripts, and substantial domain workflows.\[4\]\[5\] They 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. ### CLIs are difficult for models to use reliably Models can struggle with human-oriented output, inconsistent flags, and broad command surfaces. An 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. ### Standardisation is worth adopting early Early adoption can create useful organisational learning and reduce later integration fragmentation. It 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. ### Building both provides the best experience The combination can be appropriate when an MCP server exposes reliable capabilities and a skill provides the domain workflow around them. Building 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. ## 11. Limitations The agent-tool ecosystem is changing quickly. Product support, directory locations, protocol versions, transports, and security controls will continue to change. This 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. The 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. The security research cited includes preprints and controlled benchmarks. It supports threat modelling, not claims about production attack prevalence. Choosing 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. ## Conclusion MCP 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. The design error is starting with the mechanism. Start 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. Broad 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. A mature architecture adds the required capability without creating an unnecessary source of failure. ## About the author Jason Doyle writes about reliable software, observability, incident leadership, and applied AI. He publishes at [jasondoyle.ie](https://jasondoyle.ie) and can be contacted at . ## References 1. Model Context Protocol, *Architecture overview*, protocol documentation version 2026-07-28, . 2. Model Context Protocol, *Understanding MCP servers*, protocol documentation version 2026-07-28, . 3. OpenAI, *MCP server*, OpenAI Developers, . 4. Agent Skills, *Specification*, . 5. Anthropic, *Equipping agents for the real world with Agent Skills*, updated 18 December 2025, . 6. OpenAI, *Skills*, OpenAI Developers, . 7. GitHub Docs, *About agent skills*, . 8. GitHub Docs, *Adding agent skills for GitHub Copilot*, . 9. Gemini CLI, *Agent Skills*, . 10. GitHub Docs, *Enhancing GitHub Copilot agent mode with MCP*, . 11. Model Context Protocol, *Security Best Practices*, protocol documentation version 2026-07-28, . 12. Model Context Protocol, *Authorization Security Considerations*, specification version 2026-07-28, . 13. Mohammed Mehedi Hasan, Hao Li, Gopi Krishnan Rajbahadur, Bram Adams, and Ahmed E. Hassan, *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, . 14. Zhiqiang Wang et al., *MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers*, arXiv:2508.14925, 19 August 2025, . 15. Model Context Protocol, *The MCP Registry*, . 16. Anthropic, *Agent Skills*, Claude Platform documentation, .