The previous chapter covers what MCP is and shows a thirty-line server. This one is what changes when it has to run inside a company — and it starts with the job market, because the premise is worth checking.

The transport, the auth and the hosting are ordinary web engineering. What changes is the consumer — and it changes every design decision downstream.

Two terms, in case they are not familiar. A REST API is the ordinary web interface most systems expose — a URL identifies a thing, and the HTTP method says what to do with it. An OpenAPI specification is its machine-readable description: every endpoint, parameter and response shape, in a file. MCP is the equivalent description aimed at a model rather than a programmer — which is exactly why generating one from the other does not work.

Take the granularity row, because it is the one that decides whether the thing works. A REST API exposes GET /customers/{id}, GET /customers/{id}/orders, GET /orders/{id}/items, and a developer composes them. An agent composing three calls burns three round trips, three sets of tokens, and three chances to pick the wrong one. One tool called get_customer_order_history(email) that does the joins server-side is a better tool, even though it would be a worse REST API.

# The enterprise shape. The plumbing is ordinary; the marked lines are not.

@mcp.tool()
def find_orders(customer_email: str, status: str | None = None, limit: int = 20) -> str:
    """Find a customer's orders. Returns order ID, date, status, total and item count.

    Use this when the user asks about an order's status or purchase history.
    Do NOT use it to modify an order — use update_order for that.
    """
    # ^ THE DOCSTRING IS THE API. It is what the model reads to decide whether
    #   to call this and with what. Changing it changes behaviour: version it.

    user = current_user()                      # 1. WHO is this actually for?
    token = exchange_token(                    # 2. downscope, per call
        subject=user.token, resource="orders-api", scope="orders:read")

    limit = min(limit, 50)                     # 3. bounded by the SERVER,
                                               #    never by trusting the model
    try:
        rows = orders_api.search(email=customer_email, status=status,
                                 limit=limit, token=token)
    except NotFound:
        # 4. errors are prompts — say what to do next, not what broke
        return (f"No customer found with email {customer_email}. "
                f"Use find_customer(name) to look up their address first.")
    except Forbidden:
        # 5. and NEVER leak existence you have not authorised
        return "You do not have access to this customer's orders."

    log.info("mcp.find_orders", actor=user.id, agent=agent_id(),   # 6. both IDs
             count=len(rows))
    return format_rows(rows, fields=("id","date","status","total","items"))
    #                              ^ 7. six fields, not forty

• It is a production service. Health checks, deploys, on-call, an SLO. An MCP server that goes down takes every agent depending on it with it, and nobody will have put it in the dependency map.
• Rate limits belong on the server. An agent in a loop will call your tool far faster and far more repetitively than a human ever would.
• Log the actor chain, not just the call. Which agent, for which person, with what arguments. Without it an incident is uninvestigable — the same point as the audit line in the agent-authorisation chapter.
• Test the descriptions, not only the functions. Your unit tests prove the code works; they say nothing about whether a model picks the right tool. Add a small evaluation set of realistic requests and assert which tool gets chosen — see the eval chapter. This is the test nobody writes and the failure everybody has.
• Publish it somewhere findable, with an owner. The registry problem arrives faster than you expect — see enterprise agent platforms.

A fair question, and the answer is often no.

• If one team wants one integration, a plain function in their agent is simpler and you can delete it later. MCP earns its keep when several clients need the same capability.
• If the capability is a deterministic workflow with known steps, that is automation, not a tool for a model to reason with.
• Build one when multiple agents or teams need the same system, you want the access control and audit in one place rather than replicated, and you would otherwise be writing the same integration for the third time.
• The strongest argument for a central MCP server is not reuse. It is that the authorisation and the logging live in one reviewable place instead of five.