Custom Remote MCP

Custom integrations are useful when your organization already operates an MCP server that is not part of Oblive’s reviewed catalog.

Deployment Configuration

Approve the server’s exact HTTPS origin in customMcp.allowedOrigins in your local stack configuration. The endpoint path belongs in the integration’s MCP URL, not the origin list:

{
  "customMcp": {
    "allowedOrigins": ["https://mcp.example.com"]
  }
}

Custom MCP connections use direct HTTPS by default. customMcp.egressProxyUrl is optional; when set, it routes requests through that HTTP/HTTPS forward proxy. A Cloudflare Tunnel exposing the MCP server supplies the endpoint URL and does not require an additional outbound proxy.

Regenerate the environment and recreate the backend after changing the configuration. HTTPS, public-address checks, the exact origin allowlist, and redirect rejection apply with or without a proxy. Omitted origins leave custom MCP connections unavailable. Direct mode is for explicitly trusted endpoints; DNS checks before a request are not connection-time IP pinning.

Supported Contract

Custom MCP v1 requires:

• Streamable HTTP transport;
• a public HTTPS URL;
• no user information or URL fragment;
• no custom port;
• no local, private, link-local, or cloud-metadata address; and
• no redirect during discovery.

Authentication can be:

• none;
• a Bearer API key; or
• one named static header.

Commands, package names, STDIO configuration, environment definitions, and runtime downloads are not accepted from organization configuration.

Add the Server

1. Open Integrations and choose to add a custom server.
2. Enter a stable name and public HTTPS endpoint.
3. Select the authentication method and provide the write-only credential if required.
4. Choose Read-only, Ask before writes, or Autonomous according to the intended operations.
5. Connect and discover the bounded tool inventory.
6. Select the tools to expose. For each tool that only reads data, select Reviewed: this tool only reads data. Leave write tools classified as writes. In Read-only mode, confirm the shared read attestation for all selected tools.
7. Save and run a bounded task through the normal action policy to verify the connection.

Access Rules

The owner controls each tool’s read/write classification; provider annotations cannot grant read authority. A reviewed read remains a read even on an Autonomous or Ask before writes connection. It does not create an action or request approval. Writes retain the normal action lifecycle.

The review is pinned to the discovered tool’s name, description, input schema, and output schema. A changed contract is blocked until reviewed again. Changing a classification revokes older execution capabilities and queued actions. Owner API clients send toolPolicies entries with name, the discovered contractHash, and access: "read" | "write" to the tools endpoint.

When to Use a Managed Integration Instead

Use a reviewed managed integration when the provider is broadly useful, needs curated setup guidance, requires a fixed tool allowlist, or should receive deterministic profile grants and an agent skill.

Custom read-only connections start with no enabled tools. After discovery, select the tools you have reviewed and confirm I reviewed the selected custom tools and confirm they only read data before saving. New tools require another explicit review; a provider’s naming or read-only claim alone does not grant access. Owner API clients supply readOnlyAttestation: true when enabling new custom tools.