Skip to main content
Glama

Lexiara

by org.lexiara
OverviewDiscussionsAdmin

Every term an instrument defines

work_glossary
Read-onlyIdempotent

The act's glossary: every term it defines, alphabetical, with the publisher's own wording verbatim and the provision that defines each one. Use it to orient in an unfamiliar instrument, or to check what a term means IN THIS ACT rather than in the corpus at large — several instruments define 'consumer' differently and all are right within their own scope.

AN EMPTY GLOSSARY IS ABOUT OUR READER, NOT THE ACT. Extraction reads the drafting constructions it has been taught and coverage is uneven across legal traditions; provisions is returned so a zero can be read against the size of the instrument. Do not report it as 'this act defines no terms'.

A NULL definition means one of two things: borrowed true means the act takes the meaning from another instrument and states none of its own; otherwise the wording could not be delimited. count is three populations (defines, adoptsCount, undelimited) — never quote it as one.

The definitions are free. Only the adopts resolution (which act a borrowed definition comes from) is Lexiara Nexus data requiring an API key on a signed-in account.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
workYesELI or official number of the instrument, e.g. '32011L0083'.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "The JSON response from the corresponding Lexiara API route.",
+  "type": "object"
+}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already establish readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the warning that an empty glossary reflects extraction coverage rather than the act, the two-way meaning of a null definition (borrowed vs undelimited), the three-population nature of count, and the API-key requirement for the adopts resolution. This is exactly the behavioral detail annotations cannot carry.

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 core definition before the caveats, and each paragraph carries distinct information. The all-caps warnings and long caveat block are slightly heavy, but virtually every sentence earns its place by preventing a specific misreading.

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 an output schema present, the description need not explain return values, yet it still clarifies the ambiguous ones (count populations, null definitions). Combined with the annotations covering safety, nothing an agent needs to call this correctly is missing.

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% for the single required 'work' param, so the schema already documents format and examples. The description's field-level talk (count, provisions, borrowed, adopts) concerns outputs, not input semantics, so it adds nothing to the input parameter. Baseline 3 applies.

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 resource (the act's glossary) with concrete scope modifiers: every term it defines, alphabetical, verbatim wording, plus the defining provision. It explicitly distinguishes itself from the corpus-wide alternative by emphasizing meanings 'IN THIS ACT rather than in the corpus at large', which separates it from the sibling define_term.

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 two concrete use cases (orient in an unfamiliar instrument; verify a term's meaning within this act) and the condition that selects this tool over the corpus-level alternative. It also sets an explicit when-NOT-to-report rule: 'Do not report it as this act defines no terms' when the glossary is empty.

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

All Lexiara 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