The Revo MCP Server

01What the Revo MCP server is

A single secure address that turns your Revo workspace into a set of tools any AI assistant can call, with no plugin to build and no API key to manage.

MCP, the Model Context Protocol, is an open standard for connecting AI assistants to real systems. Revo runs an MCP server. You point your assistant at it once, sign in with your normal Revo account, and from then on the assistant can look things up in your workspace and take action there.

What that looks like on a normal working day, and note how little you have to say:

• “Draft my OKRs for next quarter.”
• “Build a gap-analysis deck for the platform migration. Use what engineering has actually said about it.”
• “Write the PRD for tap-to-pay. Pull in the decisions from the last three calls.”
• “Is another team working on something adjacent to this? I don't want to rebuild it.”
• “What did we decide about the launch date, and who pushed back?”

None of those needed a briefing. No attachments, no explaining which project you mean, no pasting last Thursday's call into the chat. That's the difference: the first draft starts most of the way there instead of at a blank page, because who was in the room, what was agreed and what has shipped since are already known.

The assistant calls the right Revo tools, gets structured data back, and answers. Everything runs as you: the same account, the same workspace, the same permissions you have in the Revo app. If you can't see something in Revo, the assistant can't see it either.

What connects to it

Anything that supports remote MCP servers over Streamable HTTP with OAuth. That includes Claude (desktop, web and Claude Code), Cursor, VS Code with GitHub Copilot, Windsurf, Zed, and a growing list of others. Section 2 has the exact steps for each.

02Installing it, manually

One URL, no API keys. You'll sign in through a normal browser window, exactly like logging into Revo.

What you need

• A Revo account with an active workspace membership.
• An MCP-capable client (see below).
• Nothing else. There is no token to generate, no secret to paste, no config file to hand-edit unless your client requires one.

The address

Claude, desktop and web

1. Open Settings → Connectors.
2. Choose Add custom connector.
3. Name it Revo and paste https://api.revo.ai/mcp as the URL.
4. Click Connect. A browser window opens on Revo's sign-in page.
5. Sign in and approve the connection.

The connector then shows as connected, and Revo's tools appear in the tool list. Leave the “Advanced settings” (client ID and secret) empty, because the server registers your client automatically.

Claude Code

claude mcp add --transport http revo https://api.revo.ai/mcp

Then run /mcp inside Claude Code and pick Authenticate. Your browser opens, you sign in, and you're done. Add --scope user to make it available in every project rather than just the current one.

Cursor

Add this to ~/.cursor/mcp.json for all projects, or .cursor/mcp.json inside one project:

{
  "mcpServers": {
    "revo": {
      "url": "https://api.revo.ai/mcp"
    }
  }
}

Cursor will prompt you to sign in the first time it connects.

VS Code (GitHub Copilot)

Add to .vscode/mcp.json in your workspace:

{
  "servers": {
    "revo": {
      "type": "http",
      "url": "https://api.revo.ai/mcp"
    }
  }
}

Any other client

Most MCP clients accept the same shape. The three facts a client needs:

If your client asks for an API key or a bearer token, it is misconfigured for this server. Revo issues none, and a manually pasted header will be rejected.

Checking it worked

Ask your assistant something only Revo would know, such as “list my open action items” or “find my meetings from last week”. If tools are wired up correctly it will call list_action_items or find_meetings and answer from real data.

To confirm the server is reachable at all, without signing in:

curl https://api.revo.ai/.well-known/oauth-protected-resource/mcp

A healthy server returns its resource identifier and the address of the sign-in service:

{
  "resource": "https://api.revo.ai/mcp",
  "authorization_servers": ["https://sso.revo.ai"],
  "bearer_methods_supported": ["header"]
}

03What the assistant can do

Twenty tools for everyday use, across meetings, action items, knowledge, memory and workspace navigation. Each one is scoped, and each one runs as you.

Read tools are marked read, tools that change something are marked write. Nothing here deletes data outright. The closest is dismissing or snoozing an action item, both reversible.

Meetings

