Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This MCP server has critical gaps in definition quality. While 4 tools are registered with basic schemas, the implementation reveals numerous issues: (1) Tool names lack action verbs and are vague (e.g., 'sql_executor', 'api_caller' instead of 'execute_sql', 'call_api'); (2) Descriptions are in Korean and generic, ranging from 10-25 characters, far below the 194-char baseline and below the 20-char floor for scoring; (3) Input schemas present but severely incomplete, parameters lack type constraints, enums, and format documentation; (4) Tool 'code_runner' is marked DESTRUCTIVE but has zero safety controls, confirmation steps, or permission gates; (5) Output schemas entirely undocumented, LLMs cannot predict what these tools return; (6) Error handling absent, no recovery guidance, retryability classification, or validation feedback; (7) Most tools are marked 'currently a stub' in descriptions, indicating unfinished implementation. The codebase shows intent classification and tool input preparation logic, but the actual tool definitions are underdeveloped for production use.
Descriptions are extremely short (10-18 characters) and largely in Korean; multiple tools admit they are 'stubs' (unfinished). HARD FAIL on description floor (< 20 chars → score 0-20).
Tool names lack action verbs and are vague: 'calculator', 'sql_executor', 'api_caller', 'code_runner'. LLMs cannot infer intent from these names alone. Should be verb_noun: 'evaluate_expression', 'execute_sql_query', 'call_http_api', 'execute_code_snippet'.
DESTRUCTIVE tool 'code_runner' with zero safety controls: no permission gates, no confirmation step, no sandboxing hints, no rollback capability. Agents will execute arbitrary code without authorization checks.
code_runner
CRITICAL
Recommendations
Rewrite all tool names to follow verb_noun pattern: 'calculator' → 'evaluate_math_expression'; 'sql_executor' → 'execute_sql_query'; 'api_caller' → 'call_http_api'; 'code_runner' → 'execute_code_snippet'.
Replace all descriptions with English, LLM-optimized text (50 - 200 chars). Example for calculator: 'Evaluates mathematical expressions safely using AST parsing. Supports: +, -, *, /, ^, sqrt, sin, cos, log, sigma. Returns numeric result or error with invalid expression details.'
Add comprehensive input schema constraints: (1) 'expression' param: add regex pattern for allowed operators, max length 500; (2) 'sql' param: add enum of allowed operations (SELECT, INSERT, UPDATE, DELETE) and validation rules; (3) 'api_caller' param: replace 'prompt' with typed params (url, method, headers, body); (4) 'snippet' param: add language restriction, timeout (e.g. 30s), and resource limits.
Document output schemas for all tools. Example calculator output: '{"result": number, "steps": string, "error": string|null}'. Enables LLMs to extract values for downstream tool calls.
Add error handling guidance to descriptions. Example: 'On invalid expression, returns {"error": "Invalid syntax at position X. Valid operators: ..."}. Retryable: yes. Guide user with constraint feedback.'
Implement permission gates for 'sql_executor' and 'code_runner': check calling agent/user has 'execute_sql' or 'execute_code' scope before executing. Return permission denied error with remediation hint.
Add confirmation step for destructive operations: offer dry-run or require explicit 'confirmed=true' param. Example: 'sql_executor' returns affected row count in dry-run mode before commit.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
WRITE tool 'sql_executor' marked as destructive but lacks any safety guardrails: no dry-run support, no permission checks, no validation against SQL injection, no audit logging hints.
Input parameters are severely underspecified: no type constraints, no enums, no format specs, no length limits, no ranges for numeric params. E.g., 'sql' param accepts any string with zero validation guidance.
Output schemas completely undocumented. LLMs have no visibility into what these tools return, cannot plan downstream calls or extract required fields for chaining.
Zero error handling guidance. No retryability classification, no recovery hints, no validation feedback. If a tool fails, the LLM has no direction on next steps.
'api_caller' parameter named 'prompt' is semantically wrong. API invocation should use URL, method, headers, body as separate typed params, not a free-form 'prompt' string.
No tool annotation hints (readOnlyHint, destructiveHint, idempotentHint) in schemas. Risk levels are tracked in metadata but not declared in tool definitions where LLMs can see them.
Descriptions are in Korean; MCP spec and LLM tooling assume English. Non-English descriptions reduce LLM comprehension and break compatibility with English-only agent systems.
calculatorsql_executorapi_callercode_runner
Add tool annotations to schema definitions: use 'destructiveHint: true' for sql_executor and code_runner; 'idempotentHint: true' for calculator (read-only math). Enables LLMs to reason about retry safety.
Create separate output documentation: 'On success, returns: {"output": string, "execution_time_ms": number, "metadata": {...}}. On failure: {"error": string, "code": string, "retryable": boolean, "suggestion": string}'. Make it visible to LLMs in tool descriptions or separate documentation.
For 'code_runner', add sandboxing note: 'Code runs in isolated Python environment with 30s timeout. Preloaded: ast, math, json. Blocked: os.system, subprocess, file I/O. Returns stdout + stderr.'
Remove or complete stub implementations: each tool marked '(현재 스텁)' should either be fully implemented or removed. If stubs are placeholders, use '(placeholder; returns mock data)' and set a development deadline.