24 AUG 2026
Connecting a client to the MCP server
Everything a client needs is on this page: the quickstart, the method by which a configuration block is earned, the tool reference, how a key works, what a session consumes, and what to do when a call fails.
What exists today
In development 24 Aug 2026
No server address has been issued, no key can be created and nothing on this page answers a request today. Every step below is written in the tense it carries on the day one does.
MCP is a request and response protocol. An MCP client cannot hold a live microphone. That is why the tool returns a join URL rather than a debate: a person opens the URL, speaks in the room, and the transcript is read back afterwards.
p50 1,471 ms, p95 1,986 ms, p99 2,156 ms, voice to voice, from the end of a human utterance to the first sample of persona audio at the client. Method: 122 readings over 200 utterances against Vertex AI in us-central1 and a real SFU, taken on 19 Aug 2026. The figure describes the room the join URL opens and not the MCP round trip, and the evidence page carries the same run broken into its stages.
The MCP tool call round trip is NOT MEASURED. What would measure it is a timed tool call against the live endpoint from each supported client, reported at p50 and p95 with the client named and dated.
The connection contract
The same rows the MCP page and the developer page carry, from the same module, so no two of the three can disagree about what a client is wiring into. Three of the six have no value yet and say so in the row.
| Field | Value |
|---|---|
| Transport | Streamable HTTP. It is the transport a hosted MCP server uses, and a client that can already reach a hosted MCP server can reach this one. |
| Server address | Not issued yet. This page carries no hostname until one resolves, and printing one early would be the first thing on this page a reader would try. |
| Authentication | An account bearer token, issued from the signed in account settings and scoped to one workspace, and no key issuance is built, so there is nothing to create today. |
| Tools | The tool list is not frozen. It is published here in full, with each tool signature, in the same commit that makes the server reachable, and it is versioned from that day. |
| Rate limits | A room is a 45 minute live audio session with a real cost behind it, so the limit is a concurrency limit on rooms rather than a request rate. The number is set when the per session cost is known. |
| What the server may not do | It may not read your repository, your files or your environment. It receives the brief the agent sends it, and nothing else reaches us. |
Last reviewed 2026-09-05. Zero client configurations have been run against this server, because no server is running, so that is the day somebody last read this page against the registers it renders from, and not the day a configuration was executed. It is typed by hand and moved by hand, never taken from the file's history.
Quickstart
Five steps, from a signed in account to a room. None of them can be completed today, because there is no address to connect to and no key to create, and that is the whole of what is missing: the steps themselves are what they will be on the day the server answers.
01
Create a key in your account settings
Sign in on the web and create a key for the workspace the sessions will be billed to. A key belongs to an account, not to an agent, and the web is where anything commercial is issued.
What you should see The key listed in your account settings, with the date it was created.
02
Add the server to your client
Put the server address and the key into your client's own MCP configuration, at the file path that client documents and under the key names that client documents. Two clients read different files and name the same setting differently, so use your client's own current documentation rather than a block copied from anywhere else.
What you should see The client starting with no configuration error, and the Tingvar server appearing in its own list of servers.
03
Restart the client
A client reads its MCP configuration when it starts. A file edited while the client is running is a file the client has not read.
What you should see The server reported as connected in the client's server list after the restart.
04
Ask the client to list the tools
The client asks the server what it can do and shows you the answer. This is the step that separates a configuration problem from a connection problem, so it comes before the first real call.
What you should see The tool names listed by the client, beginning with open_room.
05
Call open_room with a brief
Send the proposal you want argued with as the brief. The shape of the call is below this list. What comes back is a join URL rather than a debate, and the room starts when a person opens it.
What you should see A join URL and the time it expires, returned by the call.
The shape of the first two calls
This has never been run, because there is nothing to run it against, so the date on the label is the date the shape was last confirmed and not a date it executed. open_room is a proposed tool name and the tool list is not frozen.
INTENDED SHAPE. The server is not live. 2026-09-09
# The first request a client sends. It asks the server what it can do.
{
"method": "tools/list"
}
# Then one tool call, with the argument open_room takes.
{
"method": "tools/call",
"params": {
"name": "open_room",
"arguments": {
"brief": "Split the shared database behind billing, invoices first. Say what breaks."
}
}
}
# What comes back is a join URL and the time it expires. A person opens it
# and speaks in the room. get_transcript reads the transcript back once the
# room has ended. A tool call consumes nothing on its own. It returns a join URL, and one session is consumed the moment a person opens that URL and the room starts.
There is one confirmation point and it is a person. An agent running the call above on its own opens no room and consumes nothing. If nobody opens the join URL before it expires, the URL expires, nothing is consumed, and the session reports itself as never started.
Configuration
A configuration block is a claim about software somebody else writes, and the claim goes stale without telling us. So a block is earned rather than asserted, and this is what earning one means. Every block published here will carry all six of these, and a block missing any one of them is not published:
- the client named, at the version it was installed at;
- the operating system it ran on, written down beside the version;
- that client's own configuration file path, exactly as that client documents it;
- that client's own key names, read from its current documentation on the day the block was written;
- the ISO date the block was last verified;
- the result: the client listed the tools, or it did not, and what happened instead.
The fourth of those is the one that catches the error nobody expects. Two clients can read different files and call the same setting by different names, so a key name borrowed from another client produces a block that looks right, parses, and connects to nothing. That failure reads to a developer as our fault, and it is: we published it. Reading each client's own current documentation on the day is what stops it.
No block can be added until an endpoint exists to connect to. There is nothing Tingvar specific in the connection, so a client that can already reach a hosted MCP server is likely to reach this one, and likely is not a block.
Until then, step two of the quickstart is the honest instruction: use your client's own documentation for the file and the key names, and this page for the address, the key and what the tools do.
Tool reference
INTENDED SHAPE. The server is not live. 2026-09-09
These names are a proposal and they are not ratified. The list the server advertises is the list published here, in full and with each tool signature, in the same commit that makes the server reachable, and it is versioned from that day. The same names, in the same order, are on the MCP page.
No schema appears below. A schema is the machine's copy and a client already has it the moment it can ask the server; none is ratified in any case, so publishing one here would be publishing a specification of a server nobody has written. What is below is the reader's copy: what each tool is for, what it takes, what it returns, what it costs and how it fails.
open_room
| Field | Value |
|---|---|
| Purpose | Submits a written brief and opens a room for it. |
| What the caller supplies | One brief, as plain text. It is what every persona is given, so it is the proposal you want argued with rather than a description of it. |
| What comes back | A join URL, the time that URL expires, the persona roster for the session, and what the session would consume. |
| What it consumes | Nothing on the call. One session is consumed when a person opens the join URL and the room starts. |
| Error conditions | The key is rejected or revoked. The brief is empty. The account has no session left on its plan. |
list_personas
| Field | Value |
|---|---|
| Purpose | Returns the persona roster, so a caller can see who would be in the room before opening one. |
| What the caller supplies | None. |
| What comes back | Each persona's role, what it optimises for, and the blind spot published against it. |
| What it consumes | Nothing. |
| Error conditions | The key is rejected or revoked. |
get_session
| Field | Value |
|---|---|
| Purpose | Reports the state of a session opened on this account. |
| What the caller supplies | The identifier of a session on this account, as open_room returned it. |
| What comes back | One of three states: not started, running, or ended. |
| What it consumes | Nothing. |
| Error conditions | The key is rejected or revoked. No session on this account carries that identifier. |
get_transcript
| Field | Value |
|---|---|
| Purpose | Reads back the transcript of a session that has ended. |
| What the caller supplies | The identifier of a finished session on this account. |
| What comes back | The transcript, attributed line by line, in the order it was spoken. |
| What it consumes | Nothing. Reading a transcript again consumes nothing, however many times it is read. |
| Error conditions | The key is rejected or revoked. The session has not ended. The session was deleted, in which case there is nothing to return and nothing to recover. |
list_sessions
| Field | Value |
|---|---|
| Purpose | Lists the sessions opened on this account. |
| What the caller supplies | None. |
| What comes back | The sessions on this account, most recent first, each with its state. |
| What it consumes | Nothing. |
| Error conditions | The key is rejected or revoked. |
estimate_cost
| Field | Value |
|---|---|
| Purpose | Says what one session would consume against this account's plan, before anything is spent. |
| What the caller supplies | None. |
| What comes back | What one session consumes against the plan on this account, and what is left of that plan's allowance. No currency figure: prices are on one page and this is not it. |
| What it consumes | Nothing. |
| Error conditions | The key is rejected or revoked. The account carries no plan. |
A tool call consumes nothing on its own. It returns a join URL, and one session is consumed the moment a person opens that URL and the room starts.
Every tool above except open_room consumes nothing under any circumstances. A session can be consumed through that tool alone, and even then it consumes nothing until a person opens the URL it returned.
Authentication
A key is an account fact rather than a protocol fact. What it is made of is not something a reader needs and not something this page will publish. What a reader needs is where it comes from, what it reaches, how to stop it, what a rejected call looks like, and whether holding one costs anything.
Where a key is created
On the web, in your account settings, after you have an account. There is no separate developer console and there is no plan to build one: the web is the surface that issues anything commercial, and a key is issued to the account that pays for the sessions it opens. No account can create a key today, because key issuance is not built.
What a key authorises
One workspace on one account, and nothing else. A key opens rooms on that workspace and reads that workspace's own sessions and transcripts. It reaches no other account, no other workspace, and nothing on your machine: the server does not read your files, your repository or your environment, and it asks for none of them. What reaches us is the brief your agent sends.
How a key is revoked
From the same account settings that created it, by you, with no request to send us. Revoking one takes effect for every client holding it, and a revoked key cannot be restored: the replacement is a new key, which is the point. A room already running when a key is revoked is not ended by the revocation, because the person in it is a person rather than a caller.
What a caller sees when a key is rejected or has expired
The call returns an authentication error rather than a result, and no room is opened. A rejected call is indistinguishable from an expired one to the caller, on purpose, because the difference is information about somebody's account. The exact error a client displays is published here on the day the server first returns one, rather than described in advance from a server that has never answered.
Holding a key consumes nothing
A key is not a session. Creating one consumes nothing, holding one consumes nothing, and a key that is never used costs nothing at all. A tool call consumes nothing on its own. It returns a join URL, and one session is consumed the moment a person opens that URL and the room starts.
Limits and what a session consumes
What is enforced today
No rate limit and no concurrency limit is enforced today, because there is no server running to enforce one. That is the honest answer and it is the whole answer: no number is published here, because publishing one would mean inventing it.
When a limit is enforced it is published on this page, with its unit and with the date it takes effect, before it takes effect. A limit that appears in a rejected call before it appears here would be a limit we imposed and did not tell you about.
What one session consumes
A tool call consumes nothing on its own. It returns a join URL, and one session is consumed the moment a person opens that URL and the room starts.
There is no free tier, so there is no free session for a speculative call to spend. Every session comes out of a plan, and a room convened from an agent is a room on that plan rather than a separate kind of thing with a separate allowance.
| Plan | What one session consumes |
|---|---|
| Professional | One session from that month's included allowance, whether the room was convened from an agent or from a browser. A room convened this way is a room. |
| Team | One session from the workspace's included allowance. The key is scoped to one workspace, so the session is drawn from that workspace and not from another. |
| Enterprise | One session from the allowance written into your agreement. There is no separate agent allowance and no separate agent rate. |
At the edges
Tingvar plans stop at their included allowance rather than charging past it. Both plans are capped rather than metered, so the monthly figure on the pricing page is the largest amount you can be charged in a month. There is no overage and no silent upgrade. A plan that quietly bills past its own ceiling is a trick rather than a business model. Your transcripts stay available and exportable.
A session that fails on our side is not a consumed session. You are not charged, and the transcript up to that point is kept.
What happens to the brief and the transcript
Tingvar does not store your session audio: it is processed while the room is live and no recording of it is kept. What persists is the transcript, the text of what you said and what each persona said, attributed line by line. Only the account that ran the session can read that transcript, and nobody at Tingvar reads one without your written request on a support case. You can delete any session yourself, and deletions are purged from backups within 30 days. The retention schedule is published at tingvar.com/trust/your-data.
The brief an agent submits is customer content under the same terms as a brief typed in the browser.
Troubleshooting
In the order a developer meets them. The first is the one with no error message attached to it, which makes it the one nobody can search for.
The client does not list the tools
Symptom The client starts, the server appears in its own list, and no tool names appear under it. Nothing reports an error.
Likely cause The configuration was written to a file the client does not read, or under a key name the client does not recognise, or the client has not been restarted since the file changed.
What to do Open the configuration file your client documents, confirm the entry is in that file and uses that client's own key names, restart the client, then ask it to list the tools again.
Authentication is rejected
Symptom A call returns an authentication error rather than a result, and no session is opened.
Likely cause The key was revoked, it was created for a different workspace, or it was copied with a character missing.
What to do Check the key in your account settings against the one in the client configuration. Create a new key if the old one is revoked, replace it in the client, and restart the client.
The endpoint is unreachable
Symptom The client reports that it cannot connect, and no error comes back from us because nothing answered.
Likely cause No server address has been issued, so there is nothing at any address to reach. This is the state of the whole surface today rather than a fault on your machine.
What to do Nothing on your side. The address is published on the MCP page in the same commit that makes it resolve, and the state line there says which of those two days it is.
The join URL has expired
Symptom Opening the join URL says the room is no longer available, and no room opens.
Likely cause The URL carries the time it expires, and that time passed before anyone opened it. A room nobody joins does not wait indefinitely.
What to do Call open_room again and open the new URL. Nothing was consumed by the expired one, because a session is consumed when a room starts and that room never did.
The session has already been consumed
Symptom The join URL opens a session that has ended rather than a live room.
Likely cause That room already ran. A join URL opens one room, and one room is one session.
What to do Read it back with get_transcript, or call open_room again for a new room. If the room ended before you expected it to, or the transcript is not what you expected, the two support articles below answer those separately.
Where these answers continue
Two of the failures above have a longer answer in the Help Centre, written for anyone in a room rather than for a caller. They are not repeated here.
Can I use it from a coding agent or an automation?
Tingvar exposes an MCP server, so an agent you already run can convene a room from where your proposal already lives. Claude Code, Cursor, Windsurf and Zed all speak MCP. The connection details, the authentication and an exact list of what exists today against what is still roadmap are on the MCP page, written in the tense each one deserves. A room convened this way is the same room you would join from a browser.
IDLE
Nobody has used this yet
Zero real human sessions have taken place. Every measured turn to date used pre-rendered audio clips rather than a live human. What is built and verified is the decision layer: the turn-taking policy, the bid scoring and the configuration guards, with 619 automated tests passing and 81.78 % combined coverage. Everything there says the system works. Nothing there says anyone wants it, and being first is a real risk you are taking.
For a developer deciding whether to wire this into anything, that is the load bearing paragraph on the page.