openlex-mcp

Server Quality Checklist

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

Latest release: v0.2.5
Disambiguation5/5
Each tool has a clearly distinct purpose: full-text search across all laws, retrieval by number/abbreviation, article extraction, listing, specialized education search, article search within a law, live metadata, and cache update. The use case guidance in descriptions eliminates ambiguity.
Naming Consistency5/5
All tool names follow a consistent pattern: openlex__zhlaw_<verb>_<noun> (e.g., search_laws, get_law, get_article). The verb-noun structure is uniform across all tools, using standard verbs like search, get, list, find, update.
Tool Count5/5
8 tools is well-scoped for Zurich cantonal law: covers search, retrieval, listing, specialized search, metadata, and cache management. Neither too few nor too many, each tool earns its place.
Completeness5/5
The tool set covers the full lifecycle of legal retrieval: searching across laws, finding specific articles, retrieving full text, listing laws by area, getting live metadata, and managing cache. No obvious gaps for a read-only legal database.
Average 4.8/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
- 45 commits in the last 12 weeks
- Last stable release on August 2, 2026
- 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. Description adds details: real HTTP request (1-3s), required network access, return fields, error handling (404/Timeout). No contradictions. Slightly above baseline because description adds performance and error context not in annotations.
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?
Description is well-structured with clear sections (use_case, important_notes, example). Every sentence adds value. No fluff. Two short paragraphs with XML-like tags make it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description covers purpose, usage, behavioral details, parameter format, error handling, and constraints. Complete and self-contained. Sibling tools are diverse, and this description clearly differentiates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% per context, but the schema itself includes a description for the single parameter sr_number with example and format. The tool description includes an additional example. Since schema already provides parameter meaning, description adds minimal extra value. Baseline 3 is appropriate.
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?
Description clearly states it retrieves current metadata of a law live from zh.ch. It distinguishes from siblings by noting it's the only tool with a live HTTP call, while others use local cache. Verb+resource is specific and unambiguous.
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?
Use_case section explicitly describes when to use: checking current status, recent changes, PDF version, ZH-Lex URL. It states it's the only live-HTTP tool, implying alternatives. Important_notes specify input constraints (only Ordnungsnummer, no abbreviation lookup).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotent, not destructive), the description adds key behaviors: downloads ~970 laws from HuggingFace, takes ~25s first run, force=False skips if cache fresh returning 'cache_fresh', force=True forces download, requires internet. This fully informs the agent of side effects and state outcomes.
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: short introductory sentence, then use_case, important_notes (with timings and behavior), and a clear example. Every sentence serves a purpose, and it's front-loaded with the core action.
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?
For a simple one-parameter update action, the description covers usage, behavior, and output snippet. An output schema exists, so detailed return structure is not needed. Minor gap: no mention of error handling or internet failure, but still complete enough for typical use.
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 single boolean parameter 'force' is described in the schema as 'Cache auch wenn aktuell (<24h) erzwingen.' The tool description adds explicit return value behavior (status='cache_fresh' when skipped) and the time context. This adds meaningful nuance beyond the schema's brief description.
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 it updates the local cache of Zurich law data. The use_case explicitly tells when to call: when search results seem outdated or cache needs reloading. Sibling tools are all query tools, so this stands out as a cache management action.
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 provides explicit context: cache auto-refreshes every 24h, manual update rarely needed, and condition for calling (outdated results). However, it does not name specific alternative tools for when the cache should not be called, though siblings are clearly different in purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already indicate safety. Description adds specifics: supports standard/letter/bis article numbers, returns title/paragraphs/full text, returns count=0 if not found, and format requirements like omitting 'Art.' prefix.
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?
Structured with XML tags (use_case, important_notes, example) that organize information efficiently. Every sentence is necessary, no fluff, and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter retrieval tool, the description covers all needed context: what it retrieves, error behavior (count=0), and format requirements. Output schema exists, so return value details are not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover parameter formats and examples. Tool description adds a concrete example but no new semantic information beyond the schema, which already specifies 'Ohne 'Art.' Prefix' and examples.
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 states 'Extrahiert einen einzelnen Artikel aus einem Zürcher Gesetz' with a use case that clarifies when to use it and distinguishes it from sibling tool openlex__zhlaw_search_articles for searching.
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?
Explicitly includes a <use_case> block describing when to use (exact wording needed, known identifiers) and directs to openlex__zhlaw_search_articles for finding articles first.
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?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds context about sr_prefix examples, active_only filtering, pagination via offset, and return fields (no full text), which is valuable beyond annotations.
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 structured with use_case, important_notes, and example tags. It is concise, front-loaded with the main purpose, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (4 sub-params), output schema exists, and annotations are present, the description covers when to use, parameter details, return fields, and sibling differentiation. It is complete for an AI agent.
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 concrete examples for sr_prefix (412=Bildung, etc.) and explains active_only and pagination. The schema itself has decent descriptions, but the description enhances understanding with real-world usage.
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 lists Zurich laws with optional filter, using specific verb 'auflisten' and resource 'Zürcher Gesetze'. It distinguishes itself from siblings by referencing use cases for alternative tools.
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 use_case tag explicitly states when to use (structured overview) and when not (targeted text search or pure education law), naming alternative tools search_laws and find_education_laws.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnlyHint, idempotentHint, and not destructive. The description adds valuable context: it searches only active 412.x laws and if no results, automatically falls back to all legal areas with a note in the message field. There is no contradiction with annotations.
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 with clear sections (<use_case>, <important_notes>, <example>), front-loads the main purpose, and uses concise language. Every sentence adds value, and the example illustrates usage efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (search with fallback) and the presence of an output schema (though not shown), the description covers key aspects: scope, fallback behavior, related tools, and synergy with external MCP. It is comprehensive for a search tool.
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 a detailed description for the query parameter, but the tool description does not repeat it. However, the description provides an example (query='Elternrat', limit=10) and context for typical queries (e.g., 'Kindergarten', 'Schulleitungen'), which adds meaning beyond the schema. Given low schema description coverage (0% per signals), the description compensates adequately but could elaborate more.
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 it searches specifically in Zurich education law (Ordnungsnummern 412.x) and distinguishes itself from sibling tools like openlex__zhlaw_search_laws by being faster and more precise for education-related queries. It also lists specific laws covered (VSG, VSV, LPG, etc.), making the purpose unambiguous.
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 <use_case> tag explicitly states when to prefer this tool over sibling openlex__zhlaw_search_laws (e.g., when query is education-related). It also provides conditions for use (school, teachers, kindergarten, etc.) and mentions fallback behavior to all legal areas with a message hint. Additionally, it advises using other tools for articles and synergy with swiss-courts-mcp.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: include_content returns up to 5000 characters with truncation flag; lists important laws. Annotations already indicate readOnly and idempotent, no contradiction.
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?
Well-structured with clear sections (use_case, important_notes, example). Every sentence adds value, no fluff. Purpose stated in first line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required param, no nested objects, output schema exists), the description covers all necessary aspects: input format, behavior of include_content, truncation handling, and related 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?
Schema descriptions already cover both parameters (identifier and include_content). Description adds practical examples and known abbreviations, enhancing usability beyond schema.
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 retrieves a Zurich law by identifier (Ordnungsnummer or Abbreviation), and distinguishes it from sibling tools like openlex__zhlaw_search_laws for finding laws.
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?
Explicit use case: when identifier is known. Provides when-not-to-use (use search_laws or find_education_laws to find) and alternatives for truncated content (openlex__zhlaw_get_article).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits such as case-insensitive substring matching, no FTS5, parsing law into articles, and cache requirements. These add significant value beyond the annotations which only indicate read-only and idempotent hints.
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 concise and well-structured with clear sections (<use_case>, <important_notes>, <example>). Every sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the comprehensive description covering purpose, usage, behavior, and an example, the description is complete enough for an AI agent to understand and invoke the tool correctly.
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 already provides descriptions for both parameters. The description adds an example usage and reinforces the meaning, but does not introduce new semantics beyond what is in the schema. However, the example is helpful for clarifying the intended use.
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 that the tool searches all articles of a specific law for a term, using a specific verb and resource. It distinguishes itself from sibling tools by noting when to use this tool vs. openlex__zhlaw_get_article.
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 explicitly provides a use case ('when the law is known but the article is not') and an alternative ('for a specific article number, use openlex__zhlaw_get_article'). This gives clear guidance on when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds crucial behavioral details: FTS5 syntax (AND, OR, NOT, phrase search), BM25 relevance sorting, max 50 results, local caching, and a note to check metadata freshness via openlex__zhlaw_get_law_metadata. No contradictions.
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 succinct and well-structured using <use_case>, <important_notes>, and <example> tags. Each section adds necessary information without redundancy. The first sentence immediately conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, an output schema, annotations), the description covers use cases, important notes, and an example. It explains caching behavior and when to check metadata freshness. The output schema is present, so return values need not be described.
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 schema coverage at 0%, the description meaningfully explains the query, limit, and sr_prefix parameters, including FTS5 syntax examples and how to filter by legal area. It does not mention the active_only parameter, but the other parameters are well-covered with practical guidance.
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 does a full-text search across all ~970 Zurich cantonal laws using FTS5 ranking. It explicitly distinguishes itself from sibling tools: openlex__zhlaw_find_education_laws for the education law area and openlex__zhlaw_search_articles for finding articles within a known law.
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 <use_case> tag explicitly states when to use this tool (when the legal area is unknown) and when to use alternatives (for education law or within a known law). It names specific sibling tools and provides clear context.
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:

[![openlex-mcp MCP server](https://glama.ai/mcp/servers/malkreide/openlex-mcp/badges/card.svg)](https://glama.ai/mcp/servers/malkreide/openlex-mcp)

Score Badge

Copy to your README.md:

[![openlex-mcp MCP server](https://glama.ai/mcp/servers/malkreide/openlex-mcp/badges/score.svg)](https://glama.ai/mcp/servers/malkreide/openlex-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/malkreide/openlex-mcp'

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