Scoped to meetings you can already see: everything shared with your workspace, plus your own private recordings. Never anyone else's private meetings.

Action items

Your own items, in your current workspace. Reads default to open work: completed, dismissed and cancelled items are hidden unless you ask for a status explicitly.

These tools manage action items. They do not run plans: execution stays in the Revo app, where you approve it.

Ask Revo

This is the deepest tool and the one to reach for when a question spans systems: “Check Slack and the last Acme meeting. Did we ever send them the revised SOW?” It is also the slowest. Revo streams progress updates every five seconds while it works so your client doesn't time out, and it stops on its own after 20 tool calls or 15 minutes. Cancelling in your client genuinely stops the run on Revo's side.

Team memory, the part that compounds

There are two ways an assistant can have context. It can be given it: a project folder, uploaded files, a system prompt someone wrote, which is precise on the day it's assembled and quietly wrong a month later, because keeping it true is somebody's unpaid job. Or it can observe the work itself. Revo does the second.

Your team memory is assembled continuously from meetings, chat channels, email and connected tools with nobody maintaining it: the people, customers, projects and decisions your organization actually runs on, plus the relationships between them. One person stays one entity however their name is written across a dozen systems, and every connection carries a count of how many independent sources assert it, deduplicated, so a fact repeated in one long thread doesn't outrank one corroborated across a meeting, an email and a ticket. The context becomes the durable asset and the model becomes interchangeable.

What that changes at the point of use is concrete:

• You stop briefing the assistant. “Draft the follow-up from Tuesday” is enough, because who was in the room, what was agreed and what shipped since are already known. No attachments, no re-explaining your own job.
• It retrieves instead of ingesting. Rather than pushing whole documents through the context window and paying for every irrelevant page, Revo pulls the specific facts that bear on the question, which is both cheaper and sharper, since precision beats volume once a model has enough to work with.
• It tells you things you didn't know to ask. The most valuable answers tend to be the adjacent ones: that another team hit the same problem last month, that a decision you're about to relitigate was already made. No individual can hold the whole organization in their head. This can.
• It survives your tooling choices. Memory lives outside the model, so switching assistant, provider or price tier next quarter costs you nothing. Given how fast this market moves, that is not a small property.
• It gets better the longer it runs. Every meeting and thread deepens it. The teams that see the most value are simply the ones that started earliest, and a new joiner inherits all of it on day one instead of spending a quarter asking around.

Through MCP, your assistant reaches two layers of this: your own memories, which are private to you, and the team knowledge graph, filtered to exactly what you're permitted to see. Private meetings and email stay private: they inform your work and no one else's.

Usage and workspaces

Revo staff tools

A further nineteen tools exist for Revo's own support and operations staff (revo_admin): workspace lookup, billing changes, usage reporting, the integration catalogue, signup blocklists and brain debugging. They are the only tools that can address a workspace other than the caller's own.

They are off for everyone by default. Access is gated by a feature flag targeting named staff email addresses; if you are not on that list, these tools are not merely refused, they are absent from the tool list your assistant receives, so it cannot know they exist or attempt to call them. Section 5 covers the mechanism.

04How it works

Revo validates who you are, works out what you're allowed to do from its own records, and shows your assistant only the tools that survive that check.

Signing in

Revo's MCP server issues no credentials of its own. Sign-in is handled by WorkOS AuthKit at sso.revo.ai, the same identity service behind the Revo app. The server's only job is to check the resulting token and decide what it permits.

The whole exchange is automatic, and it's why you never paste a key:

1. 01
   Your client asks the server who it answers to

   It fetches /.well-known/oauth-protected-resource and learns the sign-in service is sso.revo.ai. This is the standard discovery document defined by RFC 9728.

2. 02
   Your client registers itself

   Dynamic Client Registration means the client obtains its own identity on the fly. Nothing is shared between users, and nothing was pre-provisioned by an administrator.

3. 03
   You sign in and consent, in a real browser

   Standard authorization code flow with PKCE (S256 required). Your password is entered on Revo's own sign-in page and is never seen by the AI client.

