What can you do with this server?

This server exposes a core read-only LexAPI MCP toolset for searching and retrieving EU legal documents and analyzing citation relationships and semantic content. * Search EUR-Lex with structured filters (text, date range, document type, author, language, text scope) and pagination. * Fetch full parsed document content by CELEX, including metadata, articles/sections/tables/annexes, with optional forced live fetch. * Fetch metadata only for a CELEX, or parse a document from a pasted EUR-Lex URL. * List recently published Official Journal documents, filterable by days, type, author, language, and limit. * Explore citations: inbound citing documents, outbound cited documents, and both directions with per-edge-type counts (reference, amendment, repeal, implementation, legal-basis, proposal). * Run embedding-based semantic search over EU legislation at article level and EU case law; case-law search supports filters and minimum score. Semantic search requires a paid plan and returns 403 on FREE. * This schema does not expose the README's national-law, webhook, version-history, citation-path/related/stats/export, or batch tools.

How do I use LexAPI MCP?

1. Click on "Deploy 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., "@LexAPI MCP summarize Article 17 of the GDPR" 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.

LexAPI MCP

Official

by Lex-API

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

LexAPI MCP

Model Context Protocol server for LexAPI — EU law for AI assistants: EUR-Lex legislation parsed to article level, CJEU case law, the typed citation graph, and semantic search (including the law as in force on a past date). Works with Claude, Cursor, VS Code and any other MCP client.

Ask your assistant "what does Article 17 GDPR require?", "which acts amended REACH?" or "what were the own-funds requirements for banks in June 2019?" — the model calls LexAPI and answers from the source text, with CELEX citations.

You need a LexAPI account. With the hosted server you just sign in with LexAPI from your MCP client; with the npm package (or if you prefer), use an API key from lex-api.com/dashboard. There is a FREE plan, no card required, with enough credits to try the read tools; current allowances are on lex-api.com/pricing.

The server is hosted at https://mcp.lex-api.com/v1 (Streamable HTTP). Add that URL to your client and sign in with your LexAPI account when it asks — no key to copy. You see a LexAPI consent page listing what the connection can do; calls are billed to your plan exactly like your own API key, and you can disconnect the app at any time under Dashboard → Connected apps (that revokes it immediately).

claude.ai and Claude Desktop

Settings → Connectors → Add custom connector, name it LexAPI, URL https://mcp.lex-api.com/v1, then Connect and sign in. Connectors added on claude.ai are also available in Claude Desktop (same account).

Claude Code

claude mcp add --transport http lexapi https://mcp.lex-api.com/v1

Then run /mcp in Claude Code and choose Authenticate for lexapi; your browser opens the LexAPI sign-in.

Other MCP clients

Any client that implements MCP authorization (OAuth 2.1 with protected-resource discovery) connects the same way: point it at https://mcp.lex-api.com/v1. The server answers an unauthenticated request with 401 and WWW-Authenticate: Bearer … resource_metadata="https://mcp.lex-api.com/.well-known/oauth-protected-resource/v1"; the client discovers LexAPI (https://lex-api.com) as the authorization server from there.

With an API key instead

Clients without OAuth support — or scripts — send a key from the dashboard as Authorization: Bearer lex_... (or x-api-key: lex_...):

claude mcp add --transport http lexapi https://mcp.lex-api.com/v1 --header "Authorization: Bearer lex_..."

Related MCP server: eurlex-mcp-server

Run it locally (npm, API key)

Claude Desktop (local)

Add to claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "lexapi": {
      "command": "npx",
      "args": ["-y", "@lexapi/mcp"],
      "env": { "LEXAPI_API_KEY": "lex_..." }
    }
  }
}

Restart Claude Desktop.

Claude Code (local)

claude mcp add lexapi --env LEXAPI_API_KEY=lex_... -- npx -y @lexapi/mcp

Cursor, VS Code and other stdio clients

Run npx -y @lexapi/mcp with LEXAPI_API_KEY in the environment (Cursor: ~/.cursor/mcp.json; VS Code: .vscode/mcp.json; same command / args / env shape as above).

