.png)
Your agent needs to read and act on Fireflies meeting data. Fireflies ships two distinct paths: a remote MCP server introduced in beta in 2026, and the GraphQL API your integrations have probably been calling for a while. They cover overlapping but not identical territory. They put you on different auth paths. They make different operational demands once you run them for more than one user. Here is how to pick.
Both paths hit the same Fireflies backend and the same meeting data. What differs is the surface each exposes and the auth each expects.
The Fireflies MCP server is a remote, vendor-hosted server at https://api.fireflies.ai/mcp. It was built for LLM consumption: curated tool descriptions, a token-efficient default response format (toon), and structured parameters your agent can call without hand-writing schemas. It exposes around 19 tools spanning search and retrieval, summaries, soundbites, channels, sharing, and analytics, some read-only and some that take actions like sharing a meeting or creating a soundbite.
A note on maturity: fireflies_search and fireflies_fetch are experimental and progressively rolled out, so treat them as feature-flagged rather than guaranteed. You can read the official setup and tool reference in the Fireflies MCP Server documentation.
The MCP server accepts OAuth against the user's Fireflies account, or a Bearer API key passed as a header. The API-key path is the quick local setup that most MCP clients document:
The Fireflies API is a single GraphQL endpoint: POST https://api.fireflies.ai/graphql. Reads are queries (transcripts, transcript, user, bites, analytics, channels), and writes are mutations (uploadAudio, addToLiveMeeting, createBite, shareMeeting, deleteTranscript, and more). Every call carries Authorization: Bearer your_api_key, and list queries page with limit (max 50) and skip.
The GraphQL API supports one auth method: a Bearer API key. The key is generated from the user's Fireflies Developer settings, belongs to that one user, and carries exactly that user's access. There is no OAuth path and no version to pin; you follow the changelog for schema changes. The full reference lives in the official Fireflies GraphQL API documentation.
The MCP server covers the retrieval-and-organize surface well. The GraphQL API owns ingestion, live-meeting control, and deletion. The gap is real, and it is architectural, not a temporary rollout delay.
If your agent only reads, searches, summarizes, and organizes meetings, the MCP surface is close to complete. The moment your agent has to create data or react to it, the gap opens. Ingesting a recorded call (uploadAudio), putting the notetaker into a live meeting (addToLiveMeeting), deleting a transcript for compliance, or reacting the instant a transcript finishes (webhooks) all live only in the GraphQL API. These are not tools that ship next month; they sit outside the MCP server's read-and-organize design.
The MCP server removes work the GraphQL API leaves to you. Tool schemas and descriptions arrive ready for the model, the toon default format trims token usage on large transcripts, and the mini-grammar search tool wraps filtering you would otherwise assemble by hand. For an interactive assistant querying meetings in natural language, that curation is the point.
This is where the two paths diverge in a way that shapes your production posture, and where Fireflies differs from the usual MCP-versus-API story.
The MCP server takes OAuth against the user's Fireflies account, which is the natural path for interactive clients where a browser consent flow is available. It also accepts a Bearer API key for local or headless setups. Either way, the agent inherits what the authorizing user can see and do.
The GraphQL API has no OAuth path. It authenticates with a single Bearer API key per user, and that key is a long-lived static secret: no expiry, no refresh, no rotation built in. It should live in a secret store, never in client code, and it carries the full access of the user who minted it.
Here is the point that determines your architecture. In a multi-tenant B2B meeting agent, which is the default rather than the exception, every user has their own Fireflies credential. On the MCP path you hold one OAuth grant per user; on the API path you hold one API key per user. The token type differs, but the requirement is identical: per-user credential isolation. Neither path gives you storage, refresh, or revocation. For the background on why this is delegated authority and not a login, see OAuth for AI agents: production architecture.
The path you pick shifts where the operational weight lands, but it never removes the weight.
Fireflies maintains the server, the tool schemas, and the response formatting. You still own per-user token storage, refresh where OAuth is used, and revocation. You also inherit the server's shape: when Fireflies updates the MCP tool surface, your available tools change under you, so you track the server's evolution rather than a pinned contract.
You own the full surface: query construction, pagination with limit and skip, error handling, and rate limits such as the three-requests-per-twenty-minutes cap on addToLiveMeeting. You also own the API key lifecycle end to end. Because there is no version to pin, schema changes arrive through the changelog and you adapt on your side.
MCP trades control for lower schema maintenance; the API trades higher maintenance for complete control. Both leave the credential layer to you, which is the part that actually breaks at scale.
The decision is about what your agent does, not about which is newer.
Both paths hand you a credential per user. Neither hands you a vault, a rotation policy, or a revocation flow. That infrastructure is yours to build regardless of which path you chose.
A Fireflies API key is a static secret that carries its owner's full access. Store it unencrypted, log it once, or leak it through a stack trace, and the exposure is that entire user's meeting history. Because the key never expires on its own, a leaked key stays valid until someone manually rotates it. This is exactly the kind of risk covered in depth in OAuth vs API keys for AI agents: why static credentials break in production.
Run the agent for one user and a single credential in a .env file feels fine. Run it for a team and you have N credentials to store, refresh, and revoke. Offboarding is the sharp edge: the identity provider account gets disabled, but a Fireflies key or OAuth grant issued months ago is still live, and the agent keeps using it because nothing told it to stop. For a detailed look at this problem, see when an employee leaves, who revokes their AI agent's access.
Scalekit's Fireflies connector authorizes each user through OAuth 2.1 against the vendor MCP server, stores the credential in an encrypted token vault, refreshes it, and resolves the right per-user credential on every tool call. Credentials never touch your agent runtime. The same auth layer works whether you lean on the MCP surface or, for API-only capabilities, add them through bring your own connector. The path decision does not change what you need at the credential layer. For the deeper contrast between the two approaches, see MCP vs APIs: how they are different.
The Scalekit path is the same three steps for every connector: authorize the user, discover the tools that user is allowed to call, then run the agent loop. The example below uses Python and the Claude SDK against the firefliesmcp connector. Set your credentials first, following the AgentKit quickstart.
The identifier represents the current person in your own system, resolved from your authenticated session and never accepted from the client. Scalekit looks up or creates that user's connected account and, if it is not yet active, returns an authorization link for the Fireflies OAuth flow.
The agent does not load a flat catalog of every Fireflies tool. It loads the tools this user's connected account is authorized to call, returned in the model's native format. That distinction is what separates a per-user agent from a shared-credential one. The connection name in the filter is case-sensitive; a mismatch returns an empty list with no error.
This is the standard Claude tool-use loop. Claude decides which tool to call; your code runs it through execute_tool with the user's identifier; Scalekit resolves that user's credential from the vault and calls Fireflies as them. The token never enters your code or the model context.
The same connected-account pattern works with LangChain, CrewAI, Google ADK, and others; only the tool-binding call changes. What stays constant is the flow: one connection created once, per-user tokens resolved on every call, and no OAuth handler in your codebase. Browse the full tool list and parameters on the Fireflies connector page.
A summarizer agent does not need all 20 Fireflies tools. Handing it the full server means it can share, move, revoke, and create soundbites when all you asked for was retrieval, and every unused tool widens the blast radius if something goes wrong.
Scalekit's Virtual MCP servers let you declare exactly which tools an agent role can see and whose credentials it acts with. A meeting-summary agent gets firefliesmcp_fireflies_search, firefliesmcp_fireflies_get_summary, and firefliesmcp_fireflies_get_transcript, and nothing else. The agent cannot act beyond the surface you granted. This is least-privilege in practice — the same principle explored in access control for multi-tenant AI agents.
Every tool loaded into context costs tokens before the agent does any work; scoping a server from twenty tools to a handful trims that overhead materially across thousands of runs. Isolation is handled with session tokens: one server definition serves every user, and each run receives a short-lived token scoped to that user's connected accounts. This is what makes Virtual MCP servers a fit for multi-tool, multi-tenant meeting agents.
When an agent acts on Fireflies as a user, you need to prove what it did and under whose authorization. That is an infrastructure concern, not something either raw path gives you.
Scalekit records full attribution on every downstream tool call: who authorized the connection, which agent ran it, which tool executed, the scope it ran under, and what came back. The auth logs are queryable and exportable to your SIEM, with failures separated by source so an expired grant does not hide inside a wall of successes.
Meeting transcripts are sensitive, and actions like sharing or deleting a meeting are exactly what an auditor will ask about. A per-user audit trail answers "which human authorized this share, and can we revoke it" without reconstructing state from application logs. For the compliance framing behind this, see audit trails for agent auth and the practitioner view in agent tool observability.
If your Fireflies agent is interactive and read-heavy, summarizing calls, searching conversations, pulling action items, build against the MCP server; the tool surface is curated for exactly that. If your agent ingests audio, dispatches the bot to live meetings, deletes transcripts, or reacts to webhooks, build against the GraphQL API, because those capabilities live only there. Many production meeting agents end up using both: the MCP surface for retrieval and organization, the API for ingestion and events.
The credential management problem is identical either way. That is the part that needs production-grade infrastructure, and it is the part Scalekit owns so you do not have to.
Start from a working pattern rather than a blank file. The meeting prep agent template, the sales call prep agent, and the deal intelligence agent all pair Fireflies-style meeting data with per-user auth out of the box. See the Fireflies connector docs, browse the full connector catalog, and check AgentKit pricing when you are ready to scale.
Building now and want a hand? Join the Scalekit Slack community or talk to us for immediate help.
