Gets All Material Requirements Line Items.

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

Annotations already declare read-only and idempotent. The description adds useful error-status reporting and config default behavior, but it also contains a major contradiction: it says 'Returns a single JSON object describing the material requirements line item' after saying it's a paginated list, and it claims company_id/project_id default when omitted while the schema marks them required. These inconsistencies undermine trust.

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 somewhat long and includes redundant read-only statement (already in annotations) and contradictory return type note. It does lead with the core purpose, but the extra boilerplate and internal inconsistencies make it less concise.

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 19 parameters, no output schema, and high complexity, the description provides endpoint and error context but fails to clearly describe the response shape (mentions a single object vs list) and gives no guidance on pagination or filter usage beyond schema. The contradictions create gaps.

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 3. The description's parameter-related statement about defaulting is factually wrong given the required constraint, adding no value. No other parameter semantics are explained beyond 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?

The first sentence clearly states it returns a paginated list of material requirement line items across all requirements, with a specific verb and resource. The usage phrase 'when you already know which material requirements line item you want' is confusing and slightly contradicts the list semantics, so not perfect. The endpoint and scope help distinguish it from sibling per-document line item tools.

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?

It provides a 'Use this when' clause but it's vague and misleading (knowing a specific line item would imply a single fetch, not a list). It does not mention when-not-to-use or suggest alternative tools like the sibling gets_line_items_for_a_specific_material_requirements_document. So guidance is poor.

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