Skip to main content
There are two MCP servers you will meet around UTMKit, and they do different jobs. https://docs.utmkit.co/mcp belongs to this documentation site: it searches and reads these pages, and nothing else — point an assistant at it to ask how the product works. https://app.utmkit.co/mcp belongs to the product: it operates your workspace — lists, creates, edits and withdraws links, manages campaigns and rules, reads the report — and it needs you to sign in or a token. Same protocol, same path, two hosts. This page is about the second one.

What it is

An MCP (Model Context Protocol) server, spoken over the protocol’s Streamable HTTP transport, inside the product itself. Every tool calls the same operation the console and the API call, so the workspace’s rules apply unchanged: a link the convention would refuse in the console is refused here, with the same sentence, as a tool result your assistant can read and relay or repair. There are two ways in, and they reach the same tools under the same rules:
  • Sign in (OAuth). claude.ai, Claude Desktop’s connectors, the Claude mobile app and Claude Code connect by sending you to a UTMKit page where you choose the workspace and tick the permissions. No token to copy. The connection then appears under Connected applications on the Tokens page, where you or a workspace admin can disconnect it.
  • A token. Mint one on the console’s Tokens page with the permissions the assistant should have, as described in Authentication & tokens, and send it on every request:
Either way, the workspace is fixed when you connect; no tool takes a workspace, organization or user argument, and nothing an assistant says can move a call to another one.

Connecting a client

  1. In Claude, open Customize → Connectors, choose Add → Add custom connector, name it UTMKit and paste https://app.utmkit.co/mcp as the URL.
  2. Press Connect. A UTMKit page opens; sign in if you are not already.
  3. The page shows that the request comes from Claude (marked Verified), the workspace it will act in, and the permissions it asks for. Pick the workspace, untick anything it should not do, and press Allow.
The connection works on claude.ai, Claude Desktop and the Claude mobile app alike. It stays connected while it is used at least once every 30 days; disconnect it at any time from the Tokens page. On a Team or Enterprise plan, an owner adds the connector for the organization and each member connects with their own UTMKit account.
Any other MCP client that speaks Streamable HTTP works the same way: by sending a header, or by following the MCP authorization specification to sign in.

The tools

Thirty-one tools, each behind exactly one permission. Every tool also tells your client what kind of action it is — a title, and whether it only reads or whether it changes or removes something — which is what lets an assistant ask before acting. Reads need only the permission; writes also need your role in the workspace to allow them, checked live on every call. Every tool under rules:write also needs an admin or owner role. A tool the token lacks is hidden, and refused by name if called anyway. The tool list a client receives is filtered to what the token’s permissions and your role allow, and it is recomputed on every list request. A hidden tool is still there: an assistant that calls create_campaign with a links-only token gets a tool result that says This token does not carry campaigns:write. rather than “unknown tool”, so it can tell you exactly which box to tick on the next token. There is no conversions tool. A conversion is a result your server reports against a link — a sale, a sign-up — and a server does that through the API with the conversions:write permission, not through an assistant. See Conversions.

What to expect

  • A new or edited link is pending for a few seconds, while it reaches the edge; get_link then shows it live. A link deleted with withdraw_link is gone; a link UTMKit blocked for abuse reads blocked (the state:blocked filter of list_links finds those).
  • With more than one link domain, say which one. A workspace with its own branded domains asks for domain on create_link rather than picking a brand for you.
  • Every write is attributed to you and to the token or connection, and appears in the activity log like a change made in the console.
  • Refusals are tool results, flagged as errors, one sentence each: the convention’s refusal, an unapproved value, a destination the scanner rejected, an allowance used up. A protocol error, by contrast, means the client spoke wrongly.
  • The door is the API’s door. A revoked or expired token, or a disconnected application, fails the connection with 401; an organization with no live subscription with 402; the per-token rate limit applies, with Retry-After. No session outlives its token.
  • Demotion takes effect on the next call. If your role changes, the write tools disappear from the list on the next tool listing, and a call made before that is refused for the role.

The other server, once more

If your assistant answers a request to create a link with a search result, it is talking to docs.utmkit.co/mcp, the documentation’s server. Reconnect it to app.utmkit.co/mcp, by signing in or with a token.