Architecture
Add an MCP server in the console
Open MCP connections and select Add MCP server. Complete every wizard screen in order:1
Enter the server
Enter a display name, stable lowercase key, HTTPS MCP endpoint, and
transport. Choose Streamable HTTP for current MCP servers or Legacy
SSE only when the remote server requires it. Select Next.
2
Add authentication and review the policy
Choose Bearer token or API-key header and enter the write-only secret.
For an API-key header, also enter its safe header name. Expand Security
policy and limits and confirm the exact HTTPS origin, allowed path prefix,
request timeout, and response-size limit. OAO never returns the secret after
saving it. Select Next.
3
Connect and discover
Select Test and discover. OAO saves the encrypted credential and immutable
server version, connects to the approved destination, and loads its tool
schemas.
4
Choose the tools
Select only the tools the agent needs. For each selected tool, choose Always
require approval or Run without approval. Use approval-free execution
only for a narrowly allowlisted read-only tool. Select Next.
5
Attach it to an agent
To finish the connection without an agent, leave Attach to agent empty.
Otherwise choose an agent and confirm its unique tool namespace. The wizard
will publish a new immutable agent version containing the binding. Select
Finish setup.
6
Verify it
Confirm the connection card reports ready, a discovered-tool count, and
at least one restricted toolset. If you attached an agent, create a new
session for that agent; existing sessions retain their previous version.
Add an MCP server through the API
The API follows the same dependency order as the wizard. The example below uses a static bearer credential and requirescurl plus jq. Set
OAO_API_URL, OAO_PROJECT_ID, and OAO_API_KEY first.
list_items with a name returned by discovery. Keep
toolset_version_id and policy_version_id; the agent-version request needs
both. Continue with Connect MCP tools to an
agent.
MCP administration requires
credential:write, mcp:write, and
mcp:discover; reading resources requires mcp:read. Binding the resulting
versions to an agent additionally requires mcp:bind.mcp__<namespace>__<remote-name> to prevent
collisions. A session copies the exact toolset and credential-policy versions;
later versions do not silently change an existing session.
Re-running discovery is idempotent while the remote metadata is unchanged. If
the remote server adds, removes, or changes a tool, OAO publishes the discovery
as the next immutable server version and makes it the latest version. Existing
toolsets and sessions remain pinned to their prior server version until an
operator deliberately publishes a replacement toolset and agent version.
Egress and credential boundary
The broker requires TLS, resolves the hostname before each request, denies private and special-purpose addresses, and pins the request to the validated IP while retaining TLS server-name verification. This limits SSRF and DNS rebinding. It strips caller-supplied authorization, cookie, and proxy authorization headers before injecting the configured secret. Credential-bearing requests must retain the exact scheme, host, and port and remain under the policy path prefix. Redirects are not followed. Requests and responses are size-limited, and calls honor cancellation and the policy timeout. At execution time OAO rechecks the session binding, run creator’s current authorization, project membership, and every resource lifecycle before it decrypts a credential. Tool metadata and results are untrusted input. Discovery rejects duplicate tool names, repeated pagination cursors, excessive tool counts, and unsupported JSON schemas. Non-validating$schema and default annotations are removed, and a
simple nullable anyOf is canonicalized to a nullable type before validation;
other schema unions and unsupported combinators still fail closed. Descriptions
are bounded and control characters are removed. Tool arguments are validated
against the pinned schema. Remote result text may still contain prompt
injection, so the agent’s instructions and approval policy must treat it as data
rather than authority.
Recovery behavior
Every call has a deterministic tool-call identity and one PostgreSQL call-attempt record. A process crash after dispatch can leave the remote outcome unknowable; OAO marks that attemptunknown and refuses to replay it automatically. This
fail-closed behavior avoids repeating a non-idempotent remote action. Product
events contain resource IDs, safe error codes, duration/size metadata, and state,
never request arguments, results, credentials, or authorization headers.
Current authentication support
The MVP supports static bearer credentials and arbitrary safe API-key headers. OAuth, token refresh, dynamic client registration, stdio servers, per-user delegated credentials, configurable retries/reconnects, and secret substitution for sandbox commands are not implemented. OAO uses the MCP client pinned in@oao/mcp-remote; compatibility tests lock behavior to that exact version.
See HTTP API, Authentication,
and MVP limitations.
