Skip to main content
Glama

law_packages

Read-only

Le catalogue du droit formalisé : actes, prédicats avec signatures, frontières de couverture. C'est d'ici que viennent les NOMS des prédicats — ils ne doivent jamais être inventés. Mais ne commencez PAS par le catalogue pour trouver le bon acte : l'aperçu est vaste, et le titre d'un acte coïncide rarement avec les mots d'une question (« Newton's laws of motion » ne contient pas le mot « physics »). Une question dans vos propres mots va d'abord à law_search, qui renvoie des adresses ; le catalogue sert à la signature exacte de ce que vous avez trouvé. Sans arguments — l'aperçu : une ligne par acte (clé, titre, ordre juridique, compteurs de règles, faits, signatures, normes, constantes) ; un acte entier — package="kz-gpk" ; une recherche sur les signatures, étiquettes et constantes de tous les actes — query="substring". Les trois modes sont PAGINÉS : limit et offset, le reste nommé dans le texte (showing a–b of N; k more) et dans structuredContent (total, truncated, next — un appel de continuation tout prêt). L'unité d'une page est nommée par pageUnit : l'aperçu et query paginent les ACTES (20 et 20 par défaut), package=… pagine les SIGNATURES d'un acte (20 par défaut, 300 au plus) — les grands codes en portent des milliers. package=… avec catalog=… pagine une liste séparée de l'acte : "questions" — le CATALOGUE DES QUESTIONS : quelles demandes sont prévues (une question en mots, une forme, un prédicat ou des normes) et à quoi l'acte NE répond PAS, avec le type de motif ; une fiche est un modèle de demande, non une réponse, et tous les actes n'en ont pas ; "norms" — les NORMES de l'acte, "constants" — les CONSTANTES (noms des déclarations). "task-guides" — les PARCOURS DE TÂCHE : l'ordre d'application d'un canon à un document — quoi recueillir, quelles cartes interroger et comment lire les réponses ; un parcours ne répond à rien. catalog="task-guides" est admis aussi sans package — tous les parcours du profil ; guide=… — le détail d'un parcours ; le parcours lui-même — MCP Prompts sous le même nom. Le détail d'un acte imprime un aperçu de ces listes et nomme le compte et l'appel tout prêt du mode.

Input Schema

NameRequiredDescriptionDefault
guideNoavec catalog="task-guides" : le détail d'un parcours — un nom <paquet>/<id> (comme dans prompts/list) ou un id avec package
limitNocombien par page : actes (aperçu 20, query 20), signatures d'un acte (20, 300 au plus) ou éléments d'une liste catalog (questions 20, normes 20, constantes 100, parcours de tâche 20)
queryNoun filtre de sous-chaîne sur signatures, étiquettes et constantes (sans distinction de casse)
offsetNoà partir de quel élément de la page (0) ; l'unité est le pageUnit de la réponse
catalogNoavec package : paginer le catalogue des questions, les normes, les constantes ou les parcours de tâche de l'acte au lieu de ses signatures ; "task-guides" aussi sans package : tous les parcours de tâche du profil
packageNoles signatures complètes de cet acte

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare safety hints (readOnly/openWorld/destructive), so the description carries the real behavioral load: it discloses the three modes, pageUnit semantics, per-mode defaults (20/20/20/300), the `showing a–b of N; k more` text and structuredContent fields (total, truncated, next with a ready continuation call). This is rich context well beyond the annotations, and it is internally consistent with readOnlyHint.

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?

It is long and dense, but for a six-parameter, multi-mode catalog almost every clause carries operational facts (modes, pagination, catalog types, guide handling). Purpose is front-loaded in the first sentence; structure would benefit from lists, but there is little pure filler.

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?

For a tool with no output schema and six optional parameters, the description is complete enough to call correctly: it covers all modes, pagination units and defaults, the structuredContent continuation fields, the catalog list types, and the relationship to MCP Prompts for task-guides.

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 3 is the baseline; the description exceeds it by giving per-mode defaults and caps for limit, explaining that offset's unit is the response's pageUnit, and clarifying what package vs. query vs. catalog select. It adds operational meaning (defaults, caps, mode interactions) that the schema alone does not convey.

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 and scope ("Le catalogue du droit formalisé : actes, prédicats avec signatures, frontières de couverture") and explicitly distinguishes itself from the sibling law_search, explaining that predicate NAMES come from here and must never be invented. An agent can tell this apart from law_search/law_query without opening a schema.

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 explicit when-not guidance ("ne commencez PAS par le catalogue... Une question dans vos propres mots va d'abord à law_search") and the precise condition for using it ("le catalogue sert à la signature exacte de ce que vous avez trouvé"). It even gives the selectable modes by argument. Nothing is left to inference.

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.