Ask for both, and treat the Model Context Protocol server as the more interesting one. An API lets your systems query the graph. An MCP server lets an AI assistant query it in conversation - "who can introduce me at Acme" - with no interface in the way. Few vendors in this category ship one, and it changes how the data gets used.
Why the access question is becoming the buying question
Relationship data is only valuable at the moment someone is deciding who to contact. That moment increasingly happens inside an assistant, a sequencer or a CRM record - not inside the vendor's own application.
A product that can only be used through its own UI is competing for attention with every other tab. A product reachable by API and MCP gets used in whatever tool the work is already happening in.
What an MCP server actually gives you
The Model Context Protocol is the standard for connecting an AI assistant to an external system. With one connected, a rep can ask their assistant a question in plain language and get an answer computed against the live graph - no export, no dashboard, no login.
Orbb runs one at mcp.orbb.com/mcp. Its documented tool surface covers company and people search, warm-path finding for a single target or in bulk, account and contact interaction history, and persona listing.
The security model is the part to read
An assistant with access to your relationship graph is a real access-control question, and the honest version is documented rather than asserted. Orbb's:
- OAuth 2.1, with no API keys, no shared secrets and no static credentials to leak.
- Off by default. MCP access is gated per organisation and every call is rejected until someone turns it on.
- Read-only across the whole tool surface. No tool writes to the graph, to contacts, to accounts, or back to any connected CRM, inbox or calendar.
- Server-side tenant resolution. The organisation comes from the authenticated user's identity record, not from a request parameter - a token structurally cannot return another tenant's data.
- Per-user attribution, with no shared service accounts.
- No new data store. It reads the same production databases as the application; connecting it does not copy your data anywhere new.
- Audited. Every call is logged with user, organisation, tool and outcome.
- Revocable at three levels: remove the client, deactivate the user, or disable it for the whole organisation, which cuts off every connected client immediately.
What to ask any vendor
- Is there an MCP server, or only a REST API?
- Is the tool surface read-only, or can an assistant write?
- Is access enabled per organisation, and is it off by default?
- Is each call attributed to a user, or to one shared service identity?
- Can access be revoked for one client without revoking it for everyone?
- Is every call logged, and can we see the log?
Why this favours smaller vendors right now
The large incumbents in adjacent categories were built before assistants were a surface anyone designed for, and retrofitting an access model is slow. This is one of the few places in the stack where a newer product is structurally ahead - so if your team already works through an assistant, it is worth making an explicit requirement rather than a nice-to-have.