published · Technical & MCP · Priority 2 · 2026-06-11

MCP Connectors for Claude and Cursor in the Enterprise

MCP enterprise deployment: one endpoint for Claude, Cursor, and internal agents

Your GTM team already uses Claude for drafting and Cursor for building automations. Each tool ships with its own connector story — custom GPT actions here, a local MCP server there, a Zapier webhook for CRM reads. The result is familiar: three agents that all need the same deal context, three auth paths, three audit gaps, and a RevOps lead who cannot answer "what did our AI touch in Salesforce last week?"

MCP enterprise deployment fixes that at the architecture layer. The Model Context Protocol (MCP) is an open standard for exposing tools — search, graph queries, mutations — to AI clients over HTTP. Gyri publishes one workspace-scoped endpoint at https://api.gyri.io/mcp. Claude Desktop, Cursor, and internal agent runners connect to the same company graph: federated CRM, email, Slack, and docs with cited retrieval and write-back on rails your team controls.

This guide walks through the topology, auth modes, tool surface, and client setup so security and ops leaders can approve a single AI agent endpoint instead of approving N bespoke integrations.

MCP topology: why one endpoint beats N connectors

Traditional enterprise AI rollouts look like a starburst: ChatGPT with a Salesforce plugin, Claude with a Google Drive connector, Cursor with a hand-rolled script against your wiki API. Each spoke implements search differently, cites differently, and forgets what the others learned.

Gyri's MCP topology is a hub:

```

Claude Desktop ──┐

Cursor IDE ──────┼──► https://api.gyri.io/mcp ──► Workspace graph

Internal agents ─┘ (auth + audit) ├── Federated sources (CRM, Slack, Gmail, Drive, …)

├── Typed insights & citations

└── Write-back mutations (policy-governed)

```

One graph, many clients. Whether a rep asks in Claude or an engineer runs a competitive-analysis agent in Cursor, both call the same search, query, and mutate tools against the same workspace. Insights created in one session are visible in the next — addressing the blank-slate problem that kills adoption on generic chat tools.

Federation stays server-side. Native connectors (Gmail, Slack, Google Drive, Pipedrive, Insightly) and custom HTTP connectors live in Gyri. HubSpot and Salesforce are on the native connector roadmap. MCP clients never hold CRM credentials directly; they inherit workspace membership and scoped permissions from the authenticated Gyri user. That shrinks the security review surface: you approve Gyri's access model once, not per agent framework.

SSE transport for remote clients. Production MCP runs over HTTP with server-sent events — the pattern Claude Connectors and Cursor's remote MCP config expect. No local Node process required for business users; engineers can still run a local MCP server for development, but enterprise rollout targets the hosted endpoint.

If MCP is new to your organization, start with MCP for Business Agents: A Practical Guide for Operators for plain-language framing before diving into deployment.

Auth modes: OAuth for Claude, API keys for Cursor

Enterprise MCP deployment lives or dies on authentication. Gyri supports two first-class paths, often used together during rollout.

OAuth 2.1 + PKCE (Claude and browser-native clients)

Claude's custom connector flow expects a remote MCP server that advertises OAuth via RFC 9728 protected resource metadata:

https://api.gyri.io/.well-known/oauth-protected-resource

Users connect through Settings → Connectors → Add custom connector with server URL https://api.gyri.io/mcp. Gyri supports dynamic client registration and a pre-seeded Claude OAuth client — leave OAuth Client ID and Secret blank during setup. Scopes include openid profile email offline_access gyri:mcp.

Why OAuth for Claude: Business users get a familiar consent screen tied to their Gyri account. IT can revoke access centrally. Tokens refresh without pasting long-lived secrets into a desktop app. This is the default path for Claude MCP business deployments where non-engineers connect without touching JSON config files.

User API keys (Cursor and developer workflows)

Cursor and most IDE MCP clients authenticate with a Gyri user API key (gyri_sk_…) passed on each request. Two supported patterns:

