Skip to main content
Glama

Split (creator affiliate platform)

Monetize URL

split_monetize_url

Turn a product URL into a TRACKED destination URL — the URL a checkout runner or headless browser must open so the purchase is credited to this creator, without relying on a redirect. Finds the creator's existing link for the URL — among links carrying ALL the given tags, when tags are supplied — or creates one, then registers a click on the creator's behalf and returns the URL the SplitLink would have redirected to, with the click id embedded. tracked_url is the key output: hand it to whatever completes the purchase, unchanged. requires_redirect true means the merchant is on an affiliate network and tracked_url is the network's one-hop redirector (must be followed to reach the store, cookies kept); false means it is the store URL itself with Split's parameter attached. By default the click is the creator's own (as when they open their shop-it link); shop_it_url monetizes ANOTHER creator's link with this account as the shopper (prefer split_click_link for any SplitLink you RECEIVED); clicker: anonymous registers it as an unknown shopper instead, optionally carrying your own shopper id, so a provider can attribute per end user without that user having a Split account. Each call registers a click (repeat calls within 24h for the same link and clicker count as a re-click), so call it per purchase intent, not per impression. To segment by an end user or channel, pass a tag per segment (e.g. ["shopstack", "u-8f3a2c"]): the link is reused per (URL, tag set), and split_link_performance filtered by that tag reports that segment's clicks and earnings. Use split_get_share_url instead when the creator is posting a link for people to click.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoThe product or brand URL to monetize (required unless uuid or shop_it_url is given)
tagsNoScopes the lookup (a link must carry every tag to be reused) and is applied to a newly created link. Lowercase a-z, 0-9, - and _, starting with a letter or digit
uuidNoAn existing link's uuid, to skip the URL lookup
clickerNoWho the click is attributed to. creator (default): the signed-in creator, as when they open their own shop-it link. anonymous: an unknown shopper, as when someone not signed in to Split clicks the SplitLink — the creator earns the whole commission and no buyer share is split off
new_linkNoAlways create a fresh link instead of reusing one for the same URL and tags
target_urlNoWith shop_it_url: the product url from the same click-history row, used only to work out requires_redirect
shop_it_urlNoANOTHER creator's link, as the shop_it_url from split_click_history: the tracked URL is minted with THIS account as the shopper, so that creator earns the commission and this account receives the buyer share. No link is created or looked up. Mutually exclusive with url/uuid/clicker
anonymous_idNoWith clicker: anonymous, a stable id for the shopper from YOUR system (8-64 letters or digits, no punctuation). Its LAST 11 characters are stamped into the click id and therefore onto any commission, so make that tail unique per shopper. Omit to get a random one

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate the tool is not read-only (creates clicks and possibly links), not idempotent (each call registers a click), and not destructive. The description adds crucial behavioral context: it registers a click on every call, with repeat calls within 24h counting as re-clicks, and explains the meaning of `requires_redirect` for following redirects and cookie handling. It does not disclose failure modes or rate limits, but given annotations cover safety, a 4 is warranted for the substantial added context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but information-dense, with the core purpose and output front-loaded in the first sentence. Every sentence adds critical operational detail (redirect behavior, click attribution, tag segmentation, exclusions for alternatives). It could be tightened but is well-organized, and the length is justified by the tool's complexity; the key action and output are immediately clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter tool with no output schema and no required parameters, the description compensates well by explaining the return value ('tracked_url is the key output') and how to use it, as well as the requires_redirect flag. It covers mutual exclusions and varying use cases (creator, anonymous, shop_it_url) thoroughly. It lacks explicit examples or edge-case error handling, but given the output field is described, this is nearly complete for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already has 100% coverage with detailed descriptions for each of the 8 parameters, including mutual exclusivity hints (e.g., 'Mutually exclusive with url/uuid/clicker' for shop_it_url). The description adds value by clarifying how tags affect link reuse, how anonymous_id's tail is stamped into the click id, and how target_url is used only for requires_redirect. While the schema covers each parameter, the description deepens understanding of their interplay, so a 4 is appropriate rather than a baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb ('Turn a product URL into a TRACKED destination URL') and clearly states the resource and the primary output ('tracked_url is the key output'). It frames the purpose as both a lookup-or-create action and a click registration, making the tool's job unmistakable. It also differentiates itself from siblings by explicitly naming split_click_link and split_get_share_url and stating when to use those instead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit conditions: use split_get_share_url when the creator is posting a link for people to click, prefer split_click_link for any SplitLink you RECEIVED, and call split_monetize_url per purchase intent rather than per impression. It also explains the 24-hour re-click behavior and the distinction between creator, anonymous, and shop_it_url flows, leaving no ambiguity about when to invoke this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources