Loading ToolBench
日本政府のe-Gov法令API用Model Context Protocolサーバー - A highly optimized Model Context Protocol server for Japanese e-Gov Law API with direct mapping for 16+ major laws, smart Base64/XML text extraction, and efficient article search with intelligent pattern matching.
Server has 9 tools with consistent verb-noun naming (search_, get_, find_, analyze_, compare_, list-like patterns). All tools have descriptions (avg ~120 chars, within baseline 34-392 range). Input schemas are present with type definitions and parameter descriptions. Error handling is minimal; no recovery guidance or actionable error messages visible. No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Parameter descriptions are adequate but lack format constraints, ranges, or enum declarations where applicable. No pagination support visible despite tools returning lists (search_laws, search_laws_by_keyword). Composition is sound, each tool has one responsibility. Security: no secrets in params (good), but no audit logging or permission gates visible.
Perform legal analysis of a specific article using the legal analysis instruction prompt. Provides expert interpretation including legal significance, requirements, effects, and related case law.
Compare different versions of the same law to see what has changed. Useful for tracking legislative amendments.
Find a specific article within a law by law name and article number. Supports complex patterns including 条の2 format, paragraph/item specifications, and intelligent pattern matching.
Retrieve amendment history and related laws for a specific law. Shows how the law has been modified over time.
Retrieve the full text content of a specific law by law number. Supports both JSON and XML response formats with intelligent text extraction.
Get the hierarchical structure of a law including chapters, sections, articles, paragraphs, and items. Useful for understanding the organization of complex laws.
Output schemas not documented. LLMs cannot infer what fields to expect from tool responses, forcing them to guess at downstream field names and risking broken tool chains.
No pagination support (limit/offset, next_cursor, total_count) for list-returning tools (search_laws, search_laws_by_keyword, get_related_laws). Large result sets will blow context windows.
No error handling guidance. Tool descriptions do not explain what to do if a law is not found, API fails, or input is invalid. Errors will not guide LLM recovery.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | <=2025-11-25 | v2 |
Find laws related to a specific law. Returns laws that reference or are referenced by the given law.
Search for laws by title, type, and other criteria. Returns matching laws with metadata including law number, title, promulgation date, and revision information.
Search for laws by keyword within law content. Returns laws containing the specified keyword with sentence-level matches.
Parameter descriptions lack format constraints and enums. E.g., 'law_type' accepts free-form strings ('Act', 'Cabinet Order', 'Ministry Ordinance') but no enum constraint prevents hallucinated values. 'response_format' should be enum ['json', 'xml'].
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools are read-only but this is not declared in the schema, forcing LLMs to infer safety from descriptions alone.