Core concepts

Noodle Seed is built on one idea: thin language, fat runtime. You author a small, declarative description of your server, and a large shared runtime does the work of serving it.

Thin language, fat runtime

Every MCP server needs the same machinery: a protocol server, request validation, HTTP clients, retries, auth, and policy. Building that into each project is repetitive and hard to review. Noodle Seed keeps that machinery in a runtime that is written once and shared, so your server stays small.

The payoff is reviewability (a server is data you can read), reuse (every connector and capability the runtime gains benefits every server), and scale (one runtime serves many servers).

The pipeline: author, compile, serve

You edit only server.ts. The compiler validates structure, resolves schemas, checks connector references against the catalog, and derives the advertised capabilities, producing a normalized runtime artifact that the platform stores and versions. A shared, stateless runtime loads a tenant's artifact on demand and serves MCP over HTTP. Shipped

Multi-tenancy and routing

The runtime is multi-tenant: one deployment serves many servers. Every request is routed by server identity and validated against that tenant's own manifest, issuer, policy, connector catalog, and credential scope, so tenants stay isolated. Hosted servers live under a path like /o/{org}/{app}/mcp, following the Org > App > Env > Deployment hierarchy. Shipped for tenant routing and Google-membership-gated management. Wildcard org subdomains and the full per-org governance layer are Roadmap.

The MCP surface

Your server exposes standard MCP capabilities, backed by fulfilment flows:

Connectors as data

Backing systems (a SaaS API, a first-party service, your own API) are normalized into connectors. A connector publishes operations with a uniform shape, so a tool calls booking.create_appointment or stripe.create_payment_link the same way. The server references operations; it never embeds the implementation.

• HTTP connectors call real APIs with declarative request/response mapping and SSRF-guarded, allowlisted hosts. Shipped
• Compute connectors run self-contained TypeScript in a sandbox with no ambient authority (no network, filesystem, secrets, or tokens) when a bit of logic is genuinely needed. Shipped
• Adopting an external MCP server or generating a connector from an OpenAPI spec as a first-class connector is Roadmap. (noodle import openapi today generates starter code, not a managed connector.)

Credentials and the broker

Noodle Seed never forwards an inbound MCP or OAuth bearer token to a business backend. Instead the credential broker exchanges validated identity for a downstream-scoped credential, and secrets never appear in manifests, logs, widget payloads, or artifacts.

• Service credentials (the connector's own bearer, API key, or OAuth2 client-credentials) are resolved per tenant by the broker. Shipped
• Per-user delegated credentials (end-user OAuth, ${user.*}) are Roadmap (Phase 3).

Policy is central

Authorization, quotas, rate limits, redaction, and audit happen in the runtime before any connector side effect. A UI-initiated tool call from a widget re-enters the same authentication and policy path as a model-initiated call. The admission gate (allow / deny 403 / limit 429) is Alpha; the full policy engine, audit, and OpenTelemetry tracing are Roadmap (Phase 4).

A request, end to end

Design principles

Noodle Seed's design follows seven principles:

1. Thin language, fat runtime. The server references capabilities; complexity lives in the runtime.
2. Structure is declarative, logic is the exception. Selecting capabilities and mapping data is declarative; arbitrary code is an explicit, sandboxed exception.
3. One construct for every backing system. Everything is a connector with a uniform reference shape.
4. Operation signatures are contracts. Connectors publish names, inputs, outputs, auth, and errors; servers reference, never embed.
5. State is explicit and visible. Within a call, data flows through named steps; across calls, state passes as explicit handles.
6. Validation has two layers. Static schema validation plus compile-time resolution against the live catalog, then runtime validation of inbound calls and connector results.
7. Policy is central. Governance runs in the runtime before connector side effects.

What is shipped today