Loading ToolBench
KIPRIS 특허·실용신안·상표·디자인 검색 MCP — 자유검색/항목검색/출원인/권리자/서지상세/상표/디자인 7개 도구
Korean Patent MCP has solid foundation with all 7 tools properly defined using Zod schemas and exposed via tool-registry.ts. All tools have descriptions in Korean+English pattern markers (e.g., '[자유검색]', '[항목검색]'). Input schemas are explicitly defined and converted to JSON Schema via toMcpInputSchema(). However, there are consistent quality gaps: (1) Descriptions, while present, are brief (avg 90-110 chars, baseline 194) and lack actionable guidance on when to use each tool vs. alternatives, e.g., search_patents vs search_patents_advanced distinction is unclear for LLM selection; (2) Parameter descriptions are present but minimal (20-50 chars, baseline 72), lacking format guidance, ranges, or examples of valid input; (3) No output schema documentation, LLMs cannot predict response structure; (4) Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are absent despite all tools being read-only; (5) Error handling is delegated to formatToolError (src/lib/errors.js not shown), recovery guidance unclear; (6) Pagination parameters (numOfRows, pageNo) lack min/max constraints visible in descriptions.
[서지상세] 출원번호로 상세 서지정보 조회 (출원인·발명자·IPC·청구항수·심사관·최종처분·등록상태).
[출원인검색] 기업·개인 출원인명으로 출원 특허 목록 조회. 예: '삼성전자'.
[권리자검색] 현재 특허권을 보유한 최종권리자명으로 조회 (권리 이전 반영).
[디자인검색] 물품명 키워드로 디자인 검색 (디자인분류·출원상태·도면이미지). 예: '의자'.
[자유검색] 키워드로 특허·실용신안 통합검색 (발명명칭·초록·청구항·출원인). 가장 일반적인 검색.
[항목검색] IPC분류·발명명칭·초록·청구범위·출원인·발명자를 조합한 정밀검색. 특정 기술분야 좁혀서 찾을 때.
Descriptions are too brief (avg 90 - 110 chars vs. baseline 194) and lack actionable guidance on tool selection. search_patents vs search_patents_advanced distinction is unclear, LLMs cannot determine which to use without explicit comparison. Descriptions should state WHEN to use this tool instead of similar tools.
Parameter descriptions lack format guidance and constraints. E.g., 'numOfRows': '결과 수 (기본 10, 최대 100)', maximum is buried in Korean text, not visible in JSON Schema. Numeric ranges should be explicit in parameter descriptions. IPC code format (e.g., 'B64C', 'G06N') needs pattern validation.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
[상표검색] 상표명 키워드로 검색 (출원상태·상품류·권리자·견본이미지). 예: '카카오'.
No output schema documentation. LLMs cannot determine what fields to expect in responses, breaking downstream tool chaining. Response objects should be defined (e.g., patent result returns: patentNumber, title, applicant, ipc, status, etc.). Without this, agents cannot plan multi-step calls.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are missing. All 7 tools are read-only, but LLMs have no explicit signal. Missing tool annotations per MCP spec pattern:tool-annotation, agents cannot optimize caching or retry logic.
Error handling guidance is opaque. formatToolError() function is referenced but not shown in source. LLMs need actionable recovery hints: e.g., if search returns 0 results, should agent retry with different keywords or suggest alternative search types? No retry/fatal classification visible.
No pagination documentation in tool descriptions. search_patents and others accept numOfRows (0-100) and pageNo (>=1), but descriptions do not explain how to iterate or whether total_count is returned. LLMs cannot plan multi-page searches without explicit guidance.
applicationNumber parameter in get_patent_detail lacks validation guidance. Example given: '10-2020-0000001'. Format should be explicitly documented (e.g., '^\d{2}-\d{4}-\d{7}$') or regex pattern declared in schema. Without format clarity, LLMs may pass malformed numbers.