Module routing 

Routing engine — decides which executor should handle a tool call.

The engine combines three inputs:

• Global + per-server ProxyRoutingConfig (strategy, fallback, per-tool overrides)
• A MatchReport describing which tools have both a local and a remote implementation
• The raw tool name requested by the client

Out of these it produces a RoutingDecision: a primary executor target, an optional fallback target for the error path, and a human-readable reason string for observability.

Name conventions

Clients can address tools two ways:

• Unprefixed (get_issues) — routing policy applies normally.
• Prefixed (cloud__get_issues) — the prefix is an explicit “send to that upstream” override. The engine honours it even when the strategy would otherwise pick Local.

Cloud priority

The default RoutingStrategy is Remote. Local routing is never synthesized: it must be explicitly enabled per tool, per server, or globally. When the schemas disagree, matched tools degrade back to Remote automatically.

Structs

IncompatibleTool

One row in the “schema disagrees” table.

ProxyStatus

Human-friendly summary of the current routing state. Used by the proxy status CLI command and any dashboard that wants to inspect how the proxy is configured.

RoutingDecision

Final routing plan for one invocation.

RoutingEngine

Routes tool calls based on config + match report.

Enums

RoutingReason

Short reason label attached to every decision — surfaced in logs and _meta responses.

RoutingTarget

Concrete executor target for a single call.