Your agent needs to read what happened in a meeting. Otter.ai now offers two official ways in: a hosted MCP server and a Public API. They cover overlapping data but different capabilities, sit behind different auth, and carry different operational weight in production. One is read-only and connects from almost any account. The other is Enterprise-gated, key-based, and the only path that can push events. This article is the decision framework for which one your agent should build against, and how to wire either through Scalekit.
These are two distinct objects with different design intents. The MCP server exists to drop meeting context into an interactive AI client. The API exists to move meeting data into systems on a schedule or on an event.
Otter runs a provider-hosted MCP server at mcp.otter.ai/mcp. Access is OAuth-authenticated with per-meeting permissions, so an agent reads only meetings the user captured or had shared with them. The surface is deliberately small: three tools that search meetings, fetch a full transcript, and return the current user with get user info. There are no create, update, or delete tools; the server is read-only by design. Details are in Otter's MCP server documentation.
The Public API is a REST surface at api.otter.ai/v1, available to Enterprise workspaces only. It authenticates with a Bearer API key created in the workspace Developer settings, capped at two keys per user and 10 requests per second. It exposes channels and members, conversations (list, retrieve, and POST to ingest a file), audio download links, workspace details, and cursor-based pagination. It also ships webhooks. The full reference is in Otter's Public API documentation.
The two paths diverge on four axes that decide production fit: what your agent can do, how it authenticates, what you operate, and which scenarios each one wins. Read the capability gap first; it drives the rest.
The MCP server is strongest at retrieval-by-meaning: its search tool takes a semantic query plus filters for attendee, date range, folder, channel, and transcript keywords. The API has no semantic search endpoint; it lists and filters conversations, but it returns richer structured objects and can write.
The gap is real in both directions. If your agent needs to answer "which calls mentioned pricing pushback," the MCP server does it in one call. If your agent needs the MP3, the per-meeting action items as data, or a push when a transcript is ready, only the API delivers that.
This is where Otter departs from the usual pattern. The MCP server uses OAuth 2.1 with a browser consent step, minting a token scoped to what the user authorized. The API does not support OAuth at all; it uses a static Bearer key the user generates in the dashboard. There is no public API key for the MCP server, and no OAuth for the API. The choice picks your credential type.
For a multi-tenant B2B agent, the implication is identical on both paths. Every user carries their own Otter credential: an OAuth token on the MCP path, an API key on the API path. That is N credentials to store, refresh or rotate, and revoke, regardless of which surface you chose. The token type changes; the isolation requirement does not.
On the MCP path, the hosted server owns tool schemas, endpoint normalization, and transport. You still own the OAuth lifecycle: token storage, proactive refresh, revocation on offboarding, and tenant isolation across users. When Otter renames or reshapes a tool, your agent should discover the current surface at runtime rather than hardcode names.
On the API path you own more. You write and version the request layer, handle 429 backoff against the 10-per-second limit, page through cursors, manage two-key-per-user limits, and stand up a webhook receiver if you want real-time behavior. Nothing about the key rotates itself. The tradeoff is control: deterministic, auditable, event-driven pipelines that the read-only MCP server cannot express.
The decision is rarely about preference; it follows the shape of the agent.
Use Otter MCP when:
Use the Otter API when:
The comparison table can make this look like a clean either-or. In production it is not, because the hard part is the same on both sides. Neither path is a credential manager.
An OAuth token and an API key are both just a credential handed to your agent. Neither Otter surface gives you a vault, a rotation schedule, or a revocation flow. In a single-user demo that is invisible. In a multi-tenant agent it is the whole problem: every user has their own Otter credential, and that is N secrets to store encrypted, refresh before expiry, isolate per tenant, and kill on offboarding. Get this wrong and one tenant's agent can reach another tenant's meetings.
This is the layer Scalekit's Otter connector owns: it runs the OAuth 2.1 flow, vaults and refreshes tokens, and scopes execution to a per-user connected account, so the MCP-vs-API decision does not change your auth infrastructure. For the deeper pattern, see single vs multi-tenant tool-calling agent auth.
Scalekit's prebuilt Otter connector wraps the vendor MCP, so you get authenticated tool calls without writing schemas or handling tokens. The pattern is always the same order: resolve who the user is, retrieve the tools their connected account authorizes, then run the agent loop. The examples below use LangChain in TypeScript and the Claude SDK in Python.
In the Scalekit dashboard, go to AgentKit, Connections, Create Connection, and add otteraimcp. Copy SCALEKIT_ENV_URL, SCALEKIT_CLIENT_ID, and SCALEKIT_CLIENT_SECRET from Developers, API Credentials. The connection name you pass in code must match the dashboard name character for character; a mismatch is the most common cause of an empty tool list. Full setup is in the AgentKit quickstart.
Before the loop runs, the user connects Otter once over OAuth, and the agent loads only the tools that connected account is authorized to call. It receives a scoped surface, not a flat catalog. The code below sends the user through consent, then binds the scoped Otter tools into a LangGraph agent.
The Python path uses the same connected account. list_scoped_tools returns Otter's tools in Anthropic's native format, so there is no schema writing. Each tool_use block is executed with the user's identifier, and Scalekit resolves the connected account, pulls the vaulted token, and calls Otter as that user. Credentials never touch the agent runtime.
Tool names come from the connector's current tool list; when in doubt, list the tools for the user first rather than hardcoding a name. Runnable versions live in the Scalekit LangChain and Anthropic examples.
Otter's MCP surface is small, so this is not a story about taming a hundred tools. The value shows up on the two problems a meeting agent actually hits in production: per-user isolation across tenants, and combining Otter with other connectors under one identity.
A shared credential gives every user the same access, which fails the moment a second user arrives. A connected account inverts that: scope is derived from what each user individually authorized in Otter, nothing more. What the user cannot see, the agent cannot fetch. Scope becomes a function of identity, not connector configuration; see access control for multi-tenant AI agents and the token vault model.
A real meeting agent rarely stops at Otter; it also touches a CRM, a tracker, or Slack. A Virtual MCP Server gives that agent one scoped endpoint that exposes only the tools you allow across connectors, with per-user credential isolation handled by a short-lived session token minted before each run. One server definition serves all users, and there is no MCP server to deploy, host, or maintain. Background is in agent tool observability and when to use one.
Because the read-only MCP path and the write-capable API path both act as a user, you need to answer who authorized, which agent ran, which tool it called, and what came back. Scalekit records that per tool call, so a transcript pulled or a conversation ingested is traceable to a specific connected account. See audit trails for agent auth and the broader pattern of secure token management for AI agents.
If your Otter agent is interactive and read-oriented, answering questions over a user's transcripts across standard plans, build against the MCP server. If it is event-driven or needs audio, structured insights, ingestion, or channel metadata inside an Enterprise workspace, build against the Public API. Many teams end up running both: the MCP server for the conversational surface, the API for the pipeline behind it. Either way, the credential problem is identical, and that is the part that needs production-grade infrastructure rather than a token pasted into an environment file. For the broader framing, see how MCP and APIs differ.
Building a meeting agent on Otter? Browse the Scalekit Otter connector and its docs page, then start from a template like meeting prep, sales call prep, or the deal intelligence agent. Pricing is on the Scalekit pricing page, and the full catalog is under all connectors.
For hands-on help, join the Scalekit community on Slack or talk to us for immediate answers.