Header: X-Gyri-User-Key: gyri_sk_…
Query param: gyri_user_key=gyri_sk_… on the MCP URL

Keys are minted per user under Gyri Settings → API keys. They bind to the user's workspace memberships — an agent cannot read a workspace the user does not belong to.

Auth mode toggle for operators. Gyri's server supports GYRI_MCP_AUTH_MODE=off|optional|required. Production at api.gyri.io typically runs OAuth as primary with optional API-key fallback during migration (optional), then required when Claude Connectors are the standard and Cursor keys are issued through IT. API keys remain the practical default for Cursor MCP workspace setups because Cursor's config expects a static header, not an interactive OAuth redirect.

Client	Recommended auth	Workspace binding
Claude Desktop / Claude.ai connector	OAuth 2.1 + PKCE	User's Gyri account + primary workspace
Cursor IDE	`gyri_sk_` via header or URL param	`kb_ws` query param or `use_workspace` tool
Internal agents / CI	Scoped `gyri_sk_` or service key policy	Explicit workspace slug per run

Treat API keys like passwords: one key per person or automation, rotate on offboarding, never commit to git.

Tool surface: what agents can read and write

MCP exposes Gyri's graph as named tools. Clients discover them via tools/list; the model chooses based on descriptions. For enterprise buyers, the important split is read vs write and session vs data plane.

Core data tools

Tool	Role	Typical use
`search`	Keyword + semantic discovery across federated sources	"Find everything about Acme renewal"
`query`	GraphQL reads — records, multihop traversals, insight recall	Deal → contacts → emails → tickets in one query
`mutate`	GraphQL writes — insights, records, relationships	Persist competitive intel, update custom objects

These three tools are the backbone. A pre-call brief agent runs search to gather evidence, query to traverse account relationships, and optionally mutate to file a structured insight for the next rep. See AI Answers With Citations for why citation-linked retrieval matters on every read path.

Session tools

Tool	Role
`workspace`	List workspaces, switch active workspace, lite overview

Users with multiple workspaces (sandbox vs production, or agency vs client) call use_workspace to switch context without reconnecting MCP. The active workspace persists for the session.

Operator tools

Tool	Role
`deploy_agent`	Start and poll Gyri subagent runs (long-running research, buildouts)

Enables Cursor or Claude to kick off governed background work — competitive dossiers, onboarding buildouts — without a separate job queue integration.

Write-back boundary

mutate and operator tools are where agents write back to CRM and the knowledge graph. Enterprise rollouts should document which roles may trigger writes, which record types are in scope, and whether human approval is required before CRM updates. Read tools (search, query) are safe to enable broadly; write tools warrant tighter IAM alignment.

Optional MCP App dashboards (show_pipeline_board, explore_insights_graph, etc.) expose visual surfaces when enabled — useful for demos, not required for core GTM automation.

Cursor setup: remote MCP in five minutes

Cursor supports remote MCP servers via URL + headers — no local npx tsx process for production users.

Get credentials. Sign in to Gyri, verify email, mint an API key under Settings. New accounts receive a welcome email with a ready-made config block.
Edit MCP config. Open ~/.cursor/mcp.json (or project-level .cursor/mcp.json for team sharing).
Add the Gyri server:

```json

{

"mcpServers": {

"gyri": {

"url": "https://api.gyri.io/mcp?kb_ws=your_workspace_slug",

"headers": {

"X-Gyri-User-Key": "gyri_sk_your_key_here"

}

```

Restart Cursor so the MCP client reloads.
Verify. In Agent mode, ask: "List my Gyri workspaces" or "Search for recent emails mentioning [account name]." The agent should call workspace or search and return JSON with source refs.

Multi-workspace tip: Omit kb_ws from the URL and let the agent call use_workspace to switch, or maintain separate MCP entries per workspace if your team prefers hard isolation.

Developer note: Local stdio MCP (npm run mcp) remains available for engineers hacking on Gyri itself. Enterprise GTM rollout should standardize on api.gyri.io so connector health, auth, and logging stay centralized.

