Skip to main content
Glama
Sign In

Avokata: Lithuanian law & court practice

by com.avokata
OverviewDiscussionsAdmin

Finish signing in

connect_verify

Finish signing in after connect(email). The person must review the linked terms and tick the acknowledgement on their email confirmation page themselves. Never accept for them. Then call with request_id and no code, or the code they read you. A terms_acknowledgement_required state needs that human action; do not keep retrying. Also takes a key the user already holds (api_key) to use that account here.

Input Schema

NameRequiredDescriptionDefault
codeNoThe six-digit code from the email, only if the user reads it to you instead of clicking Confirm.
api_keyNoA key the user already holds (`avk_...`, or an earlier `dic_...`), to use that account in this conversation. Not needed after an email sign-in.
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.
issue_keyNoOnly when the user asks for an API key for a client without OAuth sign-in (a script, a header or URL config). Default false: the sign-in works without one in this chat, and OAuth keeps it across chats. The key is shown once.
request_idNoThe `request_id` that `connect(email=...)` returned. Call right away with no code: it waits for the user's Confirm click.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / issue_key
      Added value: +{
+  "default": false,
+  "description": "Only when the user asks for an API key for a client without OAuth sign-in (a script, a header or URL config). Default false: the sign-in works without one in this chat, and OAuth keeps it across chats. The key is shown once.",
+  "title": "Issue Key",
+  "type": "boolean"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / api_key / description
      Previous value: -"A key the user already holds (`dic_...`), to use that account in this conversation. Not needed after an email sign-in."New value: +"A key the user already holds (`avk_...`, or an earlier `dic_...`), to use that account in this conversation. Not needed after an email sign-in."
  3. Changed8 schema fields changed
    • addedInput schema / properties / api_key / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / api_key / default
      Added value: +null
    • changedInput schema / properties / api_key / description
      Previous value: -"A key issued earlier by `connect`, in the form `dic_...`. Only needed to resume an account in a NEW conversation; a fresh `connect` is the normal path."New value: +"A key the user already holds (`dic_...`), to use that account in this conversation. Not needed after an email sign-in."
    • removedInput schema / properties / api_key / type
      Removed value: -"string"
    • addedInput schema / properties / code
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The six-digit code from the email, only if the user reads it to you instead of clicking Confirm.",
+  "title": "Code"
+}
    • addedInput schema / properties / request_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The `request_id` that `connect(email=...)` returned. Call right away with no code: it waits for the user's Confirm click.",
+  "title": "Request Id"
+}
    • addedInput schema / properties / session
      Added value: +{
+  "description": "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.",
+  "type": "string"
+}
    • removedInput schema / required
      Removed value: -[
-  "api_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 declare non-readOnly, non-destructive, non-idempotent, but the description adds the crucial operational facts: a human must tick the acknowledgement themselves and the agent must never accept on their behalf, plus the do-not-retry rule for the acknowledgement state. These are behavioral constraints no annotation could convey and are the highest-value content here.

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-loaded with the primary action and the human-in-the-loop rule, and nearly every sentence carries an instruction. It is dense — several distinct rules are compressed into single sentences and the api_key mode arrives as an appended clause — but there is little outright waste.

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?

For a five-parameter, zero-required, no-output-schema tool, the description covers both entry paths, the waiting/polling semantics, the terminal error state, and the one-time nature of an issued key. An agent has enough to call it correctly without guessing.

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; the description still adds the inter-parameter relationship the schema does not state — request_id paired with no code versus a code the user read out, and api_key as an alternative entry path. The session parameter is left to the schema, which is acceptable given full coverage.

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?

The description names a specific action ('Finish signing in') and ties it directly to the sibling it follows ('after connect(email)'). It also delineates a second mode ('Also takes a key the user already holds (api_key)'), so an agent can tell this apart from connect and the other auth-adjacent siblings.

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?

It gives explicit routing and call shapes: call with request_id and no code to wait for the Confirm click, or with the six-digit code if the user reads it aloud, or with an existing api_key. It also states a clear negative condition — a terms_acknowledgement_required state requires human action and must not be retried — which is exactly the kind of when-not guidance that prevents loops.

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