QRStuff MCP Server

Update short link

update_short_link

DestructiveIdempotent

Use this when the user wants to change a short link: its destination, ending, on or off state, password, schedule, click limit or tracking options. Overwrites the previous settings, and changing the destination changes where the live link goes. Some options are rejected if the account doesn't include them. Needs the ID from list_short_links.

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": {
      "idshorturl": "<idshorturl>",
      "settings": "<settings>"
    },
    "name": "update_short_link"
  }
}

Input Schema

Name	Required	Description	Default
`settings`	Yes	The short link settings to save, such as destination URL, slug, status, password, schedule or click limit. Send the current value from `get_short_link` unless you are changing it.
`idshorturl`	Yes	Short link ID from `list_short_links`. Never guess an ID.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 30, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the description earns credit for going further: it concretely explains that the call overwrites previous settings and that changing the destination alters where the live link points. It also discloses an account-tier gating rule ('some options are rejected if the account doesn't include them'), which no annotation conveys.

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?

Four short, front-loaded clauses with no filler: trigger first, then destructive behavior, then constraints, then prerequisite. The enumeration of settings is long but each item carries distinct meaning.

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?

For a 2-parameter mutation tool with full schema coverage, annotations declaring destructive/idempotent/openWorld, and an output schema, the description supplies everything extra needed: trigger, overwrite semantics, live-link consequence, entitlement restrictions, and ID provenance.

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 baseline is 3, but the description adds real value for the opaque free-form `settings` object by enumerating the concrete option families (destination, ending, state, password, schedule, click limit, tracking) that the schema leaves as `additionalProperties: true`. It also reinforces the ID prerequisite ('Needs the ID from `list_short_links`').

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?

States a specific verb ('change a short link') plus the exact set of mutable fields — destination, ending, on/off state, password, schedule, click limit, tracking options. It is unmistakably distinct from create_short_link, get_short_link and update_qr_code, which are the closest siblings.

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?

"Use this when the user wants to change a short link" gives a clear trigger, and "Needs the ID from `list_short_links`" names the prerequisite call. It does not explicitly rule out alternatives (e.g. pointing to get_short_link for reads), but the trigger condition is unambiguous.

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

All QRStuff MCP Server 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.

Resources

Need Help?