24 AUG 2026
Convene a room from inside your agent
The proposal is already in the agent context. An MCP server lets that agent convene a room from where the proposal is, hand it to three personas who disagree with each other, and get the transcript back.
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.
What exists today
In development 24 Aug 2026
The server is being built, no address has been issued and no key can be created today.
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 tools/call against the live endpoint from each supported client, at least 100 tool calls per client, reported at p50 and p95 with the client named and dated.
In the browser you already have.
Be told when it ships
One email, on the day this surface ships, and nothing else. Off unless you tick it, and one click to stop.
19 AUG 2026
What there is to show, and what is measured
What there is to show, and what there is not
There is no recording of a real call, because no call has been made. What stands in its place is the shape the first one has: the command that adds the server, and one tool call with the argument it takes. It has never been run, because there is no endpoint 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
# Add the server to a client. One command, the transport and the address.
claude mcp add --transport http tingvar https://<address-not-issued>/mcp
# One tool call, in the shape a client sends it.
{
"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. The transcript is read back when the room ends. The call spends nothing on its own. It returns a join URL, and a session is spent when a person opens that URL and the room starts, against the plan on the account the token belongs to. None of that is built: there is no address, no key and no meter, so nothing can be spent from this page today.
Measured
Voice to voice
1471 ms
Median, on the bench in us-central1, with a real media server
MEASURED 2026-08-19, 122 readings
Real human sessions
0 sessions
Have taken place. Every measured turn so far used pre-rendered audio
MEASURED 2026-08-23, 1 reading
The figure on the left is voice to voice: you stop speaking, the first persona's audio starts. It is published with its method rather than as a headline, because a latency number without one is a marketing adjective with digits in it. The figure on the right is why it is not enough on its own. Both sit on the evidence page with the sample size and the five stages the median breaks into.
Why from inside an agent
Handoff and async
| Handoff | Async | |
|---|---|---|
| What the agent sends | A written brief, as the argument to one tool call. | The same written brief. This mode is planned and nothing accepts one yet. |
| What comes back | A join URL and the time it expires, then the transcript once the room has ended. | A recorded transcript and no join URL. That is on the roadmap rather than built. |
| Whether a human must be present | Yes. A person opens the join URL and speaks in the room. | Nobody would join. That is what is planned, and it is why the mode is on the roadmap rather than offered. |
| How long the caller waits | The tool call returns the join URL and ends. The room it opens is one session, 45 minutes. | The call would not return until the debate had ended. It is planned and not built. |
| Whether the mode exists today | No. It is the mode being built, and no address has been issued to call it at. | No. It is on the roadmap and no work on it has started. |
Everything the async column states is an intention rather than a description. The handoff column is the mode being built.
By the time an agent has written a migration plan or a design document, the proposal already exists in its context, fully formed and long enough that moving it anywhere is a chore. The point at which it is worth putting under pressure is exactly then, before anyone has agreed to it.
An agent that has just written a plan has the least incentive to attack it and the least ability to do so. Its context is the argument that produced the plan, so the objections within reach are the ones that argument already answered. Personas that did not write it start somewhere the plan does not reach.
The tool call is the point at which the plan stops being agreed with. Up to it, one model has been extending its own reasoning. At it, the same text goes to personas optimising for different things, under no obligation to accept the premise it was written from.
What comes back is a transcript rather than a verdict. The disagreement is the output. An agent that wanted a single confident answer would be better served by the model it already has.
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.
What a room convened this way has, and what a client has to speak
| Capability | Web app | From an agent |
|---|---|---|
| Convenes a room from a written brief | Yes | Yes |
| The same personas, the same arbiter, the same transcript | Yes | Yes |
| You speak in the room and interrupt | Yes | Only by joining the room in a browser |
| The agent hears the audio | Not applicable | No. It receives the transcript |
| Runs unattended, with nobody in the room | No | No. A person opens the join URL and the room starts when they do |
| Needs an account | Yes | Yes |
What the server does not do
- It does not run a debate without a human. open_room returns a join URL, and the room starts when a person opens it.
- It does not stream audio to the client. MCP is request and response, and what a tool call returns is text.
- It does not read your files, your repository or your environment. It receives the brief your agent sends it, and nothing else reaches us.
- It does not return a verdict or a score, because disagreement is the output we are designing for.
The connection contract
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.
Client compatibility
No client row is published here, because no client has been tested. A row is earned rather than asserted, and this is what earning one means:
- the client named, at the version it was installed at;
- that client's own configuration file path, or the command that added the server, exactly as that client documents it;
- the operating system it ran on, written down beside the version;
- the result and the ISO date of the test recorded against the row;
- the tester who ran that client against a live endpoint, named.
No row 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 row.
Tools
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.
| Tool | What a caller gets |
|---|---|
| open_room | Submits a brief. Returns a join URL, the time it expires, the persona roster and what the session would consume. |
| list_personas | The persona roster: each role, what it optimises for, and the blind spot published against it. |
| get_session | The state of a session you opened: not started, running, or ended. |
| get_transcript | A finished session transcript, with attribution on every line. |
| list_sessions | The sessions opened on your account, most recent first. |
| estimate_cost | What one session would consume against your plan, before anything is spent. |
One authenticated call
INTENDED SHAPE. The server is not live. 2026-09-09
# One authenticated call. The address and the token are both placeholders,
# because neither has been issued.
curl -sS -X POST https://<address-not-issued>/mcp \
-H "Authorization: Bearer <token-not-issued>" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{ "method": "tools/list" }' A tool call consumes nothing on its own. It returns a join URL, and one session is consumed at the moment a person opens that URL and the room starts, against the plan on the account the token belongs to.
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.
What you need
| Requirement | What it means |
|---|---|
| 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. |
| 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. |
| An account | A room convened from an agent is a room on an account, and the token is issued to that account rather than to the agent. No token can be issued today. |
If a Tingvar session drops for a reason on our side you are not charged for it, and the transcript up to that point is kept and exportable. A dropped room shows in your billing history as a session that was not charged, so you can check rather than take our word for it. Nothing about a dropped room is silently absorbed into your allowance.
Questions to answer before you install
Where does the brief my agent sends go?
To us, and then into every persona system instruction for that session. It is stored with the session, on the account the token belongs to, and it reaches our model vendor as part of the personas' context.
Is my agent context stored?
Only what the agent sends as the brief. The server has no access to your repository, your files or your environment, and it asks for none. If your agent sends a whole file, the whole file is the brief and it is stored like any other brief.
Who can read the transcript that comes back?
You, signed in to the account the token belongs to. Our model vendor receives it as part of the personas' context, and every vendor that touches customer data is named rather than described.
What does the server not do?
The list is one section up, in full: it runs no debate without a person in the room, it streams no audio to a client, it reads none of your files, your repository or your environment, and it returns no verdict or score.
Has a human read what my agent sends?
Not necessarily. The brief comes from the agent's context, which can hold text pulled from a file, a page or a tool result that nobody reviewed. What reaches the room is what the agent sends.
How do I delete a session convened this way?
Yourself, from your account, the same way as a session started in the browser. There is no separate route for one an agent convened and no request to send.
Where the recording goes
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.
Where a subscription is cancelled
A room convened from an agent is a room, and it is billed as one on the account it was convened from. There is no store between you and us on this surface: you buy on the web and you cancel on the web from your account settings. The refund terms carry the window and what happens when a room drops part way through.
Where to go from here
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.