create_purchase_request

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

With no annotations provided, the description carries the full burden, and it discloses meaningful behavior: the tool creates a persisted document (implied by the instruction to confirm the full request before calling), requires warehouse codes sourced from a separate endpoint, and applies defaults like requiredDate falling back to docDueDate. It does not describe what happens after a successful call (response shape, document status, error conditions), which keeps it from a 5.

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 purpose is front-loaded in the first sentence, and the subsequent workflow detail is dense but logically organized: prerequisite, per-line collection order, defaulting options, and confirmation steps. The length is justified by the tool's interactive multi-line complexity, though the single long procedural sentence could be tightened into bullet-like structure.

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 document-creating tool with no output schema and no annotations, the description thoroughly covers the input-gathering workflow but omits post-call behavior such as the returned document number, whether the request is posted or draft, and which sibling (create_purchase_order) should be used for downstream steps. The invocation path is well specified, but the aftermath is left to inference.

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 67%, and the schema already documents the key parameter semantics (warehouseCode required from get_warehouse_list, requiredDate defaulting to docDueDate, requester defaulting to the logged-in user). The description adds value by specifying the collection order (item code, quantity, warehouse, required date) and the prerequisite list call, but it does not clarify the undocumented itemCode, quantity, unitPrice, or comments semantics beyond what the schema provides.

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 opens with a specific verb and resource: 'Create an SAP Business One purchase request (internal requisition) for required goods or services.' The parenthetical clarifies the document type, which distinguishes it from siblings like create_purchase_order and create_purchase_quotation, so an agent can route to the right tool without opening any schema.

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 gives clear operational context: call get_warehouse_list first, collect inputs one at a time, offer docDueDate as the default required date, confirm each line, and confirm the full request before invoking the tool. However, it never states when to use this tool versus alternatives such as create_purchase_order, so exclusions and alternative-selection criteria are absent.

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