TAAP MCP

Overview Schema Source Related Servers Discussions Admin

lt_get_provision

Read-onlyIdempotent

Retrieve any Lithuanian act provision by citation reference, returning its full text and a ready-to-use citation, with an optional date to get the wording in force on that day.

Instructions

Fetch one provision of an act by reference, with its full text and a ready citation.

Input Schema

Name	Required	Description
`ref`	Yes	a provision reference as written in documents - ``"12 str. 3 d. 5 p."``, ``"12 straipsnio 3 dalis"``, ``"24.1"``, ``"24.1 p."``, ``"11 punktas"``, ``"II skyrius"`` - or an id from ``lt_get_provisions`` (``"d1:p-24.1"``).
`date`	No	ISO date - the provision as worded in the text in force that day (default: today).
`document`	No	numbered document to look in when the act holds several (0 = the act; approved rules/annexes are 1, 2 ...). Without it the largest matching document wins and the other matches are listed in ``alternatives``.
`tar_kodas`	Yes	e.g. ``"1001010ISTAIII-1524"``.

Output Schema

Name	Required	Description	Default
`path`	No	Ancestor labels, outermost first.
`stale`	No
`title`	No
`eli_uri`	No
`warning`	No
`eli_note`	No		Lithuania 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.
`cached_at`	No	When that stored copy was fetched.
`full_text`	No
`provision`	Yes	One provision (chapter, article, part, point ...) with a stable id.
`tar_kodas`	No
`as_of_date`	No
`source_url`	No
`text_source`	No
`alternatives`	No	Other provision ids matching the same reference.
`dataset_note`	No		The 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_at`	No
`suvestines_id`	No
`content_sha256`	No	SHA-256 of the whole act text the provisions were parsed from.
`document_title`	No
`edition_valid_to`	No
`provision_sha256`	No
`served_from_cache`	No	True when data.gov.lt failed and a stored copy was served instead.
`source_fetched_at`	No	Oldest fetch time of any source response used (cache incl.).
`edition_valid_from`	No
`provision_citation`	No
`human_readable_citation`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.8.0Oct 29, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and open-world, so the safety profile is fully carried by structured data. The description adds only that the result includes the provision text plus a ready citation; it says nothing about failure modes for an unresolvable reference, the date/versioning behavior, or the 'alternatives' fallback for multi-document acts.

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?

A single front-loaded sentence with zero filler, leading with the action and scope and closing with the payload. Nothing is padded and nothing needs trimming.

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?

An output schema exists so return values need no explanation, annotations cover safety, and the schema fully documents parameters. The remaining gap is small: a clause about unresolved references or the point-in-time date semantics would complete the picture for a tool whose resolution rules are non-trivial.

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 coverage is 100%, so all four parameters (ref formats, ISO date, document index, tar_kodas) are already documented in detail, and the baseline of 3 applies. The description contributes only the phrase 'by reference', adding no meaning beyond the 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?

The description states a specific verb ('Fetch') and resource ('one provision of an act') and signals the return payload ('full text and a ready citation'). It implicitly separates itself from the singular/plural sibling lt_get_provisions ('one provision'), but never names a sibling or the act-level alternative lt_get_act.

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 reference' hints that the caller should already hold a reference, but there is no explicit when-to-use, when-not, or named alternative (e.g. use lt_get_provisions to discover references, lt_get_text for the whole act). The agent must infer the routing from the tool name and schema.

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