Agent Skill with MCP

An agent skill with MCP combines two different pieces of an agent system: reusable procedure and connected capability. The skill tells the agent how to do a repeatable job. MCP tells the agent what external systems it can reach.

That distinction sounds small until the workflow touches GitHub, Slack, Gmail, Google Drive, a browser, a database, or a production runbook. MCP can expose the repository, channel, inbox, file, page, query, or incident tool. It does not automatically tell the agent which source should win, what order to inspect things in, when to stop, or what evidence a human needs before trusting the result.

The Model Context Protocol specification describes MCP as a standard way for LLM applications to share context, expose tools, and build integrations. OpenAI's Codex Agent Skills docs describe a skill as a directory with SKILL.md plus optional scripts, references, and assets for a reusable workflow. Put them together when the job repeats and the agent needs live access.

If you are still deciding what belongs in the integration layer, read Agent Skill vs MCP. If the question is lower level, Agent Skill vs Tool covers the distinction between a procedure and a single callable action. This article focuses on the combined pattern: how a skill should guide an agent that has MCP servers available.

MCP has several concepts that matter for skill authors. A host is the AI application. A client is the connector inside that host. A server provides context or capabilities. A server can expose tools, resources, and prompts.

Layer	What it provides	What the skill should add
MCP server	Access to a system such as GitHub, Slack, Google Workspace, Playwright, Linear, or a database	Whether that system is relevant for this job
MCP tool	A callable action with input and output schemas	When to call it, with what limits, and how to interpret the result
MCP resource	Context such as a file, schema, runbook, transcript, or workspace artifact	Which resource is authoritative and when to ignore stale context
MCP prompt	A reusable server-provided starter template	Whether it is enough, or whether the workflow needs a full skill
Agent skill	Repeatable operating procedure	Source priority, sequencing, approval rules, evidence, and final output

The MCP tools specification is the most obvious fit because tools perform actions. The spec also includes resources, which expose context to clients, and prompts, which are user-controlled templates. A good skill can use all three, but it should not confuse them.

A resource can show the current API schema. A tool can create the GitHub issue. A prompt can help a user start a standard request. The skill is the operating contract that says: inspect the schema first, group duplicate reports before creating anything, ask before writing, and return the issue URL only after the human approves the mutation.

Use an agent skill with MCP when three things are true.

First, the job repeats. A one-off question does not need a packaged workflow. A recurring PR review, inbox triage, release QA pass, security review, or customer-escalation summary does.

Second, the job needs external truth. The agent must read live files, current tickets, messages, logs, browser state, docs, or records. A skill alone cannot fetch a private pull request or click through a checkout flow. It can only describe what should happen if the host supplies the capability.

Third, the quality bar is procedural. The agent needs to follow a sequence, make tradeoffs, cite evidence, and stop under specific conditions. More tools do not solve that. A broader MCP server can actually make the workflow worse if it gives the agent more places to wander without a clear job definition.

The tradeoff is overhead. MCP servers add authentication, tool descriptions, latency, and security review. A credible community critique on Reddit described many servers as thin API wrappers and called out context and latency costs. That is useful caution. If a short script is faster, safer, and only used by one workflow, a skill can call that script directly. Use MCP when standardized access across hosts or agents is worth the extra integration layer.

When MCP is worth using, keep the surface narrow. Prefer the smallest server set, the smallest toolset, and the smallest response that can prove the job is done. A skill should say that a PR review needs repository reads and CI status, not every project-management, security, release, and org-admin capability attached to the same account.

GitHub's official MCP server connects AI tools to repositories, code files, issues, pull requests, actions, and other GitHub surfaces. Its README also describes toolset configuration so teams can enable groups such as repos, issues, pull requests, actions, and code security instead of exposing every capability by default. GitHub's scope filtering docs add another practical detail: available tools can vary by token type and granted scopes.

That is exactly why the skill matters. A "review this PR" skill should not assume every GitHub tool is available. It should define a path that degrades cleanly:

1. Read the PR title, description, changed files, and CI status.
2. If changed-file access is missing, stop and report the missing permission.
3. Inspect changed files before searching the rest of the repo.
4. Classify findings as blocking correctness, security, regression risk, test gap, or non-blocking maintainability.
5. Cite file paths and line references for every finding.
6. Do not post a GitHub review or create an issue unless the user asks.

The MCP server gives the agent reach. The skill gives the review standard. If the agent has access but keeps commenting on style while missing API-breaking changes, the fix is not another GitHub connector. The fix is a sharper skill, a better severity rubric, and examples of acceptable findings.

The Playwright MCP docs describe browser capabilities such as navigation, clicking, typing, form filling, screenshots, dialogs, tabs, network monitoring, mocking, console messages, and storage state. The same docs warn that running arbitrary Playwright code through the unsafe code tool is RCE-equivalent and should only be enabled for trusted clients.

That is an integration surface, not a QA methodology. A checkout-QA skill should define the test shape:

• start from a clean test account and seeded cart
• run desktop and mobile widths
• cover happy path, declined payment, missing address, expired session, and coupon edge cases
• inspect console errors and failed network requests
• use only test payment credentials
• capture screenshots for cart, payment, confirmation, and failure states
• return a pass/fail table with reproduction steps

Playwright MCP can click the Pay button. The skill decides whether the checkout was actually tested. The skill should also say when not to use dangerous browser capabilities. If the task only needs accessibility snapshots and screenshots, do not enable arbitrary code execution. If the test requires a saved login state, name the expected storage-state file and forbid real customer accounts.

Slack and Google Workspace show the operational value of the skill layer because they contain sensitive, ambiguous, high-volume information.

