By the end of this tutorial, you'll know how to connect a third-party AI assistant or automation tool to your Claap workspace using the MCP server, authenticate your access, and query your Claap meetings, transcripts, emails, contacts, companies, and deals, and even publish AI-generated slides back to Claap, directly from your AI tool.

Switching between Claap and your AI assistant to manually copy meeting data breaks your workflow and slows down analysis. Claap's MCP (Model Context Protocol) server gives your AI tools direct access to your workspace data (recordings and transcripts, synced emails, contacts, companies, and deals), so you can ask natural language questions and get answers grounded in your actual Claap data without leaving your AI tool.

The server can also write back to your workspace: create and edit fields and views, update deals, create contacts, and configure automations.

Before starting, you should already have:

Add the Claap MCP server URL to your application

Open your third-party application's MCP or integration settings and enter the Claap MCP server URL:

https://api.claap.io/mcp

This endpoint is the single connection point between your AI tool and your Claap workspace data. Every query your AI tool sends to Claap passes through this URL.

Choose one of the two authentication methods below. OAuth is the default; API key authentication is available if your tool or workflow requires it.

Before authenticating, make sure you are signed in to your Claap account at https://app.claap.io.

When your third-party application connects to https://api.claap.io/mcp, Claap prompts you to complete an OAuth flow. Complete the OAuth prompt to grant your application access to your Claap workspace.

OAuth authentication verifies your identity and confirms that you have permission to access recordings, transcripts, emails, contacts, companies, and deals within your Claap workspace, and to publish to Claap Slides on your behalf.

Authenticate with an API key (alternative)

If your application supports bearer token authentication, you can bypass the OAuth flow by adding an Authorization header to your MCP requests:

Authorization: Bearer cla_xxxxx

Replace cla_xxxxx with your actual Claap API key. To obtain an API key, follow the instructions in Using Claap's API.

After authentication, wait a few seconds to a few minutes for your application to detect and install the available Claap MCP tools automatically.

When the tools are ready, your application lists them with a success indicator.

Verify: Your application should display the Claap MCP tools in its tool list before you proceed to Step 4.

With the Claap MCP tools installed, type a natural language question about your Claap data into your AI tool. Your application automatically selects the relevant Claap MCP tool based on what you ask.

For example:

Your AI tool handles tool selection automatically: you ask in plain language, and Claap's MCP server retrieves the relevant data.

The server exposes 58 tools. They fall into ten groups: Workspace & organization, Recordings & transcripts, Emails, Recording views, Deal, company & contact views, Manage contacts & companies, Fields, Deal metadata, Automations, and Publishing.

The MCP server also exposes your recording views (smart tables) and the AI columns they contain. Your AI tool can read the insights your templates already extracted (budget, objections, next steps, and any custom field) without you re-describing the extraction logic in your prompt, and can build summaries or dashboards from a full smart table.

It can also build them. The Fields and view creation tools let your AI tool define a new AI field, group it into a view, and wire that view to the right meetings with an automation, in the same conversation. These are workspace-level changes: review them in Workspace Settings afterwards, and note that nothing can be deleted through the MCP server.

There are two ways to point an AI assistant at your calls. You can hand it raw transcripts and ask it to read them, which works for a single call, but breaks down the moment your question spans the whole team ("how are we performing on SPICED?", "rank my reps", "does discovery quality predict win rate?").

To answer at that scale, an AI reading raw transcripts has to sample a handful of calls, and when you ask it to total a score or build a dashboard it fills the gaps with numbers that look right but aren't grounded in your data.

Recording Views powered by AI Fields give your AI tool the other way. A view is a structured, pre-scored table over a set of recordings: the scoring and extraction (a SPICED, MEDDIC or BANT score, an objection tag, a next step, any custom field) is computed once, consistently, for every recording in the view, and stored alongside the reasoning behind each value.

Your AI tool doesn't re-derive anything under time pressure; it reads values that already exist, across the entire population, and computes exact aggregates from them.

In one line: transcript search gives a plausible answer from a sample; a view gives a grounded answer from the whole set.

The walkthrough below runs the same request, "analyze the sales team's discovery calls on SPICED," both ways: once on raw transcripts, once on a SPICED view.

