Loading ToolBench
MCP server for ShortlyAI microservices architecture providing tools for URL shortening, analytics, and AI-powered operations
Server exposes 7 tools with basic schemas and descriptions, but significant gaps limit production readiness. Tool naming is inconsistent (getUrlStats vs get-url-stats; getTopUrls vs get-top-urls), creating confusion for LLM selection. Descriptions exist but are generic (10-150 chars, below the 50-200 char baseline for LLM optimization). Parameters lack depth: no enums for constrained inputs, no min/max bounds on numeric params, no format specifications. Output schemas are not documented. Error handling is minimal, no recovery guidance or actionable error messages. The deleteUrl tool includes a confirmation pattern (good), but lacks structured error responses if confirmation fails. Overall, definitions are skeletal rather than LLM-optimized.
Delete a shortened URL by its slug. This is permanent and cannot be undone. You MUST ask the user to explicitly confirm before calling this with confirmDeletion=true. Never call this with confirmDeletion=true unless the user's most recent message explicitly confirms the deletion.
Returns the user's best-performing shortened URLs, ranked by total click count, highest first. Use this for "what's my most popular/top link" type requests, or when the user wants an overview rather than one specific URL. Each result includes the slug, original URL, shortened URL and click count - no follow-up call needed for basic info.
Returns the total click count for a shortened URL by its slug. Use this for quick click-count checks. If you also need the original destination URL, call get_url_details instead - it returns both in one call, making a separate get_url_stats call unnecessary in that case.
Get the top performing URLs by click count for the current user
Get details of a shortened URL by its slug
Inconsistent tool naming: getUrlStats/getTopUrls (camelCase) vs get-url-stats/get-top-urls (kebab-case). LLMs struggle to select between similarly-named tools; this duplication wastes reasoning cycles and invites wrong tool selection.
No output schemas documented. LLMs cannot plan downstream calls or extract required fields (e.g., does getUrlStats return click_count or clicks? Is it an integer or string?). Breaks tool chaining.
Numeric parameters (limit, urlId) lack bounds. No min/max specified. LLMs may pass limit=999999 or negative urlId, causing API errors or timeouts. Baseline: 100% of A+ tools specify numeric ranges.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2025-06-18+ | v2 |
Get click analytics for a shortened URL by its urlId
Shorten a long URL and return the generated short URL
Descriptions are generic and brief (10-150 chars vs 50-200 char baseline). E.g., 'Get click analytics for a shortened URL by its urlId' lacks WHEN to use it, what it returns, or how it differs from get-url-stats. LLMs cannot disambiguate.
No error handling guidance. If deleteUrl fails (e.g., URL already deleted, permission denied), LLM receives no recovery hint. Baseline: 100% of A+ tools include actionable error messages.