This server provides a read-only interface to query Belgian legislation from the official gazette (Moniteur Belge / Belgisch Staatsblad) using ELI (European Legislation Identifier) coordinates. No API key is required.
be_get_act – Fetch metadata for a Belgian legal act by its ELI coordinates (doc_type, year, month, day, numac), including title, source authority, publication/entry-into-force dates, table of contents, ELI URI, and human-readable citation.
be_get_text – Retrieve the verbatim consolidated text of an act in French (default), Dutch, or German.
be_list_year – List all acts of a given type for a specific year, returning NUMAC identifiers, ELI URIs, publication dates, and best-effort titles — useful for discovering coordinates to use with the other tools.
Supported document types: loi, decret, ordonnance, arrete, constitution
Key constraints:
Read-only — never modifies official text (only writes local audit logs)
No free-text search — acts must be discovered via ELI coordinates or year-based browsing
Responses include eli_uri, human_readable_citation, and source_url for verifiability
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@be-eli-mcp Get details for act loi/2020/06/01/2020001234"
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.
An MCP server for Belgian legislation via [Moniteur Belge / Belgisch Staatsblad] (https://www.ejustice.just.fgov.be), the official gazette of the Belgian Federal Public Service Justice. It fetches act metadata and full text by ELI coordinates, with verifiable citations. Part of the eu-legal-mcp line of national legal connectors by MateMatic.
Belgian legislation is addressed by ELI coordinates - type / year / month / day / numac
(the Belgian legislative numbering system) - at
https://www.ejustice.just.fgov.be/eli/{type}/{yyyy}/{mm}/{dd}/{numac}/justel. Every response
carries a native eli_uri, a human_readable_citation and a source_url.
Read-only. The server only queries ejustice.just.fgov.be and writes a local audit log. It never modifies official text.
Belgium is trilingual (French / Dutch / German).
human_readable_citationdefaults to the French form by LDH convention; usebe_get_text(language=...)for Dutch (Belgisch Staatsblad) or German. See CONSTITUTION.md Art. 4 for the full caveat.
Tool | What it does |
| Metadata for an act by its ELI coordinates. |
| The verbatim consolidated text ("Texte"/"Tekst" section) in |
| Browse a year's listing for one |
| Declare what this connector covers, when each family was captured, and - explicitly - what it does NOT cover. Every gap carries a fallback. |
There is no free-text search: ejustice.just.fgov.be exposes no keyword-search API. Discover
acts by ELI coordinates (from a citation you already hold) or by browsing be_list_year.
Related MCP server: Belgian Law MCP Server
ejustice.just.fgov.be is keyless. Configuration is optional:
Variable | Meaning |
| ejustice host (default |
| Disk cache dir (default |
| Audit log dir (default |
Copy .mcp.json.example to your MCP client config.
py -3.13 -m venv .venv
.\.venv\Scripts\python.exe -m pip install -e ".[dev]" # Windows
# or: python -m pip install -e ".[dev]" # POSIXSmart App Control blocks unsigned executables, which covers uvx.exe, pip.exe
and the be-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 be-eli-mcp
python -m be_eli_mcppip.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 be_eli_mcp.
{ "mcpServers": { "be-eli-mcp": { "command": "python", "args": ["-m", "be_eli_mcp"] } } }Do not turn Smart App Control off to work around this - it cannot be re-enabled without reinstalling Windows.
pytest tests/test_instructions_drift.py tests/test_parse.py # offline
pytest tests/test_smoke.py -v # live, hits ejustice.just.fgov.beApache-2.0. Moniteur Belge / Belgisch Staatsblad content is © the Belgian federal state; this software only retrieves and cites it. See CONSTITUTION.md Art. 1 for a note on the licence status of the source data (widely described as CC0 by third-party catalogs; not independently re-verified against ejustice.just.fgov.be's own terms page in this project).
Fetch metadata for a Belgian act by its ELI coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | publication day, 1-31. | |
| year | Yes | publication year, e.g. ``2020``. | |
| month | Yes | publication month, 1-12. | |
| numac | Yes | the NUMAC identifier (Belgian legislative numbering system), e.g. ``2020040054``. | |
| doc_type | Yes | one of ``loi``, ``decret``, ``ordonnance``, ``arrete``, ``constitution``. |
| Name | Required | Description |
|---|---|---|
| day | No | |
| year | No | |
| month | No | |
| numac | No | |
| title | No | |
| eli_uri | No | |
| doc_type | No | |
| language | No | |
| source_url | No | |
| dataset_note | No | |
| dossier_number | No | |
| entry_into_force | No | |
| publication_date | No | |
| source_authority | No | |
| table_of_contents | No | |
| human_readable_citation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description 'Fetch metadata' is consistent but adds no extra behavioral context (e.g., permissions, limits, or side effects) beyond what annotations provide. The value added is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the main purpose, no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is short but adequate given the existence of a full output schema and 100% parameter coverage in the schema. It explains what the tool does and how to identify the act. Could be slightly more detailed about the concept of ELI coordinates, but the schema fills the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description hints at ELI coordinates but doesn't add new semantic meaning beyond the schema's parameter descriptions (e.g., doc_type enum, date fields, numac). No additional clarification on formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Fetch', the resource 'metadata for a Belgian act', and the method 'by its ELI coordinates'. It distinguishes from siblings 'be_get_text' (which likely fetches text) and 'be_list_year' (which lists acts by year).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'be_get_text' or 'be_list_year'. It only states what it does without indicating prerequisites or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the verbatim consolidated text of a Belgian act.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | publication day, 1-31. | |
| year | Yes | publication year. | |
| month | Yes | publication month, 1-12. | |
| numac | Yes | the NUMAC identifier. | |
| doc_type | Yes | one of ``loi``, ``decret``, ``ordonnance``, ``arrete``, ``constitution``. | |
| language | No | ``fr`` (default), ``nl`` or ``de``. | fr |
| Name | Required | Description |
|---|---|---|
| day | No | |
| year | No | |
| month | No | |
| numac | No | |
| content | No | |
| eli_uri | No | |
| variant | No | |
| doc_type | No | |
| language | No | |
| byte_size | No | |
| source_url | No | |
| dataset_note | No | |
| human_readable_citation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive behavior. The description adds 'verbatim consolidated text' but no further behavioral traits; 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 9 words efficiently conveys the purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple fetch tool with good annotations, but it lacks usage context to differentiate from sibling tools, and does not explain 'consolidated'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no extra parameter meaning beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('verbatim consolidated text of a Belgian act'), clearly distinguishing from siblings like 'be_get_act' and 'be_list_year'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse a year's listing of a Belgian legislation type, to discover NUMAC coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | e.g. ``2020``. | |
| doc_type | Yes | one of ``loi``, ``decret``, ``ordonnance``, ``arrete``, ``constitution``. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat these. The description adds value by specifying that the tool is used to 'discover NUMAC coordinates,' which clarifies the behavior beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the purpose and outcome without any waste. It is front-loaded with the action and resource, making it efficient and easy to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, output schema present), the description explains the purpose and the output (NUMAC coordinates) sufficiently. Annotations cover safety and idempotency, and sibling tools provide context. No gaps remain for this listing-oriented tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with clear descriptions (year as integer with example, doc_type as enum). The description does not add any additional semantic meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs and resources: 'Browse a year's listing of a Belgian legislation type' and explicitly mentions the outcome 'to discover NUMAC coordinates'. It clearly states what the tool does but does not explicitly differentiate it from sibling tools be_get_act and be_get_text, though the listing vs retrieval distinction is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for browsing and discovering NUMAC coordinates, but it does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. Sibling tools are listed but not compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0be_get_actbe_get_textbe_list_yearEach tool serves a distinct purpose: fetching metadata, fetching text, and browsing year listings. No overlap in functionality.
All tools follow a 'be_verb_noun' pattern (be_get_act, be_get_text, be_list_year). Consistent prefix and verb usage, though 'year' as a noun slightly diverges from the resource type pattern.
With 3 tools, the server is minimal but covers a basic workflow for Belgian legislation. The count is appropriate for a focused domain, though a small set may limit flexibility.
The server covers metadata retrieval, text retrieval, and year browsing. However, it lacks search or filter capabilities, which are common in legal databases, leaving some discovery gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search Belgian & EU legislation: verbatim article text, per-article links, legal Q&A.
Official EUR-Lex, UK, US, and gazette search, metadata fetch, and change-only watches.
Temporal search and comparison for official Luxembourg and reviewed EU law, with provenance.
Resolve, search and verify legal citations against the official sources, with provenance.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/matematicsolutions/be-eli-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