https://app.claap.io/claap/agent-ready-data-before-after-for-sales-coaching-c-ABTQ87D8Hg-8jgDUxJpF1XE

Without a view (transcript search). The AI finds 528 recordings, decides that's too many to transcribe individually, and silently narrows to a small sample of three calls across a few reps. The written analysis is fluent and even cites real examples. But asked to build a rep-comparison dashboard, it fabricates an average score (2.9/5) and a ranking across every SPICED dimension that are simply wrong: extrapolated from a tiny sample, not measured from the data. It looks true; dig into the detail and it isn't.

With the SPICED view. The AI finds the view, pages through all 263 recordings, and reads the score and the reasoning behind it that each AI Field already computed. It returns an exhaustive, quantitative result: the overall score, a per-rep breakdown, the distribution across each SPICED dimension, and, because win rate is a column in the same table, the relationship between score and outcome ("deals with no identified Pain rarely close"). Every number traces back to a stored value, so the analysis is reproducible and defensible.

Q: As AI models get more capable, do Recording Views still matter, or will an assistant just read the raw transcripts?

They matter more, not less. A more capable model is rarely limited by how well it reasons. It's limited by whether it can get the complete dataset cheaply, consistently, and in a form it can ground every number in. Reasoning is the part that improves on its own. Complete, consistent, groundable data access is the part that doesn't.

A Recording View hands the model the entire population, scored once and the same way for every recording, so a stronger model spends its capability on analysis instead of re-reading and re-scoring hundreds of calls under a token budget and guessing at the ones it skipped. Reading 263 stored scores is cheaper, more consistent, and more reproducible than re-deriving them on every query, and it returns the same answer twice.

In one line: the better the agent gets, the more the value shifts from who does the reasoning to who owns the structured, agent-ready data the reasoning runs on.

Use Recording Views (List Recording Views, then Read Recording View) when your question spans many recordings: scoring, ranking, coaching, aggregation, trends, or comparing reps and teams. The view already holds the score and its rationale for every recording, so your AI tool pages through the whole population and returns an exhaustive, quantitative answer.

Use Search Meeting Recordings / Get Recording Transcript when you need to dig into the content of one call or a small set of calls.

The same logic applies to deals, companies and contacts. Their views are readable through the MCP server too, so where a question spans a whole object, "which open deals have no identified champion", "which accounts mention this competitor", read the view rather than searching records one by one.

Rule of thumb: if the answer is a number, a ranking, a distribution, or a "how well are we doing across X," start from a Recording View, not from transcript search.

The friendly names above map to the following underlying MCP tools. Every tool requires a workspaceId (obtained from List Workspaces). Tools that return large result sets support cursor-based pagination via limit (1–100, default 10) and cursor. Pass the nextCursor value returned by a previous call verbatim to fetch the next page. Note that semantic searches are not paginable; widen limit (up to 100) instead of paging.

Where a tool accepts an object definition or a record identifier beyond workspaceId, the exact schema is published in your application's tool list once the Claap tools are installed.

Lists all Claap workspaces the user can access. Parameters: none.

Lists the teams configured in the workspace. Useful to scope an analysis to one team, or to resolve a team id before filtering recordings by the recorder's team. Parameters: workspaceId (required).

Lists the members of the workspace, with the id, name and email of each. This is how you resolve a rep before filtering recordings or deals by owner. Parameters: workspaceId (required).

Fetches one workspace member. Parameters: workspaceId (required), plus the user identifier.

Lists the user groups configured in the workspace. Parameters: workspaceId (required).

Lists the recording folders in the workspace. Use it to resolve a folder id before filtering recordings, rather than filtering on folder title. Parameters: workspaceId (required).

Lists every view in the workspace, across all object types, in a single call. Where list_recording_views and its CRM equivalents each cover one object, this tool returns the full inventory at once. Useful when you do not yet know which object holds the view you are looking for. Parameters: workspaceId (required).

Searches the company database. Parameters: workspaceId (required); name (complete or partial company name or domain); sort (array of {field, order}, where field is one of name, createdAt, lastInteraction, dealCreatedAt); limit; cursor.

Lists companies without a search query, when you want the population rather than a match. Parameters: workspaceId (required), plus filters and pagination.

