Loading ToolBench
A Model Context Protocol server for Surge operations
The Surge MCP server has severe definition quality gaps. Both tools have minimal descriptions (Chinese language, 16-23 chars each, below the 20-char soft minimum), no documented output schemas, missing parameter descriptions, and no error handling guidance. Tool names lack clarity on what 'surge' means without domain knowledge. Input schemas are present but sparse. The codebase shows complex logic (CLI wrapping, dependency installation, expect-based automation) but this is not reflected in the tool definitions, which are dangerously underspecified for an LLM trying to invoke them. This is a classic case where implementation complexity is hidden from the agent.
部署项目到 Surge.sh（生成随机域名）
登录到 Surge.sh 账户
Tool descriptions are critically short (16-23 chars, all in Chinese) and lack WHAT, WHEN, and WHY context. '登录到 Surge.sh 账户' and '部署项目到 Surge.sh（生成随机域名）' provide minimal actionable context for LLM tool selection.
No output schema documented for either tool. Callers cannot know what fields surge_login returns (session token? domain?) or what surge_deploy returns (deployment URL? status?). This forces the LLM to guess and breaks tool chaining.
Credentials (email, password) exposed as tool parameters. Per pattern:secret-injection, credentials must never appear in tool signatures, they are logged, traced, and visible to LLMs. Use server-side secret injection via environment variables or a vault.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 32 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter descriptions are absent. 'email' and 'password' in surge_login have minimal descriptions; 'directory' in surge_deploy has no format guidance (absolute path? relative? must exist?). Per pattern:tool-description, every parameter must have a non-empty description explaining what it controls.
No error handling guidance. The code shows complex failure scenarios (CLI not installed, expect not installed, authentication failures, spawn errors) but the tool definitions provide no recovery hints. Per pattern:recovery-guide, errors must tell the LLM what to do next.
Tool names 'surge_login' and 'surge_deploy' are not self-documenting outside Surge.sh domain context. An LLM unfamiliar with Surge.sh may conflate 'deploy' with other hosting platforms. Descriptions should clarify 'Surge.sh is a static hosting service' and disambiguate from alternatives (Vercel, Netlify, etc.).
No input validation or constraint documentation. 'directory' parameter has no validation that the path exists, is readable, or contains deployable content. 'email' and 'password' lack format constraints or fallback guidance if authentication fails.
No idempotency or duplicate-prevention guidance. surge_deploy with a random domain name suggests it generates a new deployment each time, but the tool definition does not clarify what happens if called twice with the same directory, will it fail, return the same URL, or create a duplicate?