Skip to main content
Glama

law_query

Read-only

Eine deterministische LawQL-Abfrage über das CLIR einer Formalisierung: eine Frage an das Modell des Aktes selbst, nicht an einen Fall. Relationen (14): anchors, edges, fields, imports, interpretations, labels, links, literals, nodes, norms, positions, rules, variables, windows. Feldlisten: law query --schema. Funktionen (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 über eine gebundene Variable; nur Gleichheit und Mitgliedschaft, keine Arithmetik und keine Ordnungsvergleiche. Bereich: corpus nach package.name (zum Beispiel kz.corpus.labour_code, kein Dateiname) oder ein Glob; ohne corpus der gesamte Profilausschnitt; ein Bereich außerhalb des Profils ist leer (CORPUS_EMPTY). Beispiele: from r in rules where r.head_predicate == "urn:…#eligible" select r.id as producer, r.strength as strength, anchor(r.id) as anchors — wer erzeugt; from l in literals where l.predicate == "urn:…#eligible" select l.node as reader, l.context as context — wer liest; query eligible over "pkg" { for x: Person; where applicant(x); select eligible(x); } — Inferenz durch den Kern. Dies ist Orchestrierung über CLIR und Kern; neue juristische Semantik wird hier nicht implementiert. Statt Text eine Frage aus dem Katalog mit arguments: anchors-of, imports-of, links-of, producers, readers, type-step (Stand: law query --list) (die Parameter predicate/node/type sind URNs, pkg ein package.name oder ein Glob). Die strukturelle Antwort ist eine queryPage: resultHash des vollständigen queryResult, snapshot (Hash der Paketliste des Bereichs), rowCount, rows nach rowLimit (20, höchstens 5000) und rowOffset, next mit dem snapshot zur Fortsetzung; full: true liefert das vollständige queryResult, wenn der Bereich ein einzelnes Paket ist. Jede Zeile trägt ihre Provenienz (CLIR-Knoten); eine leere Antwort trägt den Explain-Trichter (emptyAt nennt die Klausel); Fehler tragen LDC-Qxxxx-Codes mit Hinweisen; ein zu breites Quellenprodukt wird vor der Ausführung abgelehnt (QUERY_TOO_BROAD), eine Fortsetzung auf einem anderen Schnappschuss als SNAPSHOT_CHANGED.

Input Schema

NameRequiredDescriptionDefault
caseNothe case for query-over; it replaces the case clause
fullNodas vollständige queryResult statt einer Seite zurückgeben; nur wenn der Bereich ein einzelnes Paket ist
limitNoan explicit cap on eval() materialisations (it does NOT bound the rows — see rowLimit)
queryNoinline LawQL
corpusNoder Bereich des Schnappschusses: ein package.name (zum Beispiel kz.corpus.labour_code) oder ein Glob über package.name; ohne corpus der gesamte Profilausschnitt
engineNothere is one engine — the core; the reference implementation is called by its own commandlawc
questionNoder Name einer Frage aus dem Katalog benannter Abfragen (producers, readers, anchors-of, imports-of, links-of, type-step) oder eines Lints; anstelle von query
rowLimitNohow many rows in structuredContent (20; the budget may lower it)
snapshotNoder Schnappschuss-Hash aus next.snapshot der vorherigen Seite: eine Fortsetzung auf einem anderen Schnappschuss wird abgelehnt (SNAPSHOT_CHANGED)
argumentsNodie Parameter der Frage: ein Objekt „Name → Zeichenkette“ (predicate, node, type — URNs; pkg — ein package.name oder ein Glob)
rowOffsetNoab welcher Zeile (0); die Fortsetzung kommt aus next zusammen mit snapshot; nur strukturelle Abfragen

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / question / description
      Previous value: -"der Name einer Frage aus dem Katalog corpus/ql/questions (producers, readers, anchors-of, imports-of, links-of, type-step) oder eines Lints; anstelle von query"New value: +"der Name einer Frage aus dem Katalog benannter Abfragen (producers, readers, anchors-of, imports-of, links-of, type-step) oder eines Lints; anstelle von query"
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the read-only annotations, the description discloses pagination behavior (rowLimit default 20, max 5000, next/snapshot), full-result mode, provenance per row, empty-result explain funnels with emptyAt, error codes, and pre-execution rejection of overly broad queries (QUERY_TOO_BROAD) or stale continuations (SNAPSHOT_CHANGED). It also sets the scope boundary that an out-of-profile corpus yields CORPUS_EMPTY.

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 content is highly relevant for an 11-parameter query language, but it is presented as a dense, semicolon-heavy block rather than a structured reference. The purpose is front-loaded and most clauses earn their place, yet readability and scanability suffer.

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, and the description compensates by explaining the queryPage shape, row provenance, empty-result diagnostics, error codes, and snapshot-based continuation. Combined with the schema's full parameter descriptions and the listed relations/functions, an agent has enough information to form and continue queries correctly.

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 description coverage is 100%, so the baseline is 3; the description still adds useful semantics: corpus is a package.name or glob rather than a filename, without corpus means the whole profile slice, full only works for a single package, and limit caps materialisations rather than rows. It also clarifies that predicate/node/type are URNs and that snapshot continues a previous page.

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 states a specific verb and resource: a deterministic LawQL query over CLIR, explicitly framed as a question to the act's model rather than to a case. It lists the queryable relations and functions and gives concrete examples, so the agent can distinguish this structured-query tool from case-oriented or natural-language siblings.

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 explains how the tool is used (inline LawQL, catalog question names, arguments, corpus scope, continuations) and clarifies that this is orchestration over CLIR and the core rather than new legal semantics. It does not explicitly say when to choose this over siblings such as law_ask or law_search, so it lacks full when-not/alternatives guidance.

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.