Om MCP Authentication and Safety

Use the hosted Om MCP with your Om API key and keep approval and key-handling practices tight.

Om MCP uses the same Om API key model as the direct Om API. Your MCP client connects to the hosted server, and each request carries your Om API key in request headers.

Authentication options

MethodHeaderWhen to use it
Custom-header clientsx-api-key: $OM_API_KEYUse this in Claude Code and other MCP clients that support custom HTTP headers.
Bearer-token clientsAuthorization: Bearer $OM_API_KEYUse this in Codex and in any client that only supports bearer-token auth for remote HTTP MCP.

Safe setup flow

1

Create a dedicated API key

Use a separate Om API key per machine or environment so you can rotate it cleanly.

2

Keep the key out of source control

Store it in environment variables or client-local secrets, not in tracked config files.

3

Keep manual tool approval on

Review tool calls before they run, especially when the client can launch jobs or retrieve account data.

4

Start with read-oriented prompts

Use `om_status`, `pricing_get`, `datasets_catalog`, or `diligence_search` before moving into launches and artifact workflows.

Security guidance

  • Treat Om MCP as account access using your Om API key, not as a public demo surface.
  • Do not put your API key in screenshots, blog posts, repo config, or shared snippets.
  • Keep MCP tool approvals enabled in Codex, Claude Code, and other clients.
  • Use a separate API key for personal experimentation versus shared team workflows.
  • Rotate the key if you suspect the client config or environment was exposed.

Prompt safety still matters

MCP gives an LLM the ability to call tools on your behalf. Keep approval gates on and review tool calls before they execute. Om MCP is designed to make workflows faster, but it should still be treated as an authenticated tool surface under your control.

When to use direct API instead

  • Use MCP when you want Om tools inside an interactive Codex or Claude Code session.
  • Use the direct API when you need production orchestration, custom retries, or service-to-service automation.
  • Use the SDK or direct HTTP if you need hard guarantees around payloads, timing, or application-level control.