Loading ToolBench
This MCP server has 6 tools with significant inconsistencies in quality. All tools have descriptions (good), and 4 out of 6 have input schemas defined via Zod (adequate). However, output schemas are completely undocumented, responses are JSON strings with no formal schema declarations. Naming is mostly clear (verb-noun pattern), but parameter descriptions vary in quality. Error handling returns plain text without recovery guidance. The database query tool lacks input validation details despite security implications. API schema tools have vague section parameters. Overall, this is a serviceable but unpolished server that would benefit from output schema documentation and stronger error messaging.
네이버 커머스 API 스키마 상세 정보를 조회합니다. 특정 필드의 가능한 값이나 의미를 정확히 알아야 할 때 사용하세요.
네이버 커머스 API 스키마 요약을 조회합니다. 주문 데이터의 필드 의미를 빠르게 확인할 때 사용하세요.
특정 필드나 상태 코드의 의미를 조회합니다. 예: productOrderStatus가 PAYED면 무슨 뜻인지, CJGLS가 어떤 택배사인지
테이블의 컬럼 구조를 확인합니다. 11번가는 바코드, 물류온은 상품코드 컬럼이 어디인지 확인하세요.
DB의 모든 테이블 목록을 조회합니다.
SQL 조회를 실행합니다. JOIN 쿼리를 통해 매핑된 데이터를 가져올 때 사용하세요.
No output schemas documented. All tools return text/JSON responses, but no formal response schema is declared. LLMs cannot reliably parse the response structure or plan downstream tool calls. This violates the pattern:tool requirement that 'tools returning lists should declare schema and include pagination metadata.'
Error messages lack recovery guidance. When a tool fails, responses return bare error text (e.g., 'SQL 에러: <message>') without telling the LLM what to do next. Per pattern:recovery-guide, errors must guide the agent: 'User not found. Try search_users() with a partial name.' This server provides no such hints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
run_select_query lacks input validation documentation. The tool accepts arbitrary SQL strings and performs basic regex checks for SELECT/WITH and malicious keywords, but the schema does not document: (1) maximum query length, (2) timeout behavior, (3) which database roles are available, (4) result size limits. Per pattern:constrained-input and review:param-validation-rules, parameter descriptions must include format, range, and constraints.
get_field_description parameter lacks specificity. The 'field_name' parameter description lists examples (productOrderStatus, PAYED, CANCEL_REQUEST, CJGLS) but does not declare an enum or pattern constraint. Per pattern:constrained-input, free-form strings invite hallucinated values. Should define allowed field names as an enum or pattern.
get_api_schema_detail 'section' enum is unclear. The enum values ('order', 'productOrder', 'shippingAddress', 'delivery', 'claimReasons', 'all') are declared but their meanings are not explained. What is the difference between 'order' and 'productOrder'? When should an LLM choose one vs. the other? The description does not guide tool selection.
No pagination support. Tools like list_tables and get_api_schema_summary/detail that might return large result sets have no limit, offset, page, or cursor parameters. Per pattern:paginated-result, tools returning lists must support pagination to avoid context window exhaustion.
list_tables returns bare JSON text without structure hints. The description says 'DB의 모든 테이블 목록을 조회합니다.' (Korean: 'Query all DB tables'), but does not explain what fields the response contains (is it table_name only? other metadata?). This violates pattern:tool-description requirement for 'What does it return?'