.png)
Your agent needs to shorten links, tag them to a campaign, and report back on clicks and scans. Bitly ships a hosted MCP server at api-ssl.bitly.com/v4/mcp and a v4 REST API that has been in production for years. Most tool-by-tool comparisons in this space end with "MCP is OAuth-only, so headless agents need the API." Bitly breaks that pattern: its MCP server accepts a static API token as a first-class auth method. That changes which path you pick, and it changes what you have to build underneath it.
These are two entry points into the same Bitly platform, maintained by the same team, with different shapes. One is a managed tool surface built for LLM consumption. The other is the versioned REST surface that Bitly's own apps run on. Knowing which object you are pointing your agent at matters more than it usually does here, because Bitly's MCP server is unusually permissive about auth.
The Bitly MCP Server is Bitly's official hosted endpoint at https://api-ssl.bitly.com/v4/mcp, using HTTP transport. Per Bitly's MCP changelog, it shipped in August 2025 with core link, analytics, and QR tools; added six QR scan metrics tools in October 2025; and added OAuth 2.1 with Dynamic Client Registration in December 2025, at which point all MCP endpoints began requiring authentication.
Two auth methods are supported. OAuth 2.1 with DCR is the recommended path and handles token renewal without manual intervention. An API token from your Bitly account settings, passed as Authorization: Bearer, works for clients without OAuth support. Full setup details are in the Bitly MCP Server quickstart.
The Bitly v4 REST API exposes nine resource groups: Bitlinks, BSDs, Campaigns, Custom Bitlinks, Groups, Organizations, QR Codes, User, and Webhooks. Everything the MCP server does maps onto it, plus a substantial surface the MCP server does not touch.
Auth accepts a generic access token from account settings, an OAuth 2.0 access token from the web flow, or a token obtained through the resource owner credentials grant. The Bitly authentication guide documents all three. Note the shape of the OAuth web flow response, because it drives most of what follows.
Four dimensions decide this: what your agent can call, what credential it holds, what breaks in production, and which workload each path suits. Bitly is a smaller platform than Salesforce or GitHub, so the capability gap is narrower than you might expect and the operational constraints matter proportionally more.
The MCP server covers link creation, link updates, QR code creation and customization, link-level analytics, group-level analytics, and account structure. For a marketing agent that shortens, tags, and reports, that is close to complete coverage.
The gap opens on write operations at scale, on lifecycle management, and on anything event-driven.
Two rows on that table decide real architectures. The first is bulk update. Bitly's REST API exposes PATCH /v4/groups/{group_guid}/bitlinks, which archives or edits tags on up to 100 links in a single call. The MCP server has no equivalent, so a retagging agent has to loop bitlymcp_update_short_link one link at a time.
The second is webhooks. Bitly's API reference includes a Webhooks resource for pushing link engagement events out of Bitly. There is no MCP tool for it. If your agent reacts to click activity rather than polling for it, that logic lives on the REST side regardless of what the rest of your agent uses.
Here is a concrete reason not to trust any static tool list for this connector. Bitly's MCP landing page says 27 tools. Bitly's own MCP Tools Reference enumerates 31 across six categories. Scalekit's Bitly MCP connector docs enumerate 53.
The 53 is not inflation. It includes the six QR scan metrics tools the changelog says shipped in October 2025 and the group-level analytics tools, neither of which appear in the published Tools Reference. The reference page is behind the live server.
Treat the tool surface as runtime state, not documentation. Enumerate it per user before each run and pin the tool names your agent depends on, so a server-side addition does not silently widen what your agent can reach.
This is also why MCP tool schemas are a weaker dependency contract than REST endpoints here. Bitly's v4 API is versioned and stable; the MCP surface has grown three times in the documented changelog and the docs have not kept pace.
Bitly is the exception in this series. Its hosted MCP server does not require an interactive OAuth flow, which removes the usual headless blocker.
The API token path is the fastest way to a working demo and the wrong default for a B2B product. One token means every user's agent acts as whoever generated it. Link ownership, creator attribution in created_by, and group membership all collapse to that single identity.
Shared credentials are a single-user solution. They do not survive a second user. What the user cannot do, the agent should not be able to do either, and a shared token makes that guarantee impossible to state. This is the core argument covered in depth in OAuth vs API Keys for AI Agents: Why Static Credentials Break in Production Systems.
Look at what Bitly's documented OAuth web flow actually returns: access_token=%s&login=%s. There is no expires_in, no refresh_token, and no scope parameter in the documented response.
Teams read that as one less thing to build. It is the opposite. Proactive refresh is not available as a safety net, so revocation inside Bitly's settings is the only lifecycle event, and your agent learns about it when a call starts failing. A token generated eight months ago by an employee who has since left is still valid until someone revokes it explicitly. Understanding how to handle token refresh for AI agents becomes even more important when the underlying platform gives you no expiry signal to rely on.
Bitly manages the MCP server, its tool schemas, and endpoint normalization. On the REST path you own request construction, pagination, retries, and versioning. Standard tradeoff. Two Bitly-specific constraints apply to both paths equally, and they surprise people.
Bitly's rate limits come in two layers. Platform limits apply to every account: a maximum of five concurrent connections from a single IP address, per-endpoint hourly caps, and a per-minute cap equal to one tenth of the hourly cap. Exceeding them returns a 429 with RATE_LIMIT_EXCEEDED.
Plan limits are monthly and, critically, apply across all transactions in the API and the Bitly apps. Exceeding the monthly API request allowance returns a 429 with API_USAGE_LIMIT_EXCEEDED. Bitly does not publish per-endpoint hourly figures; you read your own via GET /v4/user/platform_limits and GET /v4/organizations/{organization_guid}/plan_limits.
That IP limit deserves its own paragraph because it is an infrastructure constraint disguised as an API constraint. A containerized agent fleet behind a single NAT egress IP shares those five concurrent connections across every tenant it serves. Agentic workflows issue several sequential calls per user action, so twenty concurrent agent runs do not get twenty connections. Plan egress accordingly, and monitor limit usage from day one rather than after the first 429 storm.
Use Bitly MCP when:
Use the Bitly REST API when:
Scalekit ships a Bitly MCP connector that wraps Bitly's hosted MCP server behind a per-user connected account. The agent never holds a Bitly credential; Scalekit resolves it server-side at call time and injects it into the upstream request.
One prerequisite before any code runs: the connection_name you pass in code must match the connection name configured in your Scalekit dashboard exactly. This is the single most common integration error.
Scalekit's connector docs list the Bitly MCP connector under OAuth 2.1 with DCR, while the Bitly MCP connector page describes API-token storage. Bitly's server accepts both, so confirm which mode your environment is configured for in the dashboard before you ship.
Every user authorizes Bitly once. Scalekit returns a time-limited link, the user completes the flow, and a connected account is created and bound to that identifier.
Before the agent sees anything, retrieve the tools this user's connected account is authorized to call. This is not exploration of an unknown surface; it is a scoped, deterministic list derived from what this specific user granted.
The scoping matters numerically here. Scalekit's Bitly MCP connector exposes 53 tools, of which roughly 40 are analytics reads. At Scalekit's own estimate of about 200 tokens per tool definition, handing the agent the full connector costs around 10,600 tokens of context before it does any work. A link-reporting agent needs five.
Once the connected account is active, execute_tool runs a named tool against it. Scalekit fetches the credential, calls Bitly, and returns structured output. The token never enters your process.
With auth handled, the agent loop is ordinary. Scalekit's LangChain adapter returns native StructuredTool objects filtered to the connector and tool names you specify, so the model sees a five-tool surface instead of fifty-three.
Surface reduction is the lever on tool-calling accuracy. A stronger model choosing from 53 Bitly tools, 40 of which are near-identical analytics reads differing only by dimension, still underperforms a correctly scoped surface. Model upgrades help. They are not the lever. For a deeper look at how LangChain tool calling works and where it stops, that pattern is covered in detail separately.
If you would rather drive the loop yourself, listScopedTools returns raw JSON Schema you can pass straight to the Anthropic Messages API. The pattern is the same: retrieve the authorized surface, filter it, run the loop, route each tool_use block back through executeTool.
Nothing is elided here. The loop runs until Claude stops requesting tools.
A campaign agent rarely touches Bitly alone. It reads a content calendar, shortens the URL, posts to Slack, and writes results back to a CRM. Every one of those connectors brings its own tool surface, and the bloat compounds.
Virtual MCP Servers solve this by inverting the default. A standard MCP server exposes every tool it has. A Virtual MCP server exposes only the tools you explicitly declare, across whichever connections you choose, behind one static endpoint. This is the same pattern explored in building production-ready agent workflows with remote MCP servers.
Setup happens once per agent role: define which connections and which tools the server exposes, and you get a static MCP server URL. Runtime happens before each run: confirm the user has authorized the required connections, mint a short-lived session token bound to that user, and hand the agent the URL plus the token.
The endpoint is static. The identity is not. One server definition serves every tenant, and no credential is shared between them.
Bitly's MCP server exposes write tools alongside read tools: creation, updates, and deletion sit next to analytics. An agent whose only job is weekly click reporting has no business holding bitlymcp_delete_short_link. Declaring three tools instead of fifty-three shrinks the blast radius to what you actually authorized, and it does so without deploying, hosting, or maintaining an MCP server of your own.
Link management is an attribution problem before it is an automation problem. Bitly stamps created_by on every link and rolls creator identity into group reporting. An agent running on a shared token flattens all of that into one name.
Scalekit's connected account model preserves it. Each tool call resolves that user's credential server-side, so the link Bitly records was created by the marketer who asked for it, not by a service account. This is why agent tool observability matters as much as the tool calls themselves — you need to know not just that a tool ran, but whose authority it ran under.
Every downstream tool call is logged: who triggered it, which tool ran, and what came back. The Bitly MCP connector page documents 90 days of history, exportable to a SIEM. Auth logs cover the authorization side, so grant, token, and revocation events sit alongside the tool calls they authorize.
When someone asks why a production short link started redirecting somewhere unexpected, you need the answer in minutes, not a three-week investigation. Correlating the bitlymcp_update_short_link call with the connected account that authorized it and the prompt that triggered it is the difference between an incident report and a shrug.
Both paths hand you a credential per user. Neither hands you a vault, rotation logic, or a revocation flow.
For a B2B product with 40 marketers across 8 customer organizations, that is 40 Bitly credentials to store encrypted and isolated per tenant, 40 to invalidate when someone leaves, and 40 to re-prompt when a user disconnects inside Bitly's settings.
Bitly's non-expiring tokens remove the one signal most teams accidentally rely on. There is no expiry-driven refresh cycle that would surface a dead credential on a predictable schedule. Revocation is silent until a call fails, and a failed call inside an agent run usually surfaces as a wrong answer rather than an exception.
The token type differs between the MCP path and the REST path. The credential management infrastructure required is identical. Scalekit's Bitly MCP connector handles the authorization flow, per-tenant token storage, and lifecycle for either path, so the MCP versus API decision does not change your auth architecture. The broader patterns around secure token management for AI agents at scale apply here regardless of which Bitly integration path you choose.
If your agent creates links, generates QR codes, and reports on clicks and scans, build against the hosted MCP server. Bitly maintains the schemas, the tool surface is genuinely broad, and the static-token option means a scheduled job is not blocked on a browser flow the way it would be with Notion or Salesforce.
If your agent retags or archives in batches, subscribes to engagement webhooks, manages campaigns and channels, or exports data, use the REST API. Those surfaces do not exist in MCP, and looping single-item MCP calls to simulate a bulk endpoint burns a monthly allowance that is shared with your customers' human users.
Most production Bitly agents will use both. The credential layer underneath them is the same either way, and that is the part that needs production-grade infrastructure. When you are evaluating the difference between single-tenant and multi-tenant tool calling auth, the Bitly non-expiring token problem is exactly the kind of constraint that forces your hand.
Building on Bitly and hitting the five-connection IP ceiling, the bulk-update gap, or the non-expiring token problem? Join the Scalekit community on Slack and compare notes with engineers shipping the same patterns.
Need an answer today? Talk to an engineer and we will walk your architecture with you.
Start here: the Bitly MCP connector docs and the Bitly MCP connector overview.
