Appearance
MCP
OH HAI ships a Model Context Protocol server, @oh-hai/mcp, in two forms:
| Form | Where it runs | Transport | Auth | Page |
|---|---|---|---|---|
| Hosted | https://mcp.ohhai.app (both / and /mcp) | Streamable HTTP, stateless | Sign in from the client (OAuth 2.1) — or Authorization: Bearer <agent token> for headless clients | Hosted server |
| Local stdio | Your machine, as oh-hai-mcp | stdio | MA2H_AGENT_TOKEN + MA2H_AGENT_ID in the process environment | Local stdio server |
Both expose the same five tools — the CLI's core send/receive operations:
| Tool | Does | CLI equivalent |
|---|---|---|
oh_hai_notify | Fire-and-forget notification to the human inbox (or to a peer agent with to). | oh-hai notify |
oh_hai_ask | Submit a decision and wait for the answer; resume a prior ask with { id }. The answer is a pull result trusted through the authenticated TLS connection — it carries no signature. | oh-hai ask submit + oh-hai ask await |
oh_hai_task | Hand a human (or a peer agent) a manual task. Returns immediately with the id. | oh-hai task submit |
oh_hai_inbox | Drain the agent's mailbox and ack what you have processed. | oh-hai inbox watch / oh-hai bridge |
oh_hai_list | List the messages this agent has submitted. | oh-hai messages list |
Full input schemas for every tool are on the Hosted server page. They are identical for the stdio server.
Which one
- Hosted when your runtime speaks MCP and you do not want a local process or a token in a local env file. One URL; the client signs you in.
- Local stdio when you want the token to stay in your own process environment, when you point at a different Hub (
MA2H_BASE_URL), or when you want the server to present a session you registered with the CLI (MA2H_SESSION_ID, stdio only). - Neither, if the agent has a shell. The CLI does everything the MCP does, plus
oh-hai bridge— the one command that makes a run reachable while it works. See MCP or CLI?.
What a client sees
The server identifies itself as oh-hai, version 0.3.1 — the @oh-hai/mcp package version, reported in the initialize reply by both forms. Every tool returns a text content block containing pretty-printed JSON. Errors come back as a tool result with isError: true and a message such as not_authorized: …; the server never throws a JSON-RPC error for a tool failure. Success payloads are passed through verbatim (a signed inbox entry must round-trip byte-for-byte); error messages are sanitised of terminal control characters.
Once configured, tools/list returns the five tools above — that is the acceptance test for a working client.