The Vitally MCP (Model Context Protocol) server connects an MCP-compatible AI client to your Vitally workspace. Once connected, you can ask the AI questions about your customer data in plain language and have it query Vitally on your behalf. The integration also supports "write" actions, so the AI can create records such as Tasks, Notes, and Custom Objects directly in Vitally.

MCP is an open standard for connecting AI clients to external tools and data. Any client that supports MCP can connect to Vitally, including Claude, ChatGPT, and Cursor. The AI runs inside the client you already use; Vitally exposes a set of tools that the client can call.

The MCP server is currently in Beta. The available tools will continue to grow, and some behavior may change during the Beta period. If something does not work as expected, contact your CSM and share the chat transcript.

Vitally Copilot runs natively inside Vitally and has pre-built knowledge of your workspace configuration. The MCP server is the reverse: it brings Vitally data into an outside AI tool you already use for other work. This gives you more flexibility, because you are not limited to the Vitally interface, but it also means the AI does more work to interpret your workspace's specific terminology. A few minutes of setup, described below, closes most of that gap.

Setup is a one-time process. Claude has Vitally listed in its Connector Directory, so connecting Claude works differently than connecting other MCP-compatible clients like ChatGPT or Cursor.

Vitally is published in Claude's Connector Directory. There's no URL to copy and paste, you connect through the directory page directly.

Go to the Vitally connector page and click "Connect."

Sign in to Vitally and approve the permission scopes Claude requests. This is a standard OAuth consent flow, the same kind used when connecting any other app.

Ask Claude a simple question, such as "What accounts do I have in Vitally?" If it returns real data from your workspace, the connection is working.

Vitally isn't published in these clients' directories yet, so you'll add it as a custom connector using our server URL.

Add the Vitally MCP server to your AI client using this URL:

https://mcp.vitally.io/mcp/v0

Or, to connect with access to read tools only:

https://mcp.vitally.io/mcp/readonly/v0

This endpoint exposes only read tools, and the access tokens it issues are scoped to read-only use. These tokens cannot be used against the full-access endpoint, even if a client tries.

Some clients provide a simple connector field where you paste the URL directly. Other clients use a configuration file (for example, Cursor). The URL is the same in both cases; consult your client's own documentation for where the connector setting or configuration file lives.

After you add the server, your AI client opens a browser window and prompts you to sign in to Vitally and authorize access. This is a standard OAuth consent flow, the same kind used when connecting any other app to your accounts. There is no API key to generate. Most MCP clients, including Claude, ChatGPT, and Cursor, register themselves with Vitally automatically using OAuth 2.0 Dynamic Client Registration, so you don't paste in any credentials. Clients that require you to register an OAuth client yourself can also use Dynamic Client Registration to obtain a client_id.

Access is tied to your Vitally user account. The MCP server respects your existing permissions in Vitally, including Access Groups, so the AI can only see and do what you can do. Any record the AI creates is attributed to you, the same as if you had created it in Vitally directly.

Ask your AI client a simple question, such as "What accounts do I have in Vitally?" If it returns real data from your workspace, the connection is working.

The Vitally MCP server authenticates over OAuth 2.0 and supports Dynamic Client Registration (DCR). DCR is how MCP-compatible AI clients register with Vitally. Clients that handle the OAuth redirect for you, such as Claude, ChatGPT, and Cursor, register themselves automatically, so there is nothing to configure by hand.

Each MCP endpoint publishes its own OAuth authorization server metadata. Clients read the registration, authorization, and token endpoints from that metadata rather than having them entered by hand:

Both endpoints use the same registration and authorization flow:

Registering a client with DCR is only the first step. A client still has to complete the authorization and token exchange above before it can call the MCP server.

The scopes available depend on which endpoint you connect to. The full-access endpoint supports user.info, data.read, and data.write. The read-only endpoint supports user.info and data.read only.

Once connected, you can ask the AI to look up, analyze, and (in some cases) create Vitally records, all in plain language. Everything it can do is scoped to what your own Vitally login is already permitted to see and do.