The npm package needs Node.js 20 or newer. It uses an API key; signing in with LexAPI is a feature of the hosted server.

Tools

Every call is billed from your LexAPI credit pool exactly like the REST endpoint it wraps; each tool's description states its cost so the model can see it.

Tool	What it does	Credits
`lex_semantic_legislation`	Find legislation articles by meaning. `asOf` returns the text in force on a date. Consolidated hits are labelled, with the authentic act to cite.	5 (+ up to 5 per live version fetch with `asOf`)
`lex_semantic_case_law`	Find judgments, orders and AG opinions by meaning; `hyde` for terse queries; court / date / case-number filters.	5 (15 with `hyde`)
`lex_search`	Structured EUR-Lex search: text, dates, type, author, procedure, collection.	3 per page
`lex_recent_documents`	What was published in the last N days.	3 per 10 results
`lex_resolve`	URL / ELI / ECLI → CELEX.	1
`lex_get_document`	A document by CELEX — an outline first for large acts, then `articleId` or `include` parts; language and fallback languages.	1 corpus · 4 Cellar · 5 live
`lex_get_documents_batch`	Up to 50 documents at once (plan-capped).	per document, as above
`lex_get_metadata`	Metadata only.	1 · 4 · 5
`lex_get_document_by_url`	A document from a pasted EUR-Lex URL.	1 · 4 · 5
`lex_document_versions`	LexAPI's observed version history of a document.	1
`lex_get_document_version`	One observed snapshot, by version number or date.	1
`lex_cited_by`	Documents citing / amending / correcting / repealing an act. `includeNational` adds national neighbours (BUSINESS+).	1
`lex_cites`	What a document cites. `includeNational` adds national neighbours (BUSINESS+).	1
`lex_citation_network`	Both directions in one call. `includeNational` adds national neighbours (BUSINESS+).	20
`lex_citation_path`	Shortest citation chain between two documents. `includeNational` follows national documents (BUSINESS+).	20
`lex_related`	Documents citing the same acts (bibliographic coupling). `includeNational` considers national documents (BUSINESS+).	20
`lex_citation_stats`	Citation graph totals and most-cited documents. `includeNational` counts national documents (BUSINESS+).	20
`lex_extract_citations`	Add a document's outbound citations to the graph.	5 (1 if already done)
`lex_export`	Corpus rows by type (exact label, any case) or type family (`documentTypeCode`), author, collection, language, document date (`dateFrom`/`dateTo`), `changedSince` or `fetchedSince` (BUSINESS plans and above).	1 per row returned, at least 1 per call (1-credit admission, rows reserved up to `limit`, unreturned rows refunded; 402 if the pool cannot cover the reservation)
`lex_national_coverage`	Which countries' national law LexAPI covers and what's live in each (sources, licences, attribution). Call first.	free
`lex_list_national_documents`	Browse a country's national legislation/case law by title or type; cursor paging past the first 1,000 rows.	3 per call
`lex_get_national_document`	A national document by id. Always served from the corpus.	5 → 1
`lex_national_semantic_case_law`	Semantic search over one country's case law.	5
`lex_national_semantic_legislation`	Semantic search over one country's legislation.	5
`lex_info`	Your plan, credit balance and limits.	free
`lex_list_webhooks` · `lex_get_webhook`	Your webhooks and their deliveries.	free
`lex_create_webhook` · `lex_update_webhook` · `lex_delete_webhook` · `lex_test_webhook`	Webhooks for new documents and for changes to watched acts (paid plans). The URL must be a public https URL (port 443/8443, no internal hosts or private addresses) — checked here as well as by the API.	free

National law

