MCP for URL Shorteners: Let Your AI Agent Ship Links

You ask your assistant to plan a product launch. It writes the announcement, drafts three social variants, suggests UTM tags, proposes a slug, and then it stops and tells you to go make the short link yourself. Every time. The one part of the job that is a single API call is the part that falls back on you, because your assistant has no hands.

That gap is what MCP closes. The Model Context Protocol is an open standard for connecting AI assistants to external systems, and it is why a chat window can now create a real short link, re-point a live one, and read back the click count without you opening a dashboard tab. If you have heard the acronym and never wired one up, this is the practical version: what travels over the wire, what the shortener vendors have actually shipped, and how to connect one in under two minutes.

Why a shortener is the awkward gap in agent workflows

Link creation is small, frequent and stateful. Small enough that nobody builds a custom integration for it, frequent enough that doing it by hand a dozen times a day is genuinely annoying, and stateful enough that the agent cannot fake it. A model can hallucinate a plausible-looking flyn.to/spring, but the link will not resolve unless something wrote it to a database. That is the difference between an assistant that drafts and an assistant that ships.

Strip away the marketing and MCP is a small, boring protocol, which is why it works. A client (Claude Code, Claude Desktop, Cursor, Windsurf, ChatGPT in developer mode, Perplexity) talks to a server that publishes a list of callable tools. The model reads the tool descriptions, decides which fits your sentence, fills in the arguments, and the client executes the call.

What actually travels over the wire

Flyn's server is a single HTTPS endpoint at https://www.flyn.to/mcp speaking JSON-RPC 2.0 over streamable HTTP. It is stateless: every tool call is a bounded request and response, so there is no long-lived session to keep alive and nothing to reconnect after your laptop sleeps. The handshake is three messages: initialize returns the protocol version and server info, tools/list returns the catalogue, and tools/call carries a tool name plus arguments and returns a result.

Tools, not endpoints

The design difference from a REST API is that a tool is written to be read by a model, not a developer. An MCP tool ships its own description, its own JSON Schema for arguments, and, if the vendor bothered, its own behavioural hints. That description is the whole interface. If it says "use this to re-point an existing short link without changing the printed URL", the model reaches for it at the right moment. If it says "updates a link", the model guesses.

Flyn's server also ships server instructions, a short paragraph the client feeds the model up front, spelling out the plan rules: click totals on every plan, breakdowns on Pro, 25 links a month on free. The assistant knows the limits before it tries something that will fail, which is a nicer failure mode than a 403 mid-sentence.

Remote servers versus local ones

Two shapes exist and the difference is setup pain. A local (stdio) server runs on your machine, usually launched with npx, holding credentials in a config file. A remote server is a URL your client connects to over HTTPS: nothing to install, nothing to update, and it can offer a browser sign-in instead of a pasted secret. Flyn, Bitly, Linkly and UseClick are remote. Go2 offers both. Short.io's documented setup bridges to a remote endpoint through the local mcp-remote helper.

Eight tools is a deliberate number. Each maps to a job somebody actually asks for in a sentence, and none exist to pad a count.

• create_short_link, shorten a URL, optionally with a custom slug and an expiry.
• list_links, search your links by text, tag or status.
• get_link, fetch one link with its destination, settings and total clicks.
• update_link, re-point a live link without changing the printed URL.
• delete_link, permanently remove a link.
• get_link_analytics, pull click events with whatever breakdown detail your plan allows.
• get_link_qr_code, render a QR for an existing short link, so the code survives a destination change.
• create_qr_code, make a code for a URL, plain text or a WiFi network.

The one that earns its place

update_link is the tool that changes how you work. Because it re-points a live link without changing the printed URL, a printed menu, a pressed vinyl sleeve or a scheduled newsletter can be corrected after it ships. We covered the pattern in updating links without changing the URL, and it is the reason to prefer get_link_qr_code over create_qr_code whenever the payload is a link: the dynamic version stays editable and every scan counts as a click. The static one does not, ever, which is why dynamic QR codes and the plain QR code generator are separate tools on the site.

