What do developers mean by context, skills, and MCP servers?

What do developers mean by context, skills, and MCP servers?

Context, skills, and MCP servers are the three levers developers use to control what an AI agent can see and what it can touch. Context is everything the model is shown before it works. A skill is a packaged set of instructions the agent loads for a certain kind of task. An MCP server is the socket that connects the agent to a real system, such as a database or a ticket tracker.

The previous lesson covered how much a coding agent does on its own. This one covers why the same agent performs brilliantly on one team and poorly on another. The model is identical in both places. The difference is what each team feeds it and wires it to, and that feeding and wiring is where the engineering effort now goes.

What is context?

Context is everything a model is shown before it produces an answer: the request itself, the relevant code, the instructions it should follow, and the results of earlier steps. A large language model knows nothing outside its context. It was trained on a snapshot of public text, so it has never seen this company's codebase, this team's conventions, or what happened in the conversation five minutes ago, unless someone puts those things in front of it.

The space that holds it all is the context window, covered in the model lesson. Everything an agent learns during a session lives there: each file it reads, each command result, each correction from the developer. When a coding agent "reads the codebase", what actually happens is that selected pieces of the codebase get placed into its context.

This is why context is the limiting factor. An agent with a strong model and poor context produces confident work that misses how this team does things. The model can only be as informed as the material in front of it.

What is context engineering?

Context engineering is the craft of choosing what goes into the model's context and what stays out. Which files does the agent get to see? Which instructions? Which examples of past work? Which results from a database lookup or a search? Someone decides all of that, and the deciding is the work.

The phrase largely replaced "prompt engineering" during 2025, and the change in name tracks a change in the work. A prompt is one written request. Context is the whole environment around the request: standing instructions, retrieved documents, tool results, conversation history. Early on, getting good output meant wording one request carefully. Now it means building the system that assembles the right material for every request automatically. RAG, from the plumbing lesson, is one piece of such a system: it retrieves relevant documents and places them into context at the moment they are needed.

On a resume, "prompt engineering" describes wording requests well, an ability most developers now have some of. "Context engineering" describes building the assembly system, which is a larger and rarer piece of work.

Why does more context make answers worse?

A stuffed window degrades the answer, which is the least intuitive fact in this lesson. The obvious move is to give the model everything: the whole codebase, all the documentation, every past conversation. Teams that tried it found accuracy drops as the window fills. The relevant material gets diluted by everything around it, and models weigh the middle of a long context less reliably than the ends. Developers call the result "context rot".

Cost compounds the problem. Models charge by the token, for input as well as output, so a full window makes every request more expensive. An agent that rereads an entire codebase on each step burns money for worse answers.

So the craft is curation. A good context pipeline retrieves the five documents that matter and leaves out the five thousand that might. Deciding what to exclude takes as much judgment as deciding what to include, which is why this became a named engineering discipline rather than a setting someone flips once.

What is a skill?

A skill is a packaged set of written instructions an agent loads when it hits a certain kind of task. A team might have a skill for how it deploys, one for how it writes tests, and one for how it formats a pull request. When the agent starts a matching task, it pulls the relevant skill into context and follows it.

Skills exist because of the previous section. Standing instructions for every situation would fill the window with material irrelevant to the task at hand. Packaging instructions by task and loading them on demand keeps the window lean while still giving the agent deep guidance at the right moment.

The detail that matters for hiring is the format. A skill is a text file, usually plain instructions with examples, stored in the repository next to the code. That means skills go through code review, carry version history, and improve over time the way code does. A team's skills are its accumulated judgment about how work should be done there, written down in a form a machine can follow. A developer who writes them well is encoding team conventions into reusable form, and the quality of that writing shows up immediately: unclear instructions produce an agent that follows them wrong, visibly.

What is an MCP server, and what does it connect?

An MCP server, introduced in the plumbing lesson, is a program that exposes one real system to an agent through the Model Context Protocol: a database, a browser, a calendar, a ticket tracker. Context and skills shape what an agent knows. MCP servers determine what it can do. An agent without them can only produce text. With them, it can query records, run searches, file tickets, and check the results of its own actions.

The protocol matters because it is a shared standard. A tool wrapped in an MCP server once becomes usable by any agent that speaks the protocol, so a public catalog of servers has grown to cover thousands of tools. A team building an agent starts from that catalog and writes custom servers only for its own internal systems.

Two more readings to keep straight. An MCP server contains no AI: building one requires no model and no machine-learning background. It is connector work, wrapping an existing API so agents can reach it, and it is a well-scoped project measured in days or weeks. And the protocol is young. Anthropic introduced it in November 2024, so any MCP experience dates from then at the earliest and means months, never years.

What kind of engineering is this work?

Backend engineering, mostly. Context engineering is retrieval, data plumbing, and measurement. Writing skills is precise technical writing that goes through code review. Building MCP servers is API integration. None of it involves training a model, and all of it rests on abilities that existed long before the acronyms did.

That has a direct hiring consequence. A req that mentions "context engineering", "agent tooling", or "MCP integrations" is describing backend-shaped work, so strong candidates come from the large pool of backend developers who moved toward AI, a far bigger pool than research scientists. The qualities that predict success are the ordinary ones: careful data handling, good judgment about what to include and leave out, and the discipline to measure results with evals instead of trusting impressions. The module overview places this lesson among the rest of the toolchain, and the next lesson covers what happens when the agent's work comes back for review.