Building a Skill with MCP Tool Access

By Yanni Papoutsis | 7 min read | 2026-07-12

A Claude skill does not create new tools by itself; it assumes specific MCP (Model Context Protocol) connectors are already installed and writes instructions for exactly which tools to call, in what order, and how to behave when a tool is missing or unauthenticated. The skill is the playbook; the MCP server is the tool it is calling plays for.

This is the fifth post in the skills-authoring series. It follows web search inside a skill, which is really the same idea applied to one specific tool category, and pairs well with the MCP server build guides if you are also writing the connector the skill will depend on.

TL;DR: MCP tools appear to Claude as named, callable functions, typically namespaced by server (something like mcp__servername__toolname), and some are deferred, meaning only the name is visible until a discovery step loads the full schema. A skill that depends on MCP tools should name the exact connector it needs, state a clear call order (read-only tools before anything that writes or mutates), and include a guard clause for what to do when the connector is not connected or a call fails, rather than assuming success. Never place a real API key, token, or credential in a skill file; every example should use a placeholder like YOUR_API_KEY_HERE. For anything destructive (deleting rows, pushing to production, sending money), the skill should instruct Claude to confirm with the user before calling the tool, not after. Test the skill once with the connector fully authenticated and once with it disconnected, since the disconnected path is where unclear failures usually hide. Below is the full pattern with a worked example covering connector prerequisites, call ordering, and guard clauses.

What is MCP, in one paragraph, for skill authors

The Model Context Protocol is an open standard for connecting an AI system to external tools and data sources, databases, file systems, SaaS APIs, through a consistent tool-calling interface rather than a bespoke integration per product. A skill author does not need to build an MCP server to use one; you only need to know which connector your skill assumes is present and which tools on that connector it calls.

How do MCP tools show up to a skill?

Once a connector is set up, its tools appear as callable functions, usually named with the server as a prefix, for example mcp__supabase__list_tables or mcp__slack__send_message. Some environments defer full tool schemas until they are explicitly requested, so a skill may see a tool's name before it can actually call it. A skill's instructions should account for this rather than assuming every named tool is immediately callable:

If a required tool is not yet loaded, load its schema first
before attempting to call it. If the connector is not installed
at all, tell the user which connector to add and stop.

How do you write a skill that safely depends on MCP tools?

Step 1: Name the exact connector and tools your skill needs

Vague references ("use the database tool") are hard for Claude to act on reliably. Name the connector and the specific tools:

name: schema-change-helper
description: Guides safe database schema changes through the
  connected database MCP connector. Trigger on: add a column,
  migrate the database, alter a table, change the schema.

# Schema Change Helper

This skill assumes a database MCP connector is installed
(for example a Postgres or Supabase-style connector) exposing
at minimum: a table-listing tool, a migration-apply tool, and
an advisor or lint tool.

Step 2: Write the call order explicitly, read before write

The single most useful rule for any MCP-dependent skill is ordering: inspect before you change anything.

1. Call the table-listing tool first to see current structure.
2. Call the advisor/lint tool to check for existing issues.
3. Only then call the migration-apply tool with the proposed change.
4. After applying, call the table-listing tool again to confirm
   the change landed as expected.

This mirrors how well-documented MCP servers already guide their own tool use: check structure first, diagnose with a logs or advisor tool, and only then make a change. Bake that same discipline into your skill rather than leaving the order to chance.

Step 3: Guard against missing or unauthenticated connectors

If the required connector's tools are not available, tell the
user which connector to connect and do not attempt a workaround
that skips the safety checks in Step 2.

Step 4: Never put real credentials in a skill file

Every example, sample config, or documentation snippet inside a skill must use placeholders:

API_KEY=YOUR_API_KEY_HERE
DATABASE_URL=postgres://user:YOUR_PASSWORD_HERE@host:5432/db
GITHUB_TOKEN=sk-xxx

A skill folder is a plain-text bundle that can be shared, zipped, and installed by other people. Anything written into it should be treated as visible to whoever installs the skill.

Step 5: Confirm before destructive actions

Before calling any tool that deletes data, pushes to a production
branch, sends a message, or moves money, state exactly what will
happen and wait for explicit confirmation. Never chain a
destructive call directly after a read call without this pause.

Step 6: Test connected and disconnected

Run the skill once with the connector properly authenticated, and once without it connected at all. The second run is the one people skip, and it is where a poorly guarded skill tries to call a tool that does not exist and produces a confusing failure instead of a clear message.

Example: a database migration helper skill

name: schema-change-helper
description: Guides safe schema changes through the connected
  database MCP connector, checking structure and advisories
  before applying any migration. Trigger on: add a column,
  alter a table, database migration, schema change.

# Schema Change Helper

1. List existing tables and columns using the connector's
   table-listing tool. Confirm the target table exists.
2. Run the connector's advisor or lint tool to check for
   existing issues unrelated to this change.
3. Draft the migration SQL and show it to the user before
   applying anything.
4. Wait for explicit confirmation.
5. Apply the migration using the connector's migration tool.
6. Re-list tables to confirm the change landed.
7. If any step fails or the connector is not connected, stop
   and tell the user exactly what is missing.

Common MCP skill mistakes

Mistake Risk Fix
Skill assumes a tool is always available Confusing failure when connector is missing Add an explicit guard clause and a clear message
No read-before-write ordering Untested changes applied blind Require an inspect step before any mutating call
Real API key or token pasted as an example Credential leak if the skill is shared Use placeholders like YOUR_API_KEY_HERE everywhere
Destructive call with no confirmation step Irreversible action taken by mistake Require explicit confirmation before delete, send, or pay actions
Skill never tested without the connector Silent, unhelpful failures in the field Test both connected and disconnected states

Frequently asked questions

Does a skill need to install the MCP connector itself?

No. The connector is set up separately (through the product's connector settings or configuration). The skill assumes it exists and tells Claude what to do if it does not, which is different from installing it.

Can one skill depend on more than one MCP connector?

Yes, but name each one explicitly and keep the call order clear about which connector each step uses. A skill that silently assumes several connectors are all present is harder to debug when only some of them are connected.

What is the safest default for a skill that can delete or change data?

Read-only first, explicit confirmation before anything destructive, and a clear stop condition when a required tool or connector is missing. Treat every mutating call as something the user approves in the moment, not something the skill decides alone.

About the author

Yanni Papoutsis builds AI products, automation pipelines, and technical documentation with Claude, and publishes free tooling and guides at yanni.uk.

Next step: Learn how to test a skill like this before you trust it in the skill testing and eval guide, or explore 1,000+ AI tools at yanni.uk/ai-tools.

Sources