LexAPI MCP

Official

by Lex-API

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v0.1.0
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.
Average 4/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![lexapi-mcp MCP server](https://glama.ai/mcp/servers/Lex-API/lexapi-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Lex-API/lexapi-mcp)

Score Badge

Copy to your README.md:

[![lexapi-mcp MCP server](https://glama.ai/mcp/servers/Lex-API/lexapi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Lex-API/lexapi-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Lex-API/lexapi-mcp'

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