# One knowledge base, both MCP client and MCP server

Model Context Protocol (MCP) is the open standard that lets AI models talk to external data sources and tools without vendor-specific SDKs. MCP tools can both read and write – from simple lookups to creating tickets, changing orders or cancelling bookings – so MCP is the foundation underneath what's commonly called **agentic AI**: an assistant that actually completes tasks in other systems, not just answers questions.

coreAI implements the protocol in both directions: your assistant can **use** other people's MCP servers as tools during a conversation, and it can simultaneously **be** an MCP server that other AI agents connect to. That means coreAI slots straight into the rapidly growing MCP ecosystem – Claude Desktop, Cursor, ChatGPT, internal dev agents, orchestration platforms – without you having to build per-vendor integrations.

![Sketch of Model Context Protocol as an open standard between AI models, data sources and tools](/articles/mcp-core.webp)

## coreAI as MCP client: the assistant reads, creates, updates and deletes

coreAI isn't limited to lookups. As an MCP client the assistant connects to the MCP servers you already run, reads out which tools they expose, and runs the full chain of calls needed to complete what the user is actually asking for – whether that's fetching data or doing something with it.

Tool schemas are stored in the knowledge base and refreshed automatically. The assistant picks the right tool based on the conversation, and the back-end systems retain full control over what is actually allowed to happen.

**Read – fresh data mid-conversation:**

- live stock levels, prices and delivery times that change hour by hour
- order status, shipping information and case handling per signed-in customer
- CRM lookups, customer registries and internal line-of-business systems where the answer must reflect last-minute changes
- available slots, bookings and calendars where an indexed snapshot quickly becomes stale

**Create – the assistant starts something new:**

- book a workshop appointment, on-site inspection or other appointment in a specialist system based on the first available slot the user accepts
- register a new customer case, support inquiry or internal ticket with the right category and priority
- place an order or start a subscription straight from the chat, with the right customer and delivery address pulled from context
- create a new lead or contact in the CRM when a conversation tips from question into concrete interest

**Update – the assistant adjusts what is already there:**

- move an appointment, change an order or upgrade a subscription
- update customer data, address changes or contact preferences in a master register
- adjust an ongoing case – set a new priority, add a comment, escalate to a specialist
- rework a cart, swap a product or change the payment method before checkout

**Delete or close – the assistant tidies up cleanly:**

- cancel a booking, return an order or end a subscription
- archive a case once the user confirms the issue is resolved
- remove items from a cart or a candidate from a shortlist
- pull a scheduled follow-up email or planned outreach that's no longer relevant

The MCP server is what decides which tools a given user can actually invoke: a signed-in customer can cancel their own order but not someone else's; an agent can escalate any case inside their team but not outside it. The same RBAC you already have in the back-end system is reused, with no new permission logic in the AI layer.

![Sketch of how coreAI reuses existing RBAC from the back-end system for access control](/articles/mcp-security.webp)

## Agentic AI in business processes

When the MCP client can both read and write, the assistant becomes part of the business process itself – not just a search interface in front of it. Some concrete examples of what that opens up:

- **Self-service customer care 24/7.** The customer writes: *"I'd like to move my delivery to next Friday."* The assistant looks up the order, finds valid alternatives with the carrier, changes the delivery date and confirms back to the customer – without waiting for a human agent.
- **Workshop booking with cost estimate.** The driver describes the problem in chat – *"the brakes are squealing, and the car is due for a service anyway"*. The assistant looks up the registration number and service history in the workshop system, estimates the cost of a service and brake replacement based on model, year and mileage, suggests available workshop slots and books the appointment. The user gets both the price and a confirmation in the same conversation.
- **Client conversations to an action plan.** The specialist system transcribes a conversation between a caseworker and a client. The assistant reads the transcript, extracts key points and agreed actions, builds an action plan with concrete activities, sets a due date and owner on each activity, and lets the caseworker approve the plan before it is saved back into the specialist system.
- **Internal case handling.** An employee describes an IT problem. The assistant opens a ticket with the right priority, looks up similar past cases to populate relevant fixes, and assigns it to the right team.
- **Sales and customer follow-up.** After a chat on the website the assistant creates a lead in the CRM, sends a follow-up email with the right product information, and adds a task to the salesperson's calendar.
- **Subscription and account management.** The user asks to upgrade their subscription. The assistant fetches the current plan, shows the price difference, makes the change in billing and confirms the next invoice.

What all of these have in common is that coreAI drives the dialogue and holds the context, while the back-end systems retain ownership of the data and the authorization model. You are not moving data – you are letting the assistant do exactly what it is already allowed to do on the user's behalf.

![Sketch of coreAI as both MCP client and MCP server in the same knowledge base](/articles/mcp-client-and-server.webp)

## coreAI as MCP server: one retrieval layer for all your AI agents

As a server, coreAI exposes the assistant's knowledge base via standard MCP transport over HTTP. External agents like ChatGPT, Claude and similar can connect to coreAI.

That delivers three concrete advantages:

- **One source of truth, many surfaces.** Edit a source text in coreAI and the change shows up across chat, the search API and the MCP surface at the same time. No synchronization, no duplicated vector index, no scraping on the agents' side.
- **Per-assistant access control.** Every token belongs to a user or service account, every MCP call points at one specific assistant, and every assistant is configured against an explicit set of sources. An internal developer agent can have access to the full product catalogue while a customer-specific integration only sees the one knowledge base built for that customer.
- **No vendor lock-in.** The protocol is open. Switch LLM provider or introduce a new agent platform and the MCP endpoint keeps working unchanged.

## When MCP is the right tool

Choose the MCP client when the assistant must answer based on live data from another system, when the answer depends on who is signed in, or when the user actually wants something to happen in another system – not just to be told about it. Choose the MCP server when an external AI agent already has a conversation loop and just needs the right context – coreAI handles curated retrieval, the agent handles prompting and presentation.

For relatively stable data – product catalogues, knowledge-base articles, documents, job ads – the content belongs in coreAI's own knowledge base. You fill it either by letting coreAI crawl your website on a fixed schedule, or by pushing content straight in via the coreAI API. The rule of thumb: anything that requires a live lookup or an action against another system belongs behind MCP; anything that can sit stable for hours or days belongs in the knowledge base.