MCP Server

What MCP is, and why it matters

MCP (Model Context Protocol) is an open protocol that language-model clients use to connect to outside systems. Instead of writing a separate plugin for every piece of software, a system is exposed once as an MCP server and any client that speaks the protocol can talk to it.

On the CRM side this means: someone on your team writes "list the patients who were sent a quote this week but haven't been touched for three days" and gets the list. Nobody logs in to build a filter, nobody exports a report into a spreadsheet.

In medical tourism the difference grows with volume. In a company taking 200 leads a day, "which files went quiet" is not a question anyone answers by hand every morning — so nobody does. Asked of an assistant, it takes thirty seconds.

What the gateway can do

• Read patients — List and filter patients, open a patient record, appointments, that patient's conversations and quotes.
• Conversations and messages — List conversations, read message history, reply into a conversation, read message templates.
• Quotes — List quotes and quote templates, read the content and status of a quote.
• Consultations — Open a consultation, send messages, update its status.
• Reports — Sales, leads, calls, CRM messages and advertising reports — by period and by channel.
• Update records — Update permitted fields on patient and user records.
• Reference lists — Patient statuses, tags, languages, branches, advertising channels, user groups, countries, currencies.

Personal data does not pass through

This is the gateway's design, not a setting switched on afterwards. The JSON responses it returns never contain:

• Patient and user email addresses or phone numbers
• Conversation identity details
• Contact fields on lead records

So the assistant sees a patient's treatment request, status and message flow — but not what it would need to reach them. When it has to send a message it does so through the CRM's own channel, not by learning a number.

Health data is a special category under both GDPR and KVKK. When you evaluate an AI integration, the first question is not "what can it do" but "what leaves the building".

How it connects

A key is issued for your account and added to your assistant client as an MCP server. The key is bound to a single tenant: the assistant sees only your data, and revoking the key closes access immediately.

The gateway is closed by default on every account and opened on request. For setup and permissions, talk to our sales team.

Reading is one thing, writing is another

When the gateway is opened, the assistant can use the read tools: listing, record detail, conversation history, reports, reference lists. Those come with the product.

Tools that change data are held separately. Updating a patient, sending a message into a conversation, opening and answering a consultation, updating a user — each has to be enabled for your account individually. The default is none of them. So "we connected an AI" does not mean the AI can message a patient; that permission is granted on purpose.

Permissions are defined per tool, with no wildcards. If you want reports only, only the report tools stay open — and a read tool you would rather not expose can be closed too.

Every request is on the record

The hardest question about an AI integration is "what did the assistant actually do". The gateway logs it: which key, which endpoint, read or write, the record type and id, the status code returned and the originating IP.

For write requests it also stores the old and new value of each changed field. What changed on a patient record is not a matter for debate afterwards; it is in the log.

What it does not do

• No quote PDFs — PDF output is not available through the gateway; quote PDFs are downloaded from the admin interface.
• No cross-tenant access — A key belongs to one account. There is no path to another tenant's data.
• No model training — The gateway returns data for the question you asked; it is not used to train models.
• No unprompted patient messages — Messages are sent on a user's instruction. A fully automatic reply flow is optional, not the default.

Questions people actually ask it

• Morning briefing — "Yesterday's leads, unassigned records and follow-ups due today" — the stand-up agenda.
• Files that went quiet — "List patients who received a quote and never replied" — the list nobody builds by hand every day.
• Channel comparison — "How does the Instagram DM enquiry-to-quote rate compare with paid lead forms?"
• Handover — "Summarise everything discussed with this patient and suggest the next step."

Related pages