What a Context Engineer Puts in Front of the Model

An assistant can search the public web. What comes back is whatever a search engine has already indexed: a tutorial, an older post, your docs if they happen to rank, or someone else's write-up of a similar product.

That search does not return the rest of your knowledge stack. A decision that still lives in a review document. A private repository. The support thread from this week. A behavior you changed and have not described in public yet. Context engineering is the work of putting that stack where an implementation can ask for it.

A technical writer already makes this material clear for a person who comes looking. A context engineer places the same material at the moment a change is designed or built, on MCP servers the tools can call. That placement is how a technical writer moves into context engineering.

What context engineering is

Context engineering is three decisions about knowledge you already hold.

Which questions the work depends on. What you promise. Why it is built this way. How this codebase does it. What customers are running into now.

Which source answers each question. The passage should come from your stack, not from a public average of products that happen to look like yours.

Which moment that source is for. Planning a change, writing it, reviewing it, and helping someone use what shipped are different questions. They should not all receive the same pile of pages.

The result is a set of MCP servers, one job each. An implementation asks the server for that moment and receives a short passage from your material, plus the page the passage came from. The person reviewing the change can open that page and see whether the work followed it.

Your stack is a different source than the public web

Public search is the right tool for what the world has published. Your stack is everything the world does not have, and anything you would rather hand over yourself even when a copy is already public.

What you hold	What a public search returns instead
Your current docs and changelog	An older page, or your page mixed with someone else's tutorial
The repository	Nothing, when the repository is private. A generic pattern, when the assistant is not pointed at how this codebase does the thing
Decision records and design reviews	Nothing. These are usually internal, and they are the reason a rule exists
Support notes and runbooks	Nothing. This is where this month's customer questions actually are

A public documentation site is a different input when it comes from your server. You chose the current page, and the reply can cite it. A search result chose whatever ranked.

What this changes for the product

An implementation written from your passage follows your product. Payment writes carry the idempotency key you require. A field the changelog has not announced stays out of the API. The service that owns refunds is the one your decision record names. An implementation written from a public tutorial follows the pattern that tutorial used, which may be a product you do not ship.

Customers meet that difference directly. Guidance that matches the product lets them finish the task in front of them. That completed path is what usage and adoption are: someone gets through the product you offer. Guidance that describes a path you do not have stops them, or it sends them to ask for something you never built. Keeping the assistant on your pages is how the product they were told about and the product they opened stay the same thing.

Expectations move as fast as the tools customers use. A question that showed up in support this week, or a behavior you changed in the changelog, is the current expectation. Those sources belong on a server you refresh when they change. The next implementation, and the next answer a customer receives, reads the updated page. A search result keeps returning whatever is already indexed.

From technical writer to context engineer

The writing stays. Pages still have to be clear, specific, and accurate, with one question answered in one place and the rule stated where a passage can carry it. What is added is a decision about each page: at which moment in the work it should be the one that gets asked, and how you will know that it was.

Publishing so a person can find the page is the writer's job. Maintaining the address an implementation calls, and reading the questions that came back empty, is the context engineer's job. An empty question is often a customer expectation that moved before the page did. Writing that page and putting it on the server for that moment is the work that sits between the two roles.

You do not need a new title for the work to be real. A writer who can point to the server, the question it answers, and a citation in the implementation is already doing it.

Set up a server for each part of the stack

Start from the questions, not from the tools.

1. Collect the questions implementations keep missing, and the questions customers keep asking. Sort them into four kinds: what you promise, why it is this way, how it is done here, and what just happened.
2. Name the source that already holds the answer. A docs URL, a repository, a decision record, a runbook, or a file you can upload.
3. Group sources that answer the same kind of question onto one server. A useful split is Product, Decisions, Codebase, and Operations. Draw the lines where your own work divides. Some teams want a server per product area instead. The test is whether a person at that moment can name the question the server should answer.

Then build the servers.

4. In Context MCP Studio, add the source, choose the tools, and deploy. The source guide covers a documentation URL, a GitHub repository, an uploaded file, and another MCP server. You get one endpoint, and each answer cites its page.
5. If the source should stay inside the company, make the server private. A private server requires an access token before it answers, including when a client asks which tools it has.
6. Connect the endpoint where the implementation happens. Ask a question you already know the answer to. The citation should be your page.
7. When the product or the expectation changes, update the source and refresh it. The next request sees the new page, in every tool pointed at that server.

How you know the stack is being used

A server that nobody asks never meets the implementation. On any account, the dashboard shows how often a server is asked and how that changes over time. The Action analytics add the passage that came back, and they mark requests that came back empty or only weakly matched. The analytics guide describes each view.

Empty and weak requests are the expectations you have not written down yet, or pages written so the question cannot find them. Fix the page, refresh the source, and ask again. That is how the stack stays current as customers change what they expect.

What this does not do

Your server contributes your pages. The assistant can still draw on the public web for anything you did not put there, which is why the citation matters: a reviewer can see whether the work followed your page.

The server returns what you placed in it. A decision that lives only in a meeting informs nothing until someone writes it down. And the four-way split above fits a lot of product teams. A company whose work divides differently should divide the servers the same way.

The same servers, seen from the boundaries of the system rather than from the pages, are the subject of the context a software architect keeps with the stack.

Start with the question a customer asked this week that your public pages do not answer. Give that source one server. MCP Studio takes a docs URL, a repository, or a file and returns an endpoint the implementation can call.