Economics,
gateways & futures

Where 103 left off

MCP 103 made the server survive. MCP 104 asks what it costs, who should serve which request, and where the gateways and model-backed tools people are proposing actually fit.

Start from the finished system in MCP 103. This repository adds one small file, src/economics.ts, about twenty-five lines, plus one tool and one endpoint. That file holds two functions and a table: a cost model, a router, and four providers for the router to choose between. Everything the rest of this course argues is tested against those, or is labelled as design where the repository has nothing to run.

What is inherited unchanged

The controls MCP 103 added come along untouched, and three of them matter to the economics that follow. The URL importer resolves a host once, checks the answer, and then connects to that address, so a hostile name cannot pass the check and be re-resolved to a private one. The /api/ops endpoint that reports usage and audit data answers only to an organisation administrator; anyone else gets FORBIDDEN. And a maintenance sweep, cleanupOperationalData() in src/db.ts, keeps the tables from growing without limit.

The four providers

The router has something to choose between because economics.ts declares four execution providers. They are data, not running services. Each states what it can do, how fast and how expensive it is, and what contract it obeys:

export const providers: Provider[] = [
  {
    id: 'teamspace-standard-us',
    vendor: 'teamspace',
    capabilities: ['task.search', 'page.search'],
    semantics: 'teamspace-v1',
    writes: false,
    freshness: 'live',
    residency: 'us',
    mode: 'realtime',
    p95Ms: 450,
    costMicros: 20,
    available: true,
    trust: 'verified',
  },
  {
    id: 'teamspace-priority-us',
    vendor: 'teamspace',
    capabilities: ['task.search', 'page.search', 'task.write'],
    semantics: 'teamspace-v1',
    writes: true,
    freshness: 'live',
    residency: 'us',
    mode: 'realtime',
    p95Ms: 120,
    costMicros: 90,
    available: true,
    trust: 'verified',
  },
  {
    id: 'teamspace-batch-eu',
    vendor: 'teamspace',
    capabilities: ['page.search'],
    semantics: 'teamspace-v1',
    writes: false,
    freshness: 'cached',
    residency: 'eu',
    mode: 'task',
    p95Ms: 8000,
    costMicros: 4,
    available: true,
    trust: 'verified',
  },
  {
    id: 'lookalike-fast',
    vendor: 'other',
    capabilities: ['task.search'],
    semantics: 'other-v2',
    writes: false,
    freshness: 'live',
    residency: 'us',
    mode: 'realtime',
    p95Ms: 60,
    costMicros: 2,
    available: true,
    trust: 'verified',
  },
];

Cost is in micros: millionths of a currency unit per call. Notice that the fourth provider is the cheapest and the fastest. It is there to be a trap, and Chapter 06 shows why the router refuses it.

The new surface, and the old findings

The MCP surface gains one tool, explain_route. The HTTP API gains /api/economics, which returns the lab’s default experiment for an authenticated caller. The executable suite adds router, cost-model, and end-to-end checks for explain_route. Run it for the current count.

