e-Gov Law MCP Server

by ryoooo

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between search_laws and search_laws_by_keyword, which could cause confusion about when to use each. The batch_find_articles and find_law_article tools also serve similar functions but are differentiated by batch vs. single operations, which is reasonably clear.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with clear verb_noun structure (e.g., find_law_article, get_cache_stats, search_laws). This consistency makes the toolset predictable and easy to navigate.
Tool Count5/5
With 8 tools, the server is well-scoped for its domain of Japanese law lookup and search. Each tool has a clear role, covering operations like searching, fetching, caching, and batch processing without being overwhelming.
Completeness4/5
The toolset provides strong coverage for law lookup and search, including single and batch article retrieval, full-text search, and caching utilities. A minor gap is the lack of update or delete operations, but this is reasonable given the domain of static law data.
Average 3.3/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it 'prefetches for better performance', without disclosing behavioral traits like whether it's idempotent, its impact on cache state, error handling, or rate limits. It mentions 'cache status' in returns but doesn't explain what that entails operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three brief sections (purpose, args, returns), front-loaded with the main function. However, the 'Args' and 'Returns' sections add little beyond what's implied, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that likely involves caching behavior. It fails to explain what 'prefetch' does (e.g., loads laws into cache), what 'commonly accessed' means, or the structure of the returned dict, leaving significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description adds minimal value by noting 'ctx: FastMCP context for logging', which is redundant but doesn't detract, warranting a baseline score above minimum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'prefetches commonly accessed laws for better performance', which provides a vague purpose without specifying what 'prefetch' means operationally or how it differs from sibling tools like 'get_law_content' or 'search_laws'. It mentions a resource ('laws') but lacks specificity about scope or mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_cache_stats' or 'clear_cache'. The description implies a performance optimization context but doesn't specify prerequisites, timing, or exclusions, leaving usage unclear relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it states the tool retrieves statistics (implying a read-only operation), it doesn't clarify important behavioral aspects such as whether this requires special permissions, what specific metrics are included, whether the data is real-time or cached, or if there are rate limits. The description is too vague about the actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with three brief sentences that cover purpose, arguments, and return value. It's front-loaded with the main purpose first, and there's no unnecessary verbosity. However, the structure could be slightly improved by integrating the argument/return information more seamlessly rather than as separate labeled sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations and no output schema, the description should provide more complete context for a statistics-retrieval tool. It mentions returning a 'Dict with detailed cache statistics' but doesn't specify what those statistics include (e.g., hit rates, memory usage, eviction counts) or the format/structure. For a tool with zero parameters but potentially complex return data, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema has 100% description coverage (though empty). The description correctly notes there are no parameters beyond the context argument, which is appropriate. Since there are no parameters to document, the description doesn't need to compensate for any gaps, earning a baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('current cache statistics and performance metrics'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'clear_cache' or explain how it differs from other monitoring/statistics tools that might exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of when this tool is appropriate (e.g., for monitoring cache health, troubleshooting performance issues) or when other tools like 'clear_cache' or 'prefetch_common_laws' might be more suitable. The agent receives no contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool clears caches, implying a destructive mutation, but lacks details on permissions required, whether it's reversible, rate limits, or logging behavior (though 'ctx' parameter hints at logging). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core action. The 'Args' and 'Returns' sections add structure, but the 'ctx' parameter explanation is minimal ('FastMCP context for logging'), and the return value description ('Dict with clear operation results') is vague. Overall, it's efficient with minor room for improvement in detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive mutation with 1 parameter) and lack of annotations/output schema, the description is moderately complete. It covers the purpose and parameters but misses behavioral details like side effects or error handling. For a cache-clearing tool, this is adequate but leaves gaps in understanding full implications, scoring as minimum viable with clear improvements needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the input schema. The schema has 0% description coverage, listing only 'cache_type' with a default. The description explains 'cache_type' as 'Cache type to clear' with enumerated values ('all', 'law_lookup', 'law_content', 'article'), clarifying its purpose and options. This compensates well for the low schema coverage, though it doesn't detail the 'ctx' parameter beyond 'FastMCP context for logging'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with the verb 'clear' and resource 'cache', specifying it can clear 'specified cache or all caches'. It distinguishes from sibling tools like 'get_cache_stats' (which reads) and 'prefetch_common_laws' (which populates). However, it doesn't explicitly differentiate from all siblings, such as 'batch_find_articles' which might involve caching indirectly, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., when caches need clearing), exclusions (e.g., avoid during high traffic), or compare to siblings like 'get_cache_stats' for monitoring. Usage is implied only by the action 'clear', with no explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'smart filtering' but doesn't explain what this means operationally. It doesn't describe authentication requirements, rate limits, error conditions, or what the 'Dict with search results' actually contains. The mention of 'ctx: FastMCP context for logging' in the Args section is behavioral information, but this isn't part of the actual input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns) and uses bullet-like formatting. The opening sentence establishes purpose, followed by parameter explanations. However, the inclusion of 'ctx: FastMCP context for logging' in Args is confusing since this parameter doesn't exist in the actual schema, creating some inefficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 5 parameters, 0% schema coverage, no annotations, and no output schema, the description does a reasonable job explaining parameters but leaves significant gaps. It doesn't explain the return format beyond 'Dict with search results', doesn't mention error conditions or rate limits, and provides no guidance on when to use versus sibling search tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, and it does so effectively by listing all 5 parameters with brief explanations. It clarifies that law_title and law_num support 'partial match', law_type includes examples like 'Act, CabinetOrder, etc.', and limit has a range '1-500'. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search Japanese laws with smart filtering' - a specific verb ('Search') and resource ('Japanese laws') with a qualifier ('smart filtering'). However, it doesn't differentiate from sibling tools like 'search_laws_by_keyword' or 'find_law_article', which appears to be a similar search function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple search-related sibling tools (search_laws_by_keyword, find_law_article, batch_find_articles), there's no indication of when this specific search_laws tool is appropriate versus those other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions logging via 'ctx' but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, or what happens with invalid inputs. For a search tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose followed by structured parameter and return details. Every sentence adds value, with no wasted words, though minor improvements in flow could make it slightly more polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description covers the basic purpose and parameters adequately but lacks details on behavioral traits, output format beyond 'Dict with search results,' and differentiation from sibling tools. It's minimally viable but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% schema description coverage. It explains each parameter's purpose (e.g., 'keyword: Search keyword (required)'), clarifies optional vs. required, and provides context like the limit range (1-20) and logging use for 'ctx.' This compensates well for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'Full-text keyword search in Japanese laws,' which specifies the verb (search), resource (Japanese laws), and scope (full-text keyword). However, it doesn't explicitly distinguish this from the sibling tool 'search_laws,' which might have overlapping functionality, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_laws' or 'find_law_article.' It mentions parameters but doesn't explain the context or prerequisites for using this search method, leaving the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'efficiently' and 'performance stats' in returns, hinting at optimization, but lacks critical details: whether this is read-only or mutating, authentication requirements, rate limits, error handling, or what 'performance stats' entail. For a batch tool with zero annotation coverage, this leaves significant gaps in understanding operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose statement, Args section, and Returns section, all in three sentences. It's front-loaded with the core function and avoids unnecessary fluff. However, the 'ctx' parameter in Args is not defined in the input schema, creating minor confusion that slightly reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage, the description is moderately complete. It covers the main purpose and parameter format but misses behavioral details like safety, performance implications, and output specifics beyond 'Dict with batch results and performance stats'. For a batch operation tool, this leaves room for improvement in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It provides a clear example of the JSON format for 'law_article_pairs', explaining the structure with law-article pairs. This adds meaningful semantics beyond the bare schema, though it doesn't detail all possible values or constraints. With only one parameter, this is sufficient for baseline understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Batch find multiple law articles efficiently' specifies the verb ('find'), resource ('law articles'), and scope ('batch', 'multiple'). It distinguishes from siblings like 'find_law_article' (singular) and 'search_laws' (different operation). However, it doesn't explicitly contrast with all siblings, keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for batch operations versus single lookups (contrasting with 'find_law_article'), but doesn't provide explicit guidance on when to use this tool versus alternatives like 'search_laws' or 'search_laws_by_keyword'. No when-not-to-use instructions or prerequisites are mentioned, leaving usage context partially implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions being 'ULTRA SMART & FAST' and handling complex patterns automatically, which adds useful context about performance and functionality. However, it lacks details on error handling, rate limits, or authentication needs, leaving gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by key features and parameter details. Every sentence adds value, such as specifying law support and pattern handling, with no redundant information, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (handling Japanese legal articles with automatic pattern parsing) and no annotations or output schema, the description is adequate but incomplete. It covers the purpose and parameters well but lacks details on return values (only mentions a dict with content and metadata without specifics), error cases, or performance limitations, which could hinder agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides clear examples for both parameters (law_name and article_number), such as '民法' for law_name and '192' or '325条の3' for article_number, which adds meaningful context beyond the schema's 0% coverage. This compensates well for the lack of schema descriptions, though it doesn't fully explain all possible formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as finding a specific article in Japanese law, specifying it's 'ULTRA SMART & FAST' with support for 16+ major laws and automatic handling of complex patterns like 条の2, 項, 号. This distinguishes it from sibling tools like 'search_laws' or 'get_law_content' by focusing on precise article retrieval rather than broader searches or content fetching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning support for 16+ major laws and automatic pattern handling, which suggests it's for precise article lookup. However, it doesn't explicitly state when to use this tool versus alternatives like 'batch_find_articles' for multiple articles or 'search_laws' for broader queries, leaving some ambiguity in sibling tool differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it discloses API limitations ('elm parameter is currently disabled due to e-Gov API 400 errors'), size constraints ('optimized per API spec with size limits'), and behavioral specifics for large laws ('returns summary with recommendation to use find_law_article'). It doesn't mention authentication or rate limits, but covers key operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Note) and front-loads the purpose. Some sentences could be tighter (e.g., 'optimized per API spec with size limits' is vague), but overall it's efficient with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with 0% schema coverage and no output schema, the description does a good job explaining inputs, outputs, and behavioral constraints. It covers the return format for both normal and large laws, and mentions sibling tools. It could benefit from more detail on error handling or authentication, but is largely complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains all 4 parameters in the Args section, adds context about 'elm' being disabled, and clarifies 'response_format' options. However, it doesn't fully explain the relationship between 'law_id' and 'law_num', or provide examples, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Get law content' with the verb 'Get' and resource 'law content', and specifies it's 'optimized per API spec with size limits'. However, it doesn't explicitly differentiate from sibling tools like 'find_law_article' or 'search_laws' in the purpose statement itself, though it mentions them later.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use alternatives: it states 'Use find_law_article tool for specific article searches in large laws' in the Note section, and implies this tool is for general law content retrieval. This directly helps the agent choose between this tool and its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![e-gov-law-mcp MCP server](https://glama.ai/mcp/servers/ryoooo/e-gov-law-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ryoooo/e-gov-law-mcp)

Score Badge

Copy to your README.md:

[![e-gov-law-mcp MCP server](https://glama.ai/mcp/servers/ryoooo/e-gov-law-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ryoooo/e-gov-law-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ryoooo/e-gov-law-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server