4. 04
   The client receives a short-lived access token

   Bound by audience to https://api.revo.ai/mcp, so it is useless anywhere else, including against Revo's other APIs. A refresh token keeps the connection alive without asking you again.

5. 05
   Every subsequent request carries that token

   And every one of them is re-validated from scratch. See below.

What happens on each request

There is no trusted session sitting in memory. Each call your assistant makes runs the full check:

Because this runs per request rather than per session, a role change or an offboarding takes effect immediately. There is no stale session to wait out.

Permissions, concretely

Every tool declares one required permission, written domain:action. Your workspace role grants a set of them, cumulatively: an Admin holds everything a Member holds, plus more.

The check fails closed by design. A tool with no declared permission is never exposed to anyone; a request with no resolvable user gets an empty tool list rather than a default one. Adding a tool without also granting its permission makes it invisible, not accidentally public.

Where the server runs

Revo's MCP server runs inside the main Revo API, behind the same TLS termination, edge protection and infrastructure as the product. It runs stateless: no conversation state is retained between calls, requests can be served by any instance, and session identifiers handed back to clients are encrypted rather than guessable. That is what makes the per-request revalidation above possible, and it means a deploy or restart never silently downgrades a live connection.

05Security

The short version: no long-lived secrets exist to be leaked, authorization is never taken on trust from a token, and a workspace is never a parameter your assistant can change.

No credentials to lose

• No API keys. There is no key to generate, store, rotate, accidentally commit, or paste into the wrong window. If a client asks for one, it's wrong for this server.
• Short-lived tokens. Access tokens expire quickly and are refreshed silently. A captured token has a small window and works only against the MCP endpoint.
• Audience binding. A token minted for the MCP endpoint is rejected everywhere else, and tokens minted for other Revo services are rejected here.
• PKCE is mandatory. S256 is the only challenge method offered, which closes off authorization-code interception on the redirect.
• Your password never reaches the AI client. Authentication happens in your own browser, on Revo's domain.
• Revocation is immediate. Revoking the session stops the connection at the next request. There is no offline capability to expire.
• Your identity provider stays in the loop. MCP sign-in uses the same hosted login as the Revo app, so a workspace configured with SAML or OIDC single sign-on authenticates through its own IdP here too. MFA, device posture and conditional access policies apply to the MCP connection exactly as they do to the web app.
• Offboarding takes effect immediately. Workspace membership is re-checked on every single request. Remove someone from the workspace and their next MCP call fails, regardless of how long their token had left to run. Section 6 covers revocation in full.

Authorization is computed, not claimed

This is the single most important property of the design. The access token establishes identity only. Every question of permission (which workspace, which role, which tools, which records) is answered by querying Revo's own database at the moment of the call.

The practical consequence: a forged, replayed, or over-scoped token cannot grant access, because nothing in the token is consulted when deciding what the caller may do. Neither can a compromised AI client, a malicious prompt, or a bug in the assistant. None of them are in a position to influence the answer.

Tenant isolation

The workspace an MCP call operates on is derived from your user record on the server. It is not a tool parameter: no user-facing tool accepts a workspace, team, or user identifier that would let a caller point it somewhere else. Prompt injection cannot redirect a call to another customer's data, because there is no input to inject into.

Within your own workspace, the same access rules the Revo app enforces apply again at every tool:

• Meetings resolve to workspace-shared meetings plus your own private ones, never a colleague's private recording.
• Knowledge-graph results are filtered to your visibility before they are returned.
• Memories are private to you.
• Per-teammate usage requires the admin permission; a member sees only the workspace total.
• Writes go through the same validated commands as the app, so the same rules and audit events fire.
• Record identifiers are hashed rather than sequential, so they cannot be enumerated by guessing.

The staff tools, and why they're safe

Revo's cross-workspace support tooling is the one place where a workspace is an argument, so it gets a separate control:

