MCP: connect your own agent

Connect Claude Code, Claude Desktop or any client that speaks the Model Context Protocol to your workspace. Your agent gets the same tools the built-in assistant has, acts as you with your current role, and anything high-impact waits for a person to approve it in OpenHouse.

POST/mcp

Streamable HTTP, stateless, JSON responses. One URL and one bearer header is all a client needs; there is no session to keep alive and nothing to reconnect after a deploy.

Connect in two steps

1. In OpenHouse, open Settings → Agents and create a credential. The secret starts with ohm_ and is shown once — copy it then.

2. Point your client at the endpoint with that secret as a bearer token. For Claude Code:

claude mcp add --transport http openhouse https://openhouse-api.6drei2.com/mcp \
  --header "Authorization: Bearer ohm_…"

Then ask it something about your workspace — “how many profiles opted in this month”, “which campaigns ran last week”, “draft a segment of German profiles with no order in 90 days”.

The credential is you

An agent credential is bound to the member who created it. Every call runs with your current role — lower it and the agent’s tool list shrinks on its next call; leave the organization and the credential is revoked with you. It can never do more than you can. The audit log records you as the actor and the credential’s name as the door.

What the agent can call

tools/list returns exactly the tools the built-in assistant offers someone with your role — operators run the CRM (profiles, segments, campaigns, templates, analytics), builders also configure it (fields, transformations, dashboards, automations), administrators also do the irreversible things (scheduling sends, activating automations). Tools above your role are absent, not greyed out.

Every tool carries a JSON Schema for its input. A wrong shape comes back as a tool error your agent can read and correct, never as a server failure.

High-impact actions wait for a person

Reads and drafts run immediately. Anything reversible-but-consequential or outward-facing — updating a live segment, scheduling a campaign, bulk-editing a field, activating an automation — does not execute. The tool returns:

{ "status": "requires_approval",
  "actionRequestId": "…",
  "summary": "Schedule campaign for 2026-12-01T09:00:00Z",
  "note": "A human must approve this in OpenHouse … The action has NOT been executed …" }

The request appears as an approval card in your OpenHouse AI panel (open Sessions in the composer to find the agent’s session). A member with the required role approves or rejects it there. Your agent learns the outcome by calling:

approvals_get
id
string
The actionRequestId a tool returned (required)

It returns the request’s status (pending, approved, rejected, executed, failed) and result. You can read requests you created; administrators can read any in the organization.

Sessions in OpenHouse

Each day your agent works, its calls are filed into one conversation in your AI panel, marked Agent and named after the credential. Open it to see what the agent did, and to approve or reject what it proposed. The conversation is read-only for you — talk to the agent in its own client.

When the agent uses the “open a view” tool, nobody’s workspace is open, so it receives an absolute link to the view and a note that nothing was navigated. Ask it to share the link.

Limits and errors

  • 60 requests per minute per member across all their credentials; beyond that, HTTP 429.
  • Only POST is served; GET and DELETE return 405 because the server holds no session state.
  • A missing or revoked credential is 401. A login token is not an agent credential and is refused with a hint.
  • Your agent’s reasoning runs on your side; MCP calls do not count against your workspace’s included AI usage.