Skip to main content
Glama
Sign In

Avokata: Lithuanian law & court practice

by com.avokata
OverviewDiscussionsAdmin

Open a playbook or job

get_workflow
Read-onlyIdempotent

Sign-in required: call connect(email) and connect_verify first (free, one email) unless this connection is already signed in. Open one workflow as a PLAN bound to the task: the ordered tool calls with the act number, case number or date from task filled in and every other slot left open, the principles and what the result looks like. Sizes cover the complete JSON payload; the 2,000-character target is advisory and safeguards are never cut. Compare with existing instructions: use, adapt, supplement or skip. You run applicable steps yourself: this tool runs no step and checks no result. Pass the workflow_id returned by find_workflow (one task) or list_workflows (all of them): task binds the plan's slots and does not replace that id. detail='full' adds prose; follow any explicit conditional full-read requirement. To write a new workflow use workflow_guide. Example arguments: {"workflow_id": "provision-history", "task": "CK 6.217, 2024-01-15", "detail": "plan"}.

Input Schema

NameRequiredDescriptionDefault
taskNoThe user's task in a sentence. Exact identifiers in it (an act number `XII-2603`, a case number `e3K-3-105-684/2019`, a date `2021-03-01`) are filled into the plan's slots; every other slot stays open for you to fill.
detailNo`plan` (default): calls, essential checks and outputs; complete JSON character/UTF-8 byte sizes are reported. The 2,000-character target is advisory, with over_target rather than cut safeguards. `full` adds explanation; follow any explicit conditional full-read requirement.plan
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.
workflow_idNoWhich workflow to open, by the `workflow_id` from `find_workflow` or `list_workflows` - e.g. `still-good-law`, `job-matter-memo`. A bare id is the playbook; a job is `job-<id>`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / detail / description
      Previous value: -"`plan` (the default): the ordered calls, principles and outputs, under 2,000 characters. `full` adds the prose body the plan was copied from."New value: +"`plan` (default): calls, essential checks and outputs; complete JSON character/UTF-8 byte sizes are reported. The 2,000-character target is advisory, with over_target rather than cut safeguards. `full` adds explanation; follow any explicit conditional full-read requirement."
  2. Changed7 schema fields changed
    • addedInput schema / properties / detail
      Added value: +{
+  "default": "plan",
+  "description": "`plan` (the default): the ordered calls, principles and outputs, under 2,000 characters. `full` adds the prose body the plan was copied from.",
+  "enum": [
+    "plan",
+    "full"
+  ],
+  "title": "Detail",
+  "type": "string"
+}
    • addedInput schema / properties / task
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The user's task in a sentence. Exact identifiers in it (an act number `XII-2603`, a case number `e3K-3-105-684/2019`, a date `2021-03-01`) are filled into the plan's slots; every other slot stays open for you to fill.",
+  "title": "Task"
+}
    • addedInput schema / properties / workflow_id / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / workflow_id / default
      Added value: +null
    • changedInput schema / properties / workflow_id / description
      Previous value: -"Which playbook to read, by the `workflow_id` from `list_workflows` - e.g. `still-good-law`, `matter-digest`."New value: +"Which workflow to open, by the `workflow_id` from `find_workflow` or `list_workflows` - e.g. `still-good-law`, `job-matter-memo`. A bare id is the playbook; a job is `job-<id>`."
    • removedInput schema / properties / workflow_id / type
      Removed value: -"string"
    • removedInput schema / required
      Removed value: -[
-  "workflow_id"
-]
  3. Changed1 schema field changed
    • changedInput schema / properties / session / description
      Previous value: -"The `session` value connect returned, when this client keeps no connection session. Pass it on every Avokata call in this conversation; omit it when the client sends a key."New value: +"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."
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, but the description adds material context beyond them: the sign-in dependency, that no step is executed or verified, the 2,000-character advisory size target with 'safeguards are never cut', and the conditional full-read requirement. Size reporting and the advisory-vs-hard limit distinction are exactly the kind of behavior 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?

Dense but front-loaded: the sign-in gate opens, the plan contents and execution boundary follow, then id sourcing and detail semantics. Minor waste remains in restating the 2,000-character/advisory/safeguards rule, which already appears verbatim in the `detail` schema description.

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?

There is no output schema, so the description carries the return-value burden and does it well: it describes the plan's contents (calls, slots, principles, expected result) and size reporting. For a 4-parameter, annotation-rich tool, nothing needed 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.

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 real meaning: it clarifies that `task` binds only slots and 'does not replace that id', that a bare workflow_id is a playbook while jobs use `job-<id>`, and it supplies a worked example of arguments. This clarifies the relationship between the two most confusable parameters rather than restating the schema.

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 verb and resource ('Open one workflow as a PLAN bound to the task') and enumerates what the plan contains: ordered tool calls with filled slots, principles, and expected result. It is unmistakable against siblings, since it explicitly routes to find_workflow/list_workflows for the id and to workflow_guide for authoring a new workflow.

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 prerequisites ('call connect(email) and connect_verify first ... unless this connection is already signed in'), the exact source of workflow_id, when to use detail='full', and the alternative tool for writing workflows. It also states a negative boundary: 'this tool runs no step and checks no result', i.e. the agent executes the plan itself.

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