Fetches one company by id. Parameters: workspaceId (required), plus the company identifier.

Searches contacts (both workspace users and external contacts). Parameters: workspaceId (required); query (complete or partial name, email, or domain); sort (field one of name, createdAt, lastInteraction); limit; cursor.

Lists contacts without a search query. Parameters: workspaceId (required), plus filters and pagination.

Fetches one contact by id. Parameters: workspaceId (required), plus the contact identifier.

Searches the deal database with filters and sorting. Parameters: workspaceId and filters (both required). filters supports title (contains), stage (contains), amountValue {gte, lte}, openedAt {gte, lte}, closedAt {gte, lte} (dates as ISO YYYY-MM-DD). sort field is one of amountValue, closedAt, openedAt, lastInteraction (stalled/quiet deals), dealAge (longest stuck in pipeline). Plus limit, cursor.

Lists deals without a search query. Use it when you want the population rather than a match, for example every open deal. search_deals is the right tool when you have criteria to match on. Parameters: workspaceId (required), plus filters and pagination.

Fetches one deal by id. Can also return the deal digest as summary and the values of its AI fields, behind the returnAiFields flag. Parameters: dealId, workspaceId (both required); returnAiFields (boolean).

Updates a deal: stage, type, owner, amount, and custom or AI field values. Resolve the ids you need first with list_deal_stages, list_deal_types and list_deal_owners, which return the CRM internal id alongside a human-readable label.

Deals cannot be created through the MCP server. There is no create_deal: a deal has to exist in the connected CRM, or be created through the REST API, before it can be updated here.

Requires a connected CRM. HubSpot only at this stage, same as the deal metadata tools. Salesforce is not supported yet.

Parameters: dealId, workspaceId (both required); accepts stageId, pipelineId, typeId, ownerId, plus the field values to write.

Keyword or semantic search across transcripts, with metadata filters. Returns transcript chunks grouped by recording. Parameters: workspaceId (required); search {query, type} (required; type is semantic or keyword); filters (optional): recordingId, recordingTitle, companyId, companyName, contactId, contactName, contactEmail, dealId, dealTitle, folderId, folderTitle, labelName, userId, createdAt {gte, lte}, hasExternalSpeaker, and tag (one or more of CompetitorMentions, Objections, PainPoints, FeatureRequests). Plus limit, cursor (keyword only).

Queries recording metadata by filters (company, contact, deal, folder, label, date, external-speaker) and returns the matching recordings, sortable by creation date or most recent activity. Can also return each recording's AI summary, behind an opt-in flag, so you get the gist of a meeting without pulling the full transcript.

returnSummary (boolean, default false). When true, each recording in the response includes its AI summary. If a recording has no summary yet, the generation state is returned, or the field is absent, so you can distinguish "not generated yet" from "empty".

Recommended pattern: filter first, ask for the summary second. Narrow down to the recording or recordings you care about, for example by recordingId, then request summaries. Asking for summaries on a broad search will blow up the payload.

This makes recordings consistent with deals, where get_deal already returns the deal digest as summary behind a similar returnAiFields flag.

There is no write path: you cannot edit or regenerate a summary through the API or the MCP server.

Fetches the metadata of one recording, without its transcript. Use it when you already have a recording id and need its details rather than a search across the workspace. Parameters: recordingId, workspaceId (both required).

Fetches the full transcript of one recording. Parameters: recordingId, workspaceId (both required).

Returns aggregated chart data over a set of recordings, rather than the individual rows. Use it for volume and trend questions where you do not need each recording, for example meeting count over time. For scoring and ranking questions, read a Recording View instead: the view carries the AI Field values and their rationale. Parameters: workspaceId (required), plus the aggregation and filter parameters of the chart.

Lists workspace emails with metadata, sorted by sent date. Parameters: workspaceId (required); filters contactId, companyId, dealId, threadId; sortBy (sentAt); sortOrder (asc/desc, default desc); limit; cursor.

Semantic or keyword search over email content. Parameters: workspaceId (required); search {query, type} (required; type is semantic or keyword); filters contactId, companyId, dealId; limit; cursor (keyword only).

Fetches the full body of a single email. Parameters: messageId, workspaceId (both required).

