Your agent needs to work with SurveyMonkey. It has to find last quarter's customer satisfaction survey, publish a link for a new pulse check, and tell a CX lead what 400 respondents actually said. You have four options: SurveyMonkey's own hosted MCP server, a community MCP server from a registry, the REST API v3, or Scalekit's connector in front of the official server. They differ in what the agent can do, which accounts can connect, and who ends up holding a credential that never expires. The last difference is the one a security review will ask about.
There are four paths to compare, and two of them share the same tool surface.
SurveyMonkey launched its MCP server on May 5, 2026, alongside its Claude connector. Its ChatGPT connector exposes the same tool set. SurveyMonkey hosts and maintains the server, so there is nothing to install. Users connect through a browser OAuth consent screen.
The server exposes 20 tools. SurveyMonkey's help center lists the access it requests:
Two sets of terms apply to every MCP connection. SurveyMonkey's API Developer Terms, updated June 9, 2026, define the API to include its MCP servers. The Connector Service-Specific Terms also apply.
Community servers are open-source wrappers around the REST API v3. They are written by individuals or vendors unaffiliated with SurveyMonkey. The common pattern is a local process launched over stdio that reads a SurveyMonkey access token from an environment variable. Tool coverage is whatever the author chose to wrap. SurveyMonkey doesn't review or support these servers.
The REST API is JSON over HTTPS, authorized with the OAuth 2.0 Authorization Code flow. Every integration starts as a draft app that works only against your own account for 90 days. After that, you deploy it as private or public.
Accounts in the EU and Canadian data centers use regional API hosts. The token exchange returns the correct access_url for each account.
Scalekit's SurveyMonkey MCP connector docs describe a connector that sits in front of SurveyMonkey's official server rather than reimplementing it. Each user signs in to SurveyMonkey once. Scalekit stores and refreshes that user's tokens, and the agent never handles them. Scalekit lists the connector's auth as OAuth 2.1 with Dynamic Client Registration (DCR).
You get the same 20 tools, named surveymonkeymcp_<tool>. You can call them with execute_tool or serve them through a Virtual MCP server. The SurveyMonkey MCP connector page shows client setup for Claude Code, Cursor, Codex, and Copilot.
The official server and Scalekit's connector share one tool surface, so the capability comparison is really MCP versus REST. A community server covers whatever its author implemented.
The MCP server is built for a conversational loop: find a survey, build or adjust it, publish a link, read the results. The REST API covers distribution, events, and administration.
Two MCP tools are designed for agents. get_response_summary returns pre-computed counts and percentages with choice labels already resolved, so the model doesn't have to tally raw responses itself. generate_survey_plan drafts a title and question list from a plain-language description without saving anything.
Survey agents are event-driven by nature: a feedback agent should act when a response lands, not poll for it. The API's response_completed webhook supports that. Over MCP, the only option is calling get_response_count on a schedule.
Distribution is the second gap. Sending invitations to a contact list is REST-only, so an agent that runs a full NPS cycle cannot rely on MCP alone.
Every structural edit tool on the MCP server is blocked once a survey has responses: add_page, add_question, edit_question, delete_question, reorder_questions, and update_survey. An agent can iterate freely on drafts but cannot change a live survey. Design your prompts and approval steps around that.
The four paths differ more in the shape of the credential than in capability.
The official server authenticates each user through OAuth consent. Every tool call runs with that user's SurveyMonkey plan, seat, and role. SurveyMonkey documents no static-key option for headless use.
Availability is the harder constraint. The connectors work only for accounts whose data is stored in the United States. They are not available to HIPAA-enabled Enterprise accounts or Enhanced Sensitive Data Protection accounts.
Revocation is in the user's hands: they unlink the SurveyMonkey MCP Server under Linked Accounts in their account settings. Team and Enterprise admins who want to disable it for the whole team have to contact SurveyMonkey support.
SurveyMonkey uses the standard three-step Authorization Code grant. The code is valid for five minutes, and the exchange returns a long-lived access token. SurveyMonkey's docs state that access tokens don't currently expire but may in the future. There is no refresh token.
That removes refresh logic entirely and makes storage the whole security boundary. A leaked token stays valid until the user revokes access. After revocation, calls fail with error 1013 and you have to run OAuth again.
Scopes are set per app as required or optional. Some, including responses_read_detail, require the user to be on a paid plan.
A private app can't serve a multi-tenant agent. Every user of a private app must be on the same SurveyMonkey team, and a draft app authenticates only your own account.
An agent that acts for users across 12 customer organizations therefore needs a public app, and SurveyMonkey must review and approve it before publication. SurveyMonkey's API docs also require explicit approval to use the Create/Modify Surveys and Create/Modify Responses scopes in a public app. The MCP path avoids this because users consent to SurveyMonkey's own server.
Both paths require per-user credential isolation in a B2B agent. The MCP server gives you an OAuth grant per user; the REST API gives you a long-lived token per account. Neither path stores, rotates, or revokes those credentials for you.
Take 60 HR managers across 12 customer organizations. That is 60 grants to encrypt at rest, isolate per tenant, and clean up when someone leaves. You need that infrastructure whichever path you choose.
Hosting is the smallest part of the operational work.
SurveyMonkey hosts the server and writes the tool schemas. You own:
SurveyMonkey publishes no rate limits for the MCP server.
You also own human review. The API Developer Terms require user permission before an app edits, distributes, or closes surveys. They also prohibit encouraging reliance on unreviewed automated actions where human review is reasonably appropriate.
SurveyMonkey's Connector Service-Specific Terms let it modify, limit, suspend, or discontinue the MCP feature at any time, and impose rate limits whenever it chooses. The terms prohibit the following through the connector:
They also limit use to third-party services that SurveyMonkey makes available or approves in writing. Confirm your deployment model with SurveyMonkey before launch.
You own everything above, plus the adapter layer:
Every schema you write is one you maintain through each API change.
Draft and private apps start at 120 requests per minute and 500 per day. The daily limit resets at midnight GMT. SurveyMonkey tolerates three overages of up to 150 percent within 30 days, then enforces the limit strictly. The rate-limit headers are named X-Ratelimit-App-Global-*, and every user of your agent draws from the same pool.
An analysis task that searches, fetches a survey, pulls a summary, and pages through five batches of responses costs eight calls. At 500 calls a day, that is 62 tasks across your entire user base. Published public apps get up to 500,000 requests per day. Higher private limits require contacting SurveyMonkey sales, and fees may apply.
Community servers are the fastest way to get SurveyMonkey into Claude Desktop on a laptop. Because they wrap the REST API, some also expose endpoints the official server lacks. They also carry the most risk of any path.
A community server needs a private-app token or an OAuth token, and neither currently expires. The token usually sits in plaintext in an MCP client config file or .env, readable by any process running as that user and copied into every backup. A leaked token doesn't expire in 60 minutes. It keeps working until someone notices and revokes it.
The server process holds a credential that can read every survey and response the account can see. Email collectors can attach respondent names and emails to those responses. Nothing limits what that code, or any package it depends on, does with the token.
Tool descriptions come from the same unreviewed source and go directly into your model's context. Every update pulls new code into a process that already holds your credentials.
A community server is only as current as its last commit. A server that hard-codes the US host fails for EU and Canadian accounts with error 1018. A server built on a draft-app token stops working when the 90-day draft window closes. When a tool breaks mid-task, there is no vendor to escalate to.
Every call goes out as the token owner. SurveyMonkey sees one app and one account. Your logs, if the server writes any, show a process rather than a person. When a CISO asks which user's agent edited a question or published a link, a shared-token server can't answer.
SurveyMonkey's API Developer Terms make you responsible for every Third-Party Client used with your app. All prompts, tool calls, and actions submitted through one are deemed submitted by you, and you indemnify SurveyMonkey for resulting claims.
The terms also bar giving an access token to a third party without SurveyMonkey's written consent, which any hosted community server requires. Running someone else's server doesn't shift any of that liability to its author.
Recommended reading: MCP security risks for AI agents
Choose based on where the agent runs and whose data it touches.
A community server is acceptable for a throwaway experiment against your own account on a machine you control, using a draft-app token limited to read scopes. Never use one for multiple users or in production.
The hard part of a SurveyMonkey agent is not the tool call. It is holding a credential for every user, scoping what each agent role can touch, and proving afterward who authorized what. Scalekit takes all three out of your agent: users authorize once, the token vault holds the credentials, and your code references a user identifier instead of a token.
Create a SurveyMonkey MCP connection under AgentKit > Connections in the Scalekit dashboard. The connection_name in your code must match the dashboard name exactly; a mismatched name is the most common integration error. Set these environment variables:
The connected account is Scalekit's per-user record for SurveyMonkey. If the user hasn't authorized yet, send them the authorization link. After that, your agent never touches their SurveyMonkey token. For production callback handling, see Authorize a user.
list_scoped_tools doesn't return a connector catalog. It returns the tools the current user's connected account is authorized to call. This example narrows that further to four read-only tools for a results-analysis agent. Loading four tool definitions instead of 20 reduces token overhead and gives the model fewer tools to choose between.
Each tool call goes through execute_tool with the user identifier, and Scalekit attaches that user's credential on the server side. This loop uses the Claude SDK (the anthropic Python package) with Claude Sonnet 5. Sonnet 5 returns thinking blocks by default, so the loop reads text blocks by type and passes the full content back on each turn.
Write tools need a gate. surveymonkeymcp_create_weblink_collector, for example, publishes an open link immediately, so require explicit user confirmation before execute_tool runs it.
Every execute_tool response carries an execution_id. Scalekit's agent logs attribute each downstream call to the user who authorized it and the agent that ran it, along with the response, and they can be exported to your SIEM. A shared-token community server can't produce that trail. It is also the monitoring record SurveyMonkey's Developer Terms make you responsible for.
If your agent runtime speaks MCP, a Virtual MCP server gives it a scoped endpoint instead of SurveyMonkey's full 20-tool surface. Create the server once per agent role, not once per user.
Before each run, confirm the user's connections are active, then mint a short-lived session token bound to that user. The default lifetime is about one hour, and the maximum is 24 hours. This example uses LangChain's MCP adapter.
The Node.js SDK doesn't mint MCP session tokens yet, so TypeScript agents should mint the token on a Python backend and pass it in. For the full lifecycle, see Set up and connect a Virtual MCP server and the LangChain example.
create_config accepts one McpConfigConnectionToolMapping per connection. A survey agent that also posts to Slack or updates a CRM gets a single endpoint covering all of them. The server URL is the same for every user; each user's identity arrives with their session token.
Twelve customer organizations and 60 users still means one server definition and 60 connected accounts, with no credential shared between users.
Recommended reading: What a Virtual MCP server is and When to use a Virtual MCP server
No path removes the per-user credential. They differ only in what that credential looks like.
You get per-user identity on the MCP path and per-account tokens on the REST path. Every call runs within the user's plan, seat, and role limits. That is the right security posture, but it is identity enforcement, not credential lifecycle management.
The token type differs by path; the infrastructure you need does not.
Scalekit's SurveyMonkey connector handles the per-user OAuth flow, token storage, and refresh, and records every call. Choosing the MCP path doesn't change your credential infrastructure. For REST-only capabilities such as email invitations, Add your own connector lets you define custom tools on the same connected-account model.
If your agent is a conversational assistant for US-based SurveyMonkey users, build on the official MCP server. Examples include building a survey, publishing a link, and summarizing results.
If it is event-driven, sends invitations, serves EU or Canadian accounts, or runs as a deterministic export pipeline, build on the REST API. Budget for the per-app rate limit and the public-app review.
Keep community servers on your own laptop.
Most production survey agents become multi-tenant, and that narrows the decision. Every path leaves you holding a credential per user, and on the REST path that credential never expires. The agent that passes a security review is the one where no SurveyMonkey token ever lives in agent code.
Start with the Scalekit SurveyMonkey MCP connector and the SurveyMonkey connector docs, and review Scalekit pricing. If you are building a SurveyMonkey agent and want help with per-user auth, tool scoping, or Virtual MCP setup, talk to the Scalekit team.
