Loading ToolBench

Reading the current corpus…

short-url MCP server · D · ToolBench

← Browse

short-url

github.com/fengzhongsen/short-url

MCP Server for Short URL service integration with AI assistants

2026-07-28+STDIO1 tools

56/100

Definition Quality58

Protocol Readiness50

SupportabilityNot measured-

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence

Current-spec patterns detected

Summary

Single tool with acceptable schema but weak naming and minimal description. Tool name 'shorten_url' uses verb_noun convention but lacks clarity about the resource being modified. Description is 105 characters, within the 10-1024 range, but lacks guidance on when/why to use the tool and what happens on error. Parameter 'url' is properly typed and has a description (68 chars) meeting the baseline. No output schema documented, LLM cannot introspect the response structure (short code, full URL). Error handling returns isError flag and text responses, but lacks actionable recovery guidance. No tool annotations (readOnlyHint/destructiveHint/idempotentHint) present. Single tool limits composition assessment.

Tools (1)

shorten_urlwriteauthsource verified58/100

将长链接转换为短链接。当用户想要缩短 URL 时使用此工具。

Issues (6)

HIGHtool-chain, response-shaper ↗

No output schema documented. LLM cannot predict response structure (fields like 'code', 'url', 'short_url'). Breaks pattern:tool-chain if downstream tools need output fields.

shorten_url

HIGHtool-description, command-tool ↗

Tool description (105 chars) lacks WHEN/WHY guidance and does not document side effects (irreversible URL shortening). LLMs cannot assess whether this is safe to retry.

shorten_url

HIGHrecovery-guide, error-classification ↗

Error responses lack recovery guidance. Returns 'Error: <message>' but does not tell LLM whether to retry, ask user, or abort. No error classification (retryable vs fatal).

shorten_url

MEDIUMtool-gateway ↗

No input validation documented. Parameter 'url' description states 'must start with http:// or https://' but code does not validate this, client-side validation only. Validation must occur server-side to prevent injection.

shorten_url

Recommendations

Document the output schema explicitly. Specify that response.data contains { code, url, short_url? } and example return structure: '{ "content": [{ "type": "text", "text": "短链接: http://localhost:3001/abc123\n原始链接: https://example.com/very/long/url" }] }'
Expand tool description to 150-200 chars: 'Converts a long HTTP/HTTPS URL into a short alias for easy sharing. Idempotent: calling with the same URL returns the same short code. Use when user requests URL shortening, QR code generation, or link analytics.' This signals idempotence and use case.
Implement and document input validation: if url does not match /^https?:// pattern, return structured error: '{ "content": [{ "type": "text", "text": "Invalid URL format. Must start with http:// or https://. Got: \"' + url + '\"" }], "isError": true }'
Add error classification in responses. Instead of generic error, return: 'Network error contacting API. This is retryable. Try again in a moment.' for network failures; 'Invalid URL format' for user-fixable; 'API key expired' for fatal.
Add tool annotation when registering tool: include 'idempotentHint: true' in the tool definition (if the backend guarantees same URL → same code) to signal to LLM that retries are safe.
Document response structure in README: 'Returns { content: [{ type: "text", text: "Short link: <url> | Original: <original>" }] } on success, or { content: [...], isError: true } on failure.'

Score history

Overall score trend

↑ 19 points across a rubric change (v1 → v2)

56/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-22	D	56	2026-07-28+	v2
2026-03-09	F	37	-	v1