← Rhumb · Operator intake · MCP route review

Send one MCP route.
Not a whole server.

Rhumb's route-review intake is for operators who have one MCP tool call close to production use, but still need the allowed lane, denied neighbor, authority owner, budget owner, and proof fields made explicit.

Send a route for review Copy the route card Use a public issue

Review unit

route-card.v1

Allowed lane

The exact input, caller, tenant, credential rail, quota owner, and side-effect class that may run.

Denied neighbor

The closest dangerous value that must fail closed before a provider call, handler, budget, or credential path is touched.

Receipt

The fields that prove the route selected, the neighbor refused, and the repeat envelope stayed bounded.

Name one route

Start below the server, connector, gateway, or agent role. The review unit is one repeatable MCP tool call or capability path with one owner and one expected outcome.

Pair it with the dangerous neighbor

The route is not reviewable until the adjacent thing that must fail closed is named: sibling tenant, broader path, hidden tool, expired credential, internal host, over-budget loop, or upstream token misuse.

Bind authority and budget

A route card needs the caller, tenant, credential rail, backend principal, quota owner, retry ceiling, and approval state before the handler or provider call can observe the request.

Define proof before execution

A good route review ends in receipt and denial fields: selected route, rejected neighbor, credential mode, estimate or budget owner, policy bundle, trace id, side-effect class, and recovery hint.

Demo surface

A route review should collapse abstract MCP safety into fixture pairs.

The useful output is not a generic audit report. It is a route-sized review artifact: allowed fixture, denied neighbor, authority owner, budget owner, trace fields, and the typed failure the agent should see when it tries the wrong thing.

OAuth / protected resource

Token authority is not route authority

Allowed: Unauthenticated metadata discovery followed by one client using PKCE, DCR state, and a bound resource value.
Denied: Upstream token passthrough, audience confusion, missing resource binding, or a persisted client id silently widening scope after restart.
Proof: resource, client id, credential lane, protected-resource metadata source, audience decision, and typed auth denial.

Filesystem / path boundary

Canonical path beats visible path

Allowed: Read a file under the configured workspace after resolving symlinks and platform path aliases.
Denied: Sibling directory, parent escape, hidden config, or a path that looks allowed before canonicalization but resolves outside the root.
Proof: cwd, requested path, canonical path, allowed root, symlink decision, redaction class, and typed traversal denial.

Shared budget / rate limit

The API key is not the budget owner

Allowed: Multiple MCP processes sharing one source/API-key budget with an explicit wait, lock, timestamp, and 429 adaptive state.
Denied: Different source, different API key, stale sidecar JSON, partial lock write, or retry storm crossing the route's 1 RPS envelope.
Proof: budget owner, source key, lock file, last-call timestamp, adaptive cooldown, wait receipt, and typed shared-budget recovery.

Production gateway pattern

If your answer is “we built a proxy,” the route card should prove what the proxy owns.

Teams moving MCP out of prototype usually converge on the same shape: gateway, relay, or proxy in front of tool calls; tool-level allow-lists; audit events; and some output policy. The review question is whether those controls are bound to one route before execution, or whether they are just broad platform promises.

Tool visibility is an allow-list, not a prompt hint

The agent should only see the tools, arguments, accounts, and side-effect classes that the caller is allowed to use for this route. Hidden or destructive neighbors need fixtures that prove they stay invisible or fail closed.

Enforcement happens before the handler

A gateway, relay, or proxy is useful only if it binds caller, agent, session, tenant, credential lane, and policy before the MCP handler or downstream API sees the request.

Telemetry carries route authority

Audit events should include human id, agent id, MCP session id, route id, policy decision, backend principal, quota owner, trace id, and denial reason — not just a generic tool-call log line.

Returned content is still part of the boundary

Output inspection is not a magic LLM sidecar. The route needs size limits, schema checks, redaction, artifact handoff, and typed refusals for prompt-like or credential-bearing content.

Governance control points

MCP governance should resolve into route-level proof, not platform-level reassurance.

The market is starting to talk in governance layers: startup scanning, runtime policy, response sanitization, audit, and metrics. Route review turns each layer into the same falsifiable question: what is allowed for this route, what neighbor is denied, and what receipt proves it before the agent repeats the call?

Startup visibility gate

Before a tool becomes visible, scan the registered name, description, arguments, and schema for prompt-like instructions, typosquat ambiguity, hidden Unicode, sensitive fields, and side-effect claims that do not belong in this caller's route.

Per-call policy gate

At invocation time, the route needs caller or agent identity, tenant, resource, credential lane, approval state, quota owner, and rate-limit decision bound before the MCP handler or provider call runs.

Output boundary gate

Returned content must pass the same route proof: schema shape, field allow-list, row or artifact budget, redaction class, prompt-like fragment handling, and typed refusal when the response crosses the boundary.

Audit and metric receipt

A governed route is repeatable only when the receipt records selected route, denied neighbor, policy bundle, backend principal, trace id, latency or budget decision, and recovery hint for the operator.

