The Model Context Protocol (MCP) is an open protocol, introduced by Anthropic in 2024, that gives AI applications one standard way to connect to tools and data: a service is wrapped once as an MCP server, and any MCP-compatible application can then use it. Developers who build AI features or agents should learn it, but as part of tool use generally rather than as a specialism, and they should learn its security model at the same time. It is already on employers' lists: of 315 AI and machine learning job ads we collected on 19 September 2026, 28 (9%) named MCP.
This piece explains the protocol in durable terms. The specification and the SDKs are still evolving, so check the current documentation before you build.
What problem does MCP solve?
Before MCP, every AI application that wanted to use a tool, such as a database, an issue tracker or an internal API, needed its own integration for it. Every new application multiplied the number of bespoke connectors, each written slightly differently and maintained separately. MCP replaces that with a shared interface. The tool's owner writes one server; every application that speaks the protocol can use it, from a coding agent in the terminal to a desktop chat assistant to an agent you build yourself.
It builds on the idea of tool use, or function calling, where a model asks your code to run a named function with structured arguments. Our explainer on tool use and function calling covers that mechanism. MCP standardises how those tools are described, discovered and called across applications.
How does MCP work?
Three roles:
- The host is the AI application the user works in, such as an IDE, a chat app or your own agent.
- A client lives inside the host and holds a connection to one server.
- A server exposes capabilities from a system: a database, a SaaS product, the local file system.
Servers can run locally on the user's machine, talking to the host over standard input and output, or remotely over HTTP. A server offers three kinds of capability:
| Capability | What it is | Who decides to use it | Example |
|---|---|---|---|
| Tools | Actions the model can ask to perform | The model, usually with the user's approval | Create a ticket, run a query |
| Resources | Data the application can read into context | The application or the user | A file, a schema, a record |
| Prompts | Reusable templates a user can pick | The user | "Summarise this pull request" |
When a host connects, it asks the server what it offers and gets back names, descriptions and input schemas. The model reads those descriptions to decide what to call, so a server's descriptions are part of your prompt.
A minimal server is short. This is the shape of the official Python SDK at the time of writing:
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("tickets")
@mcp.tool()
def get_ticket(ticket_id: str) -> dict:
"""Return one support ticket by its id. Read-only."""
return lookup_ticket(ticket_id)
if __name__ == "__main__":
mcp.run()
Should you build an MCP server or call an API directly?
It depends on how many applications need the tool and who controls them:
Call the API directly, with ordinary function calling, when:
- One application of yours needs the tool and you control both ends.
- There are a few tools, and they will not be reused elsewhere.
- You want the fewest moving parts to test and deploy.
Build an MCP server when:
- The same tools should work in several AI applications: your agent, your engineers' coding tools and a chat assistant.
- You run a product and want customers' agents to use it without writing their own integration.
- A platform team is exposing internal systems to many agent builders and wants one place to manage access and logging.
Build neither when a plain script or scheduled job would do the task deterministically. An agent with tools is the wrong answer to a problem with no judgement in it.
A server is only as good as the API underneath and the descriptions on top.
What are the security risks of MCP?
Connecting a model to tools means the model's mistakes, and anyone who can influence the model, can now take actions. Four risks matter most:
- Over-broad permissions. A server acts with whatever credentials you give it. Scope each one to the least it needs, start read-only, and require a person's approval for anything that writes, sends, pays or deletes.
- Untrusted tool output. Whatever a tool returns, whether a web page, an email, a ticket or a document, goes into the model's context, and it may contain instructions planted by someone else. That is indirect prompt injection, and it is the central risk of any tool-using system. Treat tool output as data, never as commands, and do not let one tool's output silently trigger another tool's destructive action.
- Untrusted servers. A local server is code running on your machine with your access. Install servers only from sources you trust, pin versions, and watch for tool descriptions that change after you approved them, since a description is an instruction the model will read.
- Weak authentication on remote servers. A remote server that exposes company data needs proper authorisation per user, not a shared secret, and a log of every call.
The practical rule: every tool call should be authorised, logged and, where the action matters, reversible or approved by a person.
Should developers learn MCP?
Yes, if you build AI features, agents or a product that other people's agents might use, and it is a small investment: the core concepts fit in an afternoon and a first server in a day. Keep the job-ad number in proportion, though. MCP appeared in 28 of 315 postings, the same count as the OpenAI API, while agents appeared in 123 (39%) and evals in 73 (23%). Employers want people who can build and check tool-using systems; MCP is one standard way of wiring them, not the whole job. The sample is Hacker News "Who is hiring?" threads for July to September 2026, Remotive and Arbeitnow, it leans towards startups and Europe, and the data is public.
Where should you start this week?
- Connect an existing MCP server to a host you already use, such as a coding agent, and watch which tools it offers and how the model calls them.
- Write a server with one read-only tool over something you own, such as a notes folder or a test database.
- Read your tool descriptions as if you were the model: would you know when to call each one?
- Add one write tool behind an approval step and log every call.
- Feed the server a document containing a planted instruction and check that nothing acts on it.
Where does Square 1 teach this?
MCP and Tool-Using Apps is an on-demand course recorded by an instructor and graded by Nova, the AI tutor: about seven and a half hours across five modules, for developers in Python or TypeScript who have made at least one LLM API call. The graded work is a server with two tools and a resource, a client that uses it, a permission model with tests, and an application on MCP where every tool call is permission-checked. Building with the Claude API covers tool use inside a single application. The Agentic AI Bootcamp is twelve weeks, live on Zoom with one instructor, about 15 hours a week, for people who have already built an LLM application; its protocols-and-tools block covers MCP in depth, with a gate that every tool call is authorised, logged and reversible where it must be. All three are taking a waitlist today. The agentic AI engineer role page describes the work these skills lead to.