rentme-tasks

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

With no annotations, the description carries the full burden and does so well: it discloses the 24-hour owner acceptance window, the 12-hour payment-link expiry, that the rental only becomes confirmed after payment, and that contacts are exchanged only then. This is rich lifecycle and side-effect context an agent could not infer from the schema.

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?

Four sentences, front-loaded with the action, then the workflow, then the confirmation advice. Each sentence carries information, though the flow is dense enough that minor trimming could help; nothing is redundant.

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 multi-step workflow tool with no output schema and no annotations, the description provides what the agent needs: what happens after the call, what is returned (id, codice_accesso), and how that output is reused with sibling tools. Nothing essential is missing.

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 100% across 11 parameters, so the schema already documents each field's meaning and constraints. The description adds only that the returned id and codice_accesso exist, not anything about the input parameters, so the baseline 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?

States a specific verb and resource: sends a rental request on behalf of a person for a thing. The agent can distinguish it from rentme_check_rental_status and rentme_cancel_rental, which it also names explicitly.

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?

Gives a clear precondition ('Chiedi sempre conferma alla persona prima di prenotare, mostrando periodo e prezzo totale') and points to rentme_check_rental_status as the place to find the payment link, plus notes that the returned id/codice_accesso are needed to check status or cancel. It does not spell out explicit when-not-to-use cases or the ordering against rentme_search_things/rentme_get_thing to obtain thing_id.

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?

No annotations are provided, so the description carries the full burden, and it delivers: refund policy with the 3% fee (min 1 EUR), the 24-hour cutoff, and the consent requirement. It stops short of stating irreversibility or failure modes (e.g., invalid access code).

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?

Purpose is front-loaded in the first clause, followed by an efficient sequence of refund rules and the confirmation instruction. Dense but every sentence carries policy or action value.

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 mutation tool with no annotations and no output schema, the description covers price/cost consequences, timing thresholds, and the consent prerequisite. Only error handling and explicit irreversibility are omitted.

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 100% (both id and codice_accesso documented), so the schema already does the work; the description adds no extra detail about parameter format or where the access code comes from beyond the schema's own note.

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 (Annulla/cancel) and resource (noleggio/rental), and explicitly ties the target to its origin tool rentme_book_thing, distinguishing it from siblings like rentme_check_rental_status or rentme_book_thing.

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?

Gives clear conditional context: free before payment, partial refund up to 24h before delivery, no refund under 24h, and requires person confirmation before cancelling. It does not, however, point to an alternative tool or state when not to use it.

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?

Without annotations, the description carries the burden of disclosing behavior. It describes what each status means and notes that 'da_pagare' includes a payment link and 'confermato' includes the Runner's name and contact, which is useful behavioral context. However, it does not mention whether the operation is read-only, what happens if the rental is not found, or any rate limits or side effects. For a status-check tool, this is adequate but leaves gaps.

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 a single, efficient sentence that front-loads the purpose and then lists statuses with brief parenthetical clarifications. There is no waste, and it is appropriately sized for the tool's complexity. The structure is clear and easy to parse.

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 tool has no output schema and no annotations, so the description must cover return values and behavior. It lists possible statuses and some associated data, which is useful, but it does not describe the return format (e.g., JSON structure) or error conditions. Given the simplicity (2 required params, no nested objects), it is mostly complete but could specify what an agent should expect in terms of output.

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 the input schema already fully documents both parameters (id and codice_accesso). The description adds no additional meaning about the parameters beyond indicating that the status is for a rental requested via rentme_book_thing, which implies the access code is from that tool. Baseline 3 is appropriate when schema does the heavy lifting.

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 purpose: checking a rental request status, and explicitly links it to the sibling tool rentme_book_thing. It enumerates possible statuses, distinguishing it from siblings like rentme_check_task_status. However, it lacks a direct verb like 'returns' and is somewhat terse, but the intent is clear.

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 when you have a rental request created by rentme_book_thing and need its status, but does not explicitly state when to use this tool versus alternatives like rentme_check_task_status or when not to use it. It provides some context by referencing rentme_book_thing, which is helpful but not complete 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?

No annotations are provided, so the description carries the full behavioral burden. It does convey that this is a read-only status check and lists the expected status values, which is useful. However, it does not disclose behavior for missing/unknown tasks, whether both id and riferimento_ai can be supplied together, or any error/return conventions.

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, well-structured sentence front-loads the verb and resource, then adds statuses and lookup methods. There is no filler or redundant repetition of the tool name.

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 low complexity of the tool—two optional parameters, no output schema, no nested objects—the description covers the core behavior, the possible status values, and both lookup keys. It is slightly incomplete in not stating what happens when no task matches or whether the result is just the status string, but it is adequate for selection and basic 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 coverage is 100%, so the baseline is 3. The description adds value by stating that the tool searches 'per id interno o per riferimento_ai', which communicates that the two parameters are alternative lookup keys and that riferimento_ai was provided at creation time. This relationship is not explicit in the schema alone.

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 and resource: 'Controlla lo stato di avanzamento di un task' and enumerates the possible statuses. It also clarifies the two lookup modes, making it clearly distinct from the sibling rentme_create_task, whose purpose is creation.

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 makes the use case clear: checking the status of an already-created Rentme task via either internal id or external riferimento_ai. It does not explicitly say 'use this instead of rentme_create_task', but the contrast between checking and creating is implied enough given the single sibling.

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?

In assenza di annotazioni, la descrizione rivela il comportamento chiave: il task viene 'pubblicato' su una bacheca e 'collaboratori umani registrati possono candidarsi' dietro compenso, quindi non è un'operazione digitale immediata. Non dichiara però esplicitamente eventuali irreversibilità, costi o assenza di garanzia di completamento.

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?

Tre frasi brevi, con l'azione principale in testa e le istruzioni d'uso/prerequisito subito dopo. Nessun contenuto ridondante o ripetizione di ciò che è già nello schema.

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?

Per un tool di creazione con 10 parametri, nessuna annotazione e nessun output schema, la descrizione copre bene scopo e contesto, ma non dice cosa restituisce la chiamata né indica esplicitamente il flusso successivo con rentme_check_task_status. Alcune informazioni sono recuperabili solo dallo schema, ad esempio tramite riferimento_ai.

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?

Lo schema descrive tutti i 10 parametri con coverage 100%, quindi il baseline è 3. La descrizione non aggiunge dettagli sui parametri oltre agli esempi di operazioni fisiche e al riferimento a rentme_list_skills, informazione già presente nella descrizione di skill_id nello 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?

La descrizione inizia con 'Pubblica una richiesta di operazione fisica nel mondo reale ... sulla bacheca Rentme', indicando verbo e risorsa specifici. Rispetto ai sibling rentme_list_skills e rentme_check_task_status, è immediatamente chiaro che questo strumento crea un annuncio di lavoro umano.

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?

La frase 'Usa questo strumento quando serve far compiere un'azione fisica reale da una persona' fornisce una condizione d'uso esplicita. Inoltre, 'chiama prima rentme_list_skills per conoscere gli id disponibili' dà un prerequisito chiaro per un caso d'uso comune.

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?

With no annotations, the description carries the disclosure burden and does well: it enumerates the return payload (rates, occupied periods, rules) and explains the conditional behavior of indirizzo_consegna (delivery feasibility). It doesn't cover permissions or error behavior for an unknown id, so it stops short of full transparency.

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 sentences, densely packed with distinct facts, front-loading the return contents before the usage instruction. No filler or restatement of the name.

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 compensates by describing the returned fields, and it explains the optional param's effect. Only error/edge behavior (e.g., nonexistent id) is left unaddressed, which is a minor gap for a single-item fetch.

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 the baseline is 3, but the description adds genuine semantics beyond the schema: passing indirizzo_consegna triggers a delivery-feasibility check, which the schema merely labels 'da verificare'. That consequence is real added meaning.

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 ('Ritorna il dettaglio di un oggetto a noleggio') and enumerates the returned content (descrizione, tariffe, foto, periodi occupati, regole), which distinguishes it from search/list siblings. An agent can tell exactly what this fetches without opening the 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?

