Skip to main content
Glama

law_query

Read-only

A deterministic LawQL query over the CLIR of a formalization: a question about the model of the act itself, not about a case. Relations (14): anchors, edges, fields, imports, interpretations, labels, links, literals, nodes, norms, positions, rules, variables, windows. Full field lists: law query --schema. Functions (9): anchor/1, labels/1..2, short/1, contains/2, overlaps/2, starts_with/2, ends_with/2, position/2, derivation/2. exists/not exists over a bound variable; equality and membership only, no arithmetic and no ordering comparisons. Scope: corpus by package.name (for example kz.corpus.labour_code, not a file name) or a glob; without corpus, the whole profile slice; a scope outside the profile is empty (CORPUS_EMPTY). Examples: from r in rules where r.head_predicate == "urn:…#eligible" select r.id as producer, r.strength as strength, anchor(r.id) as anchors — who produces; from l in literals where l.predicate == "urn:…#eligible" select l.node as reader, l.context as context — who reads; query eligible over "pkg" { for x: Person; where applicant(x); select eligible(x); } — inference by the core. This is orchestration over the CLIR and the core; no new legal semantics is implemented here. Instead of text, a question from the catalog with arguments: anchors-of, imports-of, links-of, producers, readers, type-step (see law query --list for the set) (predicate/node/type parameters are URNs, pkg is a package.name or a glob). A structural answer is a queryPage: resultHash of the full queryResult, snapshot (hash of the scope package list), rowCount, rows by rowLimit (20, at most 5000) and rowOffset, next with the snapshot for continuation; full: true returns the full queryResult when the scope is one package. Every row carries provenance (CLIR nodes); an empty answer carries the explain funnel (emptyAt names the clause); errors carry LDC-Qxxxx codes with hints; a source product too wide is refused before execution (QUERY_TOO_BROAD), a continuation on another snapshot as SNAPSHOT_CHANGED.

Input Schema

NameRequiredDescriptionDefault
caseNothe case for query-over; it replaces the case clause
fullNoreturn the full queryResult instead of a page; only when the scope is one package
limitNoan explicit cap on eval() materialisations (it does NOT bound the rows — see rowLimit)
queryNoinline LawQL
corpusNothe snapshot scope: a package.name (for example kz.corpus.labour_code) or a glob over package.name; without corpus, the whole profile slice
engineNothere is one engine — the core; the reference implementation is called by its own commandlawc
questionNothe name of a question from the named-query catalog (producers, readers, anchors-of, imports-of, links-of, type-step) or of a lint; instead of query
rowLimitNohow many rows in structuredContent (20; the budget may lower it)
snapshotNothe snapshot hash from next.snapshot of the previous page: a continuation on another snapshot is refused (SNAPSHOT_CHANGED)
argumentsNothe question parameters: an object of name → string (predicate, node, type — URNs; pkg — a package.name or a glob)
rowOffsetNofrom which row (0); continuation comes from next together with snapshot; structural queries only

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the readOnlyHint/destructiveHint=false annotations, the description discloses refusal-before-execution behavior (QUERY_TOO_BROAD), CORPUS_EMPTY for out-of-profile scope, SNAPSHOT_CHANGED on stale continuations, LDC-Qxxxx error codes with hints, row-limit budgeting (default 20, cap 5000), and the explain funnel on empty results. This is exactly the kind of operational context 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.

Conciseness3/5

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

The purpose is front-loaded, but the body is a dense run-on that enumerates 14 relations and 9 function signatures plus scope, examples, catalog questions, and pagination in one block — much of which the description itself defers to `law query --schema`. It is information-rich but substantially over-sized for a description field.

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 11 parameters, nested objects, and no output schema, the description carries the full return-shape burden and does so: queryPage with resultHash, snapshot, rowCount, rows/rowLimit/rowOffset, next-with-snapshot, and full:true semantics. Provenance, empty-answer, and error behaviors are all covered, so an agent has what it needs to call and interpret it.

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 `query` is inline LawQL vs `question` naming a catalog entry vs `case`/`arguments` replacing clauses, and it explains rowLimit's budget vs an eval cap. It largely restates the schema's own parameter docs for corpus/snapshot/full, so it does not reach a 5.

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

Purpose4/5

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

The opening states a specific verb and resource — a deterministic LawQL query over the CLIR of a formalization — and immediately scopes it as "a question about the model of the act itself, not about a case," which distinguishes it from case-oriented siblings like law_case_ask. It stops short of naming those siblings or summarizing the tool in plain terms, so the dense jargon keeps it from a 5.

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

Usage Guidelines4/5

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

It gives clear context for when the tool applies (model-level questions, structural query over relations/functions, or a catalog question from `--list`), and it contrasts the model scope against case queries. It does not explicitly route the agent between this and siblings such as law_ask or law_search, so it lacks a true when/not/alternative statement.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.