Avokata: Lithuanian law & court practice

List all matching rulings

list_practice

Read-onlyIdempotent

Sign-in required: call connect(email) and connect_verify first (free, one email) unless this connection is already signed in. EVERY held ruling (nutartis) matching structured filters - court level (teismo instancija), court, date range, topic, case type - newest first, with the exact total and counts by level and year, page by page to the end (next_cursor). Use it when the job is 'all of them': all regional labour rulings since a date, every Constitutional Court ruling of a year. Every row says the ruling's outcome (granted, dismissed, partly, remanded...) with its operative words; outcome lists only the rulings decided that way. search_practice RANKS passages by a question and stops at a limit; this lists. At least one filter is required.

Input Schema

Name	Required	Description
`limit`	No	Rulings per page, default 50, at most 200. Every page states the exact total.
`topic`	No	A branch of the courts' own case classifier, e.g. `labour`. Rulings with no topical code cannot be judged by it; the answer counts them under `withheld`.
`courts`	No	Named courts, written as the court names itself, e.g. `Vilniaus apygardos teismas`.
`cursor`	No	The `next_cursor` of the previous page, with the same filters. Omit for the first page.
`include`	No	Bring back what is left out by default, e.g. `cassation_admission` (the Supreme Court's rulings on whether to accept an appeal).
`outcome`	No	Keep rulings whose operative part decides this way: `granted`, `partly`, `dismissed`, `remanded`, `not_admitted`, `terminated`; for constitutional review `unconstitutional`, `partly_unconstitutional`, `constitutional` (one or several) - e.g. sort the Supreme Court's practice into appeals granted and dismissed. Read from each ruling's own operative words (`outcome.quote` on every row, listed with or without this filter); rulings it could not read are counted under `withheld`. At most 1,000 rulings are read per call: narrow by date or court above that.
`session`	No	The `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.
`category`	No	The court's own category code; a prefix lists everything under it (`43.5`).
`case_types`	No	Kind of case: `civil`, `criminal`, `administrative`, `administrative_offence`.
`court_level`	No	Which level of the court hierarchy to list: `supreme`, `appeal`, `regional`, `district`, `supreme_administrative`, `regional_administrative`, `constitutional` (one or several).
`decided_after`	No	Only rulings decided on or after this date, `YYYY-MM-DD`.
`decided_before`	No	Only rulings decided on or before this date, `YYYY-MM-DD`.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026

changedInput schema / properties / outcome / description

Previous value: -"Keep rulings whose operative part decides this way: `granted`, `partly`, `dismissed`, `remanded`, `not_admitted`, `terminated` (one or several) - e.g. sort the Supreme Court's practice into appeals granted and dismissed. Read from each ruling's own operative words (`outcome.quote` on every row, listed with or without this filter); rulings it could not read are counted under `withheld`. At most 1,000 rulings are read per call: narrow by date or court above that."New value: +"Keep rulings whose operative part decides this way: `granted`, `partly`, `dismissed`, `remanded`, `not_admitted`, `terminated`; for constitutional review `unconstitutional`, `partly_unconstitutional`, `constitutional` (one or several) - e.g. sort the Supreme Court's practice into appeals granted and dismissed. Read from each ruling's own operative words (`outcome.quote` on every row, listed with or without this filter); rulings it could not read are counted under `withheld`. At most 1,000 rulings are read per call: narrow by date or court above that."

Changed1 schema field changedOct 6, 2026

addedInput schema / properties / outcome

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Keep rulings whose operative part decides this way: `granted`, `partly`, `dismissed`, `remanded`, `not_admitted`, `terminated` (one or several) - e.g. sort the Supreme Court's practice into appeals granted and dismissed. Read from each ruling's own operative words (`outcome.quote` on every row, listed with or without this filter); rulings it could not read are counted under `withheld`. At most 1,000 rulings are read per call: narrow by date or court above that.",
+  "title": "Outcome"
+}

AddedOct 3, 2026
RemovedOct 3, 2026
AddedOct 3, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the readOnly/no-destructive annotations: it discloses the sign-in prerequisite (connect + connect_verify), how to propagate the session, cursor pagination to the end, per-row outcome quotes, `withheld` accounting, and a 1,000-ruling-per-call read cap. These are operational constraints an agent cannot infer from annotations.

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?

Auth prerequisite is front-loaded and every sentence carries information, but the long multi-clause sentences with em-dashes and parentheticals are dense and partly restate schema content (outcome values). Efficient for a 12-parameter tool, yet not maximally scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully covers the return shape (rows with outcomes, exact total, counts by level and year, next_cursor, withheld) plus authentication and read limits. Nothing material for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine semantics: the 'at least one filter required' rule (absent from the schema), how `cursor` must reuse the same filters, and how `outcome` is read from operative words with a `withheld` bucket. Minor repetition of enum-like values already in the schema keeps it from a 5.

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 precise verb and resource ('EVERY held ruling matching structured filters') and explicitly contrasts itself with the sibling search_practice ('RANKS passages by a question and stops at a limit; this lists'). An agent can select between them without opening either schema.

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 the exact job shape ('all of them') with concrete examples (all regional labour rulings since a date, every Constitutional Court ruling of a year), names the alternative tool and its differing behavior, and states the hard prerequisite that at least one filter is required.

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 tools Inspect

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

Need Help?