Explicitly routes usage: 'Chiamalo prima di rentme_book_thing per scegliere date libere e tariffa' names the sibling and the reason for calling this first. This is a clear when-to-use instruction tied to a concrete alternative.

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?

With no annotations, the description carries the transparency burden. It clearly indicates a retrieval operation ('Ritorna') with no side effects, and specifies that the result is a catalog of skills with their ids. It does not mention auth or error cases, but for a simple no-parameter list operation this is not a material gap.

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 short sentences. The first sentence states the core behavior and output; the second sentence gives targeted sequencing guidance. Every part earns its place with no redundancy.

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 zero-parameter, no-output-schema list tool, the description tells the agent what it returns, where it fits in the workflow, and which sibling it precedes. Nothing essential is missing 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?

The tool has zero parameters, so the schema fully covers input. The description adds useful context by explaining why the output matters ('per sapere quale skill_id passare'), which helps the agent use the returned identifiers correctly.

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 concrete verb ('Ritorna') and a specific resource ('catalogo delle competenze disponibili su Rentme'), and notes that each entry includes its id. This clearly distinguishes it from the sibling tools, which check task status or create tasks.

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 explicitly instructs the agent to call this tool PRIMA di rentme_create_task when a specific skill must be associated with a task, in order to learn the skill_id to pass. This is direct, actionable guidance about when to use it and how it relates to a named sibling.

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?

No annotations are provided, so the description carries the full burden. 'Ritorna' signals a read-only retrieval and it discloses what is returned (categories, subcategories, ids), but it says nothing about ordering, nesting depth, authentication needs, or whether the list is paginated.

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 short sentences, front-loaded with what is returned and followed by the practical use case. No filler or repetition of the title.

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 usefully clarifies that the response contains categories/subcategories with their ids. It is nearly complete for a parameterless lookup, though the exact shape of the returned category structure is left implicit.

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 tool takes zero parameters, so the schema has nothing for the description to compensate for; baseline 4 applies. The description correctly implies no input is required.

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+resource: returns the categories and subcategories of rentable 'Things' with their ids. It clearly distinguishes itself from sibling lookup tools like rentme_get_thing and rentme_search_things by naming the taxonomy-listing function.

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?

Explicitly says it is useful for filtering rentme_search_things by category, routing the agent to the right downstream tool. It does not state when not to use it, but the context (category enumeration) is unambiguous.

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?

With no annotations, the description carries the full burden and does so well: it discloses that delivery/pickup are included in price, that results are filtered to items the owner can deliver to the given address and sorted by distance, and that prices are expressed in EUR per hour/day/month. The only gap is that it does not describe result fields or pagination 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?

Purpose is front-loaded, followed by illustrative examples, the address rule, and pricing units. It is dense but every clause adds information; the example list is slightly long but helps disambiguate the catalog.

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?

There is no output schema and no annotations, so the description must stand alone, and it covers purpose, delivery semantics, filtering, sort order, and pricing units. It does not explain the returned item shape or how limit interacts with results, leaving a minor 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 100%, so a baseline of 3 applies, but the description adds genuine meaning beyond the schema by explaining the behavioral effect of indirizzo_consegna (results are restricted to deliverable items and distance-sorted), which the schema field alone does not convey.

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 (Cerca) and resource (oggetti da noleggiare) with concrete category examples (attrezzi, giardinaggio, strumenti musicali, bici...), so an agent immediately understands it is a discovery/search tool. It does not explicitly distinguish itself from siblings like rentme_get_thing or rentme_list_thing_categories, so it stops short of a 5.

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?

Implied usage (find things to rent nearby) is clear, and it gives one strong operational rule ('Indica SEMPRE indirizzo_consegna quando lo conosci'). However, it never states when to prefer this over alternatives such as rentme_get_thing or rentme_list_thing_categories, leaving tool selection partly to inference.

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