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

Even though annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, the description adds valuable behavioral detail beyond them: it discloses exactly what the tool returns (statutory text, heading, and effective date) and emphasizes that it returns FULL TEXT rather than an excerpt. There is no contradiction 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with zero filler. The core capability is front-loaded ('Get the FULL TEXT'), the citation format is illustrated immediately, the return payload is stated, and usage examples are packed into the second sentence. Every clause earns its place.

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

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

Despite having no output schema, the description names the return contents (text, heading, effective date), so agents know what to expect. Both parameters are fully specified in the schema, including examples and a pointer to ny_laws for discovering law ids. Nothing needed to call the tool correctly is missing.

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

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

Schema coverage is 100% and the schema already documents both parameters clearly. The description adds value by showing how a real-world citation decomposes into the two parameters, which helps agents map user phrasing like 'Penal Law 125.25' onto the expected law and section values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description leads with a specific verb and resource: 'Get the FULL TEXT of a section of the New York Consolidated Laws.' It immediately clarifies the scope (New York state statutes, by citation) and provides a concrete mapping example ('Penal Law 125.25' is 'PEN', '125.25'), which distinguishes it from sibling tools like ny_laws that list or search laws rather than retrieve full text.

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

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

The description explicitly states when to use the tool with natural-language query examples ('what does NY Penal Law 125.25 say', 'text of New York Labor Law 240') and a broader use case ('check a New York statute a case or contract relies on'). The input schema reinforce this by directing agents to call ny_laws to find a law id, giving clear routing guidance.

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