How do I use hu-eli-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@hu-eli-mcp get metadata for Act V of 2013 (Hungarian Civil Code)" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

hu-eli-mcp

by matematicsolutions

Overview Schema Related Servers Score Discussions

Python

Remote

hu-eli-mcp

An MCP server for Hungary's official national legislation database, the Nemzeti Jogszabalytar (NJT, njt.jog.gov.hu), maintained by MKIFK. It gives an AI agent a piece of Hungarian legislation resolved by its native ELI (European Legislation Identifier), with a verifiable citation: the ELI itself, a human-readable citation, and a link to the official source.

Part of the eu-legal-mcp line by MateMatic — one connector per EU member state, the same citation contract everywhere.

On ELI. Unlike the Netherlands and Sweden (earlier connectors in this line, neither of which publishes native ELI), Hungary has a genuine, documented national ELI implementation since 2023 (njt.jog.gov.hu/eli/urisemak). eli_uri is therefore the real /eli/ URI the tool resolved — never a substitute identifier. See DISCOVERY.md.

Tools

Tool	What it does
`hu_get_act(year, serial)`	Metadata for a Hungarian Act (torveny) by ELI, e.g. year `2013`, serial `5` (the Civil Code). No issuer code needed.
`hu_get_legislation(doc_type, year, issuer, serial)`	Metadata for any other legislation (decrees etc.) by ELI — type, year, issuer (case-sensitive) and serial.
`hu_get_text(doc_type, year, serial, issuer=None)`	The full document HTML content for either an Act or other legislation.
`hu_list_doc_types()`	Valid NJT document-type codes (e.g. `TV`=Act, `R`=decree).
`hu_list_issuers()`	Valid NJT issuer codes (e.g. `Korm`=Government) — note the exact casing matters.
`hu_coverage()`	Declare what this connector covers, when each family was captured, and - explicitly - what it does NOT cover. Every gap carries a fallback.

Every response carries the citation contract:

eli_uri — the native ELI URI resolved, e.g. https://njt.jog.gov.hu/eli/TV/2013/5.
human_readable_citation — built from the parsed title + subtitle, e.g. "2013. évi V. törvény (a Polgári Törvénykönyvről)".
source_url — the browsable njt.jog.gov.hu/jogszabaly/... document page.

No free-text search

NJT has no REST/JSON API and its search/browse UI is a JavaScript SPA requiring a session (not usable headlessly). Documents must be addressed by a known ELI — use hu_list_doc_types / hu_list_issuers to discover valid codes, then hu_get_act / hu_get_legislation. An unresolvable ELI (wrong year/serial/issuer, or wrong issuer-code case) surfaces as not_found — NJT itself redirects it to a search-assist page rather than a 404.

Related MCP server: Hungarian Legislation MCP Server

Install

pip install -e ".[dev]"

{
  "mcpServers": {
    "hu-eli-mcp": {
      "command": "hu-eli-mcp",
      "env": {
        "HU_ELI_BASE_URL": "https://njt.jog.gov.hu",
        "HU_ELI_CACHE_DIR": "~/.matematic/cache/hu-eli",
        "HU_ELI_AUDIT_DIR": "~/.matematic/audit"
      }
    }
  }
}

Windows 11 with Smart App Control

Smart App Control blocks unsigned executables, which covers uvx.exe, pip.exe and the hu-eli-mcp.exe launcher that pip writes at install time. The python.exe and py.exe from the python.org installer are signed by the Python Software Foundation, so running the module through the interpreter works:

python -m pip install hu-eli-mcp
python -m hu_eli_mcp

pip.exe is blocked for the same reason, so install with python -m pip, not pip install. If python is not on PATH, use the Windows launcher: py -3 -m hu_eli_mcp.

{ "mcpServers": { "hu-eli-mcp": { "command": "python", "args": ["-m", "hu_eli_mcp"] } } }

Do not turn Smart App Control off to work around this - it cannot be re-enabled without reinstalling Windows.

Design