Emails are read-only through the MCP server. There is no send tool.

Lists the recording views (smart tables) configured in a workspace. Each view is a structured, pre-scored table over a set of recordings, the entry point for any aggregate, scoring, or team-level question. Parameters: workspaceId (required).

Reads the rows and AI insight columns of a specific view, including the reasoning captured by your AI fields and templates. Supports cursor-based pagination: pass the nextCursor value from a previous call verbatim to read the entire view, so aggregate results cover every recording rather than a sample. Parameters: viewId, workspaceId (both required); limit (1–100, default 10); cursor.

Creates a new recording view, with its filters, its sorts and its visible columns. Useful to provision views programmatically, for example one per team or per meeting type, instead of building each one by hand. Parameters: workspaceId (required), plus the view definition.

Edits an existing recording view: filters, sorts, visible columns. Parameters: viewId, workspaceId (both required), plus the properties to change.

Views cannot be deleted through the MCP server. Remove a view from the app or through the REST API.

List the views configured for each CRM object, mirroring list_recording_views. Use them to obtain a view ID. Parameters: workspaceId (required).

Mirror get_recording_view. Given a view ID, apply the view's filters and sorts and return the actual rows, with a value per visible column, standard fields and AI fields alike. Before these tools existed, listing a view only returned its definition, not its contents: consumers had to hand-translate filters into a search query to approximate the table, and AI column values were unreachable altogether.

Parameters: viewId, workspaceId (both required); limit; cursor. Supports cursor-based pagination, respects visibility (private views are only accessible to their owner and to admins), and accepts default view IDs.

Mirror create_recording_view for each CRM object. Create a view with its filters, its sorts and its visible columns. Parameters: workspaceId (required), plus the view definition.

Mirror update_recording_view. Edit an existing view. Parameters: viewId, workspaceId (both required), plus the properties to change.

Contacts can be created and updated programmatically, reusing the same fields and validation as the manual creation flow in the app, so the app and the API stay a single source of truth. This unlocks scripted onboarding, bulk edits from external sources, and AI-agent workflows that create or update records on your behalf.

Through the MCP server, list, get, create and edit are available for contacts. For companies, list, get and search are available, plus field and view management. Company creation and deletion are API-only and are intentionally not exposed as MCP tools. Deletion is API-only for both objects.

Creates a contact. Contacts are the only object the MCP server can create outright. Parameters: workspaceId (required), plus the contact properties.

Updates an existing contact. Parameters: workspaceId (required), plus the contact identifier and the properties to change.

Views display fields. These tools let your AI tool inspect the fields that exist on an object, and create or edit them, including AI fields, without going through Workspace Settings.

Field creation is a write operation on your workspace configuration, not on a single record. A field created through the MCP server behaves exactly like one created in the app, and appears in Settings for every admin. There is no delete tool: a field created here can only be removed from the app or through the REST API.

List the custom and AI fields defined on recordings, deals and companies. Start here to check whether the field you need already exists, and to resolve it before reading or writing its value. Parameters: workspaceId (required).

Create a new custom or AI field on the object. For an AI field, the prompt and the data type are set at creation, the same way as in the AI Fields library. Parameters: workspaceId (required), plus the field definition.

Edit an existing field: its name, its definition, and for an AI field its prompt. Parameters: workspaceId (required), plus the field identifier and the properties to change.

Note: contacts have views but no field management tools. There is no list_contact_fields, create_contact_field or update_contact_field.

List the valid CRM values accepted when updating a deal. list_deal_stages returns each stage with its pipeline (pipelineId, pipeline). list_deal_owners returns name and email alongside the id. Each entry returns the CRM internal id and a human-readable label, the same id and label pairs as the Deal object.

The deal update endpoint already accepted stageId, pipelineId, typeId and ownerId, but there was no way to discover those ids programmatically: you had to read them off an existing deal or fetch them from the CRM directly. These tools remove that limitation, which matters most for an LLM that needs to resolve a stage, type or owner id correctly before writing.

Parameters: workspaceId (required).

Requires a connected CRM. A 400 validation error is returned if the workspace has none. HubSpot only at this stage, same as the deal update endpoint. Salesforce is not supported yet.

