OrcaRouter provider support for the MCP Gateway & Registry

The MCP Gateway & Registry is a strong answer to the enterprise-agent pain point: without a control plane, teams wire their own MCP servers and agents by hand, ending with separate credentials in every dotfile and no shared audit trail. One governed entry point, one access model, and one attributable audit log across servers, agents, and skills is a shape platform teams can actually operate.

It also already treats model-backed configuration as a pluggable, OpenAI-compatible concept — embeddings can point at any LiteLLM-style endpoint with an API key and custom base URL, and the roadmap's Registry Copilot chat experience will need a model backend in that same spirit. Giving operators one more optional, OpenAI-compatible provider there would expand model choice without disturbing the providers you already support.

## Proposal

I'm an engineer on the OrcaRouter team, and I'd like to propose [OrcaRouter](https://www.orcarouter.ai) as an *optional* provider the registry can point model-backed features at. It would not replace or alter any existing provider: OpenAI/Anthropic keys, LiteLLM-backed embeddings, and the security scanner would all keep working exactly as they do today. Operators would opt in through configuration, with the registry staying the single control plane.

Three OrcaRouter capabilities seem most relevant to this project's users:

- **One OpenAI-compatible endpoint across many model families** (chat, reasoning, image, video) — useful when a feature should offer model choice without per-provider plumbing.
- **Automatic model routing with provider failover** — when a provider is degraded, calls retry against healthy fallback capacity, which matters for a production gateway.
- **Usage tracking, budgets, and team access controls** — per-call grade, model, latency, and cost, plus spend caps and RBAC, fitting this project's governance and audit audience.

OrcaRouter exposes an **OpenAI-compatible API** (`api.orcarouter.ai/v1`) and uses **standard API-key authentication**, matching how the registry already configures OpenAI-compatible endpoints (`EMBEDDINGS_API_BASE`, `EMBEDDINGS_API_KEY`, `EMBEDDINGS_RESPONSE_FORMAT=openai`). The natural integration point is another optional value behind that same environment-driven style — an additional embeddings or chat-model backend choice — not a new mechanism. Nothing here is implemented or tested yet; this is a proposal to gauge interest before any PR.

OrcaRouter is already appearing in the open-source ecosystem; projects such as [Dify](https://github.com/langgenius/dify), [RAGFlow](https://github.com/infiniflow/ragflow), and [goose](https://github.com/block/goose) list it as an available provider.

Full disclosure: OrcaRouter runs an optional open-source partner program in which approved OSS projects can receive a **5% revenue share** from OrcaRouter usage attributed to their integration. Participation is **not** a prerequisite for the integration, and I'll follow this project's disclosure and governance requirements — the decision is the maintainers'.

Interested integrations are listed at https://www.orcarouter.ai/built-with.

Would the maintainers be open to this direction? If so, I'd be glad to prepare a focused implementation PR (configuration plus docs) adding OrcaRouter as an opt-in provider.