$ npm test
✔ an unreachable product API opens the circuit, and calls stop reaching it
✔ a definite refusal from a healthy dependency is not an outage
✔ tenant and team scope known identifiers
✔ viewer cannot mutate
✔ idempotency returns same result and rejects changed arguments
✔ optimistic version rejects stale write
✔ approval is actor and exact-operation bound and single use
✔ router chooses cheapest provider satisfying every hard constraint
✔ router does not substitute a semantically different tool
✔ write routing requires an explicitly write-capable provider
✔ slow task lane is selected only when requested and allowed
✔ cost model separates vendor infrastructure from client model cost
✔ operations data is admin-only and expired operational rows are removed
✔ the address check refuses internal space, including IPv4-mapped IPv6 and shared space
✔ URL import pins the validated address for the TLS connection
✔ a viewer cannot queue a job, and a member on the free plan gets PLAN_REQUIRED
✔ job tools use the same pipeline: a structured error and an audit row
✔ a successful job call is audited too
✔ the job tools now spend rate-limit permits, and throttling is audited as throttled
✔ explain_route goes through the pipeline: it is audited and returns structured content
✔ draft_release_note carries one deadline, budget and route through both internal hops
✔ the /mcp edge answers 401 with a WWW-Authenticate challenge, never a 500
✔ a refused write releases its key, so the same key can be used again
✔ publishing without an approval does not burn the operation key
✔ a failed transaction rolls back both the write and its claim
✔ a completed operation is replayed and its work is not run twice
✔ an operation key stops replaying once the seven-day sweep has removed it
✔ MCP discovery, tool call and resource read work end to end
✔ a reservation that is never settled expires and frees its hold
✔ a reservation is a ceiling: settlement never charges more than was reserved
✔ a worker runs a release-report job for its owner, scoped to the owner’s team
✔ a slow worker cannot complete a job that another worker has taken over
✔ a job that keeps failing is retried, then dead-lettered with its reason
✔ a job whose worker keeps crashing is dead-lettered instead of re-leased forever
✔ the token bucket is shared: two replicas draw from one allowance
✔ the token bucket refills over time
✔ one member cannot hold every slot their organisation has
✔ production refuses to start without its required settings, and says which is missing
✔ rate limits per actor and releases org concurrency
✔ budget reservation is atomic and reconciled
✔ jobs are scoped, leased and completed durably
✔ URL validation blocks private networks
✔ composite hop prevents cycles, excess depth and budget overrun
✔ a refused resource read is a structured not-found, the same as a page that does not exist
ℹ tests 44
ℹ pass 44
ℹ fail 0

src/production.ts is byte-for-byte the file from MCP 103, so everything that course built and fixed applies here unchanged: the shared token bucket, expiring budget holds, the job worker, the wired-in circuit breaker and the numeric address check. This course does not repeat it.

The cost stack

An MCP server is not free to run, and it is not where most of the money goes. Both statements are true, and the difference between them is the interesting part.

When someone asks “what does it cost to run our MCP server?”, they usually picture one line: the compute for the wrapper. There are at least eight, and they scale differently:

• Edge and wrapper compute: the process that receives the request, verifies the token and translates it.
• Product API work: the actual query or business logic behind the tool. Usually the largest server-side line.
• Storage and search, and outbound traffic.
• Observability: logs, metrics and traces, which grow with call volume.
• Abuse control: the limits, budgets and scanning of MCP 103.
• Support: humans explaining why a call was refused.
• A model, if the tool itself calls one (Chapter 08).

Then there is a second ledger that is not yours. The client’s model reads your tool descriptions, sends arguments and reads results, and bills its own operator for the tokens. The two ledgers are added together in the model below only so you can see their relative size.

export function estimateCost(x: CostInput) {
  const vendorPerCall = x.wrapperMicros + x.backendMicros + x.vendorModelMicros;
  const vendorTotal = x.calls * vendorPerCall;
  const clientModel = Math.round(
    (x.clientInputTokens * x.clientMicrosPerMillionInput) / 1_000_000 +
      (x.clientOutputTokens * x.clientMicrosPerMillionOutput) / 1_000_000,
  );
  return {
    vendorPerCall,
    vendorTotal,
    clientModel,
    total: vendorTotal + clientModel,
    shares: {
      vendor: Number((vendorTotal / (vendorTotal + clientModel || 1)).toFixed(3)),
      client: Number((clientModel / (vendorTotal + clientModel || 1)).toFixed(3)),
    },
  };
}

Read it as three lines. vendorPerCall is wrapper plus backend plus any model inside the tool. vendorTotal multiplies by call volume. clientModel prices the tokens the caller’s model consumed. The function returns each, the sum, and the two shares.

$ npm run lab   (the "cost" part of the baseline)
{
  "vendorPerCall": 20,
  "vendorTotal": 200000,
  "clientModel": 9000000,
  "total": 9200000,
  "shares": {
    "vendor": 0.022,
    "client": 0.978
  }
}

With the lab’s placeholders, ten thousand calls cost the vendor 200,000 micros and the client’s model 9,000,000, so the vendor side is about two percent of the total. If micros are millionths of a dollar that is twenty cents against nine dollars. The general shape is the point, not those figures: for a cheap read, the wrapper and the query are small next to the tokens spent deciding to make the call and reading the answer.

