Skip to main content
Glama
Sign In

Avokata: Lithuanian law & court practice

by com.avokata
OverviewDiscussionsAdmin

Is it in force

check_validity
Read-onlyIdempotent

Sign-in required: call connect(email) and connect_verify first (free, one email) unless this connection is already signed in. Is this act in force (galioja), and which consolidated version (suvestinė redakcija) governed on a given date. Pass on_date to ask about the past (įsigaliojimo data). Name the act with ONE of: document_id (the id of a search hit; an article id with # answers about its act) or act_number (the register number XII-2603, or a code abbreviation DK, CK). An act you know only by its title: search_law first and take the id. Validity is a property of the act, not of an article: for an article's wording on a date use read_paragraphs with on_date, for what changed use compare_provision_versions. A validity answer does not verify a quotation; use verify_citation for that. Example arguments: {"act_number": "DK", "on_date": "2024-01-15"}.

Input Schema

NameRequiredDescriptionDefault
actsNoSeveral acts at once (an audit of a sector's acts): a list of document ids or act numbers, at most 25 per call. The answer is one compact row per act (`acts`: state, the edition in force and the ones ahead, the currency verdict, a possibly missing amendment, the repeal) instead of the full answer; `document_id`/`act_number` are then not needed.
on_dateNoThe date to test, `YYYY-MM-DD` - what governed THEN rather than now. Omit for today. The parameter is `on_date`: `as_of` and `date` are ignored.
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.
act_numberNoAlternative to `document_id`: the act's official number as the register writes it, e.g. `XIII-2221`, or a code abbreviation the map knows (`DK`, `CK`, `CPK`). A number, never a title or an article (`DK 58` is the act `DK`; ask the article with read_paragraphs). One of the two is required.
document_idNoThe act to test, by the `id` of a search hit. An article id (containing `#`) is accepted and answers about its act, because validity is a property of the 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
    • addedInput schema / properties / acts
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Several acts at once (an audit of a sector's acts): a list of document ids or act numbers, at most 25 per call. The answer is one compact row per act (`acts`: state, the edition in force and the ones ahead, the currency verdict, a possibly missing amendment, the repeal) instead of the full answer; `document_id`/`act_number` are then not needed.",
+  "title": "Acts"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / act_number / description
      Previous value: -"Alternative to `document_id`: the act's official number as the register writes it, e.g. `XIII-2221`. One of the two is required."New value: +"Alternative to `document_id`: the act's official number as the register writes it, e.g. `XIII-2221`, or a code abbreviation the map knows (`DK`, `CK`, `CPK`). A number, never a title or an article (`DK 58` is the act `DK`; ask the article with read_paragraphs). One of the two is required."
  3. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: the free one-email sign-in prerequisite and the distinction that validity is a property of the act, not an article. It does less on return format, though the acts schema entry hints at the compact-row output.

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-loads the sign-in requirement, then states the purpose, then routes to alternatives, then gives an example. Dense and purposeful, though it runs long; every sentence is doing work but the routing could be tightened.

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 6 params, no output schema, and only read-only annotations, the description covers auth, act identification, date semantics, and exclusion from sibling tools. It does not explain the return value of a single-act query, but the essential call-correctness information is present.

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 parameters are fully documented already, and the description largely restates the document_id/act_number duality. It does add one constraint not obvious from the schema: name the act with ONE of document_id or act_number, and that an article id with `#` answers about its act. Baseline 3 is appropriate since the schema carries most of the load.

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 query: whether an act is in force and which consolidated version governed on a date, with the native terms (galioja, suvestinė redakcija, įsigaliojimo data). It explicitly separates itself from read_paragraphs (article wording), compare_provision_versions (what changed), and verify_citation (quotation verification).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing: sign in via connect/connect_verify first; use search_law when only the title is known; use read_paragraphs for an article's wording on a date; verify_citation to verify quotes. Names the alternative tools and the conditions that select them, plus a concrete example call.

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