read_proposition_text

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

There are no annotations, so the description must carry the behavioral disclosure burden. 'Bounded page' does reveal that a call returns only a portion rather than the entire full text, and the offset/max_chars parameters in the schema reinforce pagination. However, it doesn't disclose page size limits, offset semantics, error behavior, or whether calls are safe/read-only, so the disclosure is thin.

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?

One short sentence that front-loads the core operation and omits filler. Every word earns its place and the structure is immediately scannable.

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?

With an output schema present and only three simple parameters, the description is near the minimum viable level, but it leaves pagination mechanics and usage context to be inferred. An agent could likely call it correctly by relying on parameter names and defaults, yet the description alone is not rich enough to feel complete for repeated paging.

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 description coverage is 0%, so the description must compensate for undocumented parameters. 'Bounded page' gives a rough idea that offset and max_chars control the window, but it doesn't define units, limits, defaults, or how to page sequentially. Parameter names are suggestive, but the description adds only general context rather than precise semantics.

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 ('Read') and resource ('a bounded page of a proposition's full text'), making it clear this is about fetching text content rather than metadata or summaries. The resource is concrete, but it doesn't explicitly distinguish itself from get_proposition, which could also serve text, so it stops short of a 5.

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 implies use for reading chunks of long text, but it never states when to choose this instead of get_proposition or search_propositions, nor does it mention any exclusions or alternatives. No context about typical workflow or prerequisites is provided, leaving an agent to infer usage from name and schema.

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