fedlex-mcp

Server Quality Checklist

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

Latest release: v2.0.1
Disambiguation5/5
Each tool targets a distinct operation: law search, law detail, history, recent publications, upcoming changes, gazette search, treaty search, open consultations, consultation search, consultation detail, term lookup, and concept detail. No overlap in functionality.
Naming Consistency5/5
All tools follow a consistent prefix (fedlex_ or termdat_) followed by verb_noun pattern (e.g., fedlex_search_laws, fedlex_get_law_by_sr, termdat_lookup_term). Naming is uniform and predictable.
Tool Count5/5
12 tools cover a broad domain (laws, treaties, gazette, consultations, terminology) without being excessive. Each tool serves a clear purpose, and the count is well-scoped for the server's function.
Completeness4/5
Core workflows are covered: search, detail, history, monitoring for laws and consultations, plus terminology lookup. Minor gaps: no full text retrieval for laws (only link provided) and no treaty detail tool, but agents can work around with links.
Average 4.3/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 46 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 declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that it only considers future dates (dateEntryInForce > heute) and the configurable time window via days_ahead. This goes beyond annotations with 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the primary action. XML tags structure the additional context effectively. A minor deduction for redundancy (the core sentence repeats the title), but overall concise.
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?
The tool has an output schema, which reduces the need to describe return values. However, the description lacks coverage of two parameters (limit, language) and does not explain behavior at limits. Adequate for a simple retrieval tool but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only explains days_ahead (via example and note). The limit and language parameters are not described at all, leaving the agent uncertain about their purpose. The description partially compensates for one parameter out of three.
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 retrieves upcoming changes to laws ('Ruft Erlasse ab, die in den nächsten N Tagen in Kraft treten'), with a specific verb, resource, and scope (future effective dates). This distinguishes it from sibling tools like fedlex_search_laws or fedlex_get_law_by_sr.
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 <use_case> tag provides explicit guidance for proactive legal monitoring. The <important_notes> ensures only future dates are considered and the window size is constrained. However, it does not mention when not to use this tool or suggest alternative tools.
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=false. The description adds valuable behavioral context: deadline and days_remaining with timezone, derived status, status_conflict, and handling of missing hasSubTask (deadline=null, no throw). This goes beyond annotations without 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?
Description is short and front-loaded with purpose. Structured tags (use_case, important_notes, example) add value without unnecessary text. Every sentence earns its place.
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?
With an output schema present (not shown), the description need not explain return values. It covers use case, behavioral details, and example. Could be more explicit about the object returned, but it is sufficient for a detail retrieval tool.
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?
Context indicates schema description coverage is 0%, so description must compensate. The description provides an example event_id and mentions its source, but does not elaborate on the language parameter. Although the schema includes descriptions, the tool description adds only marginal meaning. Baseline for low coverage is higher, but the description does not fully compensate.
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 retrieves consultation details by event ID. The use_case tag elaborates that it shows full procedure with deadlines, lead office, status, documents, linking to legal resources. This distinguishes it from sibling tools like fedlex_get_open_consultations (list) and fedlex_search_consultations (search).
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 after obtaining an eventId from fedlex_get_open_consultations (mentioned in important_notes). However, it does not explicitly state when to use this tool vs alternatives (e.g., search_consultations), nor provides when-not or exclusions. Usage guidance is implied but not explicit.
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, idempotentHint, destructiveHint) are consistent. The description adds key behavioral details: filtering by eventEndDate >= today in Europe/Zurich, computation of days_remaining and status_conflict, and sorting by shortest remaining deadline. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses XML-like tags and is somewhat verbose. Each section adds value, but the overall structure could be more concise (e.g., merging use_case and important_notes). It is not minimal, but not overly bloated.
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 the presence of output schema, the description does not need to detail return values. It covers purpose, behavioral logic, and parameter hints adequately. However, it lacks information on rate limits or authentication, though annotations cover safety. Overall, it is fairly complete for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 only briefly mentions topic and keyword in important_notes, but does not describe limit, language, or the date-based filtering criteria. The explanation for keyword is helpful but insufficient for full parameter understanding.
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 'Listet aktuell OFFENE Vernehmlassungen des Bundes (Fristen-Monitoring)', specifying verb, resource, and context. The use_case reinforces the purpose of deadline monitoring. This distinguishes it from siblings like fedlex_search_consultations, which likely covers all consultations.
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 important_notes explain filtering logic (by deadline, not status), sorting, and interpretation of empty results. It provides an example and guidance on topic vs keyword. However, it does not explicitly compare with siblings or state when to use this tool versus fedlex_get_consultation.
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, and destructiveHint. The description adds behavioral details: sorted descending by effective date, max 50 versions, and SR number format requirement, which goes 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 concise with a main sentence, followed by structured sections for use case, important notes, and example. Every sentence provides meaningful information with no waste.
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 the output schema exists, the description covers the tool's purpose, usage context, and key constraints. With only one required parameter and clear notes, it is largely complete. Minor omission: no mention of the language parameter default or behavior.
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?
With 0% schema description coverage, the description provides some parameter guidance: example 'sr_number='235.1'' and note to separate SR number with dot. However, the 'language' parameter is not explained. The example adds value but is not comprehensive.
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 version history (all consolidated versions) of a law, with a specific use case and example. It distinguishes itself from sibling tools that search laws or get current law by SR number.
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 use case explains when to use it (comparing old vs revised law versions). Important notes provide context on sorting and limits. However, it does not explicitly state when not to use it or mention alternatives.
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 indicate readOnlyHint, idempotentHint, and destructiveHint are false. The description adds value by explaining it returns 'Erstpublikationen (AS)' and not the consolidated version, which is crucial behavioral information beyond the 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 very concise with two sentences and three XML tags. It front-loads the purpose and uses structured tags for use_case, important_notes, and example, making it efficient for an AI agent to parse.
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 straightforward retrieval tool, the description covers the essential behavioral aspects: what is retrieved (AS publications), the time window, and a usage example. The output schema exists, so return values are not needed. The limit parameter is missing, so it's not fully complete.
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?
The description mentions days range in important_notes and provides an example with days and language. However, it does not explain the limit parameter. The schema already describes days and language, so the description adds marginal extra meaning. The parameter coverage in the description is incomplete.
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 retrieves the latest publications of the Amtliche Sammlung (AS). The use_case tag provides concrete context for monitoring legal changes. This distinguishes it from sibling tools like fedlex_search_laws or fedlex_get_law_by_sr.
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 includes a use_case (regular monitoring) and important_notes that clarify it returns first publications, not consolidated law. This gives clear guidance on when to use the tool. However, it does not explicitly mention when to avoid it or name alternative tools.
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 declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: searches only titles (not full text), defaults to in_force_only=true, and returns a structured envelope. No contradictions 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 concise, front-loading the purpose, and uses structured XML tags for use_case and important_notes. Every sentence provides value, with no wasted words.
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 search tool with 4 parameters and an output schema, the description covers the main use case, important behavioral notes, and return envelope structure. It is complete enough given the existence of an output schema and annotations.
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%, but the input schema itself provides detailed descriptions for each parameter (keywords, limit, language, in_force_only). The description adds an example but does not significantly enhance parameter understanding beyond the schema. Baseline of 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?
The description states the verb 'Durchsucht' (searches) the resource 'Systematische Rechtssammlung (SR)' by title and lists the returned fields (SR-Nummer, Abkürzung, Status, Link). This clearly distinguishes it from sibling tools like fedlex_search_gazette or fedlex_search_treaties.
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 includes a <use_case> tag specifying legal/administrative research and an <important_notes> section clarifying title-only search and default in_force_only=true. It does not explicitly state when not to use, but the context is clear enough.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context about the specific publication (BBl) and its nature as official publications, but no new behavioral traits 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?
Very concise: one sentence for purpose, then structured use_case, important_notes, and example. Every part adds value without redundancy.
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 output schema exists and annotations cover safety, the description fully covers purpose, usage, differentiation, and key constraints. It is complete for a search tool.
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?
The input schema already includes descriptions for `keywords` and `year`. The tool description adds an example but no additional semantic detail beyond what the schema provides. Baseline 3 applies.
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 the Federal Gazette for official publications, and distinguishes from `fedlex_search_laws` for consolidated law. The use case tag further specifies political early warning, messages, initiatives, and consultations.
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 guidance on when to use (political early warning) and when not to use (for current laws, use `fedlex_search_laws`). Also hints at optional year restriction.
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 declare readOnlyHint, idempotentHint, destructiveHint false. Description adds essential behavioral context: search scope limited to titles, and empty keyword returns latest treaties. 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?
Very concise, structured with use_case and important_notes tags, front-loaded with the main action. Every sentence adds value, no superfluous text.
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 rich annotations and presence of output schema, the description covers purpose, use cases, and key behavioral constraints. Could also mention result format or pagination, but for a search tool it is sufficiently complete.
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 coverage is 0% per context, but schema actually documents keywords and language. Description adds value by explaining that omitting keywords lists latest treaties, but does not detail limit or language parameters further. Adequate but not complete compensation for low coverage.
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?
Clearly states it searches international state treaties (SR numbers starting with '0.'). Provides specific use cases (EU bilateral, double taxation, Council of Europe conventions) and distinguishes it from sibling tools like fedlex_search_laws by focusing on treaties.
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 describes when to use (search treaties) and includes important notes: search is title-only, without keywords returns latest treaties. Provides concrete examples and alternatives are implied by sibling context.
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 declare readOnlyHint, idempotentHint, and destructiveHint. Description adds extra behavioral context: it mentions that for repealed decrees, the successor law is provided if available. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with HTML-like tags but remains concise. Front-loaded with purpose and use case. Every sentence adds value, though could be slightly more streamlined.
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 a simple tool with one required parameter and an output schema, description covers what the tool does, when to use it, important usage notes, and expected output fields. Sufficient for correct selection and invocation.
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 has a description for sr_number parameter with examples. Description adds usage guidance: 'SR-Nummer mit Punkt trennen (235.1)' and an example. Despite 0% schema coverage metric, description compensates well.
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 a federal decree by SR number and lists the details (title, abbreviation, status, etc.). Distinguishes from sibling tools like fedlex_search_laws (which searches) and fedlex_get_law_history (which retrieves history).
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?
Includes explicit <use_case> tag specifying when to use (when SR number is known, e.g., from fedlex_search_laws) and <important_notes> tag with details about repealed decrees and correct format of SR number.
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 declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds value by noting the internal normalization quirk (Quirk 3) and the subset of data source (77,692 of ~400,000 entries), which is useful 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 well-structured with XML tags separating purpose, use case, important notes, and example. Every element serves a purpose without redundancy, and it is front-loaded.
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 complexity of retrieving a full concept with multiple languages and sources, the description covers purpose, accepted input formats, data source limitations, and internal quirks. With an output schema present, the description is fully adequate for an agent to use 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 single parameter 'concept' has 0% schema description coverage per context, but the tool description explains accepted formats (ID, concept URI, term URI with language suffix) and gives an example, adding meaning beyond the schema's limited 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?
Description clearly states it retrieves a full TERMDAT entry by ID or URI, including all language designations, definitions, synonyms, and sources. It distinguishes from siblings like termdat_lookup_term and FedLex tools by specifying the 'full entry' use case.
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 <use_case> tag specifies when to use ('full view of a terminology concept'), and <important_notes> provides format details. It does not explicitly mention alternatives or when not to use, but the context is clear and aids decision-making.
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 indicate readOnly, idempotent, non-destructive. The description adds transparency about data source subset (77,692 of ~400,000 entries) and that 'rm' is practically empty. This goes beyond annotations by disclosing data limitations that affect results. 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 concise and structured with clear tags: use_case, important_notes, example. Each section adds essential information without redundancy. Front-loaded with main action. No wasted words.
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 the output schema exists, the description need not detail return values. It covers data source limitations, language coverage, and provides an example. It could mention pagination or result format but is sufficiently complete for typical use.
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?
The input schema has detailed descriptions for all parameters (term, limit, target_languages). The tool description adds value with an example usage and context but doesn't significantly enhance clarity beyond what schema already provides. Schema coverage is effectively high, so 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?
The description clearly states the verb ('nachschlagen'), resource (TERMDAT), and what it returns (equivalents in other languages with definition). It distinguishes from sibling tools like termdat_get_concept by focusing on term lookup for translations.
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 provides a typical query ('Wie heisst dieser Begriff auf Französisch/Italienisch?') and context (amtliche Terminologie, mehrsprachige Stellungnahmen). Important_notes clarify the data source limitations and that a negative result doesn't mean absence. This gives clear when-to-use guidance and expectations.
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 declare readOnlyHint, idempotentHint, destructiveHint=false; description adds behavioral details like status derivation, runtime days_remaining, and filter semantics (e.g., topic is a keyword union). 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?
Description is front-loaded with main purpose, then uses structured tags (<use_case>, <important_notes>, <example>) to concisely convey usage, filters, and example, with no redundancy.
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 (multiple filters, derived fields) and the presence of an output schema, the description covers use case, filters, behavior, and alternatives, making it complete for an agent to use 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?
Despite schema description coverage reported as 0%, the description explains each filter (topic, keyword, status, dates, institution) and their semantics (e.g., status derived, days_remaining). Adds value beyond the schema's type 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?
Description clearly states 'Volltextsuche über Vernehmlassungen' (full-text search over consultations) with filters, distinguishing it from sibling tools like fedlex_search_laws and explicitly calling out the alternative fedlex_get_open_consultations.
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?
Description provides explicit use case (pre-parliamentary research), when to use (with filters), and when not to (pure deadline monitoring, refer to fedlex_get_open_consultations). Also explains derived status and days_remaining.
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:

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

Score Badge

Copy to your README.md:

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

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