Flyn is not the only shortener with an MCP server, and not the biggest. Here is the landscape as documented by each vendor on its own live pages. Where a vendor does not state something, the table says so instead of guessing.

Where Flyn is genuinely behind

Being fair here is more useful than a scorecard. Bitly's MCP server is the deepest in the category. Their marketplace page states 27 tools, and the surface goes well past links into groups, organisations, custom domains, bulk CSV upload and data export. If you run link operations across many teams, that organisational tooling is real and Flyn does not match it. Bitly also documents OAuth 2.1 as its recommended path, so OAuth is not a Flyn differentiator against them.

Go2 has a capability Flyn simply does not have. Every link their MCP server mints is stamped with four fields, agent_id, agent_run_id, actor_id and tool_call_id, and every click writes them back, so a click traces to the exact agent run and tool call that created the link. If your question is "which of my agent's runs produced revenue", that is a genuine gap. Their free plan is $0 and lists the MCP server alongside 100 tracked links a month.

Linkly documents 20 tools, including domain management and webhook subscription tools Flyn's MCP surface does not expose (Flyn has webhooks and custom domains, they are just not MCP tools yet). UseClick spans two products in one server, link management plus cookie-free website analytics, so an agent can ask about the link and the site traffic behind it in one session. And Short.io's analytics depth over MCP is strong, covering geography, devices, browsers, referrers, UTM campaigns and time series.

Where Flyn is genuinely ahead

Two things, and neither is a tool count.

First, the free OAuth door. There is no plan check on Flyn's OAuth path: add the URL, a browser window opens, you sign in with the account you already have, and the assistant is connected on a free plan. Of the shorteners, only Go2 and UseClick clearly document free-plan MCP access, and both get you there by issuing an API key you paste into a file. Zapier's free tier technically includes MCP, but every tool call bills 2 tasks against a shared 100-task monthly allowance, roughly 50 calls, and an agent's exploratory calls burn the same budget as real work.

Second, annotations on every tool, the part of the spec most vendors skip and the part that decides whether an agent asks before it deletes something.

Tool count is the vanity metric of the MCP era. What matters is whether the agent can tell a read from a write, and whether connecting cost you a secret in a plaintext file.

This is the whole setup. No package to install, nothing to keep updated.

One command, no key

In your terminal, add the server by URL:

claude mcp add --transport http flyn https://www.flyn.to/mcp

With no Authorization header supplied, the server answers the first request with a 401 carrying an RFC 9728 WWW-Authenticate header pointing at its protected-resource document. Your client reads that, discovers the authorisation server metadata at /.well-known/oauth-authorization-server, registers itself dynamically, and opens a browser window. You sign in, approve access, and the client stores a token. No key was ever typed, pasted or committed.

If you would rather use an API key (which needs Pro, Lifetime or Team), the header form is on the connector page:

claude mcp add --transport http flyn https://www.flyn.to/mcp --header "Authorization: Bearer flyn_sk_live_YOUR_KEY"

What you can then ask, in plain language

Once connected, the tool descriptions do the routing. You do not name tools, you describe outcomes:

• "Shorten this launch page and give me a slug I can say out loud in a video."
• "How many clicks did the launch link get this week, and where from?"
• "Re-point flyn.to/menu to the new autumn menu page."
• "List my links tagged pinterest, sorted by clicks."
• "Give me a printable QR for the menu link, and tell me the current scan count."
• "Create a WiFi QR for the network Cafe Guest with password flatwhite2026."

The last two are worth separating in your head. A QR "for the menu link" routes to get_link_qr_code, which encodes the short link, stays re-pointable, and counts every scan as a click in click analytics. A WiFi QR routes to create_qr_code, which is static and permanent by nature. The tool descriptions carry that distinction so the model does not have to infer it.

