DexURL

Update a DexURL short link

update_link

DestructiveIdempotent

Change an existing short link: destination, title, status (active or disabled), password (Pro) or rules. Only the fields you send change. An edit changes where the existing short link and its printed QR codes go, and visitors may see the old behaviour for up to a minute. Each nested rules object (availability, redirectNotice, choiceOptions, destinations, routing.rules, routing.windows) is REPLACED as a whole, so call get_link first and send the complete object back with your change. Scalars are set one by one. To remove a rule send null: {"rules":{"maxClicks":null}} removes the click limit, {"rules":{"availability":null}} removes the schedule, {"rules":{"expiresAt":null}} the expiry. {"rules":{"passwordRequired":false}} removes password protection (the password is deleted). A title of "" or null clears the title. The result is the updated link as get_link shows it, plus changed: the fields this request sent.

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": {
      "slug": "<slug>"
    },
    "name": "update_link"
  }
}

Input Schema

Name	Required	Description
`slug`	Yes	The link slug.
`rules`	No	Link rules to change. Fields you leave out stay as they are; null clears a field. availability, redirectNotice, routing, choiceOptions and destinations have the shapes create_link describes, and availability, redirectNotice, choiceOptions, destinations, routing.rules and routing.windows are each REPLACED as a whole when sent.
`title`	No	New title; empty or null clears it.
`status`	No	Pause (disabled) or resume (active).
`password`	No	Set or change the password (Pro).
`destinationUrl`	No	New destination (http or https).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (destructiveHint, idempotentHint, openWorldHint), the description discloses the real-world blast radius: an edit "changes where the existing short link and its printed QR codes go," and visitors may see stale behavior for up to a minute — a propagation delay no annotation conveys. It also spells out partial-update semantics, whole-object replacement for six nested paths, null-based removal, and that clearing the title uses "" or null. This is exactly the extra context the annotations cannot carry.

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 purpose is front-loaded in the first sentence and the paragraphs are ordered by importance: effect, then replacement mechanics, then removal syntax, then return value. It is somewhat long and repeats the nested-replacement rule that also appears in the rules property description, so a sentence of redundancy could be trimmed, but given six parameters and deeply nested rules almost every sentence carries load.

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?

There is no output schema, so the description usefully states the return shape: "the updated link as get_link shows it, plus changed: the fields this request sent." Combined with the coverage of merge semantics, removal syntax, and propagation delay, an agent has everything needed to invoke this destructive mutation correctly on a tool with nested objects.

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

Parameters5/5

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

Schema coverage is 100%, so a 3 would be the floor, but the description goes well past the schema: it explains that omitted fields are preserved, that each nested rules object is replaced wholesale rather than merged, that null removes a rule, and that passwordRequired=false deletes the stored password. Those are merge/removal semantics the JSON Schema cannot express, and they directly determine whether a call is safe.

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?

"Change an existing short link" gives a specific verb and resource, and the enumeration of editable fields (destination, title, status, password, rules) plus the word "existing" separates it from create_link and delete_link without opening any schema. An agent knows immediately this is a partial-update operation on a link that already exists.

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

Usage Guidelines4/5

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

It gives an explicit prerequisite workflow: "call get_link first and send the complete object back with your change," which tells the agent the correct call sequence for nested objects. It also defines the null/false conventions for removal. It stops short of explicitly naming when not to use this tool (e.g. use create_link for new links), so it is a strong 4 rather than a 5.

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

All DexURL 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.