The Bridge

Create Short Link

create_short_link

Make a tracking short link (e.g. https://thebridge.dev/tt/code8) to put in a social post or video description. A click is counted (no cookie, no IP) and forwarded to the destination with utm tags (utm_source = platform, utm_medium, utm_content = format, utm_campaign = label) and ref=. Arguments: destination (required; the https page the link opens), source (where the link will be posted: the post or channel URL, a platform name such as "TikTok", or free text such as "an Instagram reel"; the platform and format are detected from it), label (the content's name, e.g. "passkeys video"). Use the SAME label for the same content on another channel: the link then shares the content's code (thebridge.dev/yt/code8 and /tt/code8). If the user did not say where the link will be posted, ask them before calling; without a source the link is filed as "other" (thebridge.dev/go/…). Returns the short link, its code, and the detected platform and format. The link works at once. list_short_links shows the workspace's links with click counts.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "destination": "<destination>"
    },
    "name": "create_short_link"
  }
}

Input Schema

Name	Required	Description
`label`	No	Name of the content, e.g. "passkeys video". The same label on another channel reuses the code.
`source`	No	Where the link will be posted: the post or channel URL (https://www.tiktok.com/@devjoy/video/123), a platform name ("YouTube Shorts"), or free text. Omit only when unknown.
`destination`	Yes	The https page the link opens, e.g. "https://thebridge.dev/pricing". Only https is accepted.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses that destination URLs get utm_* and ref= parameters appended, that clicks are counted without cookies or IPs, that the link is live immediately, and that reusing a label across channels shares the same code. These are non-obvious side effects the annotations (readOnlyHint=false, idempotentHint=false) do not convey.

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?

Front-loaded with purpose and example, and nearly every clause carries useful information (detection rules, code reuse, the ask-first rule). It is dense, though: long compound sentences with stacked parentheticals make it slower to parse than it needs to be.

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

Completeness5/5

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

Though there is no output schema, the description states what is returned (the short link, its code, the detected platform and format) and covers the edge case where no source is given. An agent has everything needed to call this correctly without follow-up.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: `source` accepts a URL, a platform name, or free text and the platform/format are detected from it, and `label` is the key that drives code sharing across channels. It does not add much on `destination` beyond the schema's https-only note.

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?

Opens with a specific verb+resource ("Make a tracking short link") and an example URL showing the resulting shape, so the agent knows exactly what artifact is produced. It also distinguishes itself from the sibling `list_short_links` by framing that tool as the read/view counterpart.

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?

Gives an explicit precondition ("If the user did not say where the link will be posted, ask them before calling") plus the fallback behavior if they don't, and names `list_short_links` as the alternative for viewing click counts. When-to-use, when-to-ask, and alternative are all present.

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

All The Bridge tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.