Skip to main content

​
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 Digital Twin and use Pria’s own tools. Configured on the MCP integration page.

​
Adding an MCP server

1

Open your Digital Twin

Go to Admin → Instances and edit the Digital Twin 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

The Edit Connector MCP form opens (in the Studio UI: MCP Server Configuration). It starts empty; the examples in the fields are placeholders.
4

Fill in the fields

Provide Name (Label), 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

Test connection

Select Test connection. Pria asks the server for its tool list with the values in the form and shows the tools as a checklist, so you can pick the ones to allow and the ones that run without approval.
6

Save and enable

Save the server with its Status on 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

​
string
required
Name (Label) — the display name, unique within the Digital Twin.
​
string
required
Server URL — the HTTPS URL of the remote MCP endpoint (for example https://docs.praxis-ai.com/mcp). Use the server’s final URL — Pria refuses to follow a redirect from this address, so a URL that bounces to another host will fail discovery. Register the destination address instead if your provider’s URL redirects.
​
string
Description — a 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.
​
string
Authorization Header — an optional Authorization header value (for example Bearer xyz123…). Stored server-side and never echoed to the browser. All Pria users share this single credential.
​
enum
Status — 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

In the form, Test connection asks the server for its tool list with the values you entered — the quickest way to see that the URL and the authorization header work. Once a server is active, the next 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 connector is Active, you will see the tool invoked in the message trace (any conversation model with tool support can use it). If nothing happens:
Every conversation model with tool support uses connectors, including realtime voice on xAI and Gemini Live. If the tool never appears, check the connector’s Status is active; if it is held back by Require approval, it appears as an approval card instead of running straight away — in text chat, and in voice conversations as a card in the transcript or over the conversation.
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 answer as an MCP server (it speaks the MCP protocol, usually over server-sent events). A plain REST endpoint is not an MCP server. Confirm the URL with the server’s documentation, and make sure the server accepts requests from Pria’s servers (ask humans@praxis-ai.com for the addresses if it keeps an allow-list). If the URL redirects to another address, discovery fails by design — register the final destination URL instead (see Server URL above).
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 a Digital Twin, every assistant and every conversation in that Digital Twin 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 Digital Twins

MCP servers belong to a single Digital Twin. If you run several (for example one per department), add the same MCP server to each one that needs it. There is no shared catalog visible to every Digital Twin — this keeps credentials separate.

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

​
Verified learner identity on tool calls

Every call your Digital Twin makes to a connector automatically includes who the signed-in user is — their email (when they have one), user id, the Digital Twin’s id, the connector’s name, a timestamp, a nonce and a key id — plus a signature over all of them that the receiving server can check against your Digital Twin’s MCP Signing Secret. Why this matters: without it, the only identity a tool server sees is whatever the AI wrote into the request, which a crafted prompt could fake. The signed identity comes from the login session instead, so a partner can safely expose per-learner tools — a student’s own progress, quiz-result debriefs, tutor observations — and trust that the request really is about that student.
​
string
Found in the Digital Twin’s settings next to the MCP Server Secret, with copy and regenerate controls. Share it with your integration partner through a secure channel (not email). Regenerating is an immediate cutover: partners verifying signatures will reject calls until they switch to the new value, so coordinate first.
Partners who want to verify the identity on their side can follow Verified identity: the header list, the signing rule, Node and Python verifiers, and a worked example to test against. Connectors that don’t verify signatures are unaffected — the extra information is simply ignored.

​
Troubleshooting checklist

If a connector seems to be ignored, walk this list in order: (1) its status is active, (2) the conversation model supports tools, (3) Test connection succeeds, (4) the authorization header is current, (5) the tool name you expect the model to call actually exists on the server.