Then use the presets. A model inside the tool changes the picture at once, because now the vendor pays for inference on every call. Retries triple the calls multiplies every vendor line by three, and it is worth remembering that an agent can produce that multiplier without a human ever noticing: it retries, fans out, and re-reads. MCP 103’s limits and budgets are what stop that being your bill.

Tiering

Should fast customers and slow customers get different servers? Almost never. They should get one server and different treatment behind it.

A common instinct is to publish a tasks-fast server for paying customers and a tasks-slow one for everyone else. It looks tidy and it causes real trouble. A model now sees two near-identical tools and must choose between them from their names, which it will do badly. Every client integration has to know which to connect to. The two drift apart. The cleaner design keeps one semantic surface and applies plan quotas, priority, freshness and feature entitlement after identity is known.

Separate servers are right when the trust domain or the product differs: a payments server and a tasks server, an EU-only deployment for data that cannot leave. They are wrong when the only difference is how fast you serve the same contract.

export function route(operation: Operation, providers: Provider[]): Decision {
  const rejected: { id: string; reason: string }[] = [],
    eligible: Provider[] = [];
  for (const p of providers) {
    const reason =
      !p.available ? 'unavailable'
      : p.trust !== 'verified' ? 'unverified provider'
      : !p.capabilities.includes(operation.capability) ? 'capability mismatch'
      : p.semantics !== operation.semantics ? 'semantic contract mismatch'
      : operation.write && !p.writes ? 'write unsupported'
      : operation.freshness === 'live' && p.freshness !== 'live' ?
        'freshness mismatch'
      : operation.residency !== 'any' && p.residency !== operation.residency ?
        'residency mismatch'
      : operation.mode && p.mode !== operation.mode ? 'execution-mode mismatch'
      : p.p95Ms > operation.maxLatencyMs ? 'latency SLO exceeded'
      : p.costMicros > operation.maxCostMicros ? 'cost ceiling exceeded'
      : '';
    if (reason) rejected.push({ id: p.id, reason });
    else eligible.push(p);
  }
  eligible.sort(
    (a, b) =>
      a.costMicros - b.costMicros || a.p95Ms - b.p95Ms || a.id.localeCompare(b.id),
  );
  return eligible.length ?
      {
        selected: eligible[0],
        rejected,
        reason:
          'Cheapest provider satisfying the explicit semantic, policy, freshness, residency, latency and trust contract.',
      }
    : {
        rejected,
        reason:
          'No provider satisfies every hard constraint; the router refuses a silent downgrade.',
      };
}

The router works in two stages. First, every provider is tested against every constraint in a fixed order and the first failing one is recorded as the reason: available, verified, has the capability, same semantic contract, can write if a write is needed, fresh enough, right region, right mode, fast enough, cheap enough. Then the survivors are sorted by cost, then latency, then id, and the first wins. If there are no survivors, the answer is a refusal with reasons.

Try each preset, and read the table underneath, which names the first reason each provider was rejected. Three behaviours are worth seeing for yourself:

• Standard is down falls over to priority. They share the teamspace-v1 contract, so the substitution is safe. It costs more (90 against 20) but fits the 100 ceiling.
• Down, tight budget lowers the ceiling to 50, and now nothing qualifies. The router returns a refusal rather than quietly spending more than the caller allowed. Whether to raise the ceiling is a decision for a person or a policy, not for the router.
• A write selects priority, because the standard provider does not write. Writes need a provider that says it can.

Async economics

A slow lane is not just a slower fast lane. It is a different way of doing the work, and it only pays when waiting saves real money.

Two ideas get run together here and should be separated. Stateless means a request carries its own context, so any replica can serve it, which suits serverless and edge hosting. It says nothing about speed or waiting: a normal stateless tool call can still finish in ninety milliseconds. A slow lane is a lifecycle: accept the work, persist it, lease it to a worker, retry on failure, expose its status, expire the result. It is what MCP 103 Chapter 07 begins.

A slow lane earns its complexity only when waiting saves something material. The classic cases are GPU inference that batches many requests into one pass, large exports, and index rebuilds. It is a poor fit for a cheap database lookup: delaying a query that costs a few micros will not recover the cost of building and running a second service tier.

