> ## Documentation Index
> Fetch the complete documentation index at: https://docs.praxis-ai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# MCP Servers

> Connect external Model Context Protocol servers to give your Digital Twin new tools and data sources.

## What is MCP?

The **Model Context Protocol (MCP)** is an open standard that lets large language models call external tools and read external data through a uniform interface — think of it as a universal "USB-C port" for AI. Once an MCP server is connected to your Digital Twin, every tool that server exposes becomes available to Pria during a conversation, without any custom code.

<Info>
  MCP support in Pria is in **Beta**. Behaviour and field names may evolve as the standard matures.
</Info>

## Two MCP roles

Pria participates in MCP in two ways. This page covers the first.

<CardGroup cols={2}>
  <Card title="Pria consumes MCP servers" icon="arrow-down" href="/mdx/admin-guide/mcp-servers">
    Your Digital Twin connects to **remote MCP servers** to use their tools. Configure these on this page.
  </Card>

  <Card title="Pria exposes an MCP server" icon="arrow-up" href="/mdx/integrations/mcp/introduction">
    Other MCP clients (Claude Desktop, Cursor, custom agents) can connect to your instance and use Pria's own tools. Configured on the **MCP integration** page.
  </Card>
</CardGroup>

## Adding an MCP server

<Steps>
  <Step title="Open your instance">
    Go to **Admin → Digital Twin** and edit the instance you want to add the MCP server to.
  </Step>

  <Step title="Open the MCP tab">
    Switch to the **Connector MCP and Tools** tab.
  </Step>

  <Step title="Click Add a Connector MCP">
    A form opens for the new server.
  </Step>

  <Step title="Fill in the fields">
    Provide a name, the server URL, an optional authorization header, and a clear description. The description is sent to the AI as context — write it like you would write a tool description.
  </Step>

  <Step title="Save and enable">
    Save the server, then flip its status to **Active**. Only active servers are visible to Pria during conversations.
  </Step>
</Steps>

<Tip>
  For a fast start, click **Add Praxis Documentation** in the MCP tab. It registers the public Praxis docs MCP server so your Digital Twin can answer questions about Pria itself.
</Tip>

## Required and optional fields

<ParamField path="name" type="string" required>
  Display name. Must be unique within the instance.
</ParamField>

<ParamField path="server_url" type="string" required>
  HTTPS URL of the remote MCP endpoint (for example `https://docs.praxis-ai.com/mcp`).
</ParamField>

<ParamField path="description" type="string">
  Plain-language description of what the server is for. Sent to the AI as tool-selection context — be specific about *when* the model should reach for it.
</ParamField>

<ParamField path="authorization_header" type="string">
  Optional `Authorization` header value (for example `Bearer xyz123…`). Stored server-side and never echoed to the browser. All Pria users share this single credential.
</ParamField>

<ParamField path="status" type="enum">
  `Active` or `Inactive`. Inactive servers are kept for later but skipped during conversations.
</ParamField>

For tool-level filters, approval prompts, and richer behaviour, see [Connectors](/mdx/admin-guide/connectors).

## Testing the connection

Once a server is **Active**, the easiest test is to open a new conversation and ask Pria to use one of the server's tools by name. If the server is reachable and the model supports MCP, you will see the tool invoked in the message trace.

If nothing happens:

<AccordionGroup>
  <Accordion title="Model does not support MCP">
    Many older or smaller models silently ignore MCP servers. Check your instance's **Conversation Model** under **Personalization and AI Models** — it must be a model with MCP support (for example the OpenAI GPT-5 family). Switch models and retry.
  </Accordion>

  <Accordion title="Authentication failures">
    A `401`/`403` from the remote MCP server usually means the `Authorization` header is missing, expired, or scoped wrong. Update the header and save. Rotate tokens before they expire.
  </Accordion>

  <Accordion title="Tool discovery fails">
    The server URL must serve the MCP handshake (typically SSE-based). A plain REST endpoint is not an MCP server. Confirm the URL with the server's documentation, and make sure CORS allows the Pria origin.
  </Accordion>

  <Accordion title="Latency or timeouts">
    Slow MCP servers slow down every conversation that uses them. Host the server close to your Pria deployment region, and disable tools you do not need on the connector to keep the tool list short.
  </Accordion>
</AccordionGroup>

## Permission scope — who sees the server

Once an MCP server is **Active** on an instance, every assistant and every conversation in that instance can call its tools. To restrict access to a specific assistant, attach the relevant tools to that assistant only via the **Assistants** editor, and leave them off by default elsewhere. There is no per-user MCP allow-list.

## Sharing across instances

MCP servers are scoped to a **single instance**. If you operate several instances (for example one per department), add the same MCP server to each one that needs it. There is no global MCP catalog visible to every instance — this keeps credentials isolated per instance.

## Cost considerations

Each MCP tool the model decides to call counts as an extra LLM round-trip — the model sends the call, waits for the result, then incorporates it into the answer. Two practical levers:

* **Trim the tool list** on the connector. If a server exposes 200 tools and you only use 5, enable filtering on the connector and keep the rest off. Fewer tools means less prompt overhead and faster responses.
* **Avoid pointless approvals**. Approval prompts add a manual round-trip; reserve them for destructive or sensitive tools.

## Troubleshooting checklist

<Note>
  If a connector seems to be ignored, walk this list in order: (1) status is Active, (2) conversation model supports MCP, (3) URL is reachable from the public internet, (4) authorization header is current, (5) the tool name you expect the model to call actually exists on the server.
</Note>

## Related

* [Connectors](/mdx/admin-guide/connectors) — detailed connector configuration reference
* [Tools](/mdx/admin-guide/tools) — built-in tool catalog
* [Pria as an MCP server](/mdx/integrations/mcp/introduction) — exposing Pria's tools to external MCP clients