Skip to main content

Add a new MCP backend

Status: stub. The full walkthrough is queued for a subsequent tutorial round. The structure below names every step plus the existing reference doc that covers it.

This tutorial walks you through extending the NoETL platform with a new triage backend behind the same JSON-RPC contract used by mcp/ollama and mcp/vertex-ai. The worked example uses AWS Bedrock as the hypothetical new backend, but the same pattern applies to Azure OpenAI, Anthropic on AWS, or any future provider.

By the end you'll have a stub-then-real backend, registered in catalog, exercised end-to-end via workload override, and added to the parity smoke fixtures. Future contributors can use your work as the template for the next backend.

Estimated time: 2 hours.

Prerequisites​

Why pointer-swap, not branching​

Step 1 — Pick your hypothetical backend​

Step 2 — Define the JSON-RPC contract​

Step 3 — Build the stub first​

Step 4 — Wire the pointer-swap​

Step 5 — Implement the real backend​

Step 6 — Add a parity smoke fixture​

Step 7 — Document model name mapping​

Step 8 — Validation sweep​

Next steps​

  • Open a PR to upstream your new backend playbook to repos/ops.
  • File a sync issue if you discovered any architectural deltas (e.g. Bedrock's converse API maps to a slightly different message schema than Vertex's GenerateContent). The pointer-swap pattern depends on the JSON-RPC contract being tight; deltas need to be encoded on the backend side, not surfaced to the consumer.
  • Triage Model Selection — long-form reference for backend choice and model tier semantics.

Troubleshooting​