Skip to main content
Glama
ezydubs
by ezydubs

get_legislation_text

Retrieve New Zealand legislation text by work or version ID. Need a specific section or schedule? Fetch just that part, or get an official PDF link.

Instructions

Retrieve the text of a piece of legislation. Provide a version_id or work_id. Without section/schedule params, returns the whole document as cleaned plain text. With a section param (e.g. "22" or "25A"), returns just that section with its Part/subpart context. With a schedule param (e.g. "1"), returns just that schedule. Use list_sections to discover numbers first. With format:"pdf", returns the official PDF download URL instead of text; format:"pdf_original_scan" returns the scan of the original printed Act (pre-2008 as-enacted versions only).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNoSet to "pdf" to retrieve the official PDF download URL instead of the document text (falls back to the scanned original if no typeset PDF exists). Set to "pdf_original_scan" to require the scan of the original printed Act, which only as-enacted versions of pre-2008 Acts have. Returns the URL and metadata without downloading the file. Cannot be combined with section or schedule.
excludeNoContent types to exclude from the rendered text. By default everything is included. Options: - "cover": Front-page block (title, assent date, PCO reprint note). Already returned as structured metadata fields — exclude to avoid duplication in the text body. - "history_notes": Amendment-history entries at the end of each provision, recording when it was inserted, amended, or repealed and by which Act. Useful for understanding how law evolved; omit if you only need current text. - "comparative_references": Terse cross-references to equivalent provisions in predecessor or overseas legislation (e.g. '1952 No 43 s 4(1)'). Lineage information only — not part of the current operative law. - "editorial_notes": Two kinds of PCO annotation: (1) editorial-note elements — free-text PCO notes such as secondary legislation compliance tables, explicitly flagged in the source as 'not part of the Act'; and (2) amends-note elements — machine-readable scheduling data for amendments not yet in force, recording the trigger date/event, affected provisions, and replacement text. Exclude if you only need the current operative text. - "defined_term_links": Inland Revenue (Income Tax Act) navigation lists enumerating which defined terms appear in a provision. Website navigation aids only — not legislative text. - "end_matter": Document-tail reprint metadata — the reprint index (table of reprint dates) and reprint notes (free-text describing what each reprint changed), plus the leg-history element (structured list of reprint issuance dates). Appears once at the end of the whole document; not present when fetching a single section.
sectionNoReturn only this section number (e.g. "22" or "25A") instead of the whole document. Use list_sections first to discover section numbers. Cannot be combined with schedule.
work_idNoA work_id; the newest version will be resolved automatically. Provide either version_id or work_id.
scheduleNoReturn only this schedule number (e.g. "1") instead of the whole document. Cannot be combined with section.
max_charsNoTruncate whole-document output to this many characters (default 100000). Not applied when fetching a single section or schedule.
version_idNoA specific version to read. Provide either version_id or work_id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses several behavioral traits: returns cleaned plain text by default, returns PDF download URL instead of text for format pdf, falls back to scanned original if no typeset PDF exists, pdf_original_scan only available for pre-2008 as-enacted versions, max_chars truncation default 100000 and not applied to single section/schedule, and exclude options that affect output. It does not explicitly state whether the operation is read-only or has rate limits, but the sibling get_rate_limit_status exists. Given the absence of annotations, the description is quite transparent about output behavior and edge cases.

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?

The description is a single dense paragraph that front-loads the core purpose and then systematically covers variants. It is longer than ideal but every sentence adds meaningful behavioral or usage information. The structure is logical: core retrieval, section/schedule variants, discovery pointer, format variants. It could be slightly more scannable with line breaks, but it is not bloated or repetitive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 7 parameters, no output schema, and no annotations, the description is remarkably complete. It explains the default behavior, all parameter combinations, exclusions, format fallbacks, truncation behavior, and points to list_sections for discovery. The only minor gap is not describing the exact structure of the returned text/URL, but the description explicitly says 'returns the URL and metadata' for PDF formats and 'cleaned plain text' for text, which is sufficient for an agent to invoke correctly. The sibling get_rate_limit_status covers rate-limit concerns.

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 description coverage is 100%, so the schema already documents all 7 parameters. The description adds value by explaining the interaction between parameters: section/schedule cannot be combined, format cannot be combined with section/schedule, max_chars not applied to single section/schedule, and the fallback behavior for pdf format. It also clarifies that work_id resolves to newest version automatically. This goes beyond the schema's individual parameter descriptions, though the schema already does heavy lifting.

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 clearly states the tool retrieves legislation text, with a specific verb ('Retrieve') and resource ('text of a piece of legislation'). It distinguishes itself from siblings by mentioning list_sections for discovering section numbers and by describing format variants (pdf, pdf_original_scan) that no sibling tool name suggests. The description also clarifies the difference between whole-document, section, and schedule retrieval, making its purpose unambiguous.

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?

The description explicitly tells the agent when to use this tool vs alternatives: 'Use list_sections to discover numbers first.' It also provides clear conditional guidance: without section/schedule params returns whole document, with section returns just that section, with schedule returns just that schedule, and with format pdf returns URL instead of text. It also states constraints like 'Cannot be combined with section or schedule' for format, and 'Cannot be combined with schedule' for section. This is explicit when/when-not guidance.

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