Skip to main content
Glama

law_packages

Read-only

The catalogue of formalised law: instruments, predicates with signatures, the boundaries of coverage. This is where the NAMES of predicates come from — they must never be guessed. But do NOT start from the catalogue when looking for the right instrument: the overview is large, and the title of an instrument rarely matches the words of a question ("Newton's laws of motion" contains no word "physics"). A question in your own words goes to law_search first, which returns addresses; the catalogue is for the exact signature of what you found. With no arguments — the overview: one line per instrument (key, title, legal order, counters of rules, facts, signatures, norms, constants); a whole instrument — package="kz-gpk"; a search over the signatures, labels and constants of every instrument — query="substring". All three modes are PAGED: limit and offset, with the remainder named in the text (showing a–b of N; k more) and in structuredContent (total, truncated, next — a ready-made continuation call). The unit of a page is named by pageUnit: the overview and query page over INSTRUMENTS (20 and 20 by default), package=… pages over the SIGNATURES of one instrument (20 by default, 300 at most) — large codes carry thousands. package=… together with catalog=… pages a separate list of the instrument: "questions" — the CATALOGUE OF QUESTIONS: which enquiries are provided for (a question in words, a form, a predicate or norms) and what the instrument does NOT answer, with the type of reason; a card is a template of an enquiry, not an answer, and not every instrument has one; "norms" — the NORMS of the instrument, "constants" — the CONSTANTS (names of declarations). "task-guides" — TASK GUIDES: the order of applying a canon to a document — what to gather, which cards to ask and how to read the answers; a guide answers nothing. catalog="task-guides" is allowed without package too — every guide of the profile; guide=… — the detail of one guide; the walkthrough — MCP Prompts under the same name. The detail of an instrument prints a preview of these lists and names the count and the ready-made call for the mode.

Input Schema

NameRequiredDescriptionDefault
guideNotogether with catalog="task-guides": the detail of one guide — a name <package>/<id> (as in prompts/list) or an id together with package
limitNohow many per page: instruments (overview 20, query 20), signatures of an instrument (20, at most 300) or elements of a catalog list (questions 20, norms 20, constants 100, task guides 20)
queryNoa substring filter over signatures, labels and constants (case-insensitive)
offsetNofrom which element of the page (0); the unit is the pageUnit of the answer
catalogNotogether with package: page the catalogue of questions, the norms, the constants or the task guides of the instrument instead of its signatures; "task-guides" also without package: every task guide of the profile
packageNothe full signatures of this instrument

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint=false and destructiveHint=false, so safety is covered; the description goes further by disclosing pagination behaviour (limit/offset, 'showing a–b of N; k more') and the structuredContent fields it returns (total, truncated, next as a ready-made continuation call), plus default and maximum page sizes. It does not explain why idempotentHint is false, but that is a minor omission against an otherwise rich behavioural account.

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 and most sentences carry real information, but the prose is sprawling, dense with em-dashes and parentheticals, and restates some defaults already carried by the schema (20/300 limits). The mode enumeration is hard to skim, which costs it against a genuinely concise definition.

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?

There is no output schema, yet the description compensates by describing the return shape (one line per instrument with key, title, legal order and counters; page metadata in structuredContent). For a six-parameter, multi-mode, read-only catalogue tool the description covers modes, defaults, caps and continuation calls adequately; only the precise field list of the structuredContent payload is left implicit.

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?

With 100% schema description coverage the baseline is 3, but the description adds genuine cross-parameter semantics the schema cannot: how package, catalog, query and the paging pair combine ('package=… together with catalog=… pages a separate list'), which argument switches the page unit from instruments to signatures, and the fact that catalog='task-guides' is legal without package. That interaction logic is the value-add beyond the per-parameter text.

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 description names the resource precisely (the catalogue of formalised law: instruments, predicate signatures, coverage boundaries) and explicitly distinguishes itself from the sibling law_search, which it tells the agent to use for keyword questions. It is a catalogue/browse resource rather than a clean verb+resource pair, and only one of fifteen siblings is differentiated, so it stops short of 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 Guidelines5/5

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

It gives an explicit when-NOT: 'do NOT start from the catalogue when looking for the right instrument', justified by the size of the overview and title/query word mismatch, and routes the agent to law_search first, with the catalogue reserved for resolving the exact signature of something already found. It also states which mode to use under which argument combination.

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.