Admin Automations decide which meetings are processed and how: which AI Fields run, which view a recording lands in, which workflow fires. These tools expose them to your AI tool, so an automation can be inspected and changed without opening Workspace Settings.

⚠️ These are workspace-level write operations. An automation created or edited through the MCP server applies to every member of the workspace and to every meeting matching its filters. Review the result in Settings after any change.

Lists the automations configured in the workspace, with their filters and their actions. Start here before changing anything. Parameters: workspaceId (required).

Creates a new workspace automation. Parameters: workspaceId (required), plus the automation definition, its filters and its actions.

Edits an existing automation. Parameters: workspaceId (required), plus the automation identifier and the properties to change.

Automations cannot be deleted through the MCP server. Disable or remove an automation from Workspace Settings.

Publishes an artifact to Claap Slides. The artifact code is passed exactly as generated, and the platform handles all rendering. Parameters: title and code (both required); publish (boolean; if false, saved as a draft); visibility (public default, or password); password (required when visibility is password, min 4 chars); slug (custom URL slug, 3–60 chars); expires_at (ISO 8601, must be in the future).

Knowing the boundaries up front saves you designing a workflow around a tool that does not exist.

No delete, anywhere. No record, field, view or automation can be deleted through the MCP server. Deletion is available through the REST API only.

No create for companies, deals or recordings. You can update a deal but not open one. You can read recordings but you cannot upload one or trigger a capture. Contacts are the only object the server creates outright.

No email send. Emails are readable only.

No comments, shares or clips, and no meeting scheduling.

No AI summary write path. You can read a recording's AI summary, but you cannot edit or regenerate it.

No field management on contacts. Recordings, deals and companies have field tools. Contacts do not.

Situation: A sales manager has dozens of recorded discovery calls in their Claap workspace from the past month.

Goal: Find every call where a specific competitor was mentioned, without watching each recording manually.

How they built it:

Result: The manager reviewed competitor mentions across all recent calls in minutes, without leaving Claude.ai.

Situation: An account executive is picking up a deal and needs the full context fast.

Goal: See what was discussed on calls and agreed over email, in one place.

How they built it:

Result: A complete account history assembled from meetings and emails, with a shareable recap, without opening the recordings or inbox manually.

Situation: A sales manager wants to know how consistently the team runs discovery against the SPICED methodology, across hundreds of recorded calls.

Goal: A defensible, team-wide picture, not an impression from a few calls.

How they built it:

Result: A quantitative coaching dashboard grounded in every call: reproducible, auditable, and built in one pass, without watching or manually sampling recordings.

Situation: A RevOps lead wants a new qualification framework scored on every future discovery call.

Goal: Set it up once, then have it run automatically.

How they built it:

Result: The framework runs on every new matching meeting, set up without opening Settings. Note that fields, views and automations cannot be deleted through the MCP server: undo any mistake from the app.

For step-by-step instructions specific to Claude.ai, see Using Claap's MCP server with Claude.ai. For n8n workflows, see Using Claap's MCP server in your n8n workflow.

To configure the Claap MCP server in Claude Desktop, follow these steps:

Issue: Authentication fails or access is denied when connecting to https://api.claap.io/mcp

Why: Your Claap account may lack the required permissions, or you are not signed in to Claap before starting the OAuth flow.

Fix:

Issue: The Claap MCP tools do not appear in your application after authentication.

Why: Detection can take up to a few minutes, or the MCP server URL may have been entered incorrectly.

Fix:

Issue: Search returns no results for recordings you know exist in Claap.

Why: The recording or its folder may not be visible to workspace members in global search, or the search terms are too specific.

Fix:

Issue: A deal tool returns a 400 validation error.

Why: update_deal and the deal metadata tools require a connected CRM, and support HubSpot only at this stage.

Fix: Confirm a CRM is connected to the workspace. A workspace with no CRM, or with Salesforce, returns a validation error on these tools.

Issue: A write tool changed more than expected.

Why: Field, view and automation tools write to your workspace configuration, not to a single record. A field created this way appears in Workspace Settings for every admin. An automation applies to every meeting matching its filters.

Fix: Review the change in Workspace Settings. There is no delete tool on the MCP server: undo the change from the app or through the REST API.