Payments Law EU

Search legislation

search_legislation

Read-onlyIdempotent

Where does the corpus discuss X? Full-text search across articles, annexes and recitals, ranked in that order of authority. Every hit carries the exact locator get_provision accepts, its cite anchor, the matched passage and why it matched. A citation-shaped query resolves through the citation grammar first; instrument acronyms become ranking hints; initialisms of the corpus's defined terms are expanded. Absence of a result is not evidence that no relevant law exists. The matched passage is a snippet of at most 320 characters, not the provision: open the hit with get_provision before citing it, and echo the cite it serves. topic narrows these hits rather than widening them: a topic-tagged provision whose words the query misses is never reached, so a page of hits is not a sweep. For coverage questions ('everything on X', 'which instruments deal with Y') pick the instruments with list_instruments by category, enumerate each with list_provisions filtered by topic, then open them with get_provision.

Input Schema

TableJSON Schema

Name	Required	Description
`kind`	No	Restrict to one source type. Articles, annexes and recitals are all searched by default, ranked in that order of authority.
`limit`	No
`query`	Yes	What to search for, in the words you expect in the legal text. Quoted phrases are honoured; AND, OR and NOT are the only operators. A citation-shaped query ("Article 97(1) PSD2") is resolved through the citation grammar first.
`topic`	No	Keep only provisions carrying this topic.
`cursor`	No
`instrument_id`	No	Restrict to one instrument, e.g. "rts-sca".
`in_force_on_date`	No	ISO date; keeps hits from instruments in force on that date, on the same semantics list_instruments uses.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes
`error`	Yes
`coverage`	Yes
`warnings`	Yes
`pagination`	Yes
`provenance`	Yes
`derivations`	Yes
`corpus_release`	Yes

TDQS

A4.1/5.0

Behavior1/5

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

The description adds rich behavioral detail: ranking order, hit fields, 320-character snippet limit, topic narrowing, acronym ranking hints, and initialism expansion. However, it directly contradicts annotations.openWorldHint=false by stating 'Absence of a result is not evidence that no relevant law exists,' which asserts open-world semantics. Per the rubric, a direct annotation contradiction scores 1.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but front-loaded: purpose first, then hit behavior, then caveats and alternative workflow. Most sentences earn their place, though it runs long and could be tightened by merging repeated cautions about snippets and topic coverage.

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 7-parameter tool with an output schema, this is otherwise thorough: it explains result contents, ranking, query resolution, topic behavior, snippet limits, and the correct alternative workflow for coverage questions. The only serious completeness issue is the annotation contradiction, already scored separately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite schema coverage of 71%, the description adds substantial meaning beyond the input schema: citation-grammar resolution, acronyms as ranking hints, expansion of defined-term initialisms, topic-as-filter semantics, snippet length, and in_force_on_date semantics tied to list_instruments. This compensates well for undocumented params like limit and cursor.

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?

Opens with 'Where does the corpus discuss X?' and defines a precise verb/resource: full-text search across articles, annexes, and recitals with a specific ranking. It also distinguishes itself from sibling tools like get_provision and list_provisions, making its role clear.

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 guides coverage questions to list_instruments by category, list_provisions by topic, and get_provision, and warns that 'a page of hits is not a sweep.' It also explains when citation-shaped queries route through the citation grammar, giving clear when-to-use vs. when-to-use-alternative guidance.

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

All Payments Law EU tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct legal-research action: retrieval by anchor, full-text search, citation resolution, definition lookup, version diffing, and orientation. Even the paired simple/advanced tools (fetch vs get_provision, search vs search_legislation) explicitly direct agents to the fuller variant.

Naming Consistency4/5

The set is almost uniformly snake_case verb-object: get_*, list_*, search_*, compare_versions, resolve_citation. The bare-verb fetch and search are minor deviations from the verb-noun pattern but are recognizable and consistent in style.

Tool Count5/5

Thirteen tools is well-scoped for a legal corpus server: each tool represents a distinct mode of access or workflow stage, without redundant bulk. The count is comfortably within the ideal range and every tool appears to earn its place.

Completeness5/5

For a read-only legal research corpus, the surface is thorough: instrument and provision enumeration, full-text retrieval, citation resolution, definition lookup, version comparison, and guided orientation. There are no obvious dead ends; workflows are explicitly described for coverage questions.

Resources

Need Help?