Skip to main content
Glama

law_query

Read-only

Une requête LawQL déterministe sur le CLIR d'une formalisation : une question sur le modèle de l'acte lui-même, pas sur une affaire. Relations (14) : anchors, edges, fields, imports, interpretations, labels, links, literals, nodes, norms, positions, rules, variables, windows. Listes des champs : law query --schema. Fonctions (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 sur une variable liée ; égalité et appartenance seulement, sans arithmétique ni comparaisons d'ordre. Périmètre : corpus par package.name (par exemple kz.corpus.labour_code, pas un nom de fichier) ou un glob ; sans corpus, toute la tranche du profil ; un périmètre hors profil est vide (CORPUS_EMPTY). Exemples : from r in rules where r.head_predicate == "urn:…#eligible" select r.id as producer, r.strength as strength, anchor(r.id) as anchors — qui produit ; from l in literals where l.predicate == "urn:…#eligible" select l.node as reader, l.context as context — qui lit ; query eligible over "pkg" { for x: Person; where applicant(x); select eligible(x); } — inférence par le noyau. C'est une orchestration au-dessus du CLIR et du noyau ; aucune sémantique juridique nouvelle n'est implémentée ici. Au lieu du texte, une question du catalogue avec arguments : anchors-of, imports-of, links-of, producers, readers, type-step (composition : law query --list) (les paramètres predicate/node/type sont des URN, pkg un package.name ou un glob). La réponse structurelle est une queryPage : resultHash du queryResult complet, snapshot (hachage de la liste des paquets du périmètre), rowCount, rows selon rowLimit (20, au plus 5000) et rowOffset, next avec le snapshot pour continuer ; full: true renvoie le queryResult complet quand le périmètre est un seul paquet. Chaque ligne porte sa provenance (nœuds CLIR) ; une réponse vide porte l'entonnoir explain (emptyAt nomme la clause) ; les erreurs portent des codes LDC-Qxxxx avec des indices ; un produit de sources trop large est refusé avant exécution (QUERY_TOO_BROAD), une continuation sur un autre instantané — SNAPSHOT_CHANGED.

Input Schema

NameRequiredDescriptionDefault
caseNol'affaire pour query-over ; elle remplace la clause case
fullNorenvoyer le queryResult complet au lieu d'une page ; seulement quand le périmètre est un seul paquet
limitNoun plafond explicite des matérialisations eval() (il ne borne PAS les lignes — voir rowLimit)
queryNoinline LawQL
corpusNole périmètre de l'instantané : un package.name (par exemple kz.corpus.labour_code) ou un glob sur package.name ; sans corpus, toute la tranche du profil
engineNoil y a un moteur — le noyau ; l'implémentation de référence est appelée par sa propre commandelawc
questionNole nom d'une question du catalogue de questions nommées (producers, readers, anchors-of, imports-of, links-of, type-step) ou d'un lint ; à la place de query
rowLimitNocombien de lignes dans structuredContent (20 ; le budget peut le baisser)
snapshotNole hachage d'instantané de next.snapshot de la page précédente : une continuation sur un autre instantané est refusée (SNAPSHOT_CHANGED)
argumentsNoles paramètres de la question : un objet « nom → chaîne » (predicate, node, type — des URN ; pkg — un package.name ou un glob)
rowOffsetNoà partir de quelle ligne (0) ; la continuation vient de next avec snapshot ; requêtes structurelles seulement

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / question / description
      Previous value: -"le nom d'une question du catalogue corpus/ql/questions (producers, readers, anchors-of, imports-of, links-of, type-step) ou d'un lint ; à la place de query"New value: +"le nom d'une question du catalogue de questions nommées (producers, readers, anchors-of, imports-of, links-of, type-step) ou d'un lint ; à la place de query"
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, non-destructive), and the description adds substantial behavior beyond them: queryPage pagination with resultHash/snapshot/rowCount/rowLimit/rowOffset, per-row CLIR provenance, the empty-response explain funnel, and explicit error codes (CORPUS_EMPTY, QUERY_TOO_BROAD, SNAPSHOT_CHANGED, LDC-Qxxxx). This is exactly the extra context an agent needs.

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 definition is front-loaded with the core purpose, and most sentences carry real information, but it is an extremely dense single block that mixes query syntax, relations/functions, scope, examples, pagination and error codes, making it hard to scan. Structure suffers even though little is truly redundant.

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

Completeness4/5

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

For an 11-parameter, nested, no-output-schema tool, the description covers the return structure (queryPage fields), continuation protocol, scope resolution, and error taxonomy well enough to call correctly. Only minor details such as the full catalog of named questions remain to be discovered via the referenced CLI.

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%, establishing a baseline of 3. The description goes further by clarifying scope semantics (package.name or glob, whole profile slice when absent), URN typing for predicate/node/type, and continuation semantics that tie snapshot across calls, adding meaning beyond the field-level text.

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 verb+resource ("Une requête LawQL déterministe sur le CLIR d'une formalisation") and immediately scopes it as "une question sur le modèle de l'acte lui-même, pas sur une affaire", distinguishing it from case-oriented siblings. An agent can identify the operation and its domain without opening the schema.

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?

The exclusion "pas sur une affaire" implicitly routes case questions elsewhere, and named-question alternatives (anchors-of, producers, readers, type-step) are listed. However, no sibling tool is named explicitly as the alternative, so the when/when-not guidance is clear but not fully mapped to alternatives.

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.