Guides
Add live video to an AI agent via the MCP server
A remote MCP server at api.synento.com/mcp takes your agent from nothing to a verified integration: projects, keys, sessions, tokens, and manifest proof.
Integrating video the usual way means a person clicking through a dashboard: create a project, copy a key, configure webhooks, make a test call, watch the recording to check it worked. Every step waits on a human, which makes video one of the last integrations a team automates — and one of the first an AI agent is asked to do.
Synento is built so an agent can do the whole loop alone. A remote MCP server speaks the Model Context Protocol over Streamable HTTP, authenticated with OAuth 2.1, and exposes exactly the operations an integration needs: see the account, create projects, mint server keys, create sessions, mint try-out tokens, and — the step that closes the loop — verify from the recording that media actually arrived.
This guide connects a coding agent to the MCP server, walks the loop in order, and shows where each piece lands in your codebase. By the end, the agent has not only written the integration but proved it works.
1. Connect the agent
The MCP server lives at https://api.synento.com/mcp. Most clients take it as a URL with HTTP transport; the first connection signs in through the browser, which grants the connection a scoped set of projects. Nothing to install, no local server to run.
The first connection signs in through the browser, where you approve the scopes and grant the projects the connection may use. That grant is the security boundary for everything after it: widen access by reconnecting and granting more, never by handing the agent a broader credential. If a connection outlives its purpose, revoking the grant ends it.
{
"mcpServers": {
"synento": { "url": "https://api.synento.com/mcp" }
}
}2. The loop, in order
Give the agent one instruction — take this project from nothing to a verified video integration — and it runs this sequence. Each step's output feeds the next, and the loop is idempotent: re-running it reuses the project and session instead of creating duplicates.
# 1. The agent reads where it stands: org, projects, plan usage.
get_account {}
# 2. A restricted key for the project's server-side environment.
create_server_key {"project_id": "prj_abc", "label": "standup app"}
# 3. The session browsers will join. Retrying with the same key
# returns the same session instead of creating another.
create_session {"project_id": "prj_abc", "idempotency_key": "standup-1", "name": "Standup"}
# 4. A token for a local browser to try the integration with.
create_connection_token {"session_id": "sess_abc", "user_id": "alice", "mode": "live"}
# 5. The proof. Reads the recording back and reports, per participant,
# which tracks actually carried media. Ship only when this passes.
verify_session {"session_id": "sess_abc", "user_ids": ["alice", "bob"]}
# When verify_session fails but the app looks right, this checks whether
# the Synento side itself is healthy (it runs a synthetic call).
run_media_check {"project_id": "prj_abc"}3. Where the secrets land
create_server_key mints a restricted rk_live_ key for one project and returns it once, alongside the API URL and project id as ready-to-paste environment. The agent writes it to the app's server-side environment — a gitignored env file or a secrets manager — never to browser code and never to a commit. The key can only create sessions, mint connection tokens and read manifests in its own project, so it is the smallest credential that still builds the integration.
Your server then does the two things servers do here: create sessions with @synento/node, and mint short-lived connection tokens for browsers. The browser SDK carries the token as a WebSocket subprotocol, so it never lands in URLs or access logs.
4. Proof, not trust
The step that makes the loop agent-native is the last one. The agent does not report success when its code runs — it reports success when verify_session passes on a session the running app published into. The tool reads the recording back and checks each expected participant on each expected track, the same manifest check you would run by hand, and explains what is missing when it fails.
If verification fails and the app looks right, run_media_check decides which half is broken: a synthetic two-participant call through the real pipeline. A pass blames the app; a failure blames the platform. Either way the agent — or you — knows where to look instead of guessing.
5. Guides the agent reads itself
The server also serves its own documentation as MCP resources: get_guide returns the getting-started walkthrough, the SDK guide, session and webhook references, and the rest of the published docs. The agent reads the same pages you do, from the same source, so its integration follows current practice rather than its training data. Machine-readable entry points — llms.txt, the OpenAPI spec, idempotent creates — exist so the agent never has to guess a URL or a shape.
6. Scoped by default, widened on purpose
A connection sees only the projects it was granted, and every tool enforces that boundary: ask about another project and you get told it is not available, with a pointer to list_projects for the ones that are. When the agent legitimately needs a new project, you grant it by reconnecting — ownership of the boundary stays with the person who clicks, not the agent that asks.
This shapes how you hand out access. One connection per app or per environment, each granted the smallest project set that builds the thing. An agent working on the standup app never sees the research project, so a confused instruction cannot leak across them. Every call is written to the audit log with the tool, the project and the outcome, which is the record you want when something surprising happens at 2am.
7. When the loop gets stuck
Three failures cover nearly everything agents hit. Work them in this order.
Project … is not available to this connection.The agent is reaching outside its grant. List projects, use one of those, or reconnect to grant more.verify_sessionfails but the app looks right. Runrun_media_check: a pass blames the app's publishing path, a failure blames the platform underneath it.- The browser joins but publishes nothing. The token's
user_idand the room'suserIddisagree, or the token expired between minting and use — mint fresh per join and keep the ids identical.
8. Built for agents beyond the MCP server
The MCP server is the richest path, but the whole product is agent-legible underneath it. Machine-readable docs at /llms.txt, an OpenAPI spec, idempotent creates with client-chosen keys, and the manifest as ground truth mean an agent with only curl can still integrate without guessing a URL or a shape. If your agent platform cannot speak MCP yet, the same loop works over REST: create, token, publish, read the manifest back.
Whichever path the agent takes, hold it to the same bar: done means verify_session — or the manifest check it wraps — passes on a session the running app published into. An integration the agent cannot prove is an integration you will debug at midnight.
Common questions
How does the agent authenticate?
Through OAuth 2.1 in the browser on first connect, which scopes the connection to the projects you grant. Tokens are bound to the MCP endpoint as their audience, sessions are stateless, and revoking the grant ends the agent's access.
What can the agent touch?
Only the projects in its grant, and only through the tools: nothing deletes anything, nothing acts organisation-wide, and tokens are never forwarded anywhere. Every call is audit-logged.
Does the agent join calls?
No. It provisions and verifies. Browsers join with short-lived connection tokens your server mints; the agent proves the integration by reading the recording, never by watching.
Which agents work with it?
Any client that speaks MCP over Streamable HTTP with OAuth — Claude Code, Cursor, and the other mainstream coding agents. The connection snippet above is the whole setup.
More guides
- Record a video call without a recording serverThe live streams are the recording. Create a session, publish from the browser, then replay or export — with no recording pipeline to run or pay for separately.
- Verify media actually arrivedGreen dashboards lie: a participant can join while publishing nothing. The session manifest is the ground truth — a track with a non-null start_ts carried real media.
- WebCodecs vs WebRTC for recorded callsIf the call is the product, use WebRTC. If the recording of the call is the product, the WebCodecs relay trade is worth understanding.
- Async video messages and standupsAsync video is mostly replay. Create one session per standup, let the team watch on their own time through expiring links, and export only what must be kept.
- Signed webhooks for recording-ready workflowsWebhooks tell your pipeline when the recording is ready. Verify the HMAC signature on every delivery, then fan out to transcription, review or delivery.
- Restricted keys and short-lived connection tokensTwo credentials, two jobs. A restricted key identifies your server to the API; a connection token admits one participant to one session for about an hour.
Give your agent a video platform it can verify.
Sign up, point your agent at llms.txt, and have a recorded call running before lunch.