The walkthrough above uses Claude Code because it is the shortest path, but the question underneath it is usually "will this work in the assistant I already use?" Answering that needs one distinction that gets lost constantly: a model that can call tools is not the same thing as a client that speaks MCP. Tool calling is a model capability. MCP is a transport the application around the model has to implement. A model scoring well on function-calling benchmarks tells you nothing about whether the app on your desk can reach https://www.flyn.to/mcp.

A second distinction matters just as much. Flyn's server is remote, over streamable HTTP with OAuth. Many clients support MCP only as local stdio subprocesses, which is a different code path entirely. A client needs remote transport support before a hosted server is reachable at all.

Here is where the major clients stand, each row taken from that vendor's own documentation rather than from a directory listing:

Checked against each vendor's own documentation in August 2026. Client support in this space moves fast, so treat the table as a starting point rather than a guarantee, and check your client's current docs before you file a bug against ours.

The Chinese Side Is the Coding Agents, Not the Chat Apps

This part is worth saying plainly, because most English-language MCP writing skips it. The Chinese labs did not put MCP into their consumer chat products. There is no connector menu in the Doubao app or on the DeepSeek web chat the way there is in ChatGPT. What those labs shipped instead is MCP inside their terminal coding agents, and they shipped it fast.

Qwen Code picks its transport from the config key, where httpUrl routes to streamable HTTP, which is exactly the transport Flyn serves. Kimi CLI goes further than several Western clients and has a dedicated command for authorising an OAuth server, opening a browser and caching the token afterwards, the same flow Claude Code uses. DeepSeek Harness ships its own MCP client plugin and mounts one server per instance, stdio for local servers and streamable HTTP for remote ones. Z.ai's ZCode covers all three transports.

The practical upshot: if you work in Chinese-model tooling, link automation is available to you today, but through the CLI rather than through the chat app. The configuration is the same shape as the Claude Code walkthrough above, pointed at the same https://www.flyn.to/mcp endpoint, and the authentication docs apply unchanged. Flyn does not gate the MCP server by client, by region, or by plan, so an account on the free plan reaches the same eight tools from Kimi CLI as it does from Claude Desktop. One practical note: not every client implements an OAuth flow, and some pass static headers only. Flyn accepts either, so where a client cannot do the browser sign-in you authenticate with a Bearer API key against the same endpoint instead.

MCP lets a server attach behavioural hints to each tool. They are advisory, not enforcement, and that is the point: they exist so the client can decide when to ask you first. Flyn sets them on all eight tools. Here is the honest map.

Reading the two marked destructive

delete_link being destructive is obvious. update_link is the more interesting call, and it is deliberate. Re-pointing is not additive: the old destination is gone, and if that link is printed on a thousand table cards or sitting in a scheduled email, an agent that quietly changed it has done real damage. The flag lets a client surface "this will change where flyn.to/menu sends people, continue?" before the call fires.

Why an advisory hint still matters

Nothing forces a client to honour an annotation. But the alternative is worse: with no annotations at all, a client can only distinguish a read from a wipe by parsing the tool name, which is the kind of guessing that produces a bad afternoon. Publishing the hints costs the vendor nothing and gives every client a real signal.

The security story of MCP is mostly a story about where secrets live. An API key in an MCP config is a long-lived credential sitting in plaintext on disk, in a file that is easy to sync, easy to screenshot during a screen share, and easy to commit by accident. It does not expire on its own and it carries the full reach of your account until you remember to revoke it.

What the OAuth flow does differently

Flyn implements OAuth 2.1 with PKCE, S256 only. In practice that means four things:

• You never handle the secret. You type your Flyn password into flyn.to, in a browser, on a page you can inspect. The client receives a token nobody had to tell it.
• The client proves it started the flow. PKCE has the client generate a random verifier, send only its SHA-256 hash up front, and present the original when redeeming the code. An attacker who intercepts the authorisation code cannot exchange it without the verifier. Flyn accepts S256 and nothing else, so the weaker plain method is off the table.
• Registration is dynamic. The client registers itself at the registration endpoint: no per-client setup, no dashboard step, no client ID to copy around.
• Scope is narrow. The server supports a single mcp scope, so a token minted for your assistant is an MCP token, not a general-purpose key to everything you own.