Minimum proof packet

Do not ask for a review until the route has four concrete fields.

The fastest public-thread reviews are not long specs. They are small proof packets: one allowed fixture, one denied neighbor, the authority and budget owner, and the receipt or typed-denial fields that make the boundary inspectable. Missing fields are useful too — they show exactly where the implementation is still hand-wavy.

One allowed fixture

A tiny input, caller, workspace, resource, and side-effect class that should run. If the allowed case cannot be made explicit, the route is not ready for review.

One closest denied neighbor

The sibling tenant, broader path, hidden tool, internal host, stale credential, or over-budget repeat that should fail before the handler or provider call observes it.

Authority and budget owner

Name who owns the credential, backend principal, quota, retry ceiling, and approval state. Do not let the API key, OAuth token, or gateway proxy stand in for ownership.

Receipt or typed denial fields

List the fields that would prove the allowed route ran, the neighbor was rejected, and the operator has a trace id, policy bundle, recovery hint, and latency or budget decision to inspect.

Review closure

A useful route review can end in code, tests, or a documented boundary — but it should not end vague.

Not every MCP route needs a new proxy or argument rewrite. For filesystem paths, OAuth discovery, shared budgets, and gateway policies, the closure test is whether a maintainer can point to the allowed lane, the denied neighbor, and the receipt or warning that proves the boundary will not surprise the next operator.

Fixture added

Best outcome: the issue or PR gains a positive/negative fixture pair, typed denial, receipt fields, and a regression test that proves the route boundary before repeated execution.

Docs or warning only

Sometimes the right product choice is transparent pass-through plus a warning, not hidden argument rewriting. That is acceptable when the public record names the allowed path, the denied neighbor, and the test or warning that prevents first-run surprise.

Explicit non-fit

If the owner says the route should stay out of scope, close it cleanly: name the authority that remains external, the neighboring request that still fails closed, and the proof users should rely on instead.

Useful replies

What should a maintainer or operator send back?

Route review is not asking for agreement with a checklist. It is asking for the next concrete artifact: a fixture pair, maintainer-owned acceptance criteria, a documented boundary, or an explicit pull toward implementation help.

Route fixture

Reply with the smallest allowed input and the closest denied input. The review becomes useful when both can be named without exposing private data.

Acceptance criteria

If the route belongs in the issue body or PR checklist, fold the allowed lane, denied neighbor, resource binding, budget owner, and typed denial into the maintainer-owned criteria.

Boundary closure

If the answer is docs, warning text, or non-fit, state that explicitly. A clean boundary closure is better than a vague maybe because the next operator knows what proof to trust.

Implementation pull

If you want Rhumb to help shape the fixture, review a patch, or turn the route into a repeatable execution lane, say that directly. That is a different signal from generic agreement.

Good fit

Send it when the problem is route-sized.

◆You can point to one concrete route, tool call, handler, PR, issue, or acceptance test.
◆The unsafe neighbor is close enough that an unattended agent might accidentally hit it.
◆There is a real repeat use case: a loop, fleet, scheduled job, operator workflow, or production MCP server path.
◆You want route-card shape, fixture pair, denial fields, receipt fields, or review questions — not generic MCP security advice.

Not this surface

Do not turn this into a vague services page.

×A broad request to audit an entire codebase, platform, marketplace, or connector catalog.
×A request for pricing, SLA, partnership, or a commitment to operate the route for you.
×A generic best-practices question that does not name a route, allowed lane, and denied neighbor.

Public issue / PR path

Some route reviews should stay where the operator is already working.

If the implementation discussion is already public, do not force it through email. Paste a public-thread route card into the issue or PR so the maintainer can answer with fixture shape, acceptance criteria, or a concrete denial field in the same context.

◆Use public threads when the route is already being designed in an issue, PR, or spec discussion and the fixtures are safe to share.
◆Do not paste tokens, tenant names, private URLs, customer data, or internal hostnames. Replace them with stable labels that still preserve authority boundaries.
◆Keep the ask route-sized: one allowed fixture, one denied neighbor, and the receipt or typed-denial fields that should prove the decision.

Copy-paste public thread card

For GitHub issues, PRs, and public spec threads.

Route-card review ask for @supertrained:
Route / MCP tool call:
Allowed fixture:
Denied neighbor fixture:
Caller / tenant / workspace:
Credential lane / backend principal:
Budget or quota owner:
Receipt or typed denial fields:
What is unclear in the current implementation/spec:
Source: e009-mcp-route-review-public-thread

Copy-paste route card

Empty fields are signal.

Open email draft

Route / MCP tool call:
What should be allowed:
Closest denied neighbor:
Caller / tenant / workspace:
Credential lane / backend principal:
Budget or quota owner:
Expected repeat volume / retry ceiling:
Receipt or typed denial that would prove the boundary:
Current implementation or spec link, if public:
Question for Rhumb:
Source: e009-mcp-route-review-intake

Related checklists

Send one MCP route. Not a whole server.