lex_national_coverage, lex_list_national_documents, lex_get_national_document, lex_national_semantic_case_law and lex_national_semantic_legislation cover member-state legislation and case law alongside the EU_LAW tools above. A country can be registered on LexAPI before it is made available to customers — always call lex_national_coverage first; the other tools answer an error for a country that isn't live yet. The citation-graph tools (lex_cited_by, lex_cites, lex_citation_network, lex_citation_path, lex_related, lex_citation_stats) accept national document ids directly (e.g. "AT-NOR-12345") and an includeNational option to pull in national neighbours — BUSINESS, SCALE and ENTERPRISE only, 403 below that. National results have the same fields in every country (LexAPI API 2.8.0): documentKind (act | decision) everywhere, and on a decision court, chamber, caseNumbers and citedNorms — whatever the source calls them. Every national result carries attribution (the official source and its licence, e.g. RIS, gesetze-im-internet.de, Normattiva, Légifrance/Judilibre, the Rechtspraak open data) — show it to the user alongside anything quoted. On FREE/STARTER/PROFESSIONAL plans, national-law calls also draw from a separate monthly allowance (reported as allowance on each response); BUSINESS and higher have no separate limit. A document its source withdrew (a takedown, a pseudonymisation fix) answers a distinct error — nothing of it is served, not even the title; the model is told not to retry and to drop any cached copy.

How results are shaped for models

Compact output. Responses drop envelopes and duplicate legacy fields. Documents keep their metadata, textAvailability (why text is missing, which languages exist, a pointer to the latest consolidated version) and language-fallback labels.
Large documents. lex_get_document returns the whole body when it fits maxChars (default 40,000 characters), otherwise an outline (article ids, section tree, counts). Fetch an article with articleId or parts with include; long parts continue with offset.
Consolidated texts are not authentic. Consolidated versions carry consolidated: true, consolidatedAsOf, baseCelex and a note: quote them, cite the act as published in the Official Journal.
asOf. Each legislation hit says whether it carries the version in force on that date (asOfResolved, asOfVersion); unresolved hits keep the current text with an asOfReason, and the response warns about them.
Errors say what to do. A 402 states the credits needed, the credits left and the reset date; a 429 says how long to wait.

Configuration

Env var	Default	Purpose
`LEXAPI_API_KEY`	(required)	Your API key from lex-api.com/dashboard.
`LEXAPI_BASE_URL`	`https://lex-api.com/api/v1`	Override for staging or self-hosting.
`LEXAPI_MCP_READ_ONLY`	off	`true` hides (and refuses) every tool that is not read-only: webhook create / update / delete / test, and `lex_extract_citations` (it writes to the shared citation graph and costs credits).
`LEXAPI_TIMEOUT_MS`	`55000`	Deadline for one tool call towards LexAPI, retries included. Raise it only together with your MCP client's own tool timeout.
`LEXAPI_MCP_ALLOWED_ORIGINS`	(none)	Hosted HTTP server only: browser `Origin`s allowed to call it (comma-separated, `*` for any). Requests without an `Origin` header (all non-browser clients) are always allowed.

The key is sent only as the x-api-key header to LexAPI; it is never logged or included in tool output. A LEXAPI_API_KEY containing whitespace or control characters (e.g. a multi-line paste) is rejected at startup.

Hosting the HTTP server

npm run start:http (or the Dockerfile) runs the Streamable HTTP transport (POST /v1, GET /health). Self-hosted, it accepts LexAPI API keys (Authorization: Bearer lex_… or x-api-key: lex_…); a request without one gets 401. A value that cannot be an API key (it contains a . or is longer than 8192 characters) is answered 401 and never forwarded.

Env var	Default	Purpose
`PORT`	`3000`	Listen port.
`LEXAPI_BASE_URL`	`https://lex-api.com/api/v1`	LexAPI REST base.

Sign in with LexAPI is a feature of the hosted server at https://mcp.lex-api.com/v1: it needs an OAuth client registered with LexAPI, so a self-hosted copy runs with API keys only. The OAuth-related settings in src/oauth/config.ts (LEXAPI_OAUTH_*, LEXAPI_MCP_*) are for that deployment; the server refuses to start if they are set incompletely.

/health returns status, name, version, tools and oauth (whether sign-in is enabled). It never contains addresses, tokens or configuration values.

Timeouts. MCP clients give up on a tool call after their own timeout (60 s by default in the official SDK; Claude Code: MCP_TOOL_TIMEOUT). A first, live EUR-Lex fetch can take longer. The server gives each tool call one 55 s deadline — retries and rate-limit waits included — and then returns a message the model can act on, instead of the client's generic timeout error. When the client sends a progress token, the server also sends a progress notification every 10 s; whether that keeps the call alive is up to the client (the official SDK only extends its timeout on progress when the caller opts into resetTimeoutOnProgress, and a server cannot detect that), so the deadline stays 55 s. If you raise your client's timeout, raise LEXAPI_TIMEOUT_MS to match. Cancelling a call aborts the request to LexAPI.