The API key route is still there, and still fine

None of this makes API keys bad. They are the right tool for a server-side script, a cron job or a CI pipeline where no human is present to click Approve, which is what the authentication docs cover. Paid plans can hold up to five keys at once, created and revoked from Settings. The point is narrower than "keys are insecure": for an interactive assistant on your own laptop, a browser sign-in is less to go wrong, and on Flyn it is also the door that does not need a paid plan.

Linkly reached the same conclusion from the other direction. Their hosted server uses OAuth 2.1 with PKCE and their own repo marks the older API-key, self-hosted path as no longer maintained. Two independent vendors landing on the same posture says something about where remote MCP auth is heading.

Connecting an assistant to your link estate is a real permission grant, so be precise about the blast radius.

It can

• Create links, up to your plan's monthly allowance. Free accounts get 25 links a month.
• List, search and read any link owned by your account or workspace.
• Re-point a live link, which is why that tool is flagged destructive.
• Delete a link permanently.
• Read click data. Totals on every plan, breakdowns by country, device and referrer on Pro.
• Render QR codes. Link, text and WiFi codes on every plan; v-card, email, call and SMS codes, custom colours and SVG output on Pro.

It cannot

• Reach anything outside your account or workspace. Every request is authenticated and scoped to the owning account, exactly like the REST API.
• Escape your plan. The token does not upgrade you. Ask for a referrer breakdown on a free plan and you get the totals your plan includes, not a partial answer dressed up as complete.
• Bypass safety scanning. Destinations created through MCP go through the same URL safety checks as anything created in the dashboard.
• Outrun the rate limits. The limits in the rate limits docs apply, so a looping agent gets throttled rather than amplified.

The one number worth watching

Agent traffic is now a measurable share of clicks and it does not behave like human traffic. Read which clicks came from ChatGPT next: the same analytics that tell you a campaign worked will start telling you which assistant sent the visitor. Flyn separates AI-assistant referrals from human clicks rather than lumping them into "direct", and how to track clicks on a link covers the reporting basics.

Discovery is the unsolved half of MCP, and there are two different things people mean by "listed".

The official registry versus a client's directory

The official MCP registry is the vendor-neutral index of servers. Flyn is published there as to.flyn/mcp, pointing at the streamable-HTTP remote at https://www.flyn.to/mcp. Linkly is there too, as com.linklyhq/linkly. Go2 and UseClick are not, which matters if you build tooling that resolves servers by registry name rather than by hand-copied URL.

A client directory is different: one vendor's curated in-product list, like the connectors picker inside a chat app. Flyn is not in the Claude connectors directory yet, and we are not going to pretend otherwise. There you add Flyn as a custom connector with the URL instead. Claude Code, Claude Desktop custom connectors, Cursor, Windsurf, ChatGPT developer mode and Perplexity all work today.

What to wire next

If you have got this far, the useful next moves are small:

1. Connect it. Start on the AI connector page, which has the exact command for each client. No account yet? Sign up free first, the OAuth flow needs one.
2. Give the agent a slug convention and a couple of tags, so list_links returns something readable.
3. Add webhooks if you automate downstream. MCP is pull, webhooks are push, most real workflows want both.
4. Keep a non-agent path for bulk work. A hundred links belong in a CSV, not a chat window: bulk shortening from Google Sheets, or the create-many-links endpoint.
5. Not ready for MCP? The same jobs run through Zapier, and the setup guide walks through it.

MCP is early enough that the comparison above will be stale within a year. What will not change is the shape of the problem: an assistant that can only describe the link you should make is doing half a job, and the fix is a protocol, not a plugin. Browse the rest of the free link tools to see what else is worth handing to an agent.