$ route(page.search, stale-ok, EU, task mode, 10 s, ≤ 10 micros)
{
  "selected": "teamspace-batch-eu",
  "rejected": [
    {
      "id": "teamspace-standard-us",
      "reason": "residency mismatch"
    },
    {
      "id": "teamspace-priority-us",
      "reason": "residency mismatch"
    },
    {
      "id": "lookalike-fast",
      "reason": "capability mismatch"
    }
  ]
}

The lab asks for a stale-tolerant, EU-resident, asynchronous page search that can wait ten seconds. Only the batch provider qualifies: the two realtime providers are rejected on residency, and the lookalike on capability. It costs 4 micros against the standard provider’s 20, a saving of 80 percent per call. Now ask whether that is worth building:

Lower the share that can wait, or the fixed cost’s tolerance, and the verdict flips quickly. With the default numbers, 200,000 calls a month save well under the invented fixed cost, so the lane does not pay. It starts to pay at millions of calls, or at a much larger per-call gap. That is the general shape of the argument for building a slow lane: volume times per-call saving must beat the cost of running two paths, and if the per-call gap is a few micros you need very high volume.

Gateways

A gateway is a single place to enforce discovery, identity, policy, audit and quotas for many servers. It is also a single place for everything to go wrong at once.

Once an organisation has ten MCP servers instead of one, the same problems appear ten times. Which servers may a host connect to? Whose credentials does each one use? Who is allowed to call what? Where is the audit trail? A gateway answers those once. It owns:

• Discovery: a verified catalogue of servers, not a list someone pasted into a config file.
• Client OAuth and the delegated identity that goes downstream.
• Policy, audit and quotas across all servers, in one place.
• Route evidence: a record of which provider handled a request and why.

It must not mint a more privileged downstream identity than the user has, and it must not hide which provider handled a write. A gateway that quietly acts as itself, with its own broad credentials, has turned every user into whatever the gateway can do.

The one real piece: explain_route

The repository exposes the router’s reasoning as a read-only tool. It explains a routing decision and performs nothing. Here are two real calls over HTTP, the accepted one and a refusal:

POST /mcp
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: explain_route

{
  "method": "tools/call",
  "params": {
    "name": "explain_route",
    "arguments": {
      "capability": "task.search",
      "semantics": "teamspace-v1",
      "write": false,
      "freshness": "live",
      "residency": "us",
      "maxLatencyMs": 500,
      "maxCostMicros": 100,
      "mode": "realtime"
    },
    "_meta": {
      "…": "same _meta envelope as the first request"
    }
  },
  "jsonrpc": "2.0",
  "id": 1
}

POST /mcp
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: explain_route

{
  "method": "tools/call",
  "params": {
    "name": "explain_route",
    "arguments": {
      "capability": "task.search",
      "semantics": "unknown-product",
      "maxLatencyMs": 500,
      "maxCostMicros": 100
    },
    "_meta": {
      "…": "same _meta envelope as the first request"
    }
  },
  "jsonrpc": "2.0",
  "id": 2
}

{
  "rejected": [
    {
      "id": "teamspace-standard-us",
      "reason": "semantic contract mismatch"
    },
    {
      "id": "teamspace-priority-us",
      "reason": "semantic contract mismatch"
    },
    {
      "id": "teamspace-batch-eu",
      "reason": "capability mismatch"
    },
    {
      "id": "lookalike-fast",
      "reason": "semantic contract mismatch"
    }
  ],
  "reason": "No provider satisfies every hard constraint; the router refuses a silent downgrade."
}

The second answer is the useful one. Four providers were considered and none qualified: three on the semantic contract and one on capability. The reason says the router refuses a silent downgrade. It does not pick the next-best thing. That evidence is what makes a routing decision inspectable after the fact, which is the property a gateway most needs.

explain_route goes through the same guarded() pipeline as every other tool (MCP 103, Chapter 00): it takes a rate-limit permit, writes an audit row carrying its trace id, and answers in the standard shape. A read-only tool still spends server capacity, and a record of who asked how a routing decision was made is worth having.

Tool retrieval

A host with a thousand tools cannot show a model a thousand tools. Retrieval picks a few. It is a filter for attention, never a lock.

Every tool description a host loads into a model’s context costs tokens on every turn and competes for the model’s attention. With a handful of tools that is fine. With a large catalogue (many servers, hundreds of tools) two things degrade: the context fills up, and selection gets worse because there are too many plausible choices. The remedy is retrieval: search a trusted catalogue by the task in hand, and expose only a small set of candidates.

Try the default task and a few of your own. Retrieval narrows eleven tools to three, and the readout shows how much of the description text the model no longer has to read. Then switch to the viewer and call create_task even though the host hid it.

What retrieval is, and is not

• Narrowing, not authorising. Retrieval decides what the model sees. Authorisation decides what may happen. A hidden tool can still be named by a model or a caller, and the server must refuse it exactly as it would have if it were visible, which MCP 102 and 103 both build in.
• The catalogue is a trust boundary. An entry needs a publisher identity, a semantic version, the scopes it needs, whether it has side effects, its data residency, a deprecation status and its provenance. Metadata a stranger’s server supplies about itself is input to be verified, not routing policy.
• Descriptions are attack surface. Retrieval reads tool descriptions to rank them, so a description written to rank highly for everything is an attack. Rank on trusted metadata first and on description text second.
• Filter by entitlement before ranking. Offering a tool the person can never use wastes a slot and invites a failed call.

Semantic routing

Two tools can share a name and a price list and still disagree about what “search” means. Routing between them without checking is how data goes missing quietly.

Routing between models is comparatively easy, because most text models share an interface: text in, text out. If two models disagree slightly, the result is a somewhat different sentence. Routing between tools is not, because a tool has semantics. Two tools both called search_tasks may disagree on which tenants they search, whether archived items appear, how results are ranked, how fresh the index is, and whether the ids they return mean the same thing. Swap one for the other and nothing errors. The answers are simply wrong, and no one is told.

The lab includes a provider built to test exactly that: lookalike-fast. It advertises the same capability (task.search), it is cheaper (2 against 20 micros), and it is faster (60 against 450 ms). On price and latency alone it would win every time. It does not, because its contract is other-v2.

Read the presets in order. Needs teamspace-v1: the lookalike is rejected as a semantic contract mismatch, though it would have been cheapest. Needs other-v2: now it is the only provider that qualifies, and the Teamspace providers are the ones rejected. Needs a contract nobody offers: no provider is chosen at all. The router’s answer is a refusal, not the nearest match.

$ the real router: labs/economics.ts, "unsafeSwap"
{
  "rejected": [
    {
      "id": "teamspace-standard-us",
      "reason": "semantic contract mismatch"
    },
    {
      "id": "teamspace-priority-us",
      "reason": "semantic contract mismatch"
    },
    {
      "id": "teamspace-batch-eu",
      "reason": "capability mismatch"
    },
    {
      "id": "lookalike-fast",
      "reason": "semantic contract mismatch"
    }
  ],
  "reason": "No provider satisfies every hard constraint; the router refuses a silent downgrade."
}

{
  "rejected": [
    {
      "id": "teamspace-standard-us",
      "reason": "semantic contract mismatch"
    },
    {
      "id": "teamspace-priority-us",
      "reason": "semantic contract mismatch"
    },
    {
      "id": "teamspace-batch-eu",
      "reason": "capability mismatch"
    },
    {
      "id": "lookalike-fast",
      "reason": "semantic contract mismatch"
    }
  ],
  "reason": "No provider satisfies every hard constraint; the router refuses a silent downgrade."
}

$ npm test   (the router and cost tests)
✔ router chooses cheapest provider satisfying every hard constraint
✔ router does not substitute a semantically different tool
✔ write routing requires an explicitly write-capable provider
✔ slow task lane is selected only when requested and allowed
✔ cost model separates vendor infrastructure from client model cost

Note what the router does not do: decide that two contracts are equivalent. That is a human decision, made when a provider is registered, recorded as an identical contract string, and it is the same decision a database team makes when they say two indexes are interchangeable. If you want other-v2 to satisfy teamspace-v1, declare it, test it, and say why. Do not let a routing layer infer it from a matching name.

Auth brokerage

A model gateway can hold one key for many endpoints. A tool gateway cannot, because every tool is somebody’s data and every call is somebody’s permission.

When a gateway sits between hosts and MCP servers it becomes a broker: it holds or obtains credentials on the user’s behalf. Model gateways do this happily, because many providers offer interchangeable text endpoints and one account key covers them all. Tool gateways must not copy that shape. Each tool guards a particular person’s access to a particular product, and the gateway’s own credentials are the wrong answer to “who is asking?”.

Rules that hold in every design

• Carry the original subject in every downstream call. A gateway service identity alone is not enough for user data.
• Bind tokens to an audience and refuse ones meant for other services (MCP 102 Chapter 07 has a simulator for this).
• Minimise scopes per call, not per session.
• Keep approvals in the host. A gateway that can approve on the user’s behalf has removed the consent it was meant to protect.
• Log consent changes, not just calls.

A model inside a tool

Some tools should call a model. Most tools that do are hiding a second agent nobody asked for.

An MCP server can call a language model of its own inside a tool: to summarise a long document, extract fields, answer questions about a dataset. That is legitimate when synthesis is the product. A “summarise this contract” tool that calls a model is doing what it says, and the model is an implementation detail.

It is a mistake when the model is there to orchestrate: a tool that takes a goal and decides for itself which other tools to call. That is a second agent, in the server, invisible to the host. It compounds non-determinism (two models deciding), latency (a loop with no bound), and prompt-injection exposure (untrusted content now flows into a model the caller never saw). And it makes failures and spend nearly impossible for the host to explain.

With no model in the tool, the vendor share is a couple of percent. Add even a small model and the vendor pays for inference on every call, and the vendor share climbs from a rounding error to a large part of the total. This is the practical reason to be deliberate: a server-owned model turns a cheap read into a metered product, and you need to price it like one.

Server composition

An MCP server that calls another MCP server adds a hop. Each hop must be paid for in latency and in ways to fail.

Composition is the pattern where a gateway, or a higher-level server, calls other MCP servers to fulfil one request. It is right for two cases: a gateway, whose whole job is to sit in the middle, and a stable high-level transaction, a workflow that always runs the same way, exposed as one tool. Each hop must carry the caller’s subject and scopes, a trace id, the shared deadline, the remaining budget and the route so far, and must cap depth and refuse cycles. That is what nextHop() checks, and MCP 103 Chapter 08 has a simulator for it:

$ nextHop() along a chain (from MCP 103)
b: ok budget=7 visited=a>b
c: ok budget=4 visited=a>b>c
a: RECURSION
d: BUDGET_EXCEEDED  (cost 5, budget 4)
e: ok budget=3 visited=a>b>c>e
f: ok budget=2 visited=a>b>c>e>f
g: HOP_LIMIT

What a check like that cannot do is make a hop free. Every hop multiplies two things you cannot budget away:

At three-nines per server, a chain of four (the caller’s server plus three hops) is available roughly 99.6 percent of the time, which is several hours of downtime a month where each part alone would have had under an hour. And its latency budget is four times one server’s. Neither figure appears on any hop’s dashboard.

• Prefer a direct call inside a product-owned server. If your server owns the tasks and the knowledge base, call the product functions. Another MCP hop adds no independent boundary, only latency and a token exchange.
• Use audience-specific tokens per hop, and keep approval at the trusted host for anything consequential.
• Protocol uniformity is not a reason. That both ends speak MCP does not justify the extra hop.
• Make the route visible in what you return, so a caller can see which servers touched their request.

A forecast, with triggers

Some of this is buildable today. Some is likely. Some is a hope. Say which, and say what would change your mind.

Turn each into a measurement

A forecast you cannot check is an opinion. For each thing you might build, name the number that would tell you it has paid, and the number that would tell you it has not.

Check yourself

Eight questions. The explanations do the teaching.

Missed one? Costs in 01, tiers in 02, slow lanes in 03, gateways in 04, retrieval in 05, semantic routing in 06, auth in 07, models in tools in 08, and chains in 09.