.png)
Your agent needs to work with Amplemarket. It has to search the prospect database, enrich leads before a meeting, enroll people into sequences, and check what a rep has due today. Amplemarket ships both a hosted MCP server and a REST API that has been in production for years. They are not two views of the same thing. They expose different actions, authenticate on opposite models, and one of those differences is a hard constraint for multi-tenant agents. Here is how to pick.
Two objects, two auth models, two different generations of the product surface. The REST API was built for integrations. The MCP server was built for AI clients, and it shows in what each one exposes.
Amplemarket MCP is a remote, Amplemarket-hosted server reachable at https://mcp.amplemarket.com/mcp. Amplemarket runs it, versions it, and adds tools on its own cadence. At the time of writing the published catalog is 54 tools across 13 groups: Searcher, Enrichment, Contacts, Accounts, Exclusion List, Lead Lists, Sequences, Workflows, Analytics, Duo, Unibox, Personas, and Tasks.
Authentication is OAuth 2.0 and nothing else. A browser opens, the user signs in to Amplemarket, and approves read and write access. Each user authenticates individually, and the server resolves data against that person's own Amplemarket permissions. Adding it to Claude as a custom connector requires a Pro, Max, Team, or Enterprise plan, because it is not in the Claude connector directory yet. Full details live in Amplemarket's MCP server documentation.
The REST API is a JSON API at https://api.amplemarket.com, organized into roughly a dozen resource groups: searcher, people and companies enrichment, lead lists, sequences, contacts, accounts, calls, tasks, mailboxes, email validations, exclusion lists, job openings, and users. It also ships webhooks for replies, sequence stages, and workflow JSON pushes, which the MCP server has no equivalent for.
Auth is a bearer API key generated from Settings > API in the Amplemarket dashboard and passed in the Authorization header. Keys are named, but nothing in the documentation scopes a key to a single user. The reference is at docs.amplemarket.com.
Four dimensions decide this for an agent: what actions exist, what auth model you inherit, what you operate in production, and what each path costs you in rate budget and credits.
The overlap is smaller than you would expect, and the gap is bidirectional. Search and single-record enrichment are near-parity. Everything else splits.
Two more asymmetries do not fit the table. Exclusion lists are read-only on MCP, which offers check_excluded_emails and check_excluded_domains; the REST API creates and deletes entries. And webhooks exist only on the API side, so an agent that needs to react to a prospect reply has no MCP path to subscribe.
Sequence authoring is the headline. The REST API's sequences surface is two endpoints: list sequences, and add leads to one. It cannot create a sequence, append a stage, or edit step copy.
The MCP server can do all three, plus update_sequence_status to launch a draft. If your agent's job is "draft a three-step multichannel sequence and enroll these twelve leads with per-lead personalization," that workflow does not exist on the REST API. Same for ask_analytics, the Unibox reads, persona lookups, saved searches, and the Duo tools.
Volume and telephony. The API's batch endpoints take up to 10,000 leads or companies per enrichment request with a 15,000 per hour ceiling, and up to 100,000 emails per validation request. The MCP server's enrichment tools are single-record and synchronous.
Call logging is API-only: POST /calls, disposition lookups, and recording retrieval. So is mailbox management, including changing a mailbox's daily send limit. If you are building a dialer integration, a deliverability watchdog, or a nightly enrichment pipeline, the MCP catalog does not contain the primitives.
MCP uses OAuth 2.0 Authorization Code with a browser consent step, per user, every time a new user connects. There is no API key fallback documented. Amplemarket's own guidance frames connection through MCP clients, which means if you are building a backend agent you own the OAuth client registration and refresh handling yourself, and that path is not documented.
The REST API inverts every one of those properties. One bearer key, no interactive step, works from a cron job on day one. That convenience is also the problem.
An Amplemarket API key authenticates a workspace, not a person. The account_info endpoint returns the workspace the key belongs to. The users endpoint lists everyone in it. The tasks endpoint requires you to pass user_id explicitly, which is the tell: the credential itself carries no user identity, so you supply it as a parameter.
For a single-tenant internal tool, fine. For a B2B agent, it is the whole ballgame.
Serving forty reps across eight customer workspaces on the API path means every call from every rep's agent session runs under the same credential, and your audit trail in Amplemarket cannot distinguish them. Filtering by user_id is application logic, not enforcement. A prompt injection or a logic bug reaches the whole workspace.
The MCP path gives you the opposite guarantee at the cost of the interactive flow: what the rep cannot do, the agent cannot do. That property is worth more in a multi-tenant agent than the convenience of a static key.
Recommended reading: Access Control for Multi-Tenant AI Agents
On the MCP path Amplemarket owns hosting, scaling, and the tool schemas. You own the OAuth grant per user per workspace, token storage, refresh, and revocation when a rep leaves. You also absorb schema drift: Amplemarket adds tools on its own schedule, and the knowledge base explicitly tells clients to refresh their tool list when new tools do not appear.
On the API path you own more. Endpoint adapters for every resource group you touch, polling loops for the async batch endpoints, webhook receivers with signature verification, and retry logic against per-endpoint rate limits that differ by an order of magnitude.
The REST API allows 500 requests per minute per consumer by default, with tighter per-endpoint caps: 300 per minute on /people/search, 350 on /people/find, 30 on /sequences/{id}/leads, and 50 per hour on /calls/{id}/recording. The MCP server allows 100 requests per minute per user.
Those numbers are not comparable directly, and that matters. The API budget is shared across your whole workspace, so fifteen concurrent agent sessions contend for one pool. The MCP budget scales with your seat count. For a fleet of per-rep agents, the MCP model is the one that holds up.
The MCP enrich_person tool consumes 0.5 credits per enrichment with a 24-hour result cache, and revealing an email or phone number costs extra on top. The API's enrichment and validation endpoints draw from the same pool and return an insufficient_credits error when it runs dry.
Budget for credits separately from rate limits. Hitting either one stalls the agent, but in different ways and at different times.
Both are correct for different agent shapes. The split follows almost exactly the interactive versus batch line, with one exception worth knowing.
A sales agent that preps a rep before a call is an MCP agent. The pipeline that enriches tomorrow's list at 2am and logs yesterday's dials is an API job. Splitting them is the normal answer, not a compromise.
What that split does not change is the credential layer. You now have two credential types across two paths, and both need the same vault, the same rotation, and the same revocation story. Understanding credential ownership across agent tool-calling patterns becomes critical once you operate both paths in parallel.
Scalekit's Amplemarket connector wraps the REST API as 47 named tools behind a per-user connected account, authenticated with a bearer token. The connector marketing page is at scalekit.com/connectors/amplemarket.
The credential is held in Scalekit's vault and injected at call time, so it never reaches your agent runtime, your logs, or the model context. Below, a Python agent using Anthropic's SDK, then a TypeScript agent using Mastra over a Virtual MCP server.
Install the SDK and initialize the client. Your .env needs SCALEKIT_ENVIRONMENT_URL, SCALEKIT_CLIENT_ID, and SCALEKIT_CLIENT_SECRET from Developers > API Credentials in the Scalekit dashboard.
Each rep authorizes once. The connection_name string must match the connection name configured in your Scalekit dashboard exactly; a mismatch here is the single most common integration error.
The agent is not loading a flat connector catalog. It loads the tools this rep's connected account is authorized to call, which is what separates a per-user agent from a shared-credential one. Pass page_size above the default so none of the 47 tools are silently dropped.
The tools most outbound agents reach for first:
execute_tool resolves the connected account for this identifier, injects the credential, calls Amplemarket, and returns the result. The full loop, including the stop_reason check and the message append:
Handing a Mastra agent all 47 Amplemarket tools costs roughly 9,000 tokens of context before it does any work, and grants it write access to sequences and exclusion lists it has no business touching. A Virtual MCP server fixes both. Define the server once per agent role, listing only the tools that role needs.
At runtime, generate the per-user URL on your backend and hand it to the Mastra app for that user only. Never share one URL across users; each is pre-authenticated for a single identity.
Mastra's MCP client discovers the four tools and their schemas directly, so there is no Zod conversion to write.
Three properties matter once you move past one workspace and one agent. None of them are about Amplemarket specifically, which is exactly the point.
The research agent above sees four tools. A sequence-authoring agent gets a different server with a different four. An enrichment pipeline gets a third. One server definition per agent role serves every user, and each run receives a short-lived session token bound to that specific user's connected accounts. The default session token expiry is about one hour, and you remint it by calling create_session_token again.
This is the direct answer to the workspace key problem. The Amplemarket credential is still a workspace bearer token underneath, but the agent never holds it, and the tool surface it can reach is declared by you rather than by whatever the connector happens to expose.
A shared Amplemarket key produces one audit identity in Amplemarket for every action your agents take. Scalekit captures each execute_tool call as a structured event with the authorizing user, the agent, the tool, and the response, and streams it to Datadog, Splunk, or any SIEM without instrumentation on your side. Errors are classified by source, so you know whether your agent failed or Amplemarket did.
That distinction stops being academic the first time a customer asks which rep's agent enrolled a lead in the wrong sequence.
Recommended reading: Agent Tool Observability: Your Agent Is Running. Is It Actually Working?
An outbound agent is rarely Amplemarket-only. It reads the CRM, checks the calendar, and posts to Slack. Scalekit's connectors for Salesforce, HubSpot, Gmail, and Slack use the same connected account model and the same execute_tool call, and a single Virtual MCP server can span all of them.
If you want a working shape to start from, the outbound prospecting agent and sales call prep agent templates are the closest fits, and the full GTM and RevOps template library covers the adjacent patterns. AgentKit pricing starts at 5,000 tool calls free with audit logs included.
Neither path ships credential infrastructure. Both hand you a secret and leave the lifecycle to you.
MCP gives you an OAuth grant per user: a token that expires, a refresh token that can be revoked from the Amplemarket side, and a browser flow you have to orchestrate and re-orchestrate when a grant dies. The REST API gives you a static workspace key with no expiry and no user identity, which is less to manage and far more to lose.
For a B2B agent serving forty reps across eight customer workspaces, the MCP path means forty OAuth grants to store encrypted, refresh proactively, and revoke on offboarding. The API path means eight workspace keys, no rotation mechanism in the product, and no way to prove in an audit which rep's agent made a given call. Getting token refresh right for AI agents at this scale is non-trivial regardless of which path you pick.
The token type differs. The infrastructure required does not: an encrypted store, per-tenant isolation, proactive refresh, event-driven revocation, and a log that records who authorized what. Scalekit's Amplemarket connector handles the authorization flow, per-tenant token storage, injection at call time, and revocation for both paths, so choosing MCP or the API stops being a credential architecture decision.
If your agent writes outreach, reads a rep's inbox, or answers questions about their pipeline in conversation, build against Amplemarket MCP. The per-user permission model and the per-user rate budget are both working in your favor, and the sequence authoring tools do not exist anywhere else.
If your agent enriches in bulk, validates emails, logs calls, manages mailboxes, or needs to react to a reply webhook, build against the REST API. Those primitives are API-only and will stay that way for as long as the MCP catalog stays focused on conversational workflows.
Most teams shipping serious Amplemarket agents will run both, and that is when the workspace key stops being an implementation detail and starts being the thing a security questionnaire fails on. Solve the credential layer first, and the path choice becomes what it should be: a question about capability coverage, not architecture. The tool-calling auth production patterns that trip teams up are the same regardless of which Amplemarket surface you choose.
Browse the Scalekit Amplemarket connector and the full connector catalog.
Building an outbound agent on Amplemarket and want to compare notes on the auth model? Join the Scalekit Slack community, or talk to an engineer if you need an answer today.
