Skip to main content
Glama
Sign In

Avokata: Lithuanian law & court practice

by com.avokata
OverviewDiscussionsAdmin

Versions between two dates

compare_provision_versions
Read-onlyIdempotent

Sign-in required: call connect(email) and connect_verify first (free, one email) unless this connection is already signed in. What changed in an act (or one article) between two dates: the version in force on from_date (the baseline) against the one on to_date, and every change that took effect in between, each with its own įsigaliojimo data. Any window works. Returns version metadata and register links. With article, held editions also supply its wording on both dates and a word-level redline; missing wording is reported as not held, never reconstructed from register notes.

Input Schema

NameRequiredDescriptionDefault
detailNo`compact` (the default for a list of articles or a whole act): per article whether it changed, both wordings' dates, the edits and the changed paragraphs - no whole wordings. `full` (the default for one article) adds each article's wording on both dates and the marked text.
articleNoOptional article (`1.125`, `57`, or `58 str. 3 d. 4 p.` for one point): its wording on both dates and a word-level redline (`[-deleted-]`, `{+inserted+}`) where the act's editions are held, plus its own changes in the window from the register's notes. A list (`['57','65','89']` or `57, 65, 89`, up to 25) answers each under `articles` in one call. Without `article` the answer lists EVERY article whose words changed in the window (`articles_changed`, with shortened redlines).
sessionNoThe `session` value the sign-in returned. Pass it on every call in this conversation, so the sign-in survives however this client handles connections; omit it when the user connected with Sign in (OAuth) or a key.
to_dateYesThe later date, `YYYY-MM-DD` (today, say). Must be on or after from_date.
from_dateYesThe earlier date, `YYYY-MM-DD` (a contract date, say). The version in force on it is the baseline; any date works.
act_numberNoAlternative to document_id: the act number or code (`VIII-1864`, `CK`). A list (`['DK','CK','XI-2159']` or `DK, CK, XI-2159`, up to 20) checks every act's window in one call, one compact row each under `acts` (no `article` then).
amended_byNoOptional amending act number (`XV-1058`): with no `article`, keep only the articles whose new wording the register credits to that act - 'what does this amendment change'.
document_idNoThe act to compare, by search hit id. An article id (with `#`) resolves to its act.
jurisdictionNoWhich jurisdiction the act belongs to (`LT`). Omit for the account's own.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / act_number / anyOf
      Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / act_number / description
      Previous value: -"Alternative to document_id: the act number or code (`VIII-1864`, `CK`)."New value: +"Alternative to document_id: the act number or code (`VIII-1864`, `CK`). A list (`['DK','CK','XI-2159']` or `DK, CK, XI-2159`, up to 20) checks every act's window in one call, one compact row each under `acts` (no `article` then)."
  3. Changed1 schema field changed
    • addedInput schema / properties / detail
      Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "compact",
+        "full"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "`compact` (the default for a list of articles or a whole act): per article whether it changed, both wordings' dates, the edits and the changed paragraphs - no whole wordings. `full` (the default for one article) adds each article's wording on both dates and the marked text.",
+  "title": "Detail"
+}
  4. Changed1 schema field changed
    • removedInput schema / properties / detail
      Removed value: -{
-  "anyOf": [
-    {
-      "enum": [
-        "compact",
-        "full"
-      ],
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "`compact` (the default for a list of articles or a whole act): per article whether it changed, both wordings' dates, the edits and the changed paragraphs - no whole wordings. `full` (the default for one article) adds each article's wording on both dates and the marked text.",
-  "title": "Detail"
-}
  5. Changed1 schema field changed
    • addedInput schema / properties / detail
      Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "compact",
+        "full"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "`compact` (the default for a list of articles or a whole act): per article whether it changed, both wordings' dates, the edits and the changed paragraphs - no whole wordings. `full` (the default for one article) adds each article's wording on both dates and the marked text.",
+  "title": "Detail"
+}
  6. Changed3 schema fields changed
    • addedInput schema / properties / amended_by
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional amending act number (`XV-1058`): with no `article`, keep only the articles whose new wording the register credits to that act - 'what does this amendment change'.",
+  "title": "Amended By"
+}
    • changedInput schema / properties / article / anyOf
      Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / article / description
      Previous value: -"Optional article (`1.125`, `57`, or `58 str. 3 d. 4 p.` for one point): its wording on both dates and a word-level redline (`[-deleted-]`, `{+inserted+}`) where the act's editions are held, plus its own changes in the window from the register's notes."New value: +"Optional article (`1.125`, `57`, or `58 str. 3 d. 4 p.` for one point): its wording on both dates and a word-level redline (`[-deleted-]`, `{+inserted+}`) where the act's editions are held, plus its own changes in the window from the register's notes. A list (`['57','65','89']` or `57, 65, 89`, up to 25) answers each under `articles` in one call. Without `article` the answer lists EVERY article whose words changed in the window (`articles_changed`, with shortened redlines)."
  7. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description still adds substantive behavior: authentication requirements, what is returned (version metadata and register links), and a fidelity guarantee that missing wording is reported as not held and never reconstructed from register notes. That is exactly the kind of context annotations cannot convey.

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?

The auth prerequisite is front-loaded and the rest reads as a dense but purposeful paragraph with no filler. Slightly long and packed with parentheticals, but every clause carries information.

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?

For a 9-parameter read tool with no output schema, the description covers auth, the two answer modes, and the return shape ('version metadata and register links'). It stops short of describing pagination or limits on the shortened redlines, but nothing essential to a correct call is missing.

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% and the schema already documents defaults, formats, list caps, and cross-parameter interactions, so the description's parameter content largely restates it (from_date as baseline, `article` behavior). Baseline 3 is appropriate since the schema already does the heavy lifting.

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 operation ('what changed in an act (or one article) between two dates') with an explicit baseline/end semantic: the version in force on from_date vs the one on to_date plus in-between changes. This clearly separates it from siblings like get_document, check_validity, or read_paragraphs.

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 a clear prerequisite (call connect/connect_verify first unless already signed in) and explains the two usage modes: with `article` for wording plus redline, without `article` for the full changed-article list, and the `amended_by` 'what does this amendment change' case. It does not name sibling alternatives, but the branching guidance is concrete.

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

All Avokata: Lithuanian law & court practice toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources