The MCP server lets external AI agents connect to coreAI and pull answers from the same quality-assured knowledge base the chat widget uses. You don't need to duplicate content, build a new vector index, or let the agent scrape websites — your assistant becomes a standardized retrieval endpoint that any MCP-compatible client can talk to.
#What the MCP server exposes
The MCP server offers one tool today: a semantic search across the knowledge base of a chosen assistant. The agent sends a natural-language query, and the server runs the same search service that sits behind the chat. The result is a structured text context with the most relevant excerpts from the sources the assistant is already populated with — products, documents, web content, FAQs, and anything else you have imported.
Because the search runs through the same service as the chat, the same rules apply for source handling and ranking. The agent never gets access to raw data outside what the assistant is configured for, and it cannot bypass filters or publication status set at the source level.
#How an external agent connects
The MCP endpoint sits at /mcp/assistant in the coreAI portal and uses standard MCP transport over HTTP. The client authenticates with a Sanctum token in the Authorization header and specifies which assistant it should talk to via X-Assistant-Id — the assistant's public ID. After the handshake, the agent can call the search tool with a query string and get back formatted context ready to be passed into an LLM prompt.
Any MCP client can connect this way: Claude Desktop, Cursor, custom-built dev agents, internal orchestration tools, or a LangChain- or LlamaIndex-based pipeline. You don't need a coreAI-specific SDK; the protocol is open and vendor-neutral.
The fastest way in is to copy the configuration straight from the "Code" tab in the coreAI portal and paste it into your MCP client's config — endpoint, token, and assistant ID are already set correctly, and the client picks up the server on next startup.
#Access is scoped per assistant, source, and client
The access model is three-layered. Each token belongs to a user or system account, each MCP call points to one specific assistant, and each assistant is configured against an explicit set of sources. That means an internal developer agent can have access to the entire product catalog, while a customer-specific integration only sees the one knowledge base built for that customer.
Assistants protected behind a widget callback are not exposed via MCP. That prevents an agent from bypassing authentication checks the widget enforces for end users. For most B2B setups this is not a limitation — the vast majority of assistants are available directly to authenticated tokens, and access is governed in the usual way through which assistants the user is allowed to see.
#When MCP is the right choice over the chat API
Choose MCP when an existing AI agent already has a conversation loop and just needs the right context. The agent handles question formulation, prompt strategy, and user interaction — coreAI contributes nothing but precise answers from the organization's own data. It fits IDE assistants helping developers with internal APIs, customer-service agents fetching product information mid-conversation, or autonomous workflows making decisions based on fresh documents.
Choose the chat API when you want to build the entire conversation experience yourself — your own UI, your own session handling, your own model and prompt configuration. Choose the search API when you only need hits and facets without a generated answer. MCP is the right layer when the generative component already exists outside, and coreAI is to be the retrieval engine behind it.
#Combine MCP, chat, and search in the same product
A product may need several integration surfaces at the same time. A SaaS provider can offer the chat widget to end users, build the search API into its admin panel, and at the same time let its own AI agents connect via MCP for automation — all powered by the same assistant and the same source setup. A change in the knowledge base hits all three surfaces in the same moment, with no need to maintain three separate data syncs.
That is the strength of a shared retrieval architecture: one truth for the content, many channels out. MCP is just the newest of these channels — and the one that lets the rest of the AI ecosystem talk to coreAI on its own terms.