> 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/core-concepts/protocols.md).

# Protocols

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](/core-concepts/skills-and-tools.md) and the workspace-wide [Integrations](/integrations/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](/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](/agent-builder/build/mcp-tools.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           | **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](/agent-builder/deploy/agent-integration.md).

### 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](/agent-builder/deploy/whitelisted-domains.md) 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](/core-concepts/memory-and-learning.md).
* **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](/agent-builder/build/basic-details.md).

## Versions travel together

An integration is a contract between your code and a specific agent runtime, so the versions matter.

{% hint style="info" %}
Each agent reports the **SDK version** and **Executor version** it expects on its [Agent Integration](/agent-builder/deploy/agent-integration.md) 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.
{% endhint %}

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](/agent-builder/build/runtime-and-versioning.md) is where that is set.

## Where this is configured

* [Agent Integration](/agent-builder/deploy/agent-integration.md) — embed widget, REST API, JS SDK, and their credentials
* [MCP Tools](/agent-builder/build/mcp-tools.md) — the outbound MCP catalog
* [Authentication](/agent-builder/deploy/authentication.md) — the keys each integration uses
* [Whitelisted Domains](/agent-builder/deploy/whitelisted-domains.md) — where browser integrations may run
* [Runtime & Versioning](/agent-builder/build/runtime-and-versioning.md) — executor version


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.uptiq.ai/core-concepts/protocols.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.