Skip to main content

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.

​
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.
MCP support in Pria is in Beta. Behaviour and field names may evolve as the standard matures.

​
Two MCP roles

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

Pria consumes MCP servers

Your Digital Twin connects to remote MCP servers to use their tools. Configure these on this page.

Pria exposes an MCP server

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.

​
Adding an MCP server

1

Open your instance

Go to Admin → Digital Twin and edit the instance you want to add the MCP server to.
2

Open the MCP tab

Switch to the Connector MCP and Tools tab.
3

Click Add a Connector MCP

A form opens for the new server.
4

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.
5

Save and enable

Save the server, then flip its status to Active. Only active servers are visible to Pria during conversations.
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.

​
Required and optional fields

​
name
string
required
Display name. Must be unique within the instance.
​
server_url
string
required
HTTPS URL of the remote MCP endpoint (for example https://docs.praxis-ai.com/mcp).
​
description
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.
​
authorization_header
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.
​
status
enum
Active or Inactive. Inactive servers are kept for later but skipped during conversations.
For tool-level filters, approval prompts, and richer behaviour, see 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:
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.
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.
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.
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.

​
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

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.