Read a law's text

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

Annotations already cover read-only, idempotent and open-world safety, and the description adds the behavioral details they cannot: a 10-60 s paging cost with a possible not-found outcome for older laws, truncation at `max_chars`, and the resumption protocol via `offset`/`next_offset`. These are the exact performance and failure traits an agent needs before committing to the call.

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?

Three sentences, front-loaded with the purpose before the prerequisite and the cost caveat. Every clause carries information: source, fields, prerequisite, slow-path warning, pagination protocol.

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?

There is no output schema, so the description must explain return values, and it does: approver, gazette number and date, body, plus the `next_offset` field used for pagination. Combined with the slow-path caveat, an agent has everything needed to call this correctly and handle partial results.

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%, so baseline is 3, but the description adds real meaning: it explains that `offset` should be set to the returned `next_offset` to continue reading, and that `max_chars` causes truncation. That continuation contract is not stated in the schema.

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?

States a specific verb and resource (read the full text of one law/ruling) plus the source (Official Gazette, rrk.ir) and enumerates the returned fields: approver, gazette number and date, body. It is clearly distinct from rk_search_laws and rk_latest_laws, which only list laws.

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?

Explicitly says to use it after rk_search_laws or rk_latest_laws and to supply a law's `code`, naming the alternatives that produce that code. It also covers the edge case where a code was never listed, warning that lookup pages through the newest-first list, is slow (10-60 s), and may fail for older laws.

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