Avokata: Lithuanian law for your agent

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

With no annotations, the description carries the transparency burden and does disclose useful behavioral traits: no email, no signup, no key. However, it claims 'Takes NO arguments' while the schema defines two optional parameters, and it does not explain what a successful connect actually changes or returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences that front-load the purpose and no-auth guarantee, with the usage condition stated efficiently at the end. Every clause contributes information; there is no filler or repetition.

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

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

For a simple bootstrap tool, the description covers when to call it and that no user credentials are needed. It remains incomplete because it does not describe success/return behavior and contradicts the schema's optional parameters by insisting on 'NO arguments'.

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

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

Schema description coverage is 100%, so the baseline is 3 even without parameter detail in the description. The description adds no parameter-level meaning and its 'NO arguments' claim is an overstatement of the schema's optional firm and email fields, which the schema itself documents clearly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Start using Avokata' and says 'the conversation is connected', clearly identifying the tool as a connection/initialization operation. It also differentiates itself from siblings with 'Call this first if the other tools are not visible'. The meaning of 'connected' is slightly abstract, so it does not earn a 5.

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

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

It gives an explicit trigger condition: call this first if other tools are not visible, which frames it as a bootstrap/precondition tool rather than a routine lookup. It does not name alternative tools or state when not to use it, so it stops short of full exclusion guidance.

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

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

With no annotations provided, the description carries the full burden. It discloses the key side effect (later calls will not need the header), but it does not mention failure behavior, whether the key is validated at call time, or any other safety-relevant traits. Adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action and outcome, and zero filler. Every word earns its place, making the description easy to scan.

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

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

This is a low-complexity tool with one parameter and no output schema. The description states the effect, and the schema thoroughly covers the parameter and the alternative path. However, the main description alone leaves the contrast with `connect` to inference and says nothing about the result or failure behavior, so it is not fully complete.

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

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

The single `api_key` parameter is fully documented in the schema (100% coverage), including format and when it is needed. The description adds no information beyond what the schema already provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Use') and resource ('an existing Avokata key') with a clear outcome ('so later calls do not need the header'). It distinguishes from the sibling `connect` only semantically via 'existing key' rather than naming the alternative explicitly.

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

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

The description implies the precondition ('the key the user already holds') but does not explicitly state when to choose this tool over `connect` or provide exclusions. The input schema does say 'a fresh `connect` is the normal path,' but the main description itself lacks explicit routing guidance.

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

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

No annotations are provided, so the description carries the full burden. It only implies a read operation via the verb 'Get' and describes the content of the returned playbook, but it does not disclose side-effect freedom, authentication needs, error behavior, or rate limits. This is a significant gap for a tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler. It front-loads the core purpose ('Get one playbook in full') and then adds the essential content details. Every word contributes to understanding.

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

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

For a simple two-parameter tool, the description gives a high-level summary of the return content but omits behavioral context such as read-only safety, authentication requirements, and error cases. Since no output schema exists, the description's partial explanation of return values is helpful but not fully complete.

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

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

Schema description coverage is 100% for both parameters, including a clear explanation of workflow_id and session. The description adds no parameter-level meaning beyond the schema, but since the schema already does the heavy lifting, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Get' and a specific resource 'one playbook in full', and enumerates the contained elements: procedure, expected tools, and answer requirements. This unambiguous scope distinguishes it from list_workflows (which lists playbooks) and the search tools.

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

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

The description implies usage when a full playbook is needed for a known workflow_id, but it does not explicitly state when to use it versus list_workflows or the search tools, nor does it state when not to use it. There is no alternative routing or exclusion guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it only states what the tool does (lists playbooks) without revealing side effects (e.g., read-only nature), session requirements beyond the schema, or output format. It does not mention pagination, ordering, or potential errors. This is a significant gap for a tool called without any annotation guidance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with zero filler. It fronts the core function (listing playbooks) and then adds a usage hint. Every word earns its place. Highly concise and well-structured.

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

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

For a simple listing tool with no output schema and one optional parameter, the description is largely sufficient. It communicates what the tool does and when to use it. It does not describe the return format, but that can be inferred from 'List the playbooks.' Given the low complexity, it is almost complete, though a note on what the returned items look like would push it to 5.

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

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

