Skip to main content
Glama
Sign In
afsozer

Emsal MCP

by afsozer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_document

Fetch a single legal document by source and ID, with automatic pagination for long texts. Use it to retrieve official Turkish case law or legislation for citation-safe research.

Instructions

Fetch a single document by ID from the given source.

Args: source: Source identifier. document_id: Document ID (must not be empty). include_raw: If True, include the raw upstream response in the output (debugging). Default: False (deduplicated output with single markdown text field). page_number: 1-indexed page number for long documents (>= 40 000 chars). Default 1 returns the first page. Long documents are split at paragraph boundaries so no page starts or ends mid-paragraph.

Returns: Document dict with deduplicated metadata and content fields. Text is served as a single markdown field; full_text, raw, and metadata.content are omitted by default.

For long documents (>= 40 000 chars), the response includes
``current_page``, ``total_pages``, and ``total_chars`` so the
agent can request subsequent pages via ``page_number``.

Input Schema

NameRequiredDescriptionDefault
sourceYes
document_idYes
include_rawNo
page_numberNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses output deduplication (full_text, raw, metadata.content omitted by default), the 40,000-char pagination threshold, paragraph-boundary splitting, and the pagination fields returned. It does not state that the operation is read-only, nor any auth/rate-limit or missing-document error behavior, which keeps it from a 5.

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?

Front-loaded one-line summary followed by clearly labeled Args and Returns blocks; every sentence adds usable information at 0% schema coverage. The Returns section restates the deduplication rule already implied by include_raw, which is minor redundancy but not enough to hurt.

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?

There is no output schema, so describing the return shape (markdown field, current_page/total_pages/total_chars) is necessary and present; the pagination contract is fully explained. Missing pieces are error/not-found behavior and an explicit read-only guarantee, which an agent would reasonably want for a fetch tool.

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?

Schema description coverage is 0%, so the description must document all four parameters, and it does: source as identifier, document_id 'must not be empty', include_raw with default and debugging rationale, and page_number as 1-indexed with default 1 plus the threshold that activates it. This fully compensates for the bare schema.

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?

States a specific verb and resource with explicit scope: 'Fetch a single document by ID from the given source.' That distinguishes it by implication from the search tools (search_decisions, search_legislation) and from get_legislation, since retrieval is keyed by ID. It never names an alternative explicitly, so it falls short of a 5.

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?

Usage is only implied: 'by ID from the given source' suggests this is the fetch stage after a search, and 'include_raw ... (debugging)' hints at a debug use case. There is no statement of when to prefer this over get_legislation or search_local_corpus, and no preconditions (e.g., the ID must come from a prior search).

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

Deploy Server

Other Tools