Verbindliches Angebot (Quote) einholen — 15 Minuten Preisbindung.
positionen: Liste aus {"sku": "...", "menge": n}. Die Antwort enthaelt
die quote_id fuer bestellung_aufgeben sowie Netto-Einzelpreise;
Bruttopreis = Netto x 1,19, Versand siehe einkaufsbedingungen.
| Name | Required | Description | Default |
|---|---|---|---|
| client_id | No | ||
| positionen | Yes | ||
| client_secret | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals critical behaviors: a 15-minute price binding, the response containing quote_id and net unit prices, gross price calculation (Netto x 1.19), and shipping referenced to separate terms. This goes beyond a simple action statement, though it does not mention authentication requirements or side effects like quote creation.
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 two concise sentences with no wasted words. The first sentence states purpose and constraint (price binding), the second details the parameter format, response contents, and price calculation. Information is front-loaded and every sentence earns its place.
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?
Given the lack of annotations and output schema, the description covers the essential usage: how to pass line items, what comes back, and how pricing works. It ties into the ordering workflow. It omits the role of client_id/client_secret, but those have defaults and are likely authentication metadata; the description is otherwise complete enough for an agent to select and call the tool correctly.
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?
The input schema has no descriptions and 0% coverage. The description compensates for the required 'positionen' parameter by specifying its exact structure ('Liste aus {"sku": "...", "menge": n}'), which is essential. However, it provides no additional meaning for 'client_id' and 'client_secret', leaving those parameters undocumented. Since coverage of parameters is partial, a score of 3 is appropriate.
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 clearly states the tool's action: 'Verbindliches Angebot (Quote) einholen' (obtain a binding quote), with a specific verb and resource. It distinguishes itself from sibling tools by explicitly mentioning the 15-minute price lock and the resulting quote_id used for bestellung_aufgeben, making its purpose unambiguous.
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 when to use this tool: before placing an order, as it provides the quote_id for bestellung_aufgeben. It references the ordering workflow but does not explicitly state when not to use it or list alternatives. This is clear context without formal exclusions, matching a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
All six tools map to distinct steps in the purchasing workflow: searching, product details, quoting, ordering, order status, and purchase terms. No two tools compete for the same task, and the object/action pairs such as quote/order and status/tracking are clearly separable.
Tools consistently use lowercase German words with underscores, but the grammatical pattern varies: actions such as angebot_einholen and bestellung_aufgeben use object+verb, while informational tools like produkt_details and bestellung_status are noun+noun compounds. Despite these minor deviations, the naming remains readable and functional.
Six tools is a well-scoped size for a shop API: enough to cover a buyer's core journey without redundancy or excessive granularity. Each tool clearly earns its place in the workflow.
The endpoints cover the end-to-end order lifecycle: product search and details, binding quote, order placement, order tracking, and terms of purchase. There are no obvious missing operations that would prevent an agent from completing a B2B purchase.