Your agent needs to work with Gainsight. It has to pull health scores before a QBR, raise a Risk CTA when a renewal wobbles, and log what it did to Timeline. Gainsight now ships a CS MCP server alongside a REST API that has been in production for years. Both paths work. They diverge sharply on write coverage, on whether your agent can run without a human at a browser, and on what you can prove after the fact.
These are two different front doors onto the same Matrix Data Architecture (MDA). One is a curated tool surface designed for chat assistants. The other is the full integration surface Gainsight has always exposed to developers.
The CS MCP server is Gainsight-hosted and reached over Streamable HTTP at your instance URL, following the pattern https://[your-domain].gainsightcloud.com/v1/ds-mcp/mcp. There is no single shared endpoint. Every customer org has its own base URL, which matters the moment your agent serves more than one Gainsight tenant.
Gainsight's MCP connector page confirms the CS and Staircase servers are live for customer use, with Skilljar, Customer Communities, and PX still in beta. Auth is user-level OAuth with PKCE. Gainsight's setup guide labels it OAuth 2.1 and the FAQ labels it OAuth 2.0; the flow described in both is Authorization Code with PKCE enabled on the OAuth app.
The Gainsight API and developer documentation organises the surface into distinct families: Company and Relationship, Cockpit (CTAs, tasks, playbooks), Success Plan, Timeline, Customer Goals, Custom Object, Data Management, Events, Renewal Center, User Management with SCIM, and Bulk.
Two auth methods are supported. An access key passed in the accesskey header, or an OAuth bearer token in the Authorization header. The access key is the only credential that works with no interactive flow anywhere in the loop.
The gap here is not a thin one. The MCP server was built for a CSM prompting Claude or ChatGPT, and it shows in both directions: some things are easier than REST, and some things are simply absent.
Permission enforcement happens at the data layer, not in the tool description. An MCP query cannot return a field or object the authenticated user cannot see in the Gainsight UI, and field-level permissions plus bundle restrictions both apply. If a field is mandatory on a CTA layout, a create through MCP fails without it.
Gainsight also ships governance most vendor MCP servers do not. AI Tool Management lets admins deactivate individual tools and individual objects, with dependency resolution that tells you which tools break when you turn an object off. Saved reports and portfolio filters have no documented REST counterpart at all.
The absent capabilities are not obscure. No deletes on any object. No company field updates. No Customer Goals writes. No bulk batch operations. No schema or field creation, no rules engine changes, no health score configuration, no user management.
Read the list again as an agent builder and a pattern appears. Everything the MCP server exposes is a CSM's daily workflow. Everything it withholds is either destructive or operational. That is a defensible product decision, and it is also a hard boundary: a data reconciliation agent, a churn-cohort backfill, or an onboarding provisioning agent has nothing to build against on this path.
MCP is user-level OAuth with PKCE and nothing else. Each end user completes their own browser flow against your customer's Gainsight tenant. That per-user identity is the whole point, and it produces exactly the enforcement described above.
The setup is more manual than most MCP servers. There is no Dynamic Client Registration in the documented flow: an admin creates the OAuth app, enables PKCE, and pastes the AI client's callback URL back into Gainsight. Claude needs two callback URLs registered on the same app. Gainsight notes that callback and PKCE changes can take 30 to 60 minutes to propagate.
Gainsight caps each org at three OAuth applications, and only Super Admins can create them. Your MCP server consumes one. Whatever else in that customer's tenant already speaks OAuth competes for the other two.
Scope granularity is thinner still. The dropdown offers read or read_write, and the note in Gainsight's own documentation is unambiguous: the scope applies to all Gainsight APIs. There is no per-object or per-tool scope. Worse for anyone designing guardrails, a read-only OAuth app returns 403 on writes for everyone except Super Admins, who bypass it entirely. If your pilot cohort includes an admin, your read-only guarantee is not a guarantee.
This is the detail that pages someone at 3am. Gainsight documents access tokens at 3600 seconds and refresh tokens with a 365-day default usable exactly once. Rotation is on by default: every refresh issues a new token and invalidates the previous one.
Then comes breach detection. Replaying a superseded refresh token invalidates every token in the chain, including the newest, and the user must re-authorize interactively to recover. Gainsight applies a 30-second rotation overlap so the immediately preceding token stays briefly valid. That cushion is all that stands between two concurrent agent threads and a forced re-auth. Single-flight refresh is a correctness requirement here, not an optimisation. The general pattern is in handling token refresh for AI agents.
MCP has no non-interactive grant. You can run a background agent only by holding a refresh token a user issued earlier, and the rotation behaviour above makes that fragile under any concurrency.
The REST access key has the opposite profile. It never expires and needs no browser, which is exactly what a nightly sync wants. It is also org-scoped rather than user-scoped, so none of Gainsight's per-user enforcement applies to it. That tradeoff is worth reading in full in OAuth vs API keys for AI agents.
On the MCP path Gainsight owns hosting, tool schemas, and permission enforcement. You own the OAuth app in every customer tenant, the callback registrations, the token lifecycle, and the per-tenant endpoint URL your agent has to resolve at runtime.
One operational detail catches teams out: when an admin toggles a tool in AI Tool Management, connected MCP clients must reconnect before the change takes effect. All tools and objects are active by default, so this is opt-out governance, and six Core tools including get_records and get_object_metadata are locked on and cannot be deactivated at all.
Gainsight documents synchronous calls at 100 per minute and 50,000 per day, with asynchronous calls at 10 per hour and 100 per day, using fixed-window limiting. Some families are tighter; the external User Management APIs are documented at 100 requests per hour.
Critically, MCP tool calls count against the same tenant limit. Your agent is not on a separate budget from the customer's Salesforce sync, their warehouse pipeline, and their other vendors. An agentic loop that issues five sequential calls per user action burns a fixed-window minute faster than a traditional integration ever did.
Use the Gainsight CS MCP server when:
Use the Gainsight REST API when:
Both paths hand you a credential and then walk away. MCP's OAuth flow gives you a token per user per tenant. The REST access key gives you one key per tenant. Neither gives you a vault, rotation logic, revocation, or a way to answer an auditor.
Run the numbers on a Gainsight agent serving 12 customer orgs with 25 CSMs each. On MCP that is 300 OAuth grants, 300 refresh tokens under a single-use rotation policy, 12 OAuth apps consuming one of each tenant's three slots, and 12 distinct MCP base URLs to resolve per request.
On REST it is 12 access keys, one per org, each of which never expires and each of which dies the instant that customer's admin clicks Reset. There is no second key to fail over to; Gainsight permits exactly one active key per org.
Storage that keeps credentials out of your agent runtime and isolated per tenant. Refresh that does not race itself into breach detection. Revocation you can trigger when a customer churns. And attribution: a log line naming which agent called which tool for which tenant.
Gainsight's FAQ is candid on that last point. MCP operations are logged internally, customer-facing audit visibility is planned, and there is currently no way to distinguish an LLM-created timeline entry from any other API-created one. If a security review asks what your agent did in a customer's Gainsight last Tuesday, neither path answers it.
The Scalekit Gainsight connector handles credential storage, injection, and per-tenant isolation on either path.
Scalekit ships one Gainsight connector today, and it is the API one: 28 tools, authenticated with the Gainsight access key plus tenant domain. Gainsight's own MCP server is not a separate catalog entry, so you register it through Bring your own connector, which supports remote MCP servers alongside REST APIs.
Gainsight issues one access key per org. That makes the customer org, not the individual CSM, the correct isolation boundary for a connected account on this connector. Key your identifier accordingly.
Before the agent loop runs, load the tool surface bound to this connected account. The agent is not reading a flat catalog of 28 tools; it receives the tools this specific connected account can call, and nothing else.
When the flow is deterministic rather than agentic, skip the loop and use execute_tool. Gainsight's query grammar carries through unchanged, including the conditions array and expression string.
A renewal risk agent does not need gainsight_object_delete. A Virtual MCP server declares which tools an agent role can see, then mints a short-lived session token bound to one tenant at runtime. Create the server once per agent role.
Check that the connection is still active before every run, then issue a token scoped to that tenant. Never carry a token across sessions.
The Node SDK mirrors the Python surface. Writing a CTA needs company_gsid, cta_type, name, owner_email, and reference_id; the last of those is your idempotency handle, returned in error responses so you can match failures back to source records.
Mastra's MCP client reads tool schemas straight off the Virtual MCP endpoint, so there is no Zod conversion to maintain. Resolve the URL per tenant on your backend. A process-wide constant here runs every request as one tenant.
The 28 connector tools cover Cockpit, Timeline, Success Plans, Goals, and generic MDA objects. For anything outside that set, Renewal Center opportunities or the Events API, proxy the raw call through the same connected account so the credential still never enters your agent runtime.
None of the above changes what Gainsight enforces. It changes what you can prove, what your agent can reach, and how much of the credential lifecycle you own.
Gainsight has said customer-facing MCP audit visibility is still on the roadmap and that LLM-created records are indistinguishable from other API writes today. That is a real gap in a compliance conversation.
Every execute_tool call through Scalekit produces a log line with attribution: which tenant authorized it, which agent ran it, which tool, and what came back. Those agent auth logs export to your SIEM. The reasoning behind treating this as infrastructure rather than instrumentation is in agent tool observability and audit trails for agent auth.
AI Tool Management is a tenant-wide switch owned by your customer's admin. Deactivating manage_cockpit_actions for one agent deactivates it for every LLM surface in that org, including Copilot. You do not control it, and a change requires connected clients to reconnect.
A Virtual MCP server inverts that. Your renewal risk agent gets five tools; your support triage agent gets a different five. Same connector, same credentials, different exposed surface, defined in your code rather than in each customer's admin console. It also cuts context: 28 tool schemas in every window is real token spend at production volume.
Gainsight's one-key-per-org rule means a customer admin regenerating their access key silently breaks your agent for that tenant. With connected accounts, the blast radius stops at one identifier, the failure surfaces as an inactive account rather than scattered 401s, and rotating it is a single upsert_connected_account call. The broader pattern is covered in access control for multi-tenant AI agents.
Gainsight is rarely the only system a CS agent touches. Renewal risk work pulls from a CRM, call recordings, and support tickets in the same run, which is where a single scoped MCP endpoint across several connectors earns its place.
Useful starting points: the CRM AI agent and revenue forecast commentary agent templates for GTM workflows, the support triage agent for post-sales, and the meeting prep agent for the QBR pattern Gainsight users ask for most. The full CRM and sales connector category shows what else composes into the same agent.
If your users are CSMs living in Claude or ChatGPT and you want Gainsight's field-level permissions enforcing every call, the CS MCP server is the right path. Accept the setup tax: an OAuth app per tenant, hand-registered callbacks, and a refresh strategy that respects rotation.
If your agent runs headless, writes company fields, deletes anything, moves more than 50 records, or touches Renewal Center, Events, or Data Management, MCP has no surface for you. Use the REST API.
Most production Gainsight agents end up on both. The interactive assistant runs on MCP; the nightly reconciliation runs on REST. What does not change is the part nobody ships on day one: per-tenant credential custody, refresh that does not trip breach detection, and an audit trail that survives review.
Start with the Gainsight connector and its 28-tool reference, or browse all agent connectors. The free tier on AgentKit pricing includes 5,000 tool calls with no credit card.
Building on Gainsight and hitting the refresh token or multi-tenant key problem? Join the Scalekit Slack community and ask, or talk to us if you need an answer today.
