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 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. Every request carries the same header as the API:
Mint the token on the console’s Tokens page with the permissions the assistant should have, as described in Authentication & tokens. The token fixes the workspace; no tool takes a workspace, organization or user argument, and nothing an assistant says can move a call to another one.

​
Connecting a client

One command, run in any terminal:
Then /mcp in a session lists the server and the tools your token permits. To keep the token out of the command line, put it in an environment variable and reference it from .mcp.json as "Authorization": "Bearer ${UTMKIT_TOKEN}".
Any other MCP client that speaks Streamable HTTP and can send a header works the same way.

​
The tools

Nineteen tools, each behind exactly one token permission. 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

  • Every write is attributed to you and to the token, 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 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 with a token.