The schema description covers the single parameter 'session' with a clear explanation of when to pass it and when to omit it (100% coverage). The description adds no additional parameter semantics, but since the schema is thorough, the description does not need to compensate. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists available playbooks (both Avokata-shipped and account-written). It uses a specific verb, 'list,' and a specific resource, 'playbooks.' It implies a distinction from get_workflow (which likely fetches a single workflow) but does not explicitly name sibling tools, so it's not a 5.

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

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

The description gives a clear trigger condition: 'Call this when you want the procedure for a legal task rather than inventing one.' This tells the agent when to use it, but it does not explicitly state when not to use it or mention alternative tools like get_workflow or search_law. Still, the guidance is specific and actionable.

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

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

With no annotations provided, the description carries the full burden and exceeds it: discloses that it returns pinpoints not summaries, that it searches only law in force (no date filter), that English queries return confident nonsense (with measurement data), and that foreign jurisdictions won't fail but name what's unavailable. It also explains the procedural-code pitfall explicitly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Despite length, every sentence earns its place: the critical language warning is front-loaded, the procedural-code warning is bolded and quantified, and follow-up tools are named. The structure flows logically from purpose to usage to pitfalls and parameters, with no filler.

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

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

For a 9-parameter tool with no output schema, the description is remarkably complete: it explains what the tool returns, how to phrase queries, how to restrict by codes/acts/types/jurisdictions, and what happens when parameters are misused. It also points to downstream tools, covering everything an agent needs to call it correctly.

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

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 substantial meaning beyond the schema: explains why `codes` is critical for procedural questions, clarifies `also` as genuinely different angles with hit-rate measurements, interprets `limit` (more context, not more documents), and distinguishes `in_force` from past-date questions. It enriches every parameter with actionable guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Find the statutory provision') and resource ('teisės akto straipsnis', 'acts and codes in the consolidated version in force now'), and distinguishes its scope from siblings like search_practice (which handles practice guidance). The description is unambiguous about what this tool does.

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

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

Explicitly instructs the language requirement ('PASS THE QUERY IN LITHUANIAN') with measured evidence, tells when to pass `codes` for procedural matters, provides follow-up tools (read_paragraphs, cited_by), and points to alternative `check_validity` for past-date questions. It clearly differentiates from other tools and gives concrete conditions.

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

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

With no annotations, the description carries the full burden, and it does well: it warns that English queries produce confident nonsense, explains that rulings are served as the courts published them, and discloses the anonymisation reason behind the no-party-search limitation. These are substantive behavioral facts an agent needs before calling the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and front-loaded: purpose first, then the language warning, then filters and the exclusion. Every sentence contributes meaningful information, though it is somewhat long; a 4 reflects that it is efficient but not as lean as a two-sentence definition.

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

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

For an 8-parameter tool with no output schema and no annotations, the description provides enough to call the tool correctly: language requirement, filter options, and the party-name exclusion. It does not describe return format or pagination, but the schema's limit parameter already covers 'passages, not judgments', so the description is adequate.

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

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 adds value beyond the schema by giving example Lithuanian terms (kasacinis skundas, ieškinys), enumerating case types, explaining the `43.5` category-code prefix behavior, and emphasising that no parameter accepts a party name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names the resource (court practice / teismų praktika), the action (Find), and the result (rulings and judgments as courts published them). This clearly distinguishes it from the sibling search_law, which targets statutes, and from the connection/workflow tools.

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

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

The description gives explicit usage rules: pass the query in Lithuanian, use the courts' own terms with examples, and filter by court, date, case type, or category code. It also states an explicit when-not: there is no way to search by a party name because rulings are anonymised. It references search_law only for the language rationale rather than explicitly routing statutory queries elsewhere, so the alternative mapping is not fully explicit.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It describes output topics but does not state that the call is read-only, whether authentication is required, or whether quotas information implies rate-limit exposure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, compact sentence with no filler. The most important outputs—identity, quotas, jurisdictions—are front-loaded and easy to parse.

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

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

The description enumerates the three kinds of information returned, which is important because there is no output schema. It does not discuss call context or the optional session parameter, but for a simple informational tool it is largely sufficient.

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

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

The input schema already documents the only parameter, session, with 100% coverage. The description does not add extra meaning about when or how to pass session, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies what the tool reports: the server's identity for the caller, remaining quotas, and jurisdictions with a corpus. It is easily distinguished from siblings like connect or search_law, though it lacks a direct verb such as 'returns'.

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

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

No guidance is given about when to call this tool or how it relates to alternatives. It would benefit from an explicit note that it is typically called after connect to verify the session or inspect available jurisdictions.

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