Create and manage short links from ChatGPT, Claude, Cursor and other MCP-compatible AI tools using Surli. Supports OAuth authentication, custom aliases, destination updates, password protection, bulk shortening and link management.
Scored across 5 tools
Each tool targets a distinct resource or action: creation, retrieval, account limits, and two separate update operations for alias and destination. No overlap or ambiguity between tools.
All tool names follow a consistent verb_noun pattern with lowercase and underscores (create_short_link, get_account_limits, get_short_link, update_alias, update_destination). The pattern is uniform and predictable.
Five tools is well-scoped for a URL shortener service, covering the core operations without bloat. Each tool earns its place and the set feels appropriately sized.
The set covers create, read, and update operations, but lacks a delete or list tool. For a short-link lifecycle, deletion (and possibly listing all links) is a notable gap that agents may need to work around.
Shorten a destination URL via Surli and return short link and stats.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | Optional custom slug/alias for the short URL | |
| title | No | Optional display title or tag for the link | |
| destination_url | Yes | The full target destination URL to shorten (e.g. https://example.com) |
| Name | Required | Description |
|---|---|---|
| plan | No | Current account tariff plan (e.g. limited, unlimited) |
| used | No | Number of short links used in the current plan period |
| limit | No | Total short link quota for the plan period (-1 = unlimited) |
| remaining | No | Number of short links remaining (-1 = unlimited) |
| short_url | Yes | The newly created short URL |
| user_message | No | Human-readable status message |
| dashboard_url | No | Link to manage this short URL in the Surli dashboard |
| destination_url | Yes | The destination URL the short link points to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the creation behavior is implied. The description adds that the operation goes through Surli and returns 'short link and stats,' which is useful, but it does not disclose potential side effects, alias availability constraints, or external-service limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no wasted words, and the main purpose and return value are both included. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with a full input schema, optional parameters, and an output schema, the description covers the essential purpose and return behavior. It is not an exhaustive explanation, but the missing details are already available in structured fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters, so the schema carries the semantic load. The description does not add any significant parameter-level meaning, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Shorten a destination URL') and the resource ('via Surli'), and implies a creation operation rather than retrieval or update. It does not explicitly name its sibling tools, but the verb and resource are specific enough to avoid confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance about when to use this tool instead of get_short_link, update_alias, or update_destination. The operation is inferable, but no context or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check current user tariff plan and available short link limits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| plan | Yes | Current account tariff plan (e.g. limited, unlimited) |
| used | Yes | Number of short links used in the current plan period |
| limit | Yes | Total short link quota for the plan period (-1 = unlimited) |
| alias_max | No | Maximum custom alias updates allowed (0 if not supported by plan) |
| remaining | Yes | Number of short links remaining (-1 = unlimited) |
| upgrade_url | No | URL to upgrade the tariff plan |
| user_message | No | Human-readable summary of plan usage |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds specific details about what is checked (tariff plan and short link limits), which enriches the behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It states the verb first and the precise resources, making it directly actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an existing output schema, no parameters, and a clear description of what is checked, the tool is complete. An agent can correctly invoke it without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is trivially 100%. The baseline for 0-parameter tools is 4. The description adds no parameter info (none needed) and remains sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and clearly identifies the resources ('current user tariff plan' and 'available short link limits'). This distinguishes it from siblings like create_short_link or update_alias, which are action-oriented. An agent can immediately understand the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a query for checking limits but does not explicitly state when to use it versus alternatives. It does not mention exclusions or recommend using it before link creation. While context suggests it, explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve info and status about an existing short link.
| Name | Required | Description | Default |
|---|---|---|---|
| surl | Yes | The short URL or alias identifier (e.g. summer-sale or https://surl.li/abc) |
| 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 |
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.
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.
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.
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.
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.
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.
Update the custom alias of an existing short link (requires supported plan).
| Name | Required | Description | Default |
|---|---|---|---|
| surl | Yes | The current short URL or alias | |
| new_alias | Yes | The desired new custom alias |
| Name | Required | Description |
|---|---|---|
| short_url | Yes | The short URL reflecting the new alias |
| user_message | Yes | Human-readable confirmation or error message |
| dashboard_url | No | Link to manage this short URL in the Surli dashboard |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey the destructive, non-read-only, idempotent nature of the operation, so the description need not repeat that. It adds the 'requires supported plan' plan-gating constraint, but does not go further into side effects such as the old alias becoming invalid or possible uniqueness conflicts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no filler; the key action and the plan requirement are both front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with full schema coverage, an output schema, and useful annotations, the description is nearly complete. It includes the plan prerequisite and existing-link scope; only a brief note about the fate of the old alias or uniqueness constraints would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully documented in the input schema (100% coverage), so the baseline of 3 applies. The description adds only that the alias belongs to an existing short link, which is a modest elaboration over the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Update'), a precise target ('custom alias of an existing short link'), and a constraint ('requires supported plan'). It is easy to distinguish from siblings like update_destination, which targets the destination URL rather than the alias.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: the operation applies to an existing short link and requires a supported plan, which implies it is not for creating a link and not available on all plans. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the target destination URL of an existing short link.
| Name | Required | Description | Default |
|---|---|---|---|
| surl | Yes | The short URL or alias to update | |
| new_destination_url | Yes | The new destination URL |
| Name | Required | Description |
|---|---|---|
| short_url | Yes | The short URL that was updated |
| user_message | No | Human-readable confirmation message |
| dashboard_url | No | Link to manage this short URL in the Surli dashboard |
| destination_url | Yes | The newly set destination URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation is write-capable (readOnlyHint false), destructive (destructiveHint true), and idempotent (idempotentHint true). The description adds that it targets an existing short link, clarifying it modifies rather than creates or deletes the link itself, but it does not go beyond that to describe side effects or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the action and target, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With fully described parameters, annotations covering safety, and an output schema present, the description is adequate for an agent to invoke the tool correctly. The only notable gap is the lack of explicit guidance on choosing this tool over update_alias, which is more a usage guideline nuance than a missing critical detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters ('surl' and 'new_destination_url') are clearly explained in the schema. The description adds no additional meaning beyond restating the operation, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise verb ('update') and resource ('target destination URL of an existing short link'), making the operation unambiguous. It implicitly distinguishes itself from the sibling 'update_alias' by referencing the destination URL rather than the alias.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool—when the destination URL of an existing short link needs to be changed. However, it does not explicitly mention alternatives or explain when not to use it (e.g., when updating the alias instead), leaving the distinction from update_alias to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_short_link1 field 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 destination URL the short link points to",
+ "type": "string"
+ },
+ "limit": {
+ "description": "Total short link quota for the plan period (-1 = unlimited)",
+ "type": "integer"
+ },
+ "plan": {
+ "description": "Current account tariff plan (e.g. limited, unlimited)",
+ "type": "string"
+ },
+ "remaining": {
+ "description": "Number of short links remaining (-1 = unlimited)",
+ "type": "integer"
+ },
+ "short_url": {
+ "description": "The newly created short URL",
+ "type": "string"
+ },
+ "used": {
+ "description": "Number of short links used in the current plan period",
+ "type": "integer"
+ },
+ "user_message": {
+ "description": "Human-readable status message",
+ "type": "string"
+ }
+ },
+ "required": [
+ "short_url",
+ "destination_url"
+ ],
+ "type": "object"
+}get_account_limits1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "alias_max": {
+ "description": "Maximum custom alias updates allowed (0 if not supported by plan)",
+ "type": "integer"
+ },
+ "limit": {
+ "description": "Total short link quota for the plan period (-1 = unlimited)",
+ "type": "integer"
+ },
+ "plan": {
+ "description": "Current account tariff plan (e.g. limited, unlimited)",
+ "type": "string"
+ },
+ "remaining": {
+ "description": "Number of short links remaining (-1 = unlimited)",
+ "type": "integer"
+ },
+ "upgrade_url": {
+ "description": "URL to upgrade the tariff plan",
+ "type": "string"
+ },
+ "used": {
+ "description": "Number of short links used in the current plan period",
+ "type": "integer"
+ },
+ "user_message": {
+ "description": "Human-readable summary of plan usage",
+ "type": "string"
+ }
+ },
+ "required": [
+ "plan",
+ "limit",
+ "used",
+ "remaining"
+ ],
+ "type": "object"
+}get_short_link1 field 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"
+}update_alias1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "dashboard_url": {
+ "description": "Link to manage this short URL in the Surli dashboard",
+ "type": "string"
+ },
+ "short_url": {
+ "description": "The short URL reflecting the new alias",
+ "type": "string"
+ },
+ "user_message": {
+ "description": "Human-readable confirmation or error message",
+ "type": "string"
+ }
+ },
+ "required": [
+ "short_url",
+ "user_message"
+ ],
+ "type": "object"
+}update_destination1 field 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 newly set destination URL",
+ "type": "string"
+ },
+ "short_url": {
+ "description": "The short URL that was updated",
+ "type": "string"
+ },
+ "user_message": {
+ "description": "Human-readable confirmation message",
+ "type": "string"
+ }
+ },
+ "required": [
+ "short_url",
+ "destination_url"
+ ],
+ "type": "object"
+}create_short_linkget_account_limitsget_short_linkupdate_aliasupdate_destination
Add one secure layer between your agents and this server.