Model Context Protocol (MCP) and Agent Skills both help an AI coding assistant do more, but they solve different problems. MCP gives an agent a standard way to call live tools and pull current data — an account balance, the latest block, a pending transaction. Agent Skills give that same agent a standard way to remember how your team wants a job done, without needing a live connection to anything. llms.txt is a third, unrelated layer: a plain-text signpost that helps any AI tool find a site’s content in the first place, whether or not an agent is involved at all.
For blockchain teams, the stakes are higher than usual. A single product might touch dozens of networks, each with its own RPC methods and documentation, and an AI agent helping build or operate it needs a way to reach all of that without a bespoke integration per chain. This guide covers what each one actually does and where it fits, from the simplest definition to the trade-offs that matter once you’re choosing.
What Is MCP (Model Context Protocol)?
Model Context Protocol is an open standard, introduced by Anthropic in November 2024, that lets an AI model discover and call external tools and data through one interface instead of a custom integration for every pairing. Before MCP, connecting an assistant to a blockchain node and a project-management tool meant writing two separate, incompatible plugins. MCP replaces that with a single specification: any MCP-compatible client can talk to any MCP-compatible server, the same way any browser can talk to any website over HTTP.
In a blockchain context, an MCP server typically exposes a set of callable tools — get a balance, fetch a block, estimate gas, broadcast a signed transaction — each backed by a real RPC call to a validator node or full node somewhere. The AI doesn’t need to know the underlying JSON-RPC method name or authentication scheme; it just calls the tool, and the server handles the translation. Some comparisons frame this as agent skills vs. MCP vs. tools, since MCP’s building blocks are literally called “tools” — distinct from the simpler, built-in tool-calling most providers also support for a single hard-coded function.
Dhanji R. Prasanna, CTO at Block, described the goal at MCP’s launch this way: “Open technologies like the Model Context Protocol are the bridges that connect AI to real-world applications…” MCP has since moved beyond Anthropic’s own tools: Google confirmed it would adopt the standard in April 2025, and OpenAI added support to ChatGPT the same year. See the official documentation for the full spec.
What Are Agent Skills?
Agent Skills are folders — typically one markdown file plus optional scripts — giving Claude step-by-step instructions for a task, loaded automatically only when relevant. Anthropic introduced the format in October 2025. Each skill centers on a file called SKILL.md, built from plain YAML metadata and a body of instructions Claude reads like a procedure manual.
What makes a skill cheap to keep around is how it loads. Anthropic’s own documentation describes three stages:
- Metadata — a skill’s name and description sit in context at all times, at roughly 100 tokens each.
- Instructions — the SKILL.md body, usually under 5,000 tokens, loads once Claude decides the skill is relevant.
- Resources — reference files or scripts stay on disk, costing nothing until Claude actually opens one.
A hundred idle skills barely dent a context window this way, since only the matching skill’s instructions and resources ever get pulled in. Skills are built for knowledge that doesn’t change from one request to the next: a team’s checklist for auditing a new contract before mainnet, a house style for writing incident reports, the exact order in which a project wants its tests run. There’s no server to host and no protocol to implement — just a markdown file describing the procedure, plus whatever scripts the task needs.
This is often shortened to Claude agent skills vs. MCP in search, though the format isn’t exclusive to Claude — Anthropic published it as an open specification too.
What Is llms.txt, and Where Does It Fit?
llms.txt is a plain markdown file placed at a website’s root — a documentation site might publish one at docs.example.com/llms.txt — that gives AI tools a short, structured map of a site’s content instead of leaving them to parse navigation and ad markup out of raw HTML. Jeremy Howard proposed the format in September 2024; a revised version 2 shipped on August 10, 2026. The file typically lists a short project description followed by links to a site’s key pages, often pointing to plain-markdown versions rather than the styled HTML a browser renders.
The distinction from MCP and Agent Skills is worth being precise about: llms.txt doesn’t give an agent any new capability, and it isn’t specific to Claude or any other model. It’s descriptive, not functional — a signpost, not a tool call — and any AI system that bothers to fetch it can use it, from a coding assistant indexing a project’s docs to a general web-browsing agent.
Adoption has moved fast: OpenAI, Anthropic, and Google all publish their own llms.txt files, and platforms like Mintlify now generate one automatically for every site they host. For a blockchain project with API references spread across dozens of network-specific pages, that’s a low-effort way to make the whole set legible to any AI tool at once.
Why Do AI Coding Agents Need Any of This?
Here’s the problem underneath all three: a language model’s training data has a cutoff date, with no live connection to anything by default. It doesn’t know a wallet’s balance right now, what gas costs this minute, or how your team likes a pull request structured — that has to come from somewhere outside the model.
Before MCP, closing that gap meant hand-building a plugin for every tool-and-data-source pairing: one integration for Slack, another for a Postgres database, another for each blockchain’s RPC. That’s an N-times-M problem — N assistants, M data sources, a custom connector for every combination. MCP collapses it to roughly N-plus-M: build one server per data source, and every MCP-compatible assistant can use it.
Blockchain magnifies that math. A multi-chain product might need data from dozens of networks — NOWNodes alone lists support for 120-plus — each with its own RPC quirks and rate limits, so a bespoke integration per network per tool was never realistic. That’s the execution half of the problem; the other half is procedural, making sure an agent follows your team’s actual process once it has the data, which is where Skills and llms.txt come in.
Who Actually Uses Agent Skills, MCP, and llms.txt?
The honest answer is anyone building software with an AI coding assistant in the loop, but the split gets clearer once you look at specific blockchain roles. A few patterns show up consistently:
- Wallet and exchange teams reach for MCP when a support agent needs live balances, pending transactions, or deposit confirmations, not static documentation.
- Smart-contract and protocol teams encode Skills for the parts of their process that don’t change chain to chain — a pre-deployment checklist, an audit-writeup style guide, how to verify a contract address before interacting with it.
- Trading and analytics builders typically need both: MCP for the live feed, a Skill for the logic a strategy follows once new data arrives.
- Docs and developer-relations teams publish llms.txt so any AI assistant, not just one wired to a specific MCP server, can find integration guides without scraping styled HTML.
NOWNodes is one concrete example of the first category. Its MCP Server connects assistants including Claude Desktop, Claude Code, Cursor, VS Code, and Windsurf to blockchain API references across 120-plus networks, generating request examples in curl, JavaScript, and Python. It doesn’t hand an agent standing control over a wallet or a chain — it supplies documentation-backed context so a developer can build the right request faster.
A monitoring agent reacting the instant a new block lands looks more like a persistent WebSocket subscription than a one-off tool call, though both can sit behind the same MCP server. For the wider set of ways AI touches a blockchain build, see how developers are using AI tools across blockchain development.
Where Do Agent Skills and MCP Diverge?
Strip away the implementation details and the agent skills vs. MCP difference comes down to knowledge versus execution. Anthropic’s own developer blog puts it plainly: “MCP connects Claude to data; Skills teach Claude what to do with that data.” One is a live wire to the outside world; the other is a memory of how to use whatever comes through that wire.
| MCP | Agent Skills | |
|---|---|---|
| What it is | An open protocol connecting an agent to external tools and data through a server | A markdown file (SKILL.md) plus optional scripts, loaded on demand |
| Best for | Live, changing data and actions — balances, blocks, broadcasting transactions | Stable, repeatable procedures — checklists, style, workflows |
| Setup | Hosting a server, plus auth and transport configuration | Writing a markdown file; no server or hosting involved |
| Typical context cost | Full tool schemas load upfront — tens of thousands of tokens for a large server | About 100 tokens until triggered, then under 5,000 |
| Maintenance | Centralized — the server owner’s update reaches every connected agent at once | Manual — each file is edited and version-controlled like code |
| Blockchain example | Reading a live balance or broadcasting a signed transaction | Encoding a contract-audit checklist or an address-verification routine |
The context-cost gap is bigger than it sounds in practice. Janakiram MSV explored the skills vs. MCP agent architecture question in The New Stack, measuring a GitHub MCP server’s tool definitions at roughly 23,000 to 50,000 tokens against 200 to 500 tokens for an equivalent skill file — close to two orders of magnitude apart. One real-world setup he cites runs 12 skill files, about 2,000 lines of markdown, connected to 8 separate MCP servers.
Maintenance favors Skills in one specific way: a markdown file lives in a normal git repository and goes through the same pull-request review as any other code, where an MCP server’s behavior changes by editing and redeploying the server itself. Simon Willison, an independent software engineer who writes widely on AI tooling, went further after Skills shipped: “I expect we’ll see a Cambrian explosion in Skills which will make this year’s MCP rush look pedestrian by comparison.”
Which One Does Your AI Agent Need?
MCP vs. agent skills — which does your AI agent actually need? The honest answer is “it depends on the job,” but a few rules of thumb make the choice fast. Reach for MCP when an agent needs something true right now: a balance, the current block height, a transaction that has to broadcast. Reach for a Skill when the need is procedural and stable — the same checklist, the same style, the same verification steps every time, regardless of which chain is involved.
In practice, the two compose rather than compete. A contract-audit skill can define the procedure — check the verified source, compare it against a known-vulnerability checklist, flag anything unusual — while calling an MCP server mid-procedure to pull the live contract state it needs. Neither replaces the other; the skill supplies the judgment, the protocol supplies the connection.
None of the three is free of failure modes, either. A skill only fires if Claude matches the task to its description correctly, so a vaguely written skill can simply never trigger. An MCP server is a live dependency — if it goes down, the agent loses that capability until it’s back, whereas an inert skill file just sits there unused. llms.txt, meanwhile, is entirely voluntary: nothing forces a crawler or agent to respect it, so it works as guidance, not access control.
Conclusion
None of this is a competition with a single winner. MCP handles the part of an AI agent’s job that has to stay current — a live balance, a broadcast transaction, a watched mempool. Agent Skills handle the part that has to stay consistent — the checklist, the style, the verification step nobody wants skipped. llms.txt handles a narrower job before either is even involved: making sure an AI tool can find your content at all.
For a blockchain team, the practical starting point is usually MCP, since live chain data is the one thing a generic assistant has no other way to reach. Skills tend to get added once a team notices the same instructions being retyped into every prompt, and llms.txt is worth the half hour it takes to publish either way. Treated as three separate tools for three separate jobs, rather than competing standards, they stop being confusing fairly quickly.
FAQ
Is MCP the Same Thing as an API?
Not quite. An API is the interface a service exposes; MCP is a standard way for an AI agent to discover and call whatever APIs a server exposes as “tools,” without custom code for each one. Think of MCP as a common adapter in front of many APIs, not a replacement for them.
Can Agent Skills Work Without Any MCP Server Connected?
Yes. A skill encoding a writing style, a testing checklist, or a code-review routine needs no live data source, and plenty of skills run entirely on what’s already in the conversation or filesystem. MCP only becomes necessary once the task needs something outside that — a live price, a current balance, an action on a remote system.
Can You Run Your Own MCP Server Instead of Using a Third-Party One?
Yes — MCP is an open specification, and Anthropic publishes SDKs for building a server in Python, TypeScript, and other languages. Teams do this when they need tools tied to internal systems a third-party server wouldn’t reach, such as a proprietary database or deployment pipeline, while still relying on third-party servers for things like blockchain data.
Do I Need to Be a Developer to Write an Agent Skill?
Not necessarily. A skill’s core is a markdown file with plain-language instructions — closer to writing documentation than code — though one with scripts needs someone comfortable writing them. Setting up an MCP server is the bigger technical lift, since it involves hosting, authentication, and an actual running service.