Public data only. Read-only against the keyless, official njt.jog.gov.hu; nothing is sent beyond the ELI path being resolved. Honors robots.txt (never calls /search/*).
Audit log. Every call appends one JSON line to ~/.matematic/audit/hu-eli-mcp.jsonl (AI Act art. 12 record-keeping).
Vendor-neutral. No LLM provider, no telemetry; own backoff + on-disk cache.
No fabrication. The ELI, title and citation are parsed from the resolved document page. If NJT's markup changes, the connector fails loudly rather than returning stale or invented data.

See CONSTITUTION.md (the 4 principles) and DISCOVERY.md (how the source was mapped, including the njt.hu → njt.jog.gov.hu domain discovery and the issuer-code casing gotcha).

Tests

pytest tests/test_instructions_drift.py   # offline
pytest tests/test_smoke.py                 # live NJT

Licence

Apache-2.0. The Hungarian legislation served is official public data of Hungary; this connector adds no rights over it.

Available Tools

6 tools

hu_coverageA

Read-onlyIdempotent

Declare what this connector covers, how it is sourced, and what it does NOT cover.

Call this before telling a user that the law "does not contain" something, and whenever a search comes back empty: the absence may be a gap in this connector rather than in the law. Every gap carries a fallback saying where to look instead.

Returns: Coverage with families, an as-of note, and a non-empty list of known gaps.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	No
`families`	No
`as_of_note`	Yes	States what the dates mean, and what they do not promise.
`known_gaps`	No	Never empty. An empty list would mean 'not checked', not 'no gaps'.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare openWorldHint and readOnlyHint, but the description meaningfully expands on them by explaining that an empty search result might reflect a connector gap rather than an absence in the law. It also discloses that every gap includes a fallback and that the result has an as-of note, adding value beyond the structured 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 compact and well-organized: it front-loads the tool's purpose, follows with precise usage triggers, and ends with the return shape. Every sentence earns its place with no filler.

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 parameterless, read-only coverage tool with a documented output schema, the description provides the necessary operational context: when to call it, what to expect from it, and how to interpret empty results. It is complete for an agent to invoke 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 tool has zero parameters, so the baseline is satisfied; there is no input schema to elaborate on. The description focuses on return contents instead, which is appropriate for a parameterless metadata tool.

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: declaring what the connector covers, how it is sourced, and what it does not cover. It is distinct from sibling content-retrieval tools like hu_get_act or hu_list_doc_types, so an agent can select it appropriately.

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 gives explicit trigger conditions: call before telling the user the law 'does not contain' something, and whenever a search comes back empty. It does not explicitly contrast against sibling tools or state when not to use it, but it provides strong, clear context for when it is needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hu_get_actA

Read-onlyIdempotent

Fetch metadata for a Hungarian Act (torveny) by its ELI (year + serial).

ParametersJSON Schema

Name	Required	Description	Default
`year`	Yes	4-digit year, e.g. ``"2013"``.
`serial`	Yes	the Act's serial number within that year, e.g. ``"5"`` (2013. evi V. torveny is Act no. 5 of 2013, the Hungarian Civil Code).

Output Schema

ParametersJSON Schema

Name	Required	Description
`year`	No
`title`	No
`issuer`	No
`serial`	No
`eli_uri`	No
`doc_type`	No
`subtitle`	No
`source_url`	No
`dataset_note`	No
`in_force_date`	No
`human_readable_citation`	No

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false, covering key behavioral traits. The description adds no additional context (e.g., return format, auth, rate limits) but is fully consistent with the annotations, earning a neutral score.

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 a single, front-loaded sentence with no redundant words. It efficiently conveys the tool's purpose and identifier format.

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 simple tool complexity, full input schema, output schema presence, and comprehensive annotations, the description is complete enough for correct invocation. It states the purpose clearly and does not need to explain return values or safety, as those are covered by other structured fields.

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 100%, so the schema already fully documents the year and serial parameters. The description's mention of ELI provides a small clarifying connection but does not meaningfully extend parameter semantics.

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 a specific verb+resource+identifier: 'Fetch metadata for a Hungarian Act (torveny) by its ELI (year + serial)'. It clearly distinguishes from siblings like hu_get_text by focusing on metadata rather than content.

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 gives no guidance on when to use this tool versus alternatives such as hu_get_text or hu_get_legislation. It does not mention prerequisites, exclusions, or alternative tools, leaving usage only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hu_get_legislationA

Read-onlyIdempotent

Fetch metadata for any Hungarian legislation by its ELI (type + year + issuer + serial).

Use this for anything other than Acts (torveny) - government decrees, ministerial decrees, etc. Use hu_list_doc_types for valid doc_type codes and hu_list_issuers for valid issuer codes (issuer codes are case-sensitive, e.g. Korm for Government).

ParametersJSON Schema

Name	Required	Description
`year`	Yes	4-digit year, e.g. ``"2016"``.
`issuer`	Yes	NJT issuer code, case-sensitive, e.g. ``"Korm"`` (Government).
`serial`	Yes	the document's serial number within that year, e.g. ``"428"``.
`doc_type`	Yes	NJT type code, e.g. ``"R"`` (rendelet / decree).

Output Schema

ParametersJSON Schema

Name	Required	Description
`year`	No
`title`	No
`issuer`	No
`serial`	No
`eli_uri`	No
`doc_type`	No
`subtitle`	No
`source_url`	No
`dataset_note`	No
`in_force_date`	No
`human_readable_citation`	No

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds that it returns metadata and notes case-sensitivity of issuer codes, but does not add context like rate limits, pagination, or error behavior. It is consistent with annotations and provides some added detail.

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 two sentences, front-loaded with the primary purpose and followed by usage guidance. No word is wasted; it is efficient and well-structured.

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 are rich, the description adequately explains what the tool does, when to use it, and how to find valid parameter values. It is complete for a simple read-only metadata fetch 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?

Schema coverage is 100% with each parameter having descriptions and examples. The description adds the conceptual ELI composition ('type + year + issuer + serial') which helps, but does not introduce new parameter semantics beyond what the schema already documents.

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 'Fetch metadata for any Hungarian legislation by its ELI (type + year + issuer + serial)', using a specific verb and resource. It also differentiates from sibling tools by explicitly excluding Acts, which distinguishes it from hu_get_act.

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 says 'Use this for anything other than Acts' and directs users to hu_list_doc_types and hu_list_issuers for valid codes. This provides clear when-to-use and when-not-to-use guidance with named alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hu_get_textA

Read-onlyIdempotent

Fetch the full document HTML content of a Hungarian piece of legislation.

For Acts (torveny), pass doc_type="TV" and omit issuer. For anything else, pass the issuer code (case-sensitive - use hu_list_issuers).

ParametersJSON Schema

Name	Required	Description
`year`	Yes	4-digit year.
`issuer`	No	NJT issuer code, case-sensitive (required for everything except `"TV"`).
`serial`	Yes	the document's serial number within that year.
`doc_type`	Yes	NJT type code, e.g. ``"TV"`` (torveny / Act) or ``"R"`` (rendelet / decree).

Output Schema

ParametersJSON Schema

Name	Required	Description
`year`	Yes
`title`	No
`format`	No
`issuer`	No
`serial`	Yes
`content`	No
`eli_uri`	No
`doc_type`	Yes
`subtitle`	No
`byte_size`	No
`source_url`	No
`dataset_note`	No
`in_force_date`	No
`human_readable_citation`	No

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark the tool as read-only, idempotent, and non-destructive, so the description doesn't need to restate safety. It adds value by disclosing that the output is HTML content, that issuer codes are case-sensitive, and that the tool behaves differently for Acts vs. other document types, which enriches the behavioral understanding.

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 extremely concise: two short sentences that front-load the main purpose, followed by a focused usage note. Every word contributes, with no repetition or filler, making it easy to parse quickly.

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 read-only annotations, full schema coverage, and the presence of an output schema, the description fully covers the essential use cases. It explains the key distinction between Acts and other documents, which is the main contextual complexity, and doesn't leave obvious gaps for a tool of this simplicity.

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 schema covers all four parameters with descriptions, giving a baseline of 3. The description elevates this by explaining the relationship between doc_type and issuer (omit issuer for TV, require issuer otherwise) and providing concrete examples like 'TV' and 'R'. This goes beyond mere parameter listing.

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 opens with a specific verb and resource: 'Fetch the full document HTML content of a Hungarian piece of legislation.' This clearly states the tool's function, and the subsequent guidance about Acts vs. other types differentiates it from sibling tools like hu_get_act or hu_get_legislation.

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 tells when to pass doc_type="TV" and omit issuer, and when to pass the issuer code, even directing users to hu_list_issuers for valid codes. This provides concrete conditions for use and points to a sibling tool, making usage guidance clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hu_list_doc_typesA

Read-onlyIdempotent

List valid NJT document-type codes (e.g. TV=Act, R=decree) from /eli/tipuskodok.

Returns: DocTypeList with items: list[DocTypeInfo] (code + Hungarian name).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`items`	No
`dataset_note`	No

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds behavioral context by specifying the source endpoint and the return structure (DocTypeList with items of code+name), which goes 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 compact and front-loaded with the core function, followed by a clear return specification. Every sentence adds useful information without repetition or fluff.

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 parameterless list tool, the description fully covers what it does, where it gets data, and what it returns. The provided output schema and examples complete the picture, making it sufficient for an agent to invoke 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 tool takes zero parameters, and the schema coverage is 100% (empty schema). The description correctly notes that no parameters are needed, so there is no gap to fill; the baseline of 4 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 the tool lists valid NJT document-type codes, with examples (TV=Act, R=decree) and the source endpoint /eli/tipuskodok. This specific verb+resource distinguishes it from sibling tools like hu_get_text or hu_list_issuers.

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?

Usage is implied by the tool's purpose: it is a list operation that provides codes for use with other tools. However, there is no explicit guidance on when to prefer this tool over alternatives or mention that it might be a prerequisite for fetch operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hu_list_issuersA

Read-onlyIdempotent

List valid NJT issuer codes (case-sensitive, e.g. Korm=Government) from /eli/kibocsatokodok.

Returns: IssuerList with items: list[IssuerInfo] (code + Hungarian name).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`items`	No
`dataset_note`	No

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only and idempotent behavior, so the bar is lower. The description adds valuable behavioral context by noting case-sensitivity, providing an example, and specifying the return format (IssuerList with items). This goes 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 extremely concise—two sentences, with the main action in the first sentence and return details in the second. Every sentence adds value and there is no redundant information.

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 (no parameters, output schema present), the description is fully complete. It states what the tool returns and even includes the source path, which is sufficient for an agent to use it 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 tool has zero parameters, and schema coverage is 100% (empty schema). The description doesn't need to explain parameter semantics, and it doesn't; the baseline of 4 applies because there are no parameters to clarify.

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 with a specific verb and resource: 'List valid NJT issuer codes'. It also provides a concrete example and source path, making it distinct from sibling tools like hu_get_text or hu_list_doc_types.

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 clearly implies when to use the tool (to retrieve issuer codes), and no exclusions or alternatives are needed since the tool is simple and self-contained. It doesn't explicitly name alternative tools, but the context makes the usage obvious.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

1 tool updatev0.3.3Aug 28, 2026
- Addedhu_coverage
5 tool updatesv0.2.1Aug 5, 2026
- First observedhu_get_act
- First observedhu_get_legislation
- First observedhu_get_text
- First observedhu_list_doc_types
- First observedhu_list_issuers

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: two list reference data (doc types, issuers), two fetch metadata (one specific to Acts, one general), and one fetches full text content. No overlapping purposes exist.

Naming Consistency5/5

All tool names follow a consistent pattern: 'hu_' prefix + verb_noun in snake_case (e.g., hu_get_text, hu_list_doc_types). Naming is uniform and predictable.

Tool Count5/5

5 tools is well-scoped for a legislation lookup service. Each tool serves a necessary function, and the count is within the ideal 3-15 range.

Completeness5/5

The tool set covers the complete workflow for retrieving Hungarian legislation by ELI: listing valid reference codes, fetching metadata, and fetching content. No essential operations are missing for the stated purpose.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

kvasir — verifiable German, Austrian, Swiss & EU lawOAuth
legal.kvasir
Resolve, search and verify legal citations against the official sources, with provenance.
Legal & Compliance Search
2
PRIMAMCP
io.github.PLANIT-TECH
Verified, citable German & EU law for any LLM. Daily updates from official sources, hosted in DE.
Legal & Compliance Government Data Open Data
110
LawbsterOAuth
io.github.PLANIT-TECH
Verified, citable German & EU law for any LLM. Daily updates from official sources, hosted in DE.
Legal & Compliance Documentation Access
210
Lex — Temporal Luxembourg and EU Law A
io.github.SFHAJJI
Temporal search and comparison for official Luxembourg and reviewed EU law, with provenance.
Legal & Compliance Search Government Data
1019

Related MCP Servers

mcp-eur-lex
Legal & Compliance Government Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables searching and quoting EU legislation with verifiable EUR-Lex citations, including GDPR, NIS2, DORA, and the EU AI Act.
Updated 11 days ago (2026-08-26 17:05 UTC)
17
MIT
Hungarian Legislation MCP
Legal & Compliance Search Government Data
gergototh1
A
license
Not graded
quality
F
maintenance
Query 4,326 Hungarian laws (Ptk., Mt., Btk., etc.) from MCP-compatible clients. Includes full-text search, citation validation, and EU law mapping.
Updated 5 months ago (2026-03-27 08:02 UTC)
106
9
Apache 2.0
Law7 MCP
Legal & Compliance Search RAG Systems
mikhashev
F
license
Not graded
quality
D
maintenance
Provides AI assistants with up-to-date legal documents from official sources, enabling accurate legal information retrieval and analysis.
Updated 5 months ago (2026-03-29 19:04 UTC)
17
-
Romanian Law MCP Server
Legal & Compliance Search Government Data
Ansvar-Systems
A
license
Not graded
quality
F
maintenance
Enables querying and searching Romanian legislation, including statutes, provisions, and EU law integration, directly from AI clients.
Updated 2 months ago (2026-07-07 03:56 UTC)
98
5
Apache 2.0

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/matematicsolutions/hu-eli-mcp'

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