• A distinct permission namespace (revo_admin:*) that no customer role can ever be granted.
• An internal-staff check evaluated against a feature flag keyed on the caller's email address, off by default, so the tools are dark unless a named individual is explicitly targeted.
• Tools are removed from the listing, not merely refused, so a non-staff assistant never learns they exist.
• The one genuinely destructive tool, the account-erase used to reset test accounts, is additionally hard-locked to development environments by an allow-list, and refuses outright anywhere else. It cannot run in production regardless of who calls it.

Transport and infrastructure

• HTTPS only, HTTP/2, behind Cloudflare edge protection.
• Session identifiers returned to clients are encrypted with a shared key ring, so they cannot be forged or read, and remain valid across instances and restarts.
• Any credentials you store for your own custom MCP servers inside Revo are encrypted at rest.
• Failed authentication is logged with the specific reason (bad signature, wrong audience, expired) without ever writing the token itself to logs.

What you should still think about

Two honest caveats, neither specific to Revo but both worth stating:

06Administrative controls

What a workspace administrator can govern today, stated plainly, including what is not yet configurable, and the control that compensates for it.

Security reviews turn on this section rather than the last one, so it is written to be checked rather than reassuring. Where a control does not exist yet, it says so.

What you control today

What is not configurable yet

These are genuine gaps, not omissions from this page. If any is a condition of approval, raise it with your Revo contact. Several are small changes on a design that already fails closed.

If you are evaluating for an enterprise rollout

The honest summary: the security model is strong, the administrative surface is thin. Isolation, least privilege and credential handling are enforced in the platform and are not weakened by MCP. But the levers an administrator has are the platform's existing ones, roles, memberships and your IdP, rather than MCP-specific policy.

For a controlled pilot that works within today's constraints: scope it to a named group, give those users the minimum Revo role that covers the work, keep them in an SSO-enforced group so access follows your joiner-mover-leaver process, and review their usage through the admin usage report. Ask Revo directly about timelines for org-level disable, per-scope restriction and an exportable audit log.

07Privacy and compliance

The MCP server is part of the Revo platform and sits inside the same certified information security and privacy management systems. It is not a side channel around them.

The MCP server introduces no new data store, no new identity system and no new permission model. It is a protocol surface over the platform you have already assessed: the same database, the same identity provider, the same access rules, the same infrastructure and the same audit scope.

What a reviewer usually asks

Data minimisation in the tools themselves

Beyond policy, the tools are built to hand back less rather than more:

• Meeting search returns a truncated summary rather than the whole transcript; the full text requires a deliberate second call.
• Action item steps deliberately omit raw tool output and error dumps.
• Knowledge-graph results carry only recorded relationships, so an assistant can't present an inferred connection as fact.
• Usage reporting caps and truncates rather than streaming unbounded personal data, and gates the per-person view behind an admin permission.

08Limits and known behaviour

Things that are true by design, so they don't surprise you later.

• One workspace at a time. There's no picker in the sign-in flow. The connection uses whichever workspace is currently active for your account, and switch_workspace changes it globally, including in the Revo web app. The change applies from the next tool call, not the one in flight.
• Tools only. The server exposes tools, not MCP prompts or resources.
• No push notifications. Because the transport is stateless, the server can't proactively notify your client that something changed. Assistants poll by asking.
• ask_revo is slow by nature. It bounds itself at 20 tool calls and 15 minutes, and emits progress every five seconds so clients don't give up. A client with an aggressive fixed timeout may still cut it short.
• No plan execution. Action item tools manage items; running a plan stays in the Revo app where you approve it.
• No MCP-specific admin policy. Connection is self-service and permissions follow your Revo role; there is no workspace switch, per-tool restriction or client allow-list yet. Section 6 is the full inventory.
• Not in the Claude directory yet. Manual custom-connector setup is the supported path today, and is functionally identical.

09Troubleshooting

Almost every failure is one of four things.

Confirming the server itself is healthy

curl -i -X POST https://api.revo.ai/mcp \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize"}'

A healthy server answers 401 with a WWW-Authenticate header pointing at its discovery document. That is the correct response to an unauthenticated call: it's how your client learns where to sign in. Anything else (a 403, a 404, a timeout) means you have the wrong address.

10Questions

The things people ask before they connect it.