Protocols
How the agent reaches out, and how your product reaches in.
An agent that can only be used inside the builder isn't much use. Two directions matter, and they're easy to confuse because the product uses the word "integration" for both.
Outbound — the agent reaching out to systems your business runs on. Covered in Skills & Tools and the workspace-wide Integrations catalog.
Inbound — your product reaching in to the agent. That's this page.
MCP: the outbound protocol
Model Context Protocol (MCP) is a general protocol for connecting external tools to an agent. Connecting one MCP server can register several tools at once — that's what distinguishes it from a single skill: it's a mechanism by which a class of capability arrives.
Qore ships a catalog of MCP servers — market data, SEC filings, web scraping, search APIs, knowledge-base retrieval. Each server's tools become available to the planner through Skills & Capabilities.
MCP is how an agent reaches the long tail of capability the platform doesn't ship as a first-party connector. See MCP Tools.
Three ways in
Once an agent works, you wire it into your product one of three ways. The right choice depends on where the agent runs and how much of the interface you want to own.
Drop a chat onto a web page with no UI to build
Embed widget
Browser, prebuilt UI
Call the agent from a backend, service, or scheduled job
REST API
Server-to-server, no browser
Drive the agent from your own front end, with your own UI
JS SDK
Browser, your UI
They share the same credentials and domain rules. All three are documented in full on Agent Integration.
What the choice implies
The decision isn't only about convenience — it changes what the agent should be configured to do.
Embed and SDK run in a browser, so Whitelisted Domains applies: you declare where the agent may be embedded, and it refuses to run anywhere else.
REST is server-to-server, with no browser and usually no persistent user identity. Persona memory adds noise in that context — see Memory & Learning.
Output format follows the consumer. An agent answering humans in a UI should return Markdown. An agent whose output your code parses should return JSON. That's set on Basic Details.
Versions travel together
An integration is a contract between your code and a specific agent runtime, so the versions matter.
Each agent reports the SDK version and Executor version it expects on its Agent Integration page. Use those in your app and API calls. A mismatch between your SDK and the agent's executor is a likely first suspect when an integration behaves oddly after an upgrade.
The executor changes over time — new versions add capabilities, fix issues, and sometimes deprecate older behaviors. New agents are pinned to the latest version your tenant supports; existing agents stay on the version they were created with unless you change it deliberately. Runtime & Versioning is where that is set.
Where this is configured
Agent Integration — embed widget, REST API, JS SDK, and their credentials
MCP Tools — the outbound MCP catalog
Authentication — the keys each integration uses
Whitelisted Domains — where browser integrations may run
Runtime & Versioning — executor version
Last updated