Secure Vitally access for AI agents
Customer success data — accounts, users, health indicators, notes, meetings, conversations, NPS, tasks, and projects via Vitally's MCP server.
Through Vitally, agents can search and read the customer success record – accounts, users, conversations, notes, meetings, goals, indicators, projects, tasks, and NPS responses – and create notes, tasks, and custom objects when you allow it. Every call runs through your policies and is logged for audit.
Server URL: https://mcp.vitally.io/mcp/v0
Credential modes
Vitally supports per-org dynamic registration only, so there is no app to create on Vitally's side and no client ID or secret to enter. See Credential modes for how it compares with Use SecureAuth's app and Bring your own app.
Before you begin
- A Vitally account that can reach the accounts and users your agents need.
- Administrator access to your Agent Authority workspace, to add the resource.
Setup
- In the Agent Authority console, go to Resources and click Add Resource.
- Select Vitally from the catalog.
- On Choose how to install Vitally, click Per-org dynamic registration. Selecting it adds the resource right away with its tools pre-configured.
Dynamic client registration
When you add the resource, the gateway registers its own OAuth client with Vitally – the credential that lets it sign users in. Vitally's own role and permission model still applies, so an agent can only reach what the person who signed in could already reach.
Two Vitally specifics are worth knowing:
- Vitally issues public clients only – PKCE, no client secret. The gateway registers and uses one accordingly.
- Vitally does not implement OAuth client management, so a registered client cannot be deleted. Removing and re-adding the resource registers a new client and leaves the previous one in place.
Verify the connection
The gateway syncs the Vitally tools automatically. To check the connection end to end, ask your agent to run a request:
Search my Vitally accountsIf your accounts come back, the connection is working.
How users connect
Access is per user. Each additional user connects their own Vitally account the first time their agent calls a Vitally tool: the gateway returns a sign-in link, the user authorizes once, and the tools work from then on. Go to Connections to manage linked accounts.
Vitally issues no refresh token, and its access tokens carry no expiry – a connection stays valid until the token is revoked in Vitally.
Available tools
Vitally tailors its tool descriptions and input schemas to each workspace, naming that workspace's custom-object types and custom fields. The gateway syncs those tenant-specific versions on the first connection, so what your agents see may be more specific than the table below.
| Tool | Access | Description |
|---|---|---|
search_object_properties | read | List filterable properties for an object type |
search_accounts | read | Search accounts |
search_users | read | Search users |
search_team_members | read | Search team members |
search_segments | read | Look up segment ids by name |
search_conversations | read | Search conversations |
search_notes | read | Search notes |
search_meetings | read | Search meetings |
search_docs | read | Search collaborative docs |
search_goals | read | Search goals |
search_indicators | read | Search indicators |
search_projects | read | Search projects |
search_tasks | read | Search tasks |
search_nps_responses | read | Search NPS responses |
search_surveys | read | Search surveys by title |
search_custom_objects | read | Search custom object instances |
retrieve_content | read | Retrieve embedded content for a record |
create_note | write | Create a note for an account |
create_task | write | Create a task for an account |
create_custom_object | write | Create a custom object instance linked to accounts |
Call search_object_properties before the other search tools – it returns the
property keys, operands, and sort columns those calls need.
Required scopes
The gateway requests these scopes automatically when it registers the client, so there is nothing for you to configure. Vitally decides what to grant, and any scopes it returns during registration replace the list below.
| Scope | Why |
|---|---|
user.info | Identify the signed-in Vitally user |
data.read | Search and read accounts, users, conversations, notes, and more |
data.write | Create notes, tasks, and custom objects |
Vitally audience-binds each token to the resource it was issued for. A token minted for the read-only server is rejected by this one, so a connection cannot be reused across tiers.
Policy examples
Every org is created with a seeded Allow all rule at the bottom of the list, so any call your own rules don't match stays allowed. Express restrictions as deny rules above it – new rules are added at the top, so a fresh deny outranks it automatically. See Rule order.
- Read-only access: deny
create_*on the Vitally MCP. That covers every write in the table above, leaving thesearch_*andretrieve_contentreads. - Allow notes and tasks but no custom objects: deny
create_custom_object - Keep conversation contents out of agent context: deny
search_conversationsandretrieve_content
Next steps
- Create a policy – start from the read-only pattern in Policy examples above.
- Policies – how first-match-wins rule order and the seeded Allow all rule interact.