Skip to main content
Glama

lt_get_edition_text

Read-onlyIdempotent

Fetches the consolidated text of a Lithuanian legal act in force on a given date or a specific edition, using its TAR code and optional edition ID.

Instructions

Fetch the consolidated text of an act in force on a date, or a specific edition.

Input Schema

NameRequiredDescriptionDefault
dateNoISO date (``YYYY-MM-DD``); the edition in force on that day. Default: today.
tar_kodasYese.g. ``"1001010ISTAIII-1524"``.
suvestines_idNoa specific edition from ``lt_list_editions`` (instead of ``date``).

Output Schema

NameRequiredDescriptionDefault
staleNo
titleNo
formatNotext/plain
contentNo
eli_uriNo
warningNo
eli_noteNoLithuania has no data.europa.eu ELI for the TAR dataset. eli_uri carries the canonical e-tar.lt legalAct URL (the stable national identifier), which is also the source_url.
byte_sizeNo
cached_atNoWhen that stored copy was fetched.
tar_kodasNo
as_of_dateNo
source_urlNo
text_sourceNo
dataset_noteNoThe Lithuanian Register of Legal Acts (TAR) is served as open data via the data.gov.lt Spinta API (dataset gov/lrsk/teises_aktai: models Dokumentas, Suvestine, Priedas; CC BY 4.0). Acts are addressed by their TAR code (tar_kodas, e.g. '2014-21296'); discover acts with lt_search (matches the title). Consolidated editions (suvestines redakcijos) come from the Suvestine model, attachments (priedai) from the Priedas model. Language: Lithuanian.
retrieved_atNo
suvestines_idNo
content_sha256No
edition_valid_toNo
served_from_cacheNoTrue when data.gov.lt failed and a stored copy was served instead.
source_fetched_atNoOldest fetch time of any source response used (cache incl.).
edition_valid_fromNo
human_readable_citationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.8.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds nothing about output size, format, or whether the returned text reflects amendments consolidated up to the requested date — a meaningful gap for a legal-text tool.

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?

One sentence, front-loaded with the verb and resource, with no filler. Every clause (in-force date / specific edition) carries meaning.

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?

With a full output schema and rich annotations, the definition covers what the tool returns and how it is selected. The one real omission is disambiguation from the adjacent lt_get_text and lt_get_act tools.

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 date, tar_kodas and suvestines_id are already documented. The description reinforces the mutual exclusivity of date vs edition, but adds no format details beyond the schema's own ISO example and default-today note.

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?

Specific verb ('Fetch') plus resource ('consolidated text of an act') and a clear scope qualifier: the version in force on a date or a named edition. It does not explicitly say how it differs from sibling lt_get_text or lt_get_act, 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?

The phrase 'in force on a date, or a specific edition' implies the two calling modes, and the schema ties suvestines_id to lt_list_editions, but the description never states when to use this instead of lt_get_text, lt_get_act, or lt_diff_editions.

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