UNIDROIT Principles 2016

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).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "law_rules"
  }
}

Input Schema

Name	Required	Description
`lang`	No	the language the rules are put into
`limit`	No	package: how many rules per page (20; the budget may lower it)
`offset`	No	package: from which rule (0)
`package`	No	every rule of the instrument
`contract`	No	Return a machine input contract over the same import/dependency world as law_ask. No case evaluation.
`predicate`	No	the rules that derive this predicate
`inputLimit`	No	Machine contract: leaf declarations per page (50).
`inputOffset`	No	Machine contract: offset of leaf declarations.

Output Schema

Name	Required	Description	Default
`next`	No
`limit`	No
`rules`	Yes
`total`	No
`offset`	No
`compact`	No
`package`	Yes
`ruleCount`	No
`truncated`	No
`factsTemplate`	No
`inputContract`	No
`verbalizationGaps`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 28, 2026

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"
+}
```

First observedOct 14, 2026

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.

All UNIDROIT Principles 2016 tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.