wafeq_simplified_invoices_line_items_retrieve

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds a redundant '🟢 READ-ONLY' badge and the HTTP GET method, but discloses nothing beyond that, such as auth requirements or not-found behavior. This is acceptable given the annotations but adds only marginal behavioral context.

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 compact and front-loaded with the READ-ONLY badge and endpoint path, which is good. However, the final two lines are largely redundant: 'Retrieve simplified invoice line item' and 'Endpoint for retrieving a single simplified invoice line item' say essentially the same thing, so one sentence could be cut without losing information.

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?

For a low-complexity tool with only two required string parameters, rich safety annotations, and no output schema requirement, the description is nearly complete: it names the resource, the HTTP method, the endpoint pattern, and the safety profile. The only minor gap is the lack of explicit parameter guidance, which the URL template partially covers.

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% and neither parameter has a description, so the burden falls on the tool description. The URL template '/simplified-invoices/{invoice_id}/line-items/{id}/' conveys the roles of both parameters (which ID identifies the invoice, which identifies the line item), providing partial compensation. Still, it offers no format guidance or hints about where an agent would obtain these IDs.

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 uses a specific verb+resource pair: 'Retrieve simplified invoice line item' and clarifies scope with 'single', distinguishing it from the list variant. The endpoint path 'GET /simplified-invoices/{invoice_id}/line-items/{id}/' also anchors the resource hierarchy. However, it never explicitly differentiates from wafeq_invoices_line_items_retrieve, so an agent could still confuse the simplified vs. standard invoice families without relying on the name.

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?

Usage context is implied, not stated: the READ-ONLY label and 'retrieve a single ... line item' signal a safe read operation, and the name indicates it targets simplified invoices. But there is no explicit guidance about when to prefer this over the sibling list tool (wafeq_simplified_invoices_line_items_list) or over the standard invoices line item retrieve tool, which are its closest alternatives.

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