> For the complete documentation index, see [llms.txt](https://docs.uptiq.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.uptiq.ai/ai-workbench-qore/core-concepts/protocols.md).
# 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](/ai-workbench-qore/core-concepts/skills-and-tools.md) and the shared [Integrations Hub](/ai-workbench-qore/console/integrations-hub.md) 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](/ai-workbench-qore/console/agent-builder/build/skills-and-capabilities.md).
MCP is how an agent reaches the long tail of capability the platform doesn't ship as a first-party connector. See [MCP Tools](/ai-workbench-qore/console/agent-builder/build/mcp-tools.md).
An MCP server that issues a client ID and secret instead of showing a sign-in page can be connected with **OAuth client credentials (M2M)**, so no user sign-in is needed. See [Connect with client credentials](/ai-workbench-qore/console/agent-builder/build/mcp-tools.md#connect-with-client-credentials).
For every way to connect a server, how connections authenticate, where they're governed, and Qore's own MCP servers for coding agents, see [MCP](/ai-workbench-qore/core-concepts/mcp.md).
## 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.
| If you want to… | Use | Runtime |
| --------------------------------------------------------- | ----------------------------------------------- | ---------------------------- |
| Drop a chat onto a web page with no UI to build | **Embedded Chat** | Browser, prebuilt UI |
| Call the agent from a backend, service, or scheduled job | **Agent API**, with the `raw (HTTP)` client | Server-to-server, no browser |
| Drive the agent from your own front end, with your own UI | **Agent API**, with the `TypeScript SDK` client | Browser, your UI |
They share the same credentials and domain rules. All three are documented in full on [Integrate Agent](/ai-workbench-qore/console/agent-builder/deploy/agent-integration.md). For the concepts behind them, see [Embed Agent](/ai-workbench-qore/core-concepts/embed-agent.md) and [Widget](/ai-workbench-qore/core-concepts/widget.md).
### What the choice implies
The decision isn't only about convenience — it changes what the agent should be configured to do.
* **Embedded Chat and the TypeScript SDK run in a browser**, so [Allowed Domains](/ai-workbench-qore/console/agent-builder/deploy/authentication.md#allowed-domains) applies: you declare where the agent may be embedded, and it refuses to run anywhere else.
* **The raw HTTP client is server-to-server**, with no browser. It uses an API key and secret, and Allowed Domains doesn't apply.
* **Output format follows the consumer.** **Agent Output Format** is `Markdown` or `Json`, set on [Basic Details](/ai-workbench-qore/console/agent-builder/build/basic-details.md).
## Who is calling: Authentication
Access keys identify the calling application. [Authentication](/ai-workbench-qore/console/agent-builder/deploy/authentication-1.md) identifies the person. Turn it on for an agent, choose **Microsoft Entra ID** or **Google**, and Qore verifies the caller's token before each run.
* Send the token beside the message in an Agent API request, or pass it to the Embedded Chat widget.
* A verified token is available to the agent's MCP connections as `$auth.token`, so the downstream system can apply that person's permissions. Skills and instructions can't read it.
* A request without a token still runs, without `$auth.token`. A request with an invalid token is rejected.
* **Setup Identity Token** lets you try an agent as a specific signed-in person by pasting their token. It is available on request.
## Versions travel together
An integration is a contract between your code and a specific agent runtime, so the versions matter.
{% hint style="info" %}
Versions are per agent. Read the **SDK version** and **Executor version** from the agent's **Agent Config Panel**, and use those in your app and API calls. See [Integrate Agent](/ai-workbench-qore/console/agent-builder/deploy/agent-integration.md).
{% endhint %}
The executor changes over time — new versions add capabilities, fix issues, and sometimes deprecate older behaviors. New agents use the latest version available to your tenant; existing agents stay on their current version until you migrate them. [Runtime & Versioning](/ai-workbench-qore/console/agent-builder/build/runtime-and-versioning.md) is where that is set.
## Where this is configured
* [Integrate Agent](/ai-workbench-qore/console/agent-builder/deploy/agent-integration.md) — Embedded Chat, the Agent API, the TypeScript SDK, and their credentials
* [MCP Tools](/ai-workbench-qore/console/agent-builder/build/mcp-tools.md) — the outbound MCP catalog, and connecting with client credentials
* [Access & Security](/ai-workbench-qore/console/agent-builder/deploy/authentication.md) — the keys each integration uses
* [Authentication](/ai-workbench-qore/console/agent-builder/deploy/authentication-1.md) — verifying the person who calls the agent
* [Allowed Domains](/ai-workbench-qore/console/agent-builder/deploy/authentication.md#allowed-domains) — where browser integrations may run
* [Runtime & Versioning](/ai-workbench-qore/console/agent-builder/build/runtime-and-versioning.md) — executor version
***
{% columns %}
{% column width="83.33333333333334%" %}
Maintained by Abhishek Paul
AI-assisted, human-approved
{% endcolumn %}
{% column width="16.666666666666664%" %}
{% endcolumn %}
{% endcolumns %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.uptiq.ai/ai-workbench-qore/core-concepts/protocols.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