Claude setup: Connectors Directory path

Claude's connector UX is optimized for OAuth — no API keys in config files.

In Claude: Settings → Connectors → Add custom connector
Remote MCP server URL: https://api.gyri.io/mcp
Leave OAuth Client ID / Secret blank
Click Add, then Connect, and sign in to Gyri when prompted
Grant requested scopes

After connection, Claude can call the same tool surface as Cursor. A RevOps lead can ask for a cited account summary; a marketing operator can search competitive mentions — without installing Cursor or pasting CRM exports into the chat window.

Prerequisites: Verified Gyri account with access to the target workspace. Federated sources (CRM, Slack, and docs connected) must be configured in Gyri first; MCP exposes what the workspace already federates.

Public setup details also live at gyri.io/docs/connector for IT review packets.

Security review checklist for IT and InfoSec

Use this checklist when submitting Gyri MCP for enterprise approval:

Data residency and vendor boundary

MCP traffic goes to first-party api.gyri.io; Claude and Cursor access workspace data only through authenticated Gyri sessions
Source-system credentials (Salesforce, Google, Slack) remain in Gyri connector storage — not in Claude or Cursor config

Authentication and revocation

OAuth: users consent per Gyri account; revoke via Gyri account settings or IdP if SSO is enabled
API keys: per-user, revocable in Settings; map keys to individuals for audit
Confirm GYRI_MCP_AUTH_MODE policy with your Gyri admin (required vs optional key fallback)

Authorization

Workspace membership gates all tool calls — no cross-tenant reads
Insight list scope defaults to user's own insights unless workspace-wide policy applies
Write tools (mutate, deploy_agent) should be restricted to roles that already edit CRM or knowledge bases

Audit and observability

API activity logs record MCP tool invocations with user, workspace, and tool name
Citations on synthesized answers provide replay to source records for compliance review

Rollout sequence

Pilot read-only: enable search + query for one workspace with 3–5 power users in Cursor
Add Claude OAuth for a second cohort (non-engineers)
Enable write-back workflows with explicit approval gates
Document offboarding: revoke keys, remove connector, confirm workspace membership removed

Common objections — short answers

"Is this another copy of our data?" No — federated query at ask time; see federated search.
"Can Claude train on our CRM?" Connector access is scoped to your session; data handling follows Gyri's privacy policy and your vendor agreement.
"Why not build MCP ourselves?" You can — but connector long tail, citation plumbing, and graph schema are the expensive parts. Build vs buy is a separate decision; MCP deployment is about standardizing the client wire format either way.

Operating the endpoint day to day

Health checks. If Cursor shows MCP "down," verify https://api.gyri.io/mcp responds and the API key is not revoked. Claude connector issues often trace to expired OAuth refresh — reconnect the connector.

Connector drift. When Salesforce or Slack OAuth tokens expire, federation errors surface in tool responses before agents hallucinate. Assign a workspace admin to monitor connector status in Gyri — not every MCP user.

Version skew. Gyri publishes tool descriptions server-side; clients pick up changes on reconnect. No per-user MCP package upgrades.

Scaling seats. Each user needs their own Gyri account and key (or OAuth identity). Shared "team keys" break audit trails — issue keys per person or per named automation with a documented owner.

When one MCP endpoint is the right call

Deploy Gyri MCP centrally when:

Claude and Cursor (or internal SDK agents) all need the same CRM + comms context
Security wants one auth story and activity log, not per-app integrations
GTM workflows depend on cited answers and persisted insights, not ephemeral chat
You are tired of rebuilding Salesforce read logic for every new agent framework

Skip central MCP if your AI usage is a single siloed copilot with no cross-tool agents — but most revenue teams outgrow that within one quarter.

To see federation, MCP tools, and write-back on your actual stack — not a sandbox — start your free trial. We connect your CRM and comms in the first session and run live MCP queries from Cursor and Claude side by side.