Skip to main content
Glama

law_rules

Read-only

The rules of formalised law put into words: exactly how a predicate is derived (premises, source articles). Call this BEFORE supplying facts to law_ask — the rules say which facts are needed instead of leaving them to be guessed. For large instruments package=… returns a table of contents; the full text comes from predicate=…. The listing by package is paged: limit (20 by default, 500 at most) and offset; the remainder is named in the text (showing a–b of N; k more) and in structuredContent (total, truncated, next — a ready-made continuation call).

Input Schema

NameRequiredDescriptionDefault
langNothe language the rules are put into
limitNopackage: how many rules per page (20; the budget may lower it)
offsetNopackage: from which rule (0)
packageNoevery rule of the instrument
contractNoReturn a machine input contract over the same import/dependency world as law_ask. No case evaluation.
predicateNothe rules that derive this predicate
inputLimitNoMachine contract: leaf declarations per page (50).
inputOffsetNoMachine contract: offset of leaf declarations.

Output Schema

NameRequiredDescriptionDefault
nextNo
limitNo
rulesYes
totalNo
offsetNo
compactNo
packageYes
ruleCountNo
truncatedNo
factsTemplateNo
inputContractNo
verbalizationGapsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / contract
      Added value: +{
      +  "description": "Return a machine input contract over the same import/dependency world as law_ask. No case evaluation.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / inputLimit
      Added value: +{
      +  "description": "Machine contract: leaf declarations per page (50).",
      +  "maximum": 200,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / inputOffset
      Added value: +{
      +  "description": "Machine contract: offset of leaf declarations.",
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • changedInput schema / properties / lang / description
      Previous value: -"the language the rules are put into (DECISION-0032; the language of the profile by default; the rest are draft packs, with §218 label overlays)"New value: +"the language the rules are put into"
    • addedOutput schema / properties / inputContract
      Added value: +{
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: paging behavior for package listings, the default/max limit and 'the budget may lower it', the human-readable remainder text, and the structuredContent fields (total, truncated, next) that form a ready-made continuation call. It does not address the non-idempotent hint, but otherwise this is rich disclosure.

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?

Front-loaded with the core purpose and the call-ordering rule before paging details. Dense parenthetical clauses ('20 by default, 500 at most', the 'showing a–b of N' sample) make it slightly heavy, but each sentence carries distinct information.

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 8-parameter tool with an output schema and full annotation coverage, the description supplies modes, ordering relative to law_ask, paging, and continuation guidance. Return values need not be re-explained because the output schema exists; the remaining omission is minor (no explicit note on the contract mode's interplay with the other flags).

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 schema documents each parameter description. The description goes beyond it by explaining the mode interaction — package returns a table of contents for large instruments while predicate returns the full text — and by spelling out paging defaults and the continuation payload. This is more than the baseline repetition the schema already provides.

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 and resource — it returns 'the rules of formalised law ... exactly how a predicate is derived (premises, source articles)'. It distinguishes its two modes (package= gives a table of contents for large instruments; predicate= gives the full derivation) and separates itself from the sibling law_ask.

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?

Explicitly says 'Call this BEFORE supplying facts to law_ask', with the reason (the rules say which facts are needed rather than guessing). It names the alternative and the ordering condition, leaving nothing 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.