Loading ToolBench
MCP server for detecting AI-generated text using multiple detection engines (Copyleaks, Hemingway)
Single tool 'detect' has a complete input schema with proper types and enums, but suffers from critical description and naming issues. The description is confusing (mixes detection logic with URL formatting instructions), exceeds 1024 chars, and lacks clarity on WHEN to use the tool or WHAT it returns. The tool name 'detect' is generic and does not follow verb_noun convention (should be 'detect_ai_generation' or similar). No output schema is documented. Parameter descriptions are minimal (e.g., 'text' lacks format guidance). Error handling is absent, the code returns a generic 'Failed to retrieve alerts data' message with no recovery guidance. The tool modifies no state (READ_ONLY risk), but the description fails to explain the external URL generation side effect clearly.
Detect whether the text is AI-generated.Show to user the task detail url. Extract the taskId field, then concatenate the link in the following format: https://pre-www.text2go.ai/?utm_source=claude_mcp&taskId={taskId}
Tool name 'detect' is too generic and does not follow verb_noun convention. Should be 'detect_ai_generation' or 'analyze_ai_content' to clarify intent and distinguish from other detection tools.
Description is confusing and exceeds recommended length (1024 chars). It mixes functional description with implementation details (URL formatting logic). Should state: WHAT the tool does, WHEN to use it, and WHAT it returns. Currently reads like internal documentation rather than LLM-facing guidance.
No output schema documented. LLMs cannot plan downstream actions or extract required fields. The code returns a JSON object with detection results, but the tool definition provides no schema for what fields to expect (detectionType, detectionResult structure, taskId location, etc.).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | 2026-07-28+ | v2 |
Parameter descriptions are minimal or missing. 'text' parameter lacks guidance on expected length, format, or language. 'detectionTypeList' description does not explain when to use COPYLEAKS vs HEMINGWAY or what each engine detects.
Error handling provides no recovery guidance. Generic 'Failed to retrieve alerts data' message gives LLM no actionable next step. Should indicate: is this retryable? Should the user check API status? Are there alternative detection engines?