TMRS Rental Quotes

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the bar is lower. The description still adds real behavior beyond them: the link is freshly generated and short-lived, it is an absolute URL, and an access token from the issuing step is mandatory — useful for an agent that may cache or replay calls.

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?

A single dense sentence with no filler, front-loaded on the action and followed by the return value and prerequisites. Every clause carries information an agent needs.

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 no output schema, the description does describe the return (status plus document.href) and the two required inputs, which is enough for a two-parameter read tool. It omits what happens with an expired link, invalid token, or a not-yet-issued quote, which is the remaining gap.

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 0%, so the description must carry the parameters and does explain both: the quote id and the accessToken's provenance from issue_rental_quote. It adds no format, validation, or failure semantics for either, and does not say where quoteId itself originates, so the compensation is only partial.

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 and resource: read an issued quote's status and obtain a fresh short-lived PDF link, including the return field document.href as an absolute URL. The phrase 'issued quote' and the reference to the token 'returned by issue_rental_quote' clearly separate it from the issuance sibling.

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 establishes the prerequisite condition (the quote must already be issued) and where the accessToken comes from, which is effectively the when-to-use rule. It stops short of naming an explicit alternative or stating when not to call it, so it is clear context rather than full routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context beyond annotations: it explicitly says no commercial records or notifications are created, and it names the returned validation fields (missingFields, invalidFields, unsupportedFields), which is valuable since no output schema exists.

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?

Three short sentences, front-loaded with the core action and immediately followed by return details and side-effect exclusions. No wasted verbiage.

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?

The description covers return fields and side-effect exclusions, which is helpful for a read-only validation tool. But given the complex nested schema (9 parameters, deep requirements object) and no output schema, it lacks guidance on the requirements structure and how to interpret partial checks, leaving an agent under-informed for correct invocation.

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 only 33%, with many parameters (locale, contact, dates, deliveryType, deliveryTime) undocumented in both schema and description. The description mentions 'partial or complete rental need' implying optional inputs, but provides no parameter-level semantics to compensate for the low coverage.

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 ('Check') and resource ('rental need'), and clarifies it handles partial or complete needs. The final sentence ('No commercial records, no notifications') distinguishes it from commercial siblings like issue_rental_quote, though it does not name them.

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 usage by saying it returns missingFields with questions to ask the user, suggesting a validation step before quoting. However, it does not explicitly state when to use this tool versus siblings like issue_rental_quote or search_rental_offers, leaving alternatives implicit.

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

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

The description adds substantial behavioral context beyond the annotations: it flags a side effect, says the rental company may be notified, clarifies that this is not a booking, and explains idempotencyKey reuse after a timeout or 'processing' state. These details directly help an agent understand the external impact and safe retry behavior.

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 short and front-loaded with the critical 'SIDE EFFECT' warning. Every sentence carries useful information about scope, notification, booking distinction, or retry handling.

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 complex mutation with 10 parameters and no output schema, the description covers the most important side effects and retry semantics. However, it does not explain what a successful issuance returns or how the resulting quote document should be retrieved, and it leaves much of the nested requirements behavior to the schema.

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 only 40% across 10 parameters, and the description compensates for only a small portion. It adds meaning for contact fields and idempotencyKey retry behavior, but it does not explain the roles of requirements, deliveryType, dates, locale, deliveryTime, or the manual-quote caveat for complex requirements.

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 states a specific verb and resource: 'issue an actual written quote.' It clearly distinguishes this from a booking, but it does not explicitly differentiate the tool from sibling retrieval/search tools such as get_quote_document or get_quote_requirements.

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 gives a clear usage condition: the need must be complete and user-approved, including contact name, email, and phone. It also states 'Not a booking' as an exclusion and explains retry behavior with idempotencyKey, though it does not name alternative tools for related retrieval or requirement-checking tasks.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds scope context ('currently requestable') and the pagination contract via nextCursor, but says nothing about result ordering, page size, or whether locale affects result content.

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?

Two tight sentences with zero filler; the resource scope is front-loaded and the pagination instruction follows, so the agent gets the essentials first.

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 no output schema, the description carries the burden of describing returns, and it does list the key fields plus nextCursor. The remaining gap is the locale parameter's effect, which is left unstated for a tool that is otherwise self-contained.

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 only 50%: cursor is documented in the schema and reinforced by the description's pagination note, but the locale enum (de/en) is unexplained in both places — an agent must guess that it controls result language. Baseline 3 fits given the partial coverage.

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 and resource (list requestable machines from rental companies) plus the payload it returns (equipmentId, specifications, delivery options). It does not, however, differentiate itself from the closest sibling search_rental_offers, which an agent could plausibly confuse with a catalog listing.

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 sentence 'Paginate with the returned nextCursor' gives clear iteration guidance, and the phrase 'currently requestable' implies a filter scope. But there is no explicit when-to-use versus search_rental_offers or when a quote flow (get_quote_requirements/issue_rental_quote) should be preferred.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavior: no contact data required, no commercial records or notifications are created, and a successful result carries a humanConfirmationUrl where the user completes the transaction. That side-effect disclosure is exactly the context annotations cannot express.

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?

Three short sentences, front-loaded with the calculation and its components, then the no-contact constraint and the return value. Minor deduction: 'real offer' and the untranslated 'Selbstbeteiligung' are opaque to an agent without German domain knowledge.

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 9-parameter, deeply nested, zero-required-parameter pricing call with no output schema and low schema coverage, the description leaves too much open: date semantics, locale effect, pickup vs delivery, jobsite requirements, and what happens when requirements are ambiguous (that caveat lives only in the schema). The humanConfirmationUrl note is the one strong completeness contribution.

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 only 33% across 9 params with deep nesting. The description explains only that 'contact' is unnecessary and alludes vaguely to a 'need' (requirements); it says nothing about locale, startDate/endDate, deliveryType, jobsiteAddress, or equipmentId. The complex requirements/alternatives contract is left entirely to the 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?

States a specific verb and output: calculate the 'real offer' and explicitly enumerates the price components (rental, transport, insurance, VAT, Selbstbeteiligung). It implicitly separates itself from issue_rental_quote by saying the user confirms/requests the PDF themselves, but it never names that sibling, and the tool name ('search_rental_offers') is not reconciled with the 'calculate' framing.

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?

Useful signals exist: 'Contact data is not needed' tells the agent it can call without contact details, and the humanConfirmationUrl sentence implies this is the pre-quote pricing step. However, no sibling is named and no explicit when-not condition is given, so the agent must infer whether to use this versus issue_rental_quote or get_quote_requirements.

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