Surli MCP

get_short_link

Read-onlyIdempotent

Retrieve info and status about an existing short link.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`surl`	Yes	The short URL or alias identifier (e.g. summer-sale or https://surl.li/abc)

Output Schema

TableJSON Schema

Name	Required	Description
`short_url`	Yes	The short URL that was looked up
`user_message`	No	Human-readable summary of the link status
`dashboard_url`	No	Link to manage this short URL in the Surli dashboard
`destination_url`	Yes	The current destination URL for this short link

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 9, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "dashboard_url": {
+      "description": "Link to manage this short URL in the Surli dashboard",
+      "type": "string"
+    },
+    "destination_url": {
+      "description": "The current destination URL for this short link",
+      "type": "string"
+    },
+    "short_url": {
+      "description": "The short URL that was looked up",
+      "type": "string"
+    },
+    "user_message": {
+      "description": "Human-readable summary of the link status",
+      "type": "string"
+    }
+  },
+  "required": [
+    "short_url",
+    "destination_url"
+  ],
+  "type": "object"
+}

First observedSep 8, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already disclose read-only, idempotent, non-destructive behavior. The description adds the scoping constraint that the short link must exist, but does not describe error behavior or other contexts like permissions. This modest addition earns the baseline 3 while annotations carry most of the burden.

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

Conciseness5/5

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

The description is one front-loaded sentence with no wasted words, precisely identifying the subject, action, and scope. It is ideal for agent scanning.

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 read-only tool with one parameter and an output schema, the description fully covers the success path and scoping. Since the output schema will convey return values, no additional return details are necessary.

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

Parameters3/5

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

The schema fully documents the single 'surl' parameter with examples, and the description adds no semantic layer beyond indicating the link must be existing. With 100% schema coverage, baseline 3 is appropriate.

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 clearly states a specific verb ('Retrieve') with a precise resource ('info and status about an existing short link'). It implicitly differentiates the tool from sibling creation and update tools by emphasizing 'existing.'

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?

The description gives clear context: the tool is for retrieving info about existing short links, which contrasts with the creating/updating siblings via the verb choice. It doesn't explicitly name when not to use it or point to alternatives, but the intended usage is unambiguous.

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

All Surli MCP 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?