Skip to main content
Glama

Get Document Tool

get_document
Read-onlyIdempotent

Retrieves one court decision or one legislative act in full: metadata, the AI summary where one exists, and the text.

Addressing: pass an official identifier (ECLI, ELI, CELEX) if you know it — no prior search is needed — or the id from a search result. Decisions without an ECLI are only addressable through that id.

Text is returned in bounded chunks. When the response carries text.next_cursor, pass it back as cursor to continue exactly where the previous chunk ended; text.complete tells you when you have everything. If chunking gets in your way, set include_full_text to true and the whole text comes back in one response.

Paragraph numbers (Randnummern) appear as [Rn. 42] markers and are the citation unit — quote them. Where the source carries none, the field text.paragraph_numbering says so; do not invent them.

For a CJEU case, related_documents lists the other documents of the same proceeding (judgment, Opinion of the Advocate General, order, request for a preliminary ruling) with the id needed to retrieve each.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "identifier": "<identifier>"
    },
    "name": "get_document"
  }
}

Input Schema

NameRequiredDescriptionDefault
typeNoOnly needed when the identifier does not reveal it; both are tried otherwise.
anchorNoStart the text at this anchor, e.g. "gruende" or "randnummer-42".
cursorNoContinuation token from `text.next_cursor` of a previous call.
languageNoISO 639-1 code of the desired text version, e.g. "de", "en", "fr". EU documents exist in up to 24 languages; the response lists them under `available_languages`. Defaults to German, then English, then whatever is held.
identifierYesECLI, ELI, CELEX number, or the `id` from a search result.
paragraph_toNoLast Randnummer to return.
max_charactersNoSize of the returned text chunk. Defaults to 20000.
paragraph_fromNoFirst Randnummer to return.
include_full_textNoReturn the entire text in one response instead of a chunk. Use this if paging fails.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare readOnly/idempotent; the description goes well beyond them by disclosing chunked return behavior, the `text.next_cursor` → `cursor` continuation loop, the `text.complete` termination signal, and the full-text escape hatch. It also warns that paragraph numbers are the citation unit and that `text.paragraph_numbering` must not be fabricated — behavior an agent could not infer from structured fields.

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?

Front-loads the core purpose, then uses short labeled paragraphs ('Addressing:', chunking, paragraph numbering, CJEU relations) so an agent can scan to the relevant concern. No filler sentences; each block carries distinct operational 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 9-parameter retrieval tool with no output schema, the description covers addressing, pagination, citation-unit handling, and the CJEU `related_documents` structure — everything needed to call it correctly and interpret the response. The absence of an output schema is compensated by describing the key return fields inline.

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%, so `cursor`, `include_full_text`, `identifier`, and `type` are already documented in the schema and the description largely restates them. It adds useful cross-parameter workflow context (the cursor loop, the full-text fallback) but says nothing about `anchor`, `language`, `paragraph_from`, `paragraph_to`, or `max_characters` beyond what the schema already states, so baseline 3 applies.

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?

States a specific verb and resource ('Retrieves one court decision or one legislative act in full') and enumerates exactly what comes back: metadata, AI summary, full text. The word 'in full' distinguishes it from the sibling search tools that return snippets.

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?

Gives concrete routing guidance: pass an ECLI/ELI/CELEX 'if you know it — no prior search is needed', otherwise use the `id` from a search result, and flags that decisions lacking an ECLI are only reachable via `id`. It also explains when to prefer `include_full_text` over paging. It stops short of naming `search_legal_documents` or `get_provision` as the explicit alternatives.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources