Skip to main content
Glama

Read a law's text

qv_law
Read-onlyIdempotent

Read an Iranian law, regulation, court vote or opinion as paged sections with article text, amendment status and optional interpretive opinions; fetch one article or a date-specific version.

Instructions

Read the text of a law, regulation, court vote or opinion as sections (articles, notes, headings).

Sections: id, label, text, status (amended, repealed, opinion), history: true (see qv_article_history). Paged by offset/next_offset within max_chars; the civil code takes about 15 s. Use article for one article.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ids": "<ids>"
    },
    "name": "qv_law"
  }
}

Input Schema

NameRequiredDescriptionDefault
idsYesId from qv_search, e.g. '12021850837713548188'.
dateNoJalali 'YYYY/MM/DD': text as of that date.
offsetNoSections to skip (next_offset).
articleNoOnly this article with its notes, e.g. '10', '10 مکرر'.
max_charsNoText budget.
with_opinionsNoAdd interpretive opinions (نظر تفسیری).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.2.1
    • changedInput schema / properties / article / description
      Previous value: -"Only this article with its notes, e.g. '10', 'ماده 10', '10 مکرر'."New value: +"Only this article with its notes, e.g. '10', '10 مکرر'."
    • changedInput schema / properties / date / description
      Previous value: -"Jalali 'YYYY/MM/DD': the text as it stood on that date (before later amendments)."New value: +"Jalali 'YYYY/MM/DD': text as of that date."
    • changedInput schema / properties / ids / description
      Previous value: -"Law id (IDS) from qv_search, digits only, e.g. '12021850837713548188'."New value: +"Id from qv_search, e.g. '12021850837713548188'."
    • changedInput schema / properties / max_chars / description
      Previous value: -"Text budget per call."New value: +"Text budget."
    • changedInput schema / properties / offset / description
      Previous value: -"Skip this many sections (use next_offset from the last call)."New value: +"Sections to skip (next_offset)."
    • changedInput schema / properties / with_opinions / description
      Previous value: -"Add interpretive opinions (نظر تفسیری) as extra sections."New value: +"Add interpretive opinions (نظر تفسیری)."
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so safety is covered. The description adds genuinely useful operational detail annotations cannot express: the section field set, status values (amended, repealed, opinion), pagination via next_offset within a max_chars budget, and a latency warning that the civil code takes about 15 s.

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 front-loaded, sized to a few short lines, and every clause carries content: purpose, section shape, paging, latency, alternative parameter. The telegraphic fragment style ('Sections: `id`, `label`...') is compact rather than wasteful, though it reads more like terse notes than prose.

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?

With no output schema, the description correctly spends its words describing the returned section structure and status values, which is the critical missing piece. Combined with the latency note and paging behavior, an agent has enough to call this correctly, though truncation behavior and error cases remain unstated.

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 baseline is 3, but the description still adds meaning by explaining the offset/next_offset paging contract inside max_chars and by contrasting `article` with full-section reads. It does not explain `date` (Jalali as-of semantics) or `with_opinions`, leaving those entirely to the schema.

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?

The description opens with a specific verb and resource ('Read the text of a law, regulation, court vote or opinion') and immediately frames the output unit as sections with named fields. It also distinguishes scoped reading of a single article from paged full-text reading, so an agent can tell it apart from qv_article_history and qv_search 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 Guidelines4/5

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

It gives concrete routing guidance: 'Use `article` for one article' and 'history: true (see qv_article_history)', which tells the agent when to switch tools or parameters. It does not state when not to use this tool versus qv_law_info or qv_search, so it stops short of full alternative coverage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.