Skip to main content
Glama

Read law

read_law
Read-onlyIdempotent

The text of a provision as it was in force on a date, with the law that last changed it, the next change, its history in brief, and any limit of the record that applies. Several provisions in one answer: give paths, or a folder (an act) as path.

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": "read_law"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNoAn in-force date, YYYY-MM-DD, or "today". Defaults to today.
pathNoA provision file, for example united-states/federal/usc/title-11/1182.md, from find_provision. Or a folder (an act): its provisions are read in order.
pathsNoSeveral provision files to read in one answer (up to 20), instead of path.
offsetNoWhere the part starts, in characters: the offset the previous part gave for the next one (default 0).
max_charsNoLongest part of the text in one answer (default 40000, at least 1000, at most 100000). A longer text comes in parts.
include_textNofalse for dates, laws, sources and notes only (default true).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / path / description
      Previous value: -"A provision file, for example united-states/federal/usc/title-11/1182.md, germany/bund/acts/grundgesetz/artikel/016a.md or united-kingdom/uk/legislation/uksi/2014/1530/regulation/13.md. Use find_provision to look one up."New value: +"A provision file, for example united-states/federal/usc/title-11/1182.md, from find_provision. Or a folder (an act): its provisions are read in order."
    • addedInput schema / properties / paths
      Added value: +{
      +  "description": "Several provision files to read in one answer (up to 20), instead of path.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "maxItems": 20,
      +  "type": "array"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "path"
      -]New value: +[]
  2. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already establish that this is a safe, idempotent, non-destructive read, so the safety profile is covered. The description adds useful disclosure about what is returned — in-force text plus the last changing law, the next change, brief history, and any record limitation — which is meaningful context beyond the annotations. It stops short of describing part/pagination behavior in the description (that lives only in the schema) or any access constraints, so a 3 reflects partial added value.

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?

Two sentences, zero filler, with the primary capability front-loaded. The second sentence is telegraphic to the point of being a fragment ('Several provisions in one answer: give paths, or a folder (an act) as path'), which costs a little readability but not clarity.

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?

An output schema exists, so return values need not be explained, yet the description still characterizes the payload accurately. For a six-parameter, all-optional read tool, the description plus rich schema and annotations leave nothing critical missing; only explicit routing to sibling tools is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all six parameters are already documented in the schema, including the path-vs-paths mutual exclusivity and folder semantics. The description restates the paths/folder choice but adds no new syntax, format, or default information beyond what the schema provides. Baseline 3 is appropriate when the schema carries the full parameter burden.

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?

States a specific verb and resource — returning the text of a provision as in force on a given date — and enumerates the accompanying payload (last changing law, next change, brief history, record limits). It implicitly distinguishes itself from history-oriented siblings by emphasizing point-in-time text, but never names an alternative, so it stops short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The second sentence gives real guidance on how to request multiple provisions (paths, or a folder/act as path), which is genuine usage context. However, there is no statement of when to use this instead of provision_history, law_details, or search_law, and no exclusion of cases where it is the wrong tool — usage is implied rather than directed.

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.