Lithuanian laws article by article, with whether each applies today, past versions and search
Scored across 8 tools
Each tool has a distinct role: search_law finds articles, get_article/get_articles read them (single vs batch, explicitly cross-referenced), get_act_contents lists an act's articles, list_acts lists acts, find_definition targets term definitions, related maps citations, upcoming_changes filters by date. The only mild overlaps are search_law vs find_definition (both text-driven) and get_article vs get_articles, but the descriptions make the boundaries clear.
Seven of eight names follow a verb_noun snake_case pattern (find_definition, get_act_contents, get_article, get_articles, list_acts, search_law, upcoming_changes is noun-ish). 'related' is a bare adjective with no verb, a minor deviation, but the set is still highly readable and predictable.
Eight tools for a read-only legal-acts mirror is well-scoped: search, list, read (single/batch), act contents, definitions, citations, and pending changes each cover a distinct workflow. No tool appears redundant or padded.
The read-only surface covers the core lifecycle: discovery (search_law, list_acts), retrieval (get_article, get_articles, get_act_contents), interpretation (find_definition, related), and temporal awareness (upcoming_changes, status labels). A minor gap is access to historical/superseded versions of an article (only current and adopted-future text are described), but agents can largely work around this.
Where a term is legally defined, in every act on the site: the term, its alias ("toliau – …"), the definition text, the act and article/part with a link, and the article's status today. Inflection-tolerant ("vartotojo objektas" = "vartotojo objektą"). The same word often means different things in different acts ("vartotojas" in EĮ, EEĮ, GDĮ, VTAĮ): all are returned, plus narrower terms ending in it ("elektros energijos vartotojas").
| Name | Required | Description | Default |
|---|---|---|---|
| act | No | Optional: the meaning in this act (key, abbreviation, TAR code or name). If the act does not define the term itself but says its terms are understood as defined in other acts ("sąvokos suprantamos taip, kaip jos apibrėžtos … įstatyme"), those acts' definitions are returned, with the sentence in by_reference | |
| term | Yes | A word or phrase: "vartotojo objektas", "bešeimininkis daiktas" | |
| limit | No | How many definitions, at most 50 (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint already declares this a safe read, so the description's job is added context, and it delivers: exhaustive multi-act scope, inflection tolerance, automatic inclusion of narrower terms, and the by_reference referral behaviour. It stops short of describing result ordering, truncation signalling when the limit is hit, or what an empty result means, which keeps it off 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose and return contents, with parenthetical examples that earn their place. The first sentence is dense and comma-laden, but no sentence is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must carry the return shape, and it does precisely: term, alias, definition text, act and article/part with link, plus the article's current status. Combined with the act-referral explanation, an agent has everything needed to call this correctly and interpret the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description earns an increment by stating that term matching is inflection-tolerant and by explaining the semantic expansion ('all are returned, plus narrower terms ending in it') that the schema does not convey. The act parameter's referral behaviour is largely duplicated from the schema rather than extended.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening clause states a specific verb and resource: 'Where a term is legally defined, in every act on the site', followed by an enumeration of exactly what is returned. It is clearly distinguishable from list_acts, get_article and search_law because it targets term definitions across acts rather than acts, articles or full-text hits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is strongly implied by the purpose statement (call this when you need a legal definition rather than an article's text), and the act-parameter paragraph explains the referral case in which definitions are pulled from other acts. However, no sibling tool is named and there is no explicit when-not-to-use guidance, leaving the agent to infer that search_law is the fallback for non-definition lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The articles of one act in order (number, title, chapter, status), paged, and its annexes (read one with get_article: "6 priedas").
| Name | Required | Description | Default |
|---|---|---|---|
| act | Yes | Act key, abbreviation, TAR code or name: "DK", "CK", "2016-23709", "darbo kodeksas" | |
| limit | No | Entries per page, at most 300 (default 100) | |
| offset | No | Skip this many entries of the contents (from the answer's next_offset) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds real context beyond that by stating results are ordered, paged, and that annexes are only indexed here and must be fetched via get_article. It does not mention truncation or what next_offset signals, but the substantive behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence front-loads the resource and its return fields, then tacks on paging and the annex pointer. Very little waste, though the parenthetical field list and trailing annex clause make it slightly harder to parse than two short sentences would.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing the return shape and does so precisely (number, title, chapter, status), while also explaining the annex relationship. For a simple paged read tool with 100% schema coverage, nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with act, limit and offset fully documented in the schema including accepted act identifier forms and the 300 cap. The description only implies paging and adds no syntax or format detail beyond that, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific resource (an act's articles) and states exactly what each entry carries: number, title, chapter, status, plus a companion annexes list. It is clearly distinct from get_article, which it names as the way to read annex text, though it never contrasts itself with get_articles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the wording: use this to enumerate one act's contents in order and page through them. It routes the agent to get_article for reading an annex ("6 priedas"), but offers no exclusion against get_articles or list_acts, so the agent must infer when this is preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The text of one article (or point) as published by the Seimas Chancellery, unchanged, with its status today (Galioja šiandien / Įsigalios D / Gali būti pasenęs / Neaišku, ar galioja / Neteko galios), until when that label is certain, amending acts, the future wording if adopted, defined terms used, a citation line and the official e-tar.lt link.
| Name | Required | Description | Default |
|---|---|---|---|
| act | Yes | Act key, abbreviation, TAR code or name: "DK", "CK", "KET", "2016-23709", "darbo kodeksas" | |
| date | No | Optional YYYY-MM-DD: the text in force on that date (the Chancellery's official consolidation for it, since 2020, where the open data hold one); without it, today's text | |
| find | No | Optional: only the paragraphs and table rows holding these words, e.g. a substance's name or CAS number in a long annex ("formaldehidas", "50-00-0") | |
| part | No | Optional: one part of the article, by number or anchor ("107" or "d107"; a rule's sub-point "8.12" or "p8.12"): only that part's text (and its future wording) instead of the whole article | |
| offset | No | Optional: a very long text comes in pieces of about 60,000 characters; the answer's next_offset says where the next begins | |
| article | Yes | Article or point number: "52", "21¹" or "21-1", "6.228-1", "3.2" (also accepted as `n`); an annex: "6 priedas", "V priedas" (whether an annex is in force today is not checked: its status says so) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already covering safety, the description adds real behavioral context: the text is unchanged as published, it enumerates the five status labels (Galioja šiandien / Įsigalios D / Gali būti pasenęs / Neaišku, ar galioja / Neteko galios), it distinguishes future wording from current text, and it warns that an annex's force status is not verified. It stops short of describing how status certainty is bounded in edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence, front-loaded with the core resource before listing what comes back with it. The enumeration of return components is informative but reads as a run-on list. Nothing is redundant given there is no output schema to carry it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must describe returns, and it does so in detail: status, certainty horizon, amending acts, future wording, defined terms, citation, and official link. Pagination is handled in the schema (offset, ~60,000-char pieces). Minor gap: nothing explains ordering or how the article is located when act/article are ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter including act, date, find, part, offset, and article is already documented with examples. The description adds meaning about returns (amending acts, defined terms, citation line, e-tar.lt link) rather than about parameters. Baseline 3 is appropriate when the schema carries the parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource and scope: the unchanged published text of one article or point, plus derived status and amendment data. It is unambiguous about being a single-article retrieval. It does not explicitly differentiate itself from siblings like get_articles or find_definition, which is the only thing keeping it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the reader infers this is the tool for pulling one article's text, and the date parameter hints at historical vs. current retrieval. There is no explicit when-to-use/when-not guidance and no mention of when to prefer search_law, get_articles, or find_definition instead. The annex caveat is the closest thing to a usage hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Several articles (or points, or parts) in one call, up to 20: each as get_article returns it. Use it to read everything a search or related found, instead of one call per article.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Optional YYYY-MM-DD for all of them (as get_article's `date`) | |
| refs | Yes | References: "DK 52", "EEĮ 2 str. 15 d." (one part), "KET 3.2", "CK 6.228¹", or {act, article, part} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered; the description adds the meaningful behavioral contract that each item comes back 'as get_article returns it' and that the batch is capped. It does not say what happens if one ref is invalid or if more than 20 are supplied, which is the main remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the batch capability and followed by the routing guidance. No sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only batch tool with a fully described schema and no output schema, this is nearly complete: it covers scope, cap, return-shape proxy, and usage. Only error/partial-failure behavior is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both `refs` formats and the optional `date`. The description mentions 'up to 20' and hints at points/parts, but adds no format or date guidance beyond the schema — baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — fetch several articles/points/parts in one call — and immediately frames it as the batch counterpart of `get_article`. An agent can tell it apart from `get_article`, `search_law`, and `related` without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names the triggering context (reading everything a `search` or `related` returned) and the alternative it replaces (one `get_article` call per item). The single-article exclusion is strongly implied by 'instead of one call per article'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The acts on the site, 50 at a time: key, citation form, name, number of articles. Over 1,200 acts: give query (words of the name or a common name: "energetikos", "GDPR"). You rarely need this: search_law and get_article take an act's name, abbreviation, common name or EU number directly.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Acts per page, at most 200 (default 50) | |
| query | No | Words of the act's name, abbreviation or common name | |
| offset | No | Skip this many (from `more`) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, and the description adds real behavior: results come 50 at a time, a filterable corpus of 1,200+ acts exists, and pagination is driven by `offset` taken 'from `more`'. The only soft spot is that `more` is never defined as a response field, so an agent must infer it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the resource and its returned fields, then the query hint, then the routing advice. Every sentence carries information, though the bulleted field list plus a parenthetical aside is slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates the returned fields and explains pagination, which is exactly what an agent needs to page through results. The unexplained `more` reference and the absence of any note on ordering or total-count semantics keep it from full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3 and all three parameters are already documented. The description adds marginal value by illustrating `query` with concrete examples ('energetikos', 'GDPR') and tying `offset` to a `more` value, but it never clarifies the limit ceiling (200) or default behavior beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the resource and exactly what each entry contains ('key, citation form, name, number of articles'), and its closing sentence implicitly separates it from search_law/get_article, which take an act name directly. The verb is only implied ('The acts on the site'), so it falls just short of a fully explicit verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly discourages use ('You rarely need this') and names the alternatives (search_law, get_article) plus the reason those are usually better. It also gives the positive trigger condition: when the site has over 1,200 acts, supply `query` with words of the name or common name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find articles of Lithuanian codes, laws and Government-approved rules (unofficial mirror of e-tar.lt). Use a reference ("DK 52", "CK 6.228¹", "KET 52", "GDPR 17", "2019/944 15", "Energetikos įstatymo 15 straipsnis") or Lithuanian words ("kasmetinės atostogos", also everyday ones: "alimentai"). Returns articles with their URL, whether their text applies today, and for the first 10 the part where the words are (part, snippet); suggested: chosen for these everyday words, not from the text. Annexes are searched too (label "priedas-6"): lists, forms and tables that the articles refer to.
| Name | Required | Description | Default |
|---|---|---|---|
| act | No | Optional: limit to one act (key, abbreviation or name, e.g. "DK") | |
| limit | No | How many results, 1 to 30 (default 10) | |
| query | Yes | A reference or Lithuanian words (4+ letters each; all must occur; when fewer than 3 articles have them all, then also those with all but one, each naming the word it lacks in `lacks_word`). Up to 3 alternative wordings separated by "|" are searched together: "telefono numeris | ryšio duomenys" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint=true, the description discloses that this is an unofficial e-tar.lt mirror, that results carry URL and current-applicability status, that snippet/part detail is limited to the first 10 results, and notably that `suggested` results are chosen for everyday words rather than drawn from the text. That last point is a real behavioral caveat an agent could otherwise misread as a keyword match.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences: purpose and source, then query forms, then return shape. Dense but nearly every clause carries information; the parenthetical mirror note and the trailing annex sentence are slightly tacked on but still earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so: URL, current applicability, part/snippet for the first 10, and the `suggested` field's distinct meaning. Combined with the 100%-covered schema, an agent has everything needed to invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already defines `act`, `limit`, `query`, the 4+ letter rule, AND-of-all-words logic, the lacks_word fallback, and pipe-separated alternatives. The description largely restates those rules and only adds the reference syntax and annex label ('priedas-6') angle, which the schema does not cover.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Find articles of Lithuanian codes, laws and Government-approved rules,' and the query-by-reference-or-words framing implicitly separates it from siblings like get_article or get_act_contents. It never names an alternative tool explicitly, so the differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Concrete context is supplied: use a legal reference ('DK 52', 'CK 6.228¹') or Lithuanian words including everyday terms ('alimentai'), and annexes are also searchable. There is no statement of when to prefer a sibling tool or when this search will fail, so exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Articles whose text or status changes in the next days (adopted amendments with a date).
| Name | Required | Description | Default |
|---|---|---|---|
| act | No | Optional: only this act (key, abbreviation, TAR code or name) | |
| days | No | How many days ahead from the labels' day, at most 30 (default 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds the meaningful scope constraint that only adopted amendments with a date are included, but says nothing about result volume, ordering, or what a 'change' record looks like — and no output schema exists to fill that gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with the scoping clause front-loaded and no wasted wording. Slight loss for the parenthetical clarification, which is compact but reads as an afterthought rather than structured context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only tool with full schema coverage, the description covers scope adequately. But with no output schema, it never indicates what a returned 'change' contains (old vs new text, status, effective date) or how results are ordered, leaving an agent guessing about the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented, including the act filter formats and the days maximum of 30. The description reinforces the time-window concept with 'in the next days' but adds no detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource and filter: articles whose text or status changes within the next days, restricted to adopted amendments that carry a date. An agent can distinguish this from generic retrieval siblings like get_articles, though it never explicitly says it returns a list or names the sibling it contrasts with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the scope phrase 'adopted amendments with a date', which effectively states the inclusion condition. However, there is no explicit when-to-use guidance, no mention of when not to use it, and no pointer to alternatives such as get_article or search_law for current (non-upcoming) content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_definition1 field changedInput schema / properties / limit / descriptionAdded value: +"How many definitions, at most 50 (default 20)"get_act_contents3 fields changedInput schema / properties / act / descriptionAdded value: +"Act key, abbreviation, TAR code or name: \"DK\", \"CK\", \"2016-23709\", \"darbo kodeksas\""Input schema / properties / limit / descriptionAdded value: +"Entries per page, at most 300 (default 100)"Input schema / properties / offset / descriptionAdded value: +"Skip this many entries of the contents (from the answer's next_offset)"search_law1 field changedInput schema / properties / limit / descriptionAdded value: +"How many results, 1 to 30 (default 10)"upcoming_changes2 fields changedInput schema / properties / act / descriptionAdded value: +"Optional: only this act (key, abbreviation, TAR code or name)"Input schema / properties / days / descriptionAdded value: +"How many days ahead from the labels' day, at most 30 (default 30)"get_article2 fields changedInput schema / properties / findAdded value: +{
+ "description": "Optional: only the paragraphs and table rows holding these words, e.g. a substance's name or CAS number in a long annex (\"formaldehidas\", \"50-00-0\")",
+ "type": "string"
+}Input schema / properties / offsetAdded value: +{
+ "description": "Optional: a very long text comes in pieces of about 60,000 characters; the answer's next_offset says where the next begins",
+ "type": "number"
+}list_acts3 fields changedInput schema / properties / limitAdded value: +{
+ "description": "Acts per page, at most 200 (default 50)",
+ "type": "number"
+}Input schema / properties / offsetAdded value: +{
+ "description": "Skip this many (from `more`)",
+ "type": "number"
+}Input schema / properties / queryAdded value: +{
+ "description": "Words of the act's name, abbreviation or common name",
+ "type": "string"
+}get_article1 field changedInput schema / properties / article / descriptionPrevious value: -"Article or point number: \"52\", \"21¹\" or \"21-1\", \"6.228-1\", \"3.2\" (also accepted as `n`)"New value: +"Article or point number: \"52\", \"21¹\" or \"21-1\", \"6.228-1\", \"3.2\" (also accepted as `n`); an annex: \"6 priedas\", \"V priedas\" (whether an annex is in force today is not checked: its status says so)"search_law1 field changedInput schema / properties / query / descriptionPrevious value: -"A reference or Lithuanian words (4+ letters each; all must occur). Up to 3 alternative wordings separated by \"|\" are searched together: \"telefono numeris | ryšio duomenys\""New value: +"A reference or Lithuanian words (4+ letters each; all must occur; when fewer than 3 articles have them all, then also those with all but one, each naming the word it lacks in `lacks_word`). Up to 3 alternative wordings separated by \"|\" are searched together: \"telefono numeris | ryšio duomenys\""get_articlesrelatedsearch_law1 field changedInput schema / properties / query / descriptionPrevious value: -"A reference or Lithuanian words (4+ letters each; all must occur)"New value: +"A reference or Lithuanian words (4+ letters each; all must occur). Up to 3 alternative wordings separated by \"|\" are searched together: \"telefono numeris | ryšio duomenys\""find_definitionget_article3 fields changedInput schema / properties / act / descriptionPrevious value: -"Act key, abbreviation or name: \"DK\", \"CK\", \"KET\", \"darbo kodeksas\""New value: +"Act key, abbreviation, TAR code or name: \"DK\", \"CK\", \"KET\", \"2016-23709\", \"darbo kodeksas\""Input schema / properties / article / descriptionPrevious value: -"Article or point number: \"52\", \"21¹\" or \"21-1\", \"6.228-1\", \"3.2\""New value: +"Article or point number: \"52\", \"21¹\" or \"21-1\", \"6.228-1\", \"3.2\" (also accepted as `n`)"Input schema / properties / partAdded value: +{
+ "description": "Optional: one part of the article, by number or anchor (\"107\" or \"d107\"; a rule's sub-point \"8.12\" or \"p8.12\"): only that part's text (and its future wording) instead of the whole article",
+ "type": "string"
+}get_act_contentsget_articlelist_actssearch_lawupcoming_changesWhat a Lithuanian act said on one given date, with its validity window and a register URL.
Latvian law search: in-force statutes, verbatim articles, verified Q&A. Anonymous, read-only.
Lithuanian legislation and court practice for your AI agent. Search laws and 2.4 million court decisions, read the exact article or ruling paragraph, see which version was in force on any date, follow citations both ways and check a quote against its source. Lithuanian and EU law. Free during beta: sign in with your email. --- Lietuvos teisės šaltiniai jūsų DI asistente (Claude, ChatGPT ir kt.). Galiojančios įstatymų ir kitų teisės aktų redakcijos su datomis, teismų praktika su punktais, VMI ir kitų institucijų paaiškinimai, citatų patikra. Kiekvienas atsakymas su nuoroda į oficialų šaltinį. Teisininkams, buhalteriams, personalo, viešųjų pirkimų ir kitiems specialistams.
Full text and amendment history of Hungarian acts: section-level search, point-in-time text, diffs.
Add one secure layer between your agents and this server.