Slack's MCP server docs require a registered Slack app identity and describe admin approval, logging, rate limits, access control, IP allowlists, and the risk of mixing Slack data with other MCP servers. That is the correct place for workspace-level controls. It still does not define the triage policy.

A Slack-escalation skill should name the channels, time window, classification scheme, and approval behavior. For example: inspect #support-escalations, #incidents, and #enterprise-customers for the last business day; classify threads as incident, customer escalation, product question, sales handoff, or no action; draft replies but never send; cite message links and timestamps; escalate private HR, legal, or security threads instead of summarizing them into a general report.

Google Workspace MCP has a similar shape. Google's Workspace MCP configuration guide says the servers can search emails, retrieve files, list calendar events, create draft emails, upload files, schedule meetings, and inherit user permissions and governance controls. Google's Universal Search MCP Server can search across Gmail, Drive, Calendar, and Chat, while respecting which scopes were granted.

An executive-briefing skill can turn those capabilities into a bounded job: search only the named customer, restrict the time window, prefer signed contracts over email claims, draft but do not send follow-ups, and list unavailable scopes as blockers. Without that procedure, a universal search tool can produce a plausible but unsafe summary by blending stale docs, private emails, and unrelated chat messages.

For MCP-heavy skills, write the skill around the job, then map MCP capabilities to steps.

A customer-escalation skill might use:

• a Google Drive resource for the account plan
• a Gmail or universal-search tool for recent customer messages
• a Slack tool for internal incident discussion
• a CRM tool for contract tier and owner
• a GitHub issue tool for known product defects
• a prompt from an internal support server as a starting template for the handoff

The skill should decide source priority. A signed contract beats a Slack recollection. A current incident page beats a month-old customer-success note. A public docs page beats a draft proposal when describing product behavior. If sources conflict, the skill should surface the conflict rather than averaging them into a confident answer.

This is where many teams go wrong. They put workflow policy into MCP tool descriptions because that is the field the model sees during tool selection. Tool descriptions should remain narrow: what the tool does, what inputs it expects, and what risk it carries. The full operating policy belongs in the skill, where it can be reviewed, versioned, tested, and improved after real runs. How to Write an Agent Skill That Actually Works goes deeper on that contract.

MCP security should be enforced in the host, server, authorization layer, and runtime. The skill should not be the only thing preventing a write to production. The MCP authorization specification defines authorization for HTTP transports, while noting that stdio implementations typically get credentials from the environment. Tool access, scopes, tenant isolation, audit logging, and network policy belong outside the prose of a skill.

The MCP tools spec puts hard requirements on servers: validate inputs, enforce access controls, rate limit invocations, and sanitize outputs. It also recommends client-side confirmation, visible tool inputs, result validation, timeouts, and audit logs. A skill should assume those controls exist, then add the job-specific layer: which actions are acceptable for this workflow and what proof the user should see.

The skill still has safety work to do. It should make human-visible behavior concrete:

• read-only by default unless the job explicitly requires a write
• ask before posting, sending, deleting, merging, purchasing, deploying, or changing production data
• show the planned write action and destination before asking for approval
• do not include secrets, tokens, private customer data, or unnecessary personal data in the final answer
• stop when a requested scope is broader than the task requires
• cite the source that drove each recommendation

This matters because MCP introduces prompt-injection and tool-surface risks. Simon Willison's analysis of MCP prompt-injection problems calls out tool poisoning, where malicious instructions can hide inside tool descriptions that the model sees but users may not. Reddit discussions about MCP security concerns echo the same practical fears: malicious updates, overbroad permissions, and weak monitoring.

The right response is layered. Pin and review servers. Prefer official servers for sensitive systems when available. Use least-privilege scopes. Keep write tools separate from read tools. Log tool calls. Require approval for side effects. Then encode the workflow's judgment rules in the skill so the agent knows when using access is appropriate.

A skill for an MCP-backed workflow should stay readable. Put the core job in SKILL.md; move long rubrics, examples, and scripts into supporting files.

customer-escalation-triage/
  SKILL.md
  references/
    source-priority.md
    privacy-rules.md
    severity-rubric.md
  examples/
    good-brief.md
    blocked-missing-access.md
  scripts/
    normalize_thread_export.py

Inside SKILL.md, include the MCP contract in plain language:

• required servers or tool families
• minimum access needed for a valid run
• source order and conflict handling
• read actions allowed without confirmation
• write actions that require explicit approval
• blocker behavior when scopes or tools are missing
• final evidence format

Do not list every tool name unless the exact tool changes the workflow. The skill should read like a professional operating procedure, not an inventory of connector methods.

Before combining a skill with MCP, ask:

Question	If yes
Does the same job repeat across users, repos, customers, or incidents?	Write a skill
Does the agent need live access to external systems?	Use MCP or another tool layer
Does the task include side effects?	Add authorization, approval, and audit controls
Can a prompt template fully solve it?	Use an MCP prompt instead of a full skill
Does quality depend on source priority, sequencing, or stop rules?	Put those rules in the skill
Is the MCP server just a slow wrapper around one internal API?	Consider a script or direct tool instead

The durable rule is simple: MCP packages access; skills package expertise. A strong agent workflow often needs both, but the boundary should stay visible. When the workflow fails because the agent could not reach the system, improve the MCP layer. When it fails because the agent had access but used it poorly, improve the skill.

For Skillfully's audience, that boundary is the point. Skill authors are not just collecting prompts. They are publishing repeatable operating procedures that can improve over time. MCP gives those procedures access to real systems. The skill defines what good work looks like once that access exists.