Each capability below names the underlying tool call the AI invokes, shown in code format. That name is useful if you are troubleshooting an odd answer or want to know exactly what data the AI touched.

Accounts (search_accounts)

Look up your accounts and filter by health score, MRR/ARR, renewal or trial dates, NPS, activity counts and recency, assigned CSM/AE/owner, segment, firmographics, risk or opportunity indicators, or any custom field your workspace tracks. Results can be sorted (for example, health score ascending) and paged through when there are a lot of matches.

Example: "Show me accounts with health score under 50, sorted lowest first" or "Which accounts renew in the next 30 days?"

Users (search_users)

Find end users inside your accounts by name, email, session activity, last-seen date, NPS score, product event counts, or custom fields. Can be narrowed to users within a specific account.

Example: "Which users at Acme haven't logged in in 30 days?"

Your team (search_team_members)

Look up your own teammates by name, email, title, role, or license status.

Example: "Who on our team is a licensed admin?"

Meetings (search_meetings)

Find meetings by date range, participant (by email or team member), or linked account. Returns title, start and end time, recurrence, organizer and participant emails, recording URL, and the AI-generated summary.

Example: "What meetings did we have with Acme last month?"

Conversations (search_conversations)

Find email or support threads by subject, status, or linked account. Returns message counts, timestamps, and email engagement (opens, clicks, bounces, replies).

Example: "Show me open conversations with Acme from this week."

Notes (search_notes)

Find notes logged on an account, filtered by date, author, category, or tags. This returns note metadata; use Retrieve content (below) to pull the actual written text.

Example: "What notes were logged on Acme in Q2?"

Docs (search_docs)

Find collaborative docs (like QBR decks or account plans) linked to an account, filtered by name, template, tags, or last-updated date.

Example: "Find the most recently updated account plan for Acme."

Tasks (search_tasks)

Find tasks by due date, status, assignee, category, tags, linked project, or account.

Example: "What's overdue for Acme right now?"

Projects (search_projects)

Find projects (like onboarding or implementation plans) by status, target or actual dates, completion percentage, owner, or account.

Example: "How far along is Acme's onboarding project?"

Goals (search_goals)

Find goals tied to an account, along with overall percent complete, deadline, and owner.

Example: "Which of Acme's goals are past their deadline?"

Risks & opportunities (Indicators) (search_indicators)

Find flagged risk or opportunity indicators (typically surfaced by playbooks) on an account, including type, start, end, and addressed dates, and who addressed them.

Example: "What unaddressed risk indicators does Acme have open?"

NPS responses (search_nps_responses)

Find NPS scores and written feedback, filterable by score or account.

Example: "Show me detractor responses (score under 7) from this quarter."

Surveys (search_surveys)

Look up which surveys exist in your workspace by title, whether each includes an NPS question, whether it's published, and its response count. This finds the survey itself; use Retrieve content (below) to see what respondents actually said.

Example: "Do we have a published survey with an NPS question?"

Custom objects (search_custom_objects)

Find records in any custom object type your workspace has configured, such as Product Requests, Risks, Bugs, Commitments, Deals, Invoices, Key Moments, or Outcomes, filtered by any field you've set up and linked to a specific account or organization.

Example: "Show me all open Product Requests linked to Acme."

Segments (search_segments)

Look up your saved account or user segments by name to get their IDs, which can then narrow an Accounts or Users search to just that list.

Example: "Filter accounts to just the 'Enterprise' segment."

Retrieve content (retrieve_content)

Given a specific account, conversation, meeting, or note, this pulls the actual embedded substance (note text, meeting transcript excerpts, conversation messages, survey and NPS responses, docs, tasks, or custom object content) relevant to a specific question, optionally scoped to a date range. This is what lets the AI answer "what has this customer told us about X" using what was actually written or said, rather than just returning a list of titles. Retrieved results also include a link back to the record in Vitally, so the AI can point you directly to the account, conversation, meeting, or note it pulled from.

Example: "What has Acme said about our reporting features in the last 3 months?"

