Field Noteson AI
Back to the shelf

Field Notes

Skills, Tools, and MCP Servers

Ani · 2025 · 8 pages

The vocabulary of the agent world decoded. What's a tool, a skill, a server, a capability? How they compose into systems that can actually automate complex work.

The agent ecosystem has a vocabulary problem. Everyone uses "tools," "skills," "servers," and "capabilities" to mean slightly different things, often interchangeably. This is the definitive breakdown of what each term actually means and how they compose.

Tools

A tool is a function an AI model can call. It has a name, a description, a set of typed parameters, and it returns a result.

name: search_web
description: Search the internet for current information
parameters:
  query: string (required) — the search query
  num_results: integer (optional, default 5) — number of results
returns: list of {title, url, snippet}

When the model receives a tool definition, it can decide — based on the conversation — whether to call it. If it decides yes, it produces a structured tool call: search_web(query="MCP protocol 2025"). Your code executes the function and returns the result to the model.

Tools are stateless. Each call is independent. The model can call the same tool multiple times with different inputs. There's no persistent connection between tool calls.

Skills

Skill is a looser term used differently in different contexts. In most usage, a skill is a higher-level capability built on top of one or more tools — a pattern of behavior the agent has been configured to perform well.

Example: a "research skill" might involve calling search_web, then read_page for the top results, then summarize_content. The individual tools are atomic. The skill is the coordinated use of them to accomplish a specific type of task.

Some frameworks (including Claude Code's own skill system) use "skill" to mean a reusable prompt + behavior pattern that gets loaded into the agent's context when needed. This is a useful pattern: skills are plugins for agent behavior.

In practice: tools are the atomic functions; skills are the workflows built on top of them.

MCP Servers

An MCP server is a process that exposes tools (and resources, and prompts) over the Model Context Protocol. It's the host for tools — the thing that actually runs the functions when the model calls them.

One MCP server can expose many tools. A PostgreSQL MCP server might expose:

  • query_database — run a SELECT query
  • list_tables — list available tables
  • describe_table — get schema for a table
  • insert_record — insert a new row

The server handles the actual database connection, query execution, and result formatting. The AI client just calls tools; the server does the work.

The important properties of MCP servers:

Process isolation. The server runs as a separate process from the AI client. It has its own environment, its own credentials, its own lifecycle.

Protocol standardization. Any MCP client can connect to any MCP server. Write a server once; use it with any MCP-compatible AI product.

Transport flexibility. MCP servers communicate over stdio (for local tools) or HTTP/SSE (for remote tools). Same protocol, different transports.

Resources

Resources are a distinct MCP concept: data sources the model can read but not call as functions. File contents, database records, API responses.

The distinction from tools: resources are read-only context. Tools are callable functions that may have side effects. An MCP server can expose both: a filesystem server might expose read_file as a resource (the model reads the contents) and write_file as a tool (the model calls it to modify files).

Prompts

MCP servers can also expose prompts — reusable prompt templates. A server might expose a analyze_competitor prompt that takes a company name as input and returns a structured prompt designed to make good use of the server's other tools for competitive analysis.

This is less commonly used than tools and resources, but it's part of the protocol. It allows server authors to encode best practices for using their tools directly in the server.

How they compose

A complete agent setup looks like this:

  • Host (Claude Desktop, your custom app) connects to several MCP servers
  • Each server exposes tools and resources
  • Skills define patterns for how the agent uses tools together to accomplish tasks
  • The model decides which tools to call based on the task and the tool descriptions

The composition is what makes agents powerful. An agent with access to a database server, a web server, a communication server, and a file server can accomplish surprisingly complex tasks by chaining tool calls.

Practical naming convention

When you're designing your own agent infrastructure, use this convention:

  • Tool — a single callable function. Verb-noun: create_record, search_documents, send_message.
  • Server — a process exposing a set of related tools. Named for the system: postgres-server, slack-server, filesystem-server.
  • Skill — a higher-level behavioral pattern. Named for the capability: research, data-analysis, outreach.
  • Capability — the union of everything the agent can do. "This agent has research, data-analysis, and communication capabilities."

Clear naming makes systems easier to reason about, debug, and explain to stakeholders who aren't deep in the implementation.

Published under Field Notes. Not for sale. Share freely.