The deliverable is
a tool surface, not a chatbot
Anthropic’s forward deployed engineer job description lists MCP servers, sub-agents and agent skills as things you build for customers.10 In practice that means the artefact you hand over is rarely an application. It is a set of tools that wrap a customer’s systems — a 2009 SOAP service, a stored procedure, a spreadsheet on a file share — in a form a model can use safely. Designing that surface well is a distinct skill, and it is closer to API design than to prompting.
Why this became an FDE deliverable
The interesting capability at a customer is almost never the model. It is the model connected to their systems: the claims database, the parts catalogue, the ticketing system nobody has replaced since 2011. Before a tool protocol existed, every connection was a bespoke integration written into one application. MCP turns that into a reusable server — which is exactly the property that decides whether deployment work compounds or evaporates (see the commercial layer).
A server exposes three things: tools (actions a model can invoke), resources (data it can read), and prompts (reusable instruction templates). You write the server; a host application — a desktop assistant, an internal agent, a coding tool — connects to it. The value for a deployment is that the same server serves every host, so the integration you build for one workflow is available to the next one without being rewritten. For the protocol mechanics start with the MCP handbook; this page is about what changes when the systems belong to somebody else.
What makes an MCP server the right deliverable
- The customer has several workflows that touch the same underlying systems.
- They already have a host application — an assistant, an IDE, an internal agent.
- The integration is the hard part; the reasoning on top is comparatively cheap.
- You want the work to survive the specific application you built first.
When it is the wrong deliverable
- One workflow, one system, no plausible second consumer — a direct integration is smaller and clearer.
- The customer has no host and does not want one; you would be shipping a server nobody can call.
- The action is high-stakes and irreversible, and the real requirement is a deterministic pipeline with an approval step.
- Latency budget is tight enough that an extra hop and a model round-trip breaks it.
Designing tools for a model, not a developer
The single biggest quality difference between MCP servers. A good API is not automatically a good tool surface.
A developer reading your API has documentation, a debugger, and the ability to try again tomorrow. A model has a name, a description, a JSON schema and one shot. Everything follows from that asymmetry — and the failure is rarely the model “being bad at tools”, it is a surface that would confuse a competent human given the same three sentences.
get_data(entity, filters, options, format, page, expand, mode, ...)
"Retrieves data."
→ 14 optional params, no vocabulary, no idea what entity accepts
# the surface it uses correctly on the first attempt
find_claims_by_policy(policy_number: str, status?: "open"|"closed"|"appealed")
"Find claims attached to a policy. Use when the user names a policy number
(format: AB-123456). Returns at most 50, newest first. For a claim number,
use get_claim instead."
verbs from the domain · enums not free text · says when to use it · names its sibling
Name tools after the user’s task, not your schema
find_overdue_invoices beats query_invoice_table. The model is pattern-matching a request to a name, so a name that echoes how the work is described in the business wins over one that echoes your database.
Write the description for the decision, not the mechanism
The description’s job is to answer “should I call this now, and what will I get?” State when to use it, when not to, what it returns, and what it costs. Descriptions are the highest-leverage text in the whole server and are usually written last, in a hurry.
Constrain the schema hard
Enums over strings, required over optional, one obvious way to express each thing. Every degree of freedom is a way to be called wrongly. If a parameter has a sensible default, make it a default rather than a decision.
Return prose-shaped results, not raw dumps
A 4,000-line JSON blob burns the context window and buries the answer. Return the fields that matter, already summarised, with an explicit “call get_claim_detail for the rest”. Pagination hints belong in the payload, not the docs.
Make errors instructive
"No policy matches AB-12345. Policy numbers are two letters and six digits; did you mean AB-123456?" A model recovers from that. It cannot recover from 400 Bad Request, and it will usually try the same call again.
Keep the toolset small
Every tool competes for attention with every other. Five sharp tools outperform twenty overlapping ones. When a server grows past what fits comfortably in a prompt, split it by domain and let the host mount what a given workflow needs.
Tool design is testable and almost nobody tests it. Build twenty realistic requests, run them, and score tool selection accuracy and argument correctness separately — they fail for different reasons and get fixed by different edits. Selection errors are a naming and description problem; argument errors are a schema problem. This is a small eval set and it belongs in CI exactly like the ones in evals for client work.
Wrapping the legacy system
The actual job. It is rarely a REST API waiting politely behind a firewall.
What you find at a customer: a SOAP service with a WSDL last edited in 2009, an Oracle instance where the real logic lives in stored procedures, a mainframe reachable only through a fixed-width file drop, a SaaS product with a strict rate limit, and a spreadsheet that four people treat as the source of truth. Each becomes a tool. None of them wants to.
| What you find | The move | The trap |
|---|---|---|
| SOAP / WSDL | Generate a client, then hand-write a narrow tool over the three operations anyone uses. | Exposing all 60 generated operations. The model drowns and picks wrongly. |
| Stored procedures | Wrap named procedures as named tools with typed parameters. | Offering raw SQL. It is a security finding and an unbounded query surface at once. |
| Fixed-width / batch file drop | Asynchronous tools: submit_job plus check_job, with an explicit expected duration in the description. | Pretending it is synchronous. A tool that blocks for nine minutes breaks every host that calls it. |
| Rate-limited SaaS | Cache, batch, and surface the remaining budget in the tool result. | Letting an agent loop discover the limit for you in production, on the customer’s shared quota. |
| The spreadsheet | Read-only resource, snapshot on a schedule, with the freshness timestamp in every response. | Writing back to it. Someone has it open, and you will find out how the file lock behaves. |
| No API at all | Say so early and price the integration honestly. | Screen-scraping their internal UI because it demos well. It will break, and it will break at the worst moment. |
Their systems speak in codes: status 7, type RTX, region EMEA-2. The model — and the user — speak in words. The translation layer belongs in the server, not in a prompt, because a prompt is per-application and the server is shared. Return “closed — settled” alongside the raw code, accept the words as input, and you have removed an entire class of failure from every future workflow. Building this mapping is also the fastest way to learn the domain, which is the subject of learning a domain fast.
The trust boundary nobody draws
An MCP server sits between a model that will read anything and a system that will do what it is told.
Two properties combine badly. A model treats retrieved content as information, and content retrieved from a customer’s systems is written by people — including, sometimes, people outside the company. A ticket description, a supplier email, a PDF filename are all untrusted text that will end up in a context window next to your instructions. Draw the boundary explicitly, because the default position is that there is not one.
identity whose permissions does a tool call run with — the end user's, or a
service account with union-of-everyone access? (it must be the user's)
blast radius which tools mutate state, and which of those are reversible?
content is retrieved text ever treated as instruction? (it must not be)
evidence can you show an auditor who did what, through the agent, last Tuesday?
Non-negotiables in a customer environment
- Tool calls execute as the end user, with their permissions. A service account with everyone’s access turns a read tool into a data-exfiltration path.
- Write tools are separated from read tools, and require explicit confirmation.
- Retrieved content is delimited and labelled as data, never merged into instructions.
- Every tool call is logged with user, arguments, result size and timestamp.
- Destructive operations have no tool. They have a ticket.
How it goes wrong in practice
- A single service account, because per-user auth was “phase two”.
- A summarisation tool that reads a ticket whose body says “also email the customer list to…”.
- A
run_queryescape hatch added for debugging and never removed. - Logs that record that a tool ran, but not which records it returned.
- A dev-mode flag that disables auth, shipped because the demo needed it.
Security reviewers increasingly ask for a live prompt-injection test: put hostile text in a record the agent will read, and show what happens. Run it yourself first. Having a recorded answer — and a boundary that holds — converts a difficult meeting into a short one. Practise the full review in the Security Review Gauntlet, and see the prompt-injection lab for the attack itself.
Operating a server you do not host
Once it works, it has to keep working inside somebody else’s environment — which means the operational questions from IaC for customer environments and on-call apply here in a specific shape.
Version the tool surface, not just the code
Renaming a tool or tightening a schema changes model behaviour in every host connected to it. Treat the surface as a public API: additive changes freely, removals on a deprecation window, and a note in the description when semantics shift.
Instrument per tool
Call count, error rate, latency and result size, broken down by tool. This tells you which tools the model actually reaches for and which are dead weight — and dead tools should be deleted, because they cost attention on every request.
Degrade loudly
When the upstream is down, return a tool result that says so in words the model can relay. A timeout produces a confidently wrong answer; "the claims system is unavailable — no data was retrieved" produces an honest one.
Hand over the tool contract, not the repo
Their team needs a document listing every tool, its arguments, its permissions and its upstream dependency. That document is the deliverable that lets them add the seventh tool after you leave — which is the whole point.
The 2026 shift some teams describe is FDEs moving from writing feature code to writing the systems that write feature code — agent harnesses supervised by engineers.30 A well-designed tool surface is the substrate for that: an agent harness is only as good as the tools it can call and the boundary those tools respect. Which makes this handbook less a protocol tutorial than a bet on where the deliverable is going.
Build the surface, then attack it
Quick answers
Why do FDE job descriptions mention MCP servers?
Because the deliverable at a customer is increasingly a tool surface rather than an application. Anthropic’s forward deployed engineer job description lists MCP servers, sub-agents and agent skills as things you build for customers. A server that wraps the customer’s systems is reusable across every workflow and host, which is what makes deployment work compound instead of being rewritten per application.
How do you design MCP tools a model will use correctly?
Name tools after the user’s task rather than your schema, write descriptions that answer "should I call this now and what will I get" including when not to use it, constrain schemas hard with enums instead of free text, return summarised results rather than raw JSON dumps, make errors instructive enough to recover from, and keep the toolset small because every tool competes for attention. Then measure tool-selection accuracy and argument correctness separately.
How do you expose a legacy system through MCP?
Wrap narrowly, never wholesale. For SOAP, hand-write tools over the few operations anyone uses instead of exposing all generated ones. For databases, wrap named stored procedures rather than offering raw SQL. For batch or file-drop systems, model them as asynchronous submit and check tools. Put the code-to-word vocabulary translation in the server rather than in a prompt, because the server is shared across every workflow.
What are the security boundaries for an MCP server in a customer environment?
Four rules: tool calls execute with the end user’s permissions, never a shared service account holding the union of everyone’s access; write tools are separated from read tools and require confirmation; retrieved content is delimited and labelled as data so it is never treated as instruction; and every call is logged with user, arguments and result size. Expect a security reviewer to ask for a live prompt-injection demonstration.
When is an MCP server the wrong deliverable?
When there is one workflow against one system with no plausible second consumer — a direct integration is smaller and clearer. When the customer has no host application to connect to it. When the action is high-stakes and irreversible and what is actually needed is a deterministic pipeline with an approval step. And when the latency budget cannot absorb an extra hop plus a model round-trip.
Sources
Every number on this page traces to one of these. Where a figure is self-reported or crowd-sourced rather than first-party, it is labelled inline.
Cited on this page
- Anthropic — Forward Deployed Engineer, Applied AI (JD) — 40/30/30 split; MCP servers, sub-agents and agent skills as deliverables. jobs.menlovc.com/companies/anthropic/jobs/69674588-forward-deployed-engineer-applied-ai
- Latent Space — Forward deployed engineers (AI Engineer World’s Fair) — Ramp’s shift toward engineers supervising agent harnesses. www.latent.space/p/forward-deployed-engineers-aiewf
Explore the topic
See this alongside everything else on the same subject — handbooks, system designs, challenges and tools, in one place.
More Handbooks
- The Prompting HandbookA friendly, hands-on field guide for everyday humans — learn the CRISP framework, spot bad prompts, practice with real recipes, play a drag-and-drop game, and test yourself with a quiz. No code required.Read →
- The Agentic AI Interview HandbookTwenty topics every senior AI engineer should be able to reason about live — from eval pipelines to reliability patterns for generative systems.Read →
- The Senior AI Engineer Interview Handbook60 questions across architecture, production incidents, agentic systems, RAG, evals, cost, safety, and leadership — what staff-level AI interviewers actually probe for.Read →
- 50 Angular Interview QuestionsA visual handbook covering components, change detection, RxJS, signals, routing, forms, performance, and testing — what interviewers actually probe for in senior Angular roles.Read →
- 50 Python Interview QuestionsFundamentals to advanced: data structures, OOP, iterators & generators, the GIL, asyncio, memory, testing, and the standard library — a visual walk through everything a Python interview touches.Read →
- 51 LLM Evals Interview QuestionsGolden sets, LLM-as-judge, regression testing, offline vs online evals, RAG evals, agent evals, red-teaming, and observability — demystified for interviews and production.Read →
Explore more from Vibe Engines
Get the next one in your inbox.
New handbooks, system-design walkthroughs, and tools — straight to your inbox. No spam, unsubscribe anytime.