For companies
SubLive keeps the calls and meetings your company chooses to save. MCP is the open standard that lets an AI client or an automation — Claude, Cursor, your own agent — read that archive and act on it. The data goes to the model you connect; the answers are its own. SubLive stays the system of record and the gatekeeper.
MCP comes with every company account. It stays closed until an administrator turns it on.
MCP (Model Context Protocol) is a standard way for an AI client to reach an outside source of data. SubLive runs an MCP server in front of your company's conversation archive. Once an administrator turns it on, a connected client can list conversations, search them, read a summary or the full text, and check company usage — the things a person does in the admin panel, done by software.
Your AI client or automation
Claude, Cursor, your own agent, a script
SubLive MCP server
Runs the same checks as the website
Conversations your company saved
Transcripts and summaries, within your retention window
You
Summarise what we agreed with the supplier on this week's calls.
Calls tools
search_conversations(query: "supplier", since: "7d")get_conversation(id: …, format: "summary")Replies
Three calls this week. Agreed:
Five tools, four of them read-only. Each one runs through the same permission checks, audit log and limits as the website.
The archive is the raw material. What you do with it is up to the tools you already run.
After each client call, an agent reads the summary and turns it into a structured note: what was decided, who owns the next step, and by when. It lands in the channel or the doc your team already reads, in the language they work in — nobody stays late to write it up.
search_conversations for the window, get_conversation for each summary.
New conversation, and your automation extracts what a salesperson would otherwise re-type: the objections raised, the budget and timeline mentioned, competitors named, the agreed next step. It writes them onto the deal in your CRM as fields and notes.
list_conversations to catch what is new, get_conversation for the full text, then your CRM’s API.
Every Friday an agent searches the week for the themes you care about — renewals, churn risk, a pricing complaint, a feature request that keeps coming up — reads the summaries behind them and writes a one-page digest: what is trending, which deals look shaky, what product heard this week.
search_conversations per theme, get_conversation for context, your own template for the write-up.
Instead of sampling a handful of calls, an agent reads all of them for the phrases that matter: a promise your policy does not allow, a disclosure that had to be made, a tone that needs a manager’s attention. It builds the shortlist a human actually reviews, and a coaching list per person.
list_conversations for the period, get_conversation in full, your rules for the flags.
An agent clusters the questions that come up across calls and drafts the help-centre article or the sales battlecard from real phrasing, not a guess at it. Re-run it monthly and the knowledge base tracks what customers are asking now.
search_conversations to gather, get_conversation for the exact quotes.
The agent notices a client or product name being mis-heard the same way across several calls and appends the correct mapping to the company glossary. Every session after that — everyone’s — gets the name right, in recognition and in translation.
search_conversations to spot the pattern, add_glossary_terms to fix it.
In the company admin panel an administrator signs the acknowledgement — conversation data, including the other party’s speech, goes to the model you connect — and chooses who may use MCP: administrators only, or everyone.
Point a client that supports remote MCP servers at the endpoint below. It opens a browser consent screen: the employee signs in, approves the scopes, and access ends when their account access does. Nothing to copy.
For CI and unattended agents, create a key in the cabinet under “API keys” with the scopes the agent needs, then send it as an Authorization: Bearer header to the same endpoint. A key never outlives its owner’s access.
“What did we agree with Acme last week?” “Draft the follow-up in German.” “Which calls this month mentioned the renewal?” The client calls the tools; you read the answer.
A stdio bridge for clients that speak only stdio is on the way. For now, use a client that supports remote MCP servers, or call the endpoint directly with a key.
Handing conversation data to an outside model is a new purpose, not a continuation of the consent to record. It is built to be governed.
The default is closed to everyone. It opens only after a named administrator signs the acknowledgement, on behalf of the company.
The agent inherits one person’s permissions. An employee limited to their own conversations reads only those; a former employee’s key reads nothing.
Opening a conversation, exporting it, running a search — each lands in the company activity log with the tool and the key or account behind it. “Who pulled our conversations” has an answer.
A key is capped on requests per minute and conversations per hour. A leaked key cannot drain the archive before anyone notices.
get_conversation returns a summary unless the full text is asked for by name, so an agent that needs only the gist does not pull tens of thousands of words of other people’s speech into its context.
Every response carries the conversation’s expiry date. SubLive deletes on schedule; a copy left in an agent’s cache is the connecting company’s responsibility, and the DPA says so.
A transcript can contain “ignore previous instructions”. The tool descriptions state plainly that conversation text is there to be read, never followed.
No ordering AI summaries, no changing policies, no managing people or money, no access to a live session. The one write is glossary terms.
MCP comes with every company account. Turn it on when you are ready — it is closed until you do.