Platform
MCP & widgets — connect both ways, embed anywhere
Oraclous is an MCP server and an MCP client, plus embeddable widgets — connect to Claude Desktop and Cursor, import external tools, and publish Agents into your product.
Oraclous treats MCP — the Model Context Protocol — as first-class in both directions: an MCP server that exposes your workspace capabilities to external clients, and an MCP client that imports external tools into the platform. Plus embeddable widgets that publish your Agents into your own product — without bypassing governance.
Connect via MCP → See the architecture →
Does Oraclous support MCP?
Yes — both ways. MCP (Model Context Protocol) is the open standard for connecting AI systems to tools and context. As an MCP server, Oraclous exposes your workspace capabilities through the Application Gateway to any MCP-compatible client — Claude Desktop, Cursor, Continue — and the surface each client sees is determined by ReBAC, so connecting an external client never widens access. As an MCP client, Oraclous consumes external MCP servers and brings their tools into the Capability Registry as native OHM tools — once imported, they’re first-class capabilities like any other.
Citable answer — Is Oraclous an MCP server or client? Both. Oraclous is an MCP server — it exposes ReBAC-scoped workspace capabilities through the Application Gateway to clients like Claude Desktop, Cursor, and Continue — and an MCP client — it consumes external MCP servers and imports their tools into the Capability Registry as native OHM tools. MCP is the open standard for connecting AI systems to tools.
What is MCP? → · What is a Capability? →
How does MCP & widgets work?
Outbound (Oraclous as MCP server). The Application Gateway publishes an MCP server endpoint. An MCP client authenticates and sees exactly the capabilities ReBAC permits it — no more. Because the visible surface is computed from relationships, not handed out as a static key scope, the same governance that runs the work also bounds what an external client can reach. Your Agents and tools become usable from Claude Desktop or Cursor without leaving your policy envelope.
Inbound (Oraclous as MCP client). The Capability Registry owns the inbound adapters that translate external formats into OHM. The MCP tool adapter maps an external MCP tool definition to an OHM tool; alongside it sit a SKILL.md adapter and an OpenAPI 3.x adapter (one OHM tool per operation). Whatever the source, the result is a uniform capability descriptor — so an imported MCP tool, a SKILL, and a hand-built tool are governed, versioned, and invoked identically.
Embeddable widgets. The Application Gateway also publishes Agents as embeddable widgets and integration keys, with slug-based routing, key validation, and rate limits. A widget renders inside your own product or marketing site and reaches the work through the gateway — and only the gateway. Per the frontend’s widget contract, a widget stays inside its own root: it does not read or modify the host page’s DOM, does not reach into window.parent/window.top beyond a postMessage to a configured origin, scopes its own styles, and calls nothing but the configured gateway endpoint. Embedding Oraclous never pollutes the host page or routes around governance.
Why does MCP & widgets matter?
For a platform builder, interop both ways is the difference between a walled garden and a citizen of your toolchain. Outbound MCP means your team can drive Oraclous capabilities from the editor and desktop clients they already live in. Inbound MCP means you adopt the growing ecosystem of MCP tools without writing per-tool glue — they land in the registry as governed OHM capabilities. Widgets mean the work reaches your customers inside your own product surface. In every direction the boundary holds: ReBAC scopes the server, the registry normalises imports, and widgets are sandboxed — interop without giving up control.
MCP & widgets is the connective tissue of the openness story. It sits beside BYOM — bring the model you choose — and Portability — leave the platform without re-implementing — so your models, your tools, and your work are each independently open.
Frequently asked questions
Q: Is Oraclous an MCP server or client? A: Both. As an MCP server it exposes ReBAC-scoped workspace capabilities through the Application Gateway to clients like Claude Desktop and Cursor. As an MCP client it consumes external MCP servers and imports their tools into the Capability Registry as native OHM tools. The two directions are independent and both first-class.
Q: Can I embed Oraclous in my product? A: Yes. The Application Gateway publishes Agents as embeddable widgets with slug-based routing, key validation, and rate limits. A widget renders inside its own root in your host page, scopes its own styles, talks only to the configured gateway endpoint, and never reads or modifies the host DOM beyond a postMessage to a configured origin.
Q: Which MCP clients work — Claude Desktop, Cursor, Continue? A: Any MCP-compatible client. Oraclous exposes a standard MCP server through the Application Gateway, so clients such as Claude Desktop, Cursor, and Continue connect to it directly. What each client can see is determined by ReBAC, so connecting a client never widens access beyond the relationships you’ve granted.
Q: How do external tools become Oraclous capabilities? A: Through the Capability Registry’s inbound adapters, which translate external formats into OHM. The MCP tool adapter maps an MCP tool definition to an OHM tool; SKILL.md and OpenAPI 3.x adapters do the same for those formats. Imported tools become uniform capability descriptors — governed, versioned, and invoked exactly like native ones.