eu-parliament-mcp-server

Search parliamentary documents

euparl_search_documents

Read-onlyIdempotent

Search adopted texts, committee documents, or plenary documents, then retrieve metadata and source-file links with mode get and document_id. Get accepts IDs from procedures, speeches, votes, questions and answers without a source family; parent_document_ids lead from subdivisions to parent files. Detail preserves adopted_document_ids, based_on_document_ids and public_register_ref; follow published document relations with mode get, while preserving ordinary missing-record and upstream-error outcomes for unavailable targets. Document relations never imply procedure links. Only adopted_texts supports text, title, sitting dates and related_process_id. Committee supports term but no year; plenary supports year but no term. Use euparl_list_reference topic document_types for family-specific work_type codes. Detail returns links, not extracted full text. Adopted texts expose at most 10000 search results; continue with page.next_offset when present, otherwise narrow supported filters.

Input Schema

Name	Required	Description	Default
`mode`	No	Default search discovers records; get requires document_id and rejects source and all search filters.	search
`term`	No	Parliamentary term 0–10; adopted_texts and committee search only.
`text`	No	Adopted-texts-only keyword search in the requested language.
`year`	No	Four-digit document year; adopted_texts and plenary search only.
`limit`	No	Whole items requested; default 20, effective maximum 100 with notice.
`title`	No	Adopted-texts-only title search in the requested language.
`offset`	No	Zero-based collection offset; default 0.
`source`	No	Search-only family; omitted search defaults to adopted_texts. Omit entirely in get mode.
`language`	No	Supported EU ISO-639-1 language, case-insensitive; default en; source text is never translated.
`work_type`	No	Search-only family-specific code from euparl_list_reference topic document_types; case-insensitive and whitespace-trimmed.
`document_id`	No	Get-only canonical work ID, eli/dl/doc/ prefix or exact public URI; no family restriction.
`sitting_date`	No	Adopted-texts-only sitting date YYYY-MM-DD; start of range when sitting_date_end is supplied.
`sitting_date_end`	No	Adopted-texts-only inclusive range end YYYY-MM-DD; requires sitting_date and must not precede it.
`related_process_id`	No	Adopted-texts-only procedure reference YYYY-NNNN, YYYY/NNNN(TYPE), known prefix or public URI.

Output Schema

Name	Required	Description
`cap`	No	Effective whole-item page limit.
`mode`	No	Executed retrieval mode.
`page`	No	Search continuation metadata; absent in get mode.
`error`	No	Present when the call failed. Absent on success.
`found`	No	Get-only publication result; false for missing or empty detail.
`items`	No	Whole sparse records on a search page; absent in get mode.
`shown`	No	Whole items shown on this partial page.
`notice`	No	Publication, language fallback, empty-result or continuation guidance.
`source`	No	Effective family in search mode; absent in generic get.
`document`	No	Present only when get finds published detail.
`available`	No	Whether the selected source array was published, including a published empty array.
`truncated`	No	True when this page returns only part of the selected collection.
`totalCount`	No	Exact count only when published or computed over a complete collection.
`appliedFilters`	No	Actual normalized retrieval scope and filters.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond readOnly/openWorld/idempotent annotations, the description discloses important behavior: get returns links rather than extracted full text, detail preserves specific ID fields, unrelated missing-record and upstream-error outcomes remain ordinary, and document relations never imply procedure links. It also states the 10,000-result cap and page.next_offset continuation rule.

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-loads purpose and mode behavior, and almost every sentence carries operational information. Some clauses are compressed to the point of being cryptic, notably the detail/relations sentence, but there is little obvious filler.

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

Completeness5/5

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

For a 14-parameter, two-mode tool with rich schema coverage, an output schema, and safety annotations, the description covers the essential decision points: mode choice, family-specific filters, work_type lookup, pagination limits, detail output nature, and non-procedure relation semantics. Remaining gaps are minor and largely covered by structured fields.

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 description coverage is 100%, so the baseline is 3. The description adds cross-parameter meaning beyond the schema: text/title/sitting_date/related_process_id are adopted-texts-only, committee supports term but not year, plenary supports year but not term, and get mode rejects source and all search filters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource set: searching adopted texts, committee documents, or plenary documents, and retrieving metadata/source links via get mode. It clearly separates search from get and names the document families, though it does not explicitly contrast itself with sibling tools such as euparl_search_speeches or euparl_get_procedure.

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?

It gives strong mode guidance: search discovers records, get requires document_id and rejects source plus search filters. It also states which filters apply to which families (adopted_texts/committee/plenary) and points to euparl_list_reference for work_type codes, leaving only sibling-level alternatives implicit.

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

All eu-parliament-mcp-server tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.