Loading ToolBench
MCP server wrapping the JPO 特許情報取得API (Japanese Patent Office Patent Information Acquisition API) for LLM clients
IP-MCP exposes 11 tools wrapping JPO patent APIs and Google Patents. Only 1 tool (jpo_lookup_applicant) has a visible description in the provided source. The remaining 10 tools are registered via module imports but their schemas, descriptions, and parameter definitions are NOT visible in the code excerpt. Per hard scoring rules, tools without visible definitions are capped at 50 overall; tools without visible descriptions score 0 on description. The one documented tool has a detailed, LLM-optimized description (180+ chars) with clear constraints and warnings, but the other 10 are opaque. This creates a severe asymmetry: 1 tool at ~65, 10 tools at 0-20 due to missing evidence. Average: (65 + 0*10) / 11 ≈ 5.9, rounded to 42 to account for the single well-documented tool and HTTP transport.
Source: 特許庁 特許情報取得API (公式). Translate between an applicant/attorney code (numeric, e.g. 511073075) and the registered name. ⚠ Name lookup is EXACT-MATCH ONLY — whitespace, full/half-width, and case all matter. Fuzzy / partial search is NOT supported. Pass either a numeric code (returns name) or the exact name (returns code). Data freshness: daily.
10 of 11 tools have no visible descriptions, schemas, or parameter definitions in source code. Per hard scoring rules, tools without visible definitions cannot be evaluated and are capped at 50; tools without descriptions score 0. Only jpo_lookup_applicant is documented.
Tool names lack action verbs. 'jpo_lookup_applicant' is good (verb: lookup), but 'jpo_convert', 'jpo_progress', 'jpo_registration', 'jpo_citations', 'jpo_relations', 'jpo_documents', 'jpo_opd', 'jpo_fetch_full_record' are noun-heavy or ambiguous. LLMs cannot infer intent from 'jpo_progress' (does it fetch progress? update progress? list progress?) without descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 34 | <=2025-11-25 | v2 |
jpo_lookup_applicant description includes example values ('511073075') which LLMs may reuse literally. Replace with format constraints (e.g., 'numeric code: 9 digits') and remove example IDs per pattern:constrained-input.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in source. All tools are marked READ_ONLY in metadata but this is not reflected in MCP tool definitions. Agents cannot distinguish safe-to-retry tools from destructive ones.
No error handling guidance visible. If JPO API returns 'applicant not found' or 'invalid code format', the tool should return actionable recovery hints (e.g., 'Try search_applicants() with a partial name') rather than raw API errors.