Skip to main content
Glama

Get Act Section Body

get_act_section_body
Read-only

The publisher's own text for one provision.

Cost: 3 credits. Refunded when we hold the provision and cannot reproduce its text, because you asked for text and did not get it.

The text is sliced out of the act document by the character offsets stored with each passage. It is never assembled by concatenating search passages: those carry a retrieval header that we synthesized (Act: ... | India | State | In Force), and serving that as statute would put our words inside a quotation of the law.

This text is as the publisher published it. We do not apply amendments to it. GET /acts/{actId}/sections/{n}/history lists every amendment we hold for the provision, each with an appliedStatus saying whether it is reflected here. It is not.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
act_idYesSection identifier, e.g. `USC_T42_C21_S1983` (Title 42, Chapter 21, Section 1983, written 42 U.S.C. 1983). Take it from a search result rather than assembling it: the title and section are derivable from a citation but the CHAPTER is not, so hand-built ids usually 404.
section_numberYesSection number exactly as the publisher writes it. Alphanumeric suffixes are part of the number, not a sub-provision: `498A` is one section, not section 498 clause A.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

The readOnlyHint annotation is reinforced by the description's emphasis that it returns the publisher's original text and does not apply amendments. It also transparently discloses the credit cost, refund condition, and potential 404 for hand-built IDs. No contradictions with annotations.

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 structured in clear paragraphs and contains valuable warnings and context. It is slightly repetitive in places, such as the refund explanation and the trailing 'It is not.' phrase, but overall each sentence contributes useful 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?

The description covers the tool's purpose, cost, refund behavior, important usage cautions, and the relationship to amendment history. With an output schema present, it does not need to describe return fields. It is sufficiently complete for an agent to decide when and how to call it.

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

Parameters5/5

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

Both parameters are fully described in the schema. act_id guidance explains why IDs should come from search results and why hand-built IDs often fail; section_number clarifies exact formatting and that alphanumeric suffixes are part of the number. This goes beyond basic schema definitions.

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?

The description clearly states that the tool returns 'the publisher's own text for one provision,' distinguishing it from search snippets and amended versions. The title 'Get Act Section Body' reinforces the retrieval purpose, though the first sentence is a noun phrase rather than an explicit action verb.

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?

The description gives practical usage guidance: it warns against assembling text from search passages, points to the history endpoint for amendments, and explains the refund condition when text cannot be reproduced. It does not explicitly contrast with every sibling tool like get_act_text or get_act_section, but the core alternatives are addressed.

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.