Create a note (create_note)

Logs a new note on an account with a subject, a Markdown-formatted body (headers, lists, bold, italics, links, inline code), and any custom fields your workspace has configured for notes.

Example: "Log a note on Acme summarizing today's call."

Create a task (create_task)

Creates a task on an account with a name, description, due date, and assignee, and can mark it complete with a completion date and owner.

Example: "Create a task for me to follow up with Acme next Friday."

Create a custom object record (create_custom_object)

Creates a new record in one of your custom object types (for example, a Product Request, Risk, or Bug), links it to one or more accounts, assigns an owner, and sets any custom field values your workspace has configured for that type.

Example: "Log a new Product Request for Acme asking for SSO support."

Write actions run directly, without a separate confirmation step built into the tool. Review what the AI is about to create before you ask it to proceed, the same way you would for any other AI-assisted action with real consequences. This matters most for customer-facing records.

search_object_properties isn't something you ask for directly. It's a lookup the AI runs automatically before almost every search above, to confirm the exact field names, filter operators, and sortable columns available for that object type (including your workspace's custom fields). It's why the AI can accurately filter on something like "health score" or a custom field without guessing at the underlying key. You won't see it called out by name in a normal conversation, but it may show up in a tool-call log if you're debugging.

If a question about a custom field is answered oddly, the cause is usually that the field's description in Vitally does not give the AI enough context to interpret it. Add or improve descriptions on your Traits and Custom Objects in Vitally so the AI has more context about how each one is meant to be used.

If your workspace has duplicate fields, stale Traits, or properties that are no longer used, you can use the MCP server to run a data-cleanup pass. The MCP server gives the AI raw access to all your properties, so it can audit what exists, tell you what is actually being used, and recommend what to consolidate or retire.

Point the AI at a set of properties and an object type and ask it for an audit report. A prompt like this works well:

"Load properties related to [topic], load a sample set of [object type], figure out which ones are used, and give me a detailed audit report with recommendations."

The AI reads the properties and a sample of real records, then reports back on which fields carry current data and which look stale or redundant, along with recommendations. You review the findings and decide what to delete or merge. Deletions are still done by you in Vitally (or through Vitally support when you know what you want removed).

The AI locates fields by running a semantic similarity search over property names and descriptions. When duplicate or superseded fields exist, add guidance to the descriptions so the AI knows which one to use. For a field you are retiring, a description like this steers the AI to the correct replacement:

DEPRECATED: Use [property name] instead.

After you update descriptions, confirm the change worked: ask the AI to perform a task that depends on the corrected field and check that it uses the right one and returns the outcome you expect. Repeat the cycle (audit, update descriptions, verify) until you are satisfied with the results.

This approach works well as a deliberate, guided cleanup. It is less reliable for ad-hoc analysis on a messy dataset where you expect the AI to automatically know which data to ignore. Cleaning up and describing your fields first gives you dependable results.

Multi-step requests work, but you can improve results by breaking them down. A request like, "Find accounts at risk, then check their open tasks, then draft a follow-up plan" asks the AI to chain several actions together on its own. This generally works well, but if a complicated request returns an incomplete or confusing answer, split it into smaller, sequential questions.

You can also prompt the AI to iterate. Ask it directly why something did not work, or ask it to try a different approach, with prompts such as, "Do a deeper analysis on this," "What else can you tell me about X," "Did you miss anything important," or "Try again and take a closer look at the conversations."

When you connect the Vitally MCP server, you use your own AI client and its subscription. Any tokens consumed by a conversation are billed through your client (for example, your Claude, ChatGPT, or Cursor plan), not through Vitally. This is the same for any MCP server or connector you attach to your AI client, whether it is Vitally, Notion, or another tool. Connecting to Vitally through the MCP does not change how your AI client bills you.

The MCP server is in Beta, and it is actively being improved based on how you use it. If something does not work the way you expect, or you hit a wall doing something that feels like it should be possible, tell your CSM and share the chat transcript. That feedback goes directly into what gets built next.