Troubleshooting

LEXAPI_API_KEY is not set — the variable isn't reaching the spawned process; check the env block of your MCP client config.
LexAPI error 401 — the key is wrong or revoked; create a new one at the dashboard.
Hosted server: "LexAPI sign-in expired or was revoked" — the connection was disconnected (for example from the dashboard); reconnect LexAPI in your client to sign in again.
Hosted server: 403 Subscription inactive — the signed-in account's paid plan is not active; the same as with an API key.
LexAPI error 402 (CREDITS_EXHAUSTED) — the monthly credit pool is used up. The message gives the reset date; top-ups and upgrades are on the dashboard.
LexAPI error 429 — the per-minute rate limit of your key (FREE: 15 per minute). Short waits are retried once automatically; otherwise the message says how long to wait.
LexAPI error 403 — the plan doesn't include the feature (e.g. export below BUSINESS, or semantic search on a legacy pre-credits FREE plan).
LexAPI error 400 creating a webhook — the details name the problem (unsupported criteria, a watch list over the plan limit, or the plan's webhook limit; FREE has none).

Development

git clone https://github.com/Lex-API/lexapi-mcp.git
cd lexapi-mcp
npm install
npm test                       # build + unit and transport tests (mocked API, no network)
npm run typecheck && npm run lint
node scripts/smoke-stdio.mjs   # stdio smoke test against a local mock API
LEXAPI_API_KEY=lex_... node scripts/smoke-stdio.mjs --live   # against the real API (spends roughly 6–25 credits)

npm run start:http runs the hosted Streamable HTTP transport (POST /v1, GET /health, port from PORT, default 3000; see Hosting the HTTP server above); the Dockerfile builds it. The OAuth tests run against a local mock authorization server (tests/oauth-mock.ts), no network.

License

MIT

Available Tools

10 tools

lex_citation_networkAInspect

Fetch both inbound and outbound citations for a CELEX in one call, with per-edge-type counts. Use when the user wants a holistic view of how a document sits in the citation graph.

Name	Required	Description	Default
`celexNumber`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description bears full burden. It states it fetches citations with counts, implying a read operation, but does not disclose details like error handling, rate limits, or what happens if the CELEX is not found. It is adequate but not comprehensive.

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-loading the key action and result. No extraneous words, every sentence adds value.

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 tool with one parameter, no annotations, and no output schema, the description provides the essential information: what it does, when to use it, and what it returns (citations with counts). Could mention pagination or limits but is largely complete.

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 coverage is 0%, so the description must compensate. The single parameter 'celexNumber' is explained by context ('for a CELEX'), and the description clarifies its role. It could specify the format but is sufficient for 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 the action ('fetch'), the resource ('citations for a CELEX'), and the scope ('both inbound and outbound in one call'). It also mentions per-edge-type counts, distinguishing it from sibling tools like lex_cited_by and lex_cites.

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 a clear use case ('when the user wants a holistic view of how a document sits in the citation graph'). It implicitly contrasts with directional siblings but does not explicitly state when not to use it or provide alternatives.

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

lex_cited_byAInspect

Find documents that cite this CELEX (inbound edges). Returns source documents grouped with their edge type (reference, amendment, repeal, implementation, legal-basis, proposal). Use to see who depends on or modifies a given act.

Name	Required	Description
`celexNumber`	Yes
`citationType`	No	Optionally filter to one edge type.
`limit`	No
`offset`	No

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses that the tool returns source documents grouped with edge types and lists the possible edge types. This covers key behaviors for a citation query tool, though it omits details like pagination handling or error states.

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?

Two sentences: first defines action and output, second gives usage guidance. Every sentence is essential and the purpose is front-loaded. 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?

No output schema exists, so description must explain return values. It does so by stating 'Returns source documents grouped with their edge type' and listing edge types. Parameters celexNumber and citationType are explained. However, pagination (limit/offset) behavior is only in schema, not description. Overall adequate for the tool's complexity.

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 only 25% (only citationType has a description). The tool description explains celexNumber (the CELEX to find citing docs) and mentions citationType for optional filtering. However, it does not describe limit or offset, relying on schema defaults. With low coverage, the description adds moderate value beyond the 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 finds documents citing a given CELEX (inbound edges) and returns them grouped by edge type. The verb 'Find' and resource 'documents that cite this CELEX' are specific. It distinguishes from siblings like lex_cites (outbound) and lex_citation_network (broader network).

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 usage hint: 'Use to see who depends on or modifies a given act.' This gives context for appropriate use. It does not explicitly exclude alternatives or mention when not to use, but the purpose is clear enough.

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

lex_citesAInspect

Find documents this CELEX cites (outbound edges). Returns target documents grouped with their edge type. Use to see what an act relies on, amends, or implements.

Name	Required	Description	Default
`celexNumber`	Yes
`citationType`	No
`limit`	No
`offset`	No

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It states returns are grouped with edge type and gives usage context, but lacks details about pagination, error handling, or side effects. For a read-only tool, this is adequate but not comprehensive.

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?

Two sentences, front-loaded with main action, no wasted words. Efficiently communicates purpose and usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters, no output schema, and no annotations, description is minimal. It covers core functionality but omits pagination details, response format beyond grouping, and potential errors. Adequate for simple use but not fully complete.

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%, requiring description to compensate. However, description only implicitly refers to celexNumber ('this CELEX') and does not explain citationType, limit, or offset. Parameter names are somewhat self-explanatory but description adds no semantic value.

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 verb 'Find documents' and specific resource 'this CELEX cites (outbound edges)'. It distinguishes from sibling lex_cited_by by specifying outbound vs inbound, and mentions grouping by edge type.

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?

Description explicitly says 'Use to see what an act relies on, amends, or implements', providing clear context for when to use. Though it doesn't explicitly mention not to use for inbound citations, the term 'outbound edges' hints at the distinction.

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

lex_get_documentAInspect

Fetch the full parsed content of a single EU document by CELEX number. Returns metadata (title, type, dates, author, ECLI/ELI, keywords) plus structured body (articles, sections, tables, annexes). Articles are individually addressable with id, number, title, and content. Use this when the user has a specific CELEX or wants the body of a known document.

Name	Required	Description	Default
`celexNumber`	Yes	CELEX identifier, e.g. 32016R0679 for the GDPR.
`bypassCorpus`	No	Force a fresh live fetch instead of the cached copy.

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses return structure comprehensively: metadata fields and structured body with articles, sections, etc. Mentions the 'bypassCorpus' parameter for fresh fetch. Lacks minor details like error handling or rate limits.

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?

Extremely concise at two sentences. First sentence states purpose and output clearly. Second sentence provides usage guidance. No unnecessary words; front-loaded with key 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?

For a simple retrieval tool with 2 parameters and no output schema, the description is complete. It explains what it does, when to use it, and what it returns in detail. No gaps for typical use cases.

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% with clear descriptions for both parameters. The description adds context (e.g., 'by CELEX number') but does not significantly extend beyond the schema. 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 'Fetch the full parsed content of a single EU document by CELEX number.' It specifies the verb (Fetch), resource (full parsed content), and method (CELEX number). Differentiates from siblings like 'lex_get_metadata' and 'lex_get_document_by_url' by focusing on full document retrieval by CELEX.

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?

Provides explicit usage guidance: 'Use this when the user has a specific CELEX or wants the body of a known document.' However, it does not explicitly state when not to use it or mention alternatives (though sibling names imply them).

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

lex_get_document_by_urlAInspect

Fetch a parsed document from any EUR-Lex URL — useful when the user pastes a link from their browser. Extracts the CELEX from the URL and returns the same shape as lex_get_document plus sourceUrl and extractedCelex echoes.

Name	Required	Description	Default
`url`	Yes	Any eur-lex.europa.eu URL containing a CELEX: identifier or uri= parameter.

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool extracts CELEX from the URL and returns specific fields, but does not mention behavior for invalid URLs, authentication requirements, rate limits, or any side effects.

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 with no wasted words. It front-loads the main action and efficiently communicates the tool's purpose and key differentiator.

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 tool's simplicity (single parameter, no output schema, no annotations), the description is fairly complete. It explains what it does, when to use it, and how it relates to a sibling. It could mention error handling but is adequate for basic 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?

Schema coverage is 100% with a single parameter already described. The description adds context that the URL must be an eur-lex.europa.eu URL containing a CELEX identifier or uri= parameter, which adds marginal value beyond what the schema already states.

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 fetches a parsed document from any EUR-Lex URL, extracts CELEX, and returns the same shape as lex_get_document plus additional echoes. It distinguishes the tool from its sibling lex_get_document by specifying the output differences.

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 explicitly says 'useful when the user pastes a link from their browser', giving clear usage context. However, it does not mention when not to use this tool or provide alternatives beyond implicit comparison to lex_get_document.

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

lex_get_metadataAInspect

Fetch metadata only for a CELEX (title, dates, type, author, ECLI/ELI, keywords, subjects) — significantly faster than lex_get_document because it skips body parsing. Use this for quick "what is this document" lookups or before deciding whether to fetch the body.

Name	Required	Description	Default
`celexNumber`	Yes	CELEX identifier.

TDQS

A4/5.0

Behavior3/5

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

With no annotations, description discloses key behavioral trait: it skips body parsing (thus faster and lighter). Does not mention safety (read-only) or permissions, but for a metadata fetch tool this is adequate. 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?

Two sentences, no redundant words. Purpose stated upfront, key differentiator in second sentence. Highly efficient.

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?

No output schema, but description lists expected metadata fields (title, dates, etc.), compensating well. Explains speed advantage and use case. For a simple one-parameter tool, this is sufficient for an agent to decide.

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% (celexNumber described with pattern). Description adds no additional parameter-specific meaning beyond the CELEX identifier, but explains what metadata is returned, which indirectly justifies the parameter. Baseline score 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?

Clearly states 'Fetch metadata only for a CELEX' and lists specific metadata fields (title, dates, type, author, ECLI/ELI, keywords, subjects). Distinguishes from sibling lex_get_document by noting it skips body parsing and is faster.

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?

Provides usage context: 'Use this for quick "what is this document" lookups or before deciding whether to fetch the body.' Implicitly excludes use cases needing full content. No explicit when-not-to-use or alternatives beyond lex_get_document, but sufficient guidance.

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

lex_recent_documentsAInspect

List documents published to the Official Journal recently. Default window is 7 days. Filterable by document type, author, and language. Use this when the user asks "what was published this week" or wants a delta over a date window.

Name	Required	Description	Default
`days`	No	Look-back window in days.
`documentType`	No
`author`	No
`language`	No		en
`limit`	No

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so description bears full burden. It states it's a list operation (read-only), default window 7 days, and filterable by type, author, language. Does not disclose if there are rate limits, authentication needs, or what fields are returned.

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?

Two sentences: first states purpose, second provides usage tip. No unnecessary words or redundancy. Front-loaded with core function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, no annotations, and 5 parameters, the description covers basic purpose and filters but omits mention of the limit parameter, return format, and how it relates to other tools (e.g., as a supplement to lex_search). Sufficient for a simple list tool but could be more complete.

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 only 20% (only 'days' has a description). The description mentions default window and filterable options but does not explain the meaning of enum values for documentType, author, language, or the limit parameter. It adds minimal value beyond the 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 action (list) and resource (documents published to the Official Journal recently). It distinguishes itself from siblings like lex_search, which is for general search, by focusing on recent publications.

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?

Provides explicit usage context: use when user asks 'what was published this week' or wants a delta over a date window. However, it does not mention when not to use it or explicitly list alternatives.

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

lex_searchAInspect

Search EUR-Lex with structured filters (free text, date range, document type, author, language). Returns a paginated list of matching documents with CELEX numbers, titles, and dates. Use this when the user wants to find documents matching a topic or filter; use lex_get_document afterwards to fetch full content of a specific result.

Name	Required	Description	Default
`query`	No	Free-text search.
`textScope`	No	Where to apply the query string.
`dateFrom`	No
`dateTo`	No
`year`	No
`documentType`	No
`author`	No
`language`	No		en
`maxPages`	No	Result pages to fetch (clamped by subscription tier).

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden. It discloses that the tool returns a paginated list, mentions the result fields, and notes that maxPages is clamped by subscription tier. This adds useful behavioral context beyond a simple search description.

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?

Two sentences: first defines the tool and its output, second gives usage guidance. Every word earns its place. Front-loaded with the most critical information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters and no output schema, the description covers the main functionality and return format. However, it omits details on pagination behavior (e.g., page size, navigation) and does not elaborate on all parameter constraints. Still, it provides a solid overview.

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 lists the filter categories (free text, date range, document type, author, language) but does not add detailed semantics beyond the schema. Since schema description coverage is only 33%, the description partially compensates by summarizing parameter groups, but lacks specifics on format or values.

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 searches EUR-Lex with structured filters and returns a paginated list of documents with specific fields (CELEX numbers, titles, dates). It distinguishes itself from the sibling tool lex_get_document by advising to use it afterward for full content.

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 says 'Use this when the user wants to find documents matching a topic or filter; use lex_get_document afterwards to fetch full content of a specific result.' This provides clear when-to-use and alternative guidance.

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

lex_semantic_case_lawAInspect

Embedding-based search over EU case law — finds cases by meaning, not exact keywords. Returns relevance-scored matches with ECLI, court, case name/number, and (where available) full text. Requires a paid LexAPI plan; returns 403 on FREE tier.

Name	Required	Description
`query`	Yes
`limit`	No
`min_score`	No	Drop results below this cosine similarity (0–1).
`filters`	No	Optional upstream filters passed through to the semantic backend.

TDQS

A3.9/5.0

Behavior4/5

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

No annotations exist, so the description carries the full burden. It discloses important behavioral traits: requires a paid LexAPI plan, returns 403 on free tier, and returns relevance-scored matches with specific fields. It does not cover pagination or error handling beyond 403.

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 with three short sentences, front-loaded with the key differentiator. Every sentence adds essential information without 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 no output schema, the description adequately covers what is returned (ECLI, court, name, full text). It lacks details on pagination, empty results, or full error handling, but is sufficient for basic usage.

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 coverage is 50% (only min_score and filters have descriptions). The description adds no explanation for parameters; it does not clarify what 'query' or 'limit' mean beyond the schema. The description's value for parameters is minimal.

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 is an embedding-based semantic search over EU case law, finding by meaning rather than keywords. This distinguishes it from sibling tools like lex_search (keyword) and lex_semantic_legislation (semantic for legislation).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for conceptual searches by saying 'finds cases by meaning, not exact keywords', but does not explicitly state when to avoid this tool or provide direct alternatives. It relies on sibling tool names for differentiation.

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

lex_semantic_legislationAInspect

Embedding-based search over EU legislation at article granularity. Returns relevance-scored article hits with parent CELEX, article reference, and law title. Requires a paid LexAPI plan; returns 403 on FREE tier.

Name	Required	Description	Default
`query`	Yes
`limit`	No
`min_score`	No
`filters`	No

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, description carries full disclosure burden. It reveals it's embedding-based, returns relevance scores, and requires a paid plan. However, it omits behaviors like how filters work, pagination, rate limits, or side effects, leaving gaps.

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 three sentences, each carrying essential information: purpose, output details, and prerequisite. No fluff, front-loaded with key verb and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters, no output schema, and no annotations, the description is too brief. It fails to explain parameter usage (e.g., what 'filters' accepts, meaning of 'min_score') and does not fully specify return format, leaving significant gaps for agent invocation.

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 has 0% description coverage, and the description does not explain any parameter semantics (query, limit, min_score, filters). It only describes output fields, so the agent lacks guidance on how to configure inputs meaningfully.

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 performs embedding-based search over EU legislation at article granularity, and lists specific returned fields (parent CELEX, article reference, law title). This distinguishes it from sibling tools like lex_semantic_case_law (case law) and lex_search (likely keyword 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?

Description mentions the paid plan requirement but does not explicitly guide when to use this tool versus alternatives (e.g., keyword search or case law semantic search). Usage context is implied but not delineated.

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.

10 tool updatesv0.1.0Jun 25, 2026
- First observedlex_citation_network
- First observedlex_cited_by
- First observedlex_cites
- First observedlex_get_document
- First observedlex_get_document_by_url
- First observedlex_get_metadata
- First observedlex_recent_documents
- First observedlex_search
- First observedlex_semantic_case_law
- First observedlex_semantic_legislation

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-06-25 01:15 across 10 tools

Disambiguation4/5

Most tools have distinct purposes, but the citation tools (lex_citation_network, lex_cited_by, lex_cites) overlap in scope. However, descriptions clearly differentiate holistic vs directional usage, preventing major confusion.

Naming Consistency3/5

All tools share the 'lex_' prefix, but naming patterns vary: verb_noun (lex_get_document), noun_verb (lex_citation_network), adjective_noun (lex_semantic_case_law), and plain verb (lex_search). This inconsistency may require extra attention.

Tool Count5/5

With 10 tools, the set is well-scoped for a legal document API. Each tool covers a distinct aspect of retrieval and search without feeling bloated or sparse.

Completeness5/5

The tool set covers all essential operations for a read-only EU legal API: search, recent publications, metadata, full document retrieval, citation network (holistic and directional), and semantic search for both case law and legislation. No obvious gaps in core functionality.

Maintenance

ActivityMaintained

ResponsivenessNo recent community issues

Resources

Related MCP Connectors

kvasir — verifiable German, Austrian, Swiss & EU law
legal.kvasir
Resolve, search and verify legal citations against the official sources, with provenance.
Legal & Compliance Search
2
https://kvasir.legal/mcp
ezel
ai.ezel
Search U.S. case law, fetch opinions, and ask matter-aware legal questions over your documents.
Legal & Compliance Search
2
https://app.ezel.ai/mcp
Lex — Temporal Luxembourg and EU LawC
io.github.SFHAJJI
Temporal search and comparison for official Luxembourg and reviewed EU law, with provenance.
Legal & Compliance Search Government Data
2719
https://law.soufien.lu/mcp
mcp-eurlex
io.github.lexsocket
Eurlex MCP client: Access EU law & Official Journal. https://www.lexsocket.ai/
Government Data Search Legal & Compliance
2
https://mcp.lexsocket.ai/eurlex/

Related MCP Servers

Slovak Law MCP Server
Legal & Compliance Search
Ansvar-Systems
A
license
Not graded
quality
F
maintenance
Enables querying and analyzing Slovak legislation via natural language, including full-text search, provision retrieval, and EU law integration.
Updated 4 months ago (2026-07-22 10:34 UTC)
56 npm
2
Apache 2.0
eurlex-mcp-server
Legal & Compliance Search Government Data
Honeyfield-Org
A
license
A
quality
B
maintenance
Enables searching and retrieving EU legal documents (regulations, directives, court decisions) via the EUR-Lex Cellar API, supporting full-text search, metadata, citations, and consolidated versions without requiring an API key.
Updated a day ago (2026-11-06 08:01 UTC)
11
67 npm
7
MIT
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 6 days ago (2026-11-01 20:56 UTC)
9 npm
MIT
French Law MCP Server
Legal & Compliance Government Data
BenjoNX
A
license
Not graded
quality
D
maintenance
Enables querying and retrieving legal texts and decisions from French public APIs Légifrance and JudiLibre for legal research.
Updated 8 months ago (2026-02-25 10:55 UTC)
MIT

LexAPI MCP

Connect to the hosted server (sign in with LexAPI)

claude.ai and Claude Desktop

Claude Code

Other MCP clients

With an API key instead

Run it locally (npm, API key)

Claude Desktop (local)

Claude Code (local)

Cursor, VS Code and other stdio clients

Tools

National law

How results are shaped for models

Configuration

Hosting the HTTP server

Troubleshooting

Development

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers