Viajadorum

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

With no annotations, the description carries the full behavioral burden and does disclose two non-obvious side effects: automatic Google Calendar sync when the user has it linked, and notifications sent to shared travelers. It does not cover permissions/ownership requirements, duplicate handling, or what happens if the calendar link is absent, so it is informative but not complete for a mutation tool.

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, front-loaded with the action and resource, then the side effects. The parenthetical type list partially duplicates the planType enum, which is mild redundancy, but it aids at-a-glance tool selection rather than wasting space.

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 an 18-parameter create tool with a nested object and no output schema, the description covers purpose and side effects but says nothing about what is returned (e.g., a created plan ID or calendar event link) and nothing about failure conditions. Adequate to invoke, thin on outcome expectations.

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% and every parameter, including the nested flightSegment fields, is documented inline, so the baseline is 3. The description adds only the hint that flight plans use structured IATA segments, which lightly signals when to populate flightSegment but adds no format or validation detail beyond 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?

"Agrega un plan, reserva o actividad a un viaje" states a specific verb and resource, and the parenthetical enumerates the supported plan kinds (flight with IATA segments, lodging, restaurant, tour, train, car rental, transport, note). It is clearly the creation counterpart to update_plan/delete_plan, though those siblings are never named explicitly, so differentiation is implied by the verb rather than stated.

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 is implied: add a plan to an existing trip. There is no explicit when-not guidance (e.g., use update_plan to modify an existing item, delete_plan to remove one) and no stated prerequisite that tripId must reference a trip previously created via create_trip. An agent can infer the correct usage but must do the work itself.

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 disclose the important hidden behaviors: an automatic representative image, automatic inclusion of the traveler's Círculo Íntimo contacts, and outbound email notifications. It still omits failure/duplicate-name behavior, whether the emails are sent immediately and irreversibly, and what the call returns.

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, zero filler, with the core action front-loaded and the side effects packed efficiently into the second sentence. Nothing is repeated from the schema or 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?

For a create operation with irreversible outbound side effects and no annotations or output schema, the description covers the side effects well but leaves the agent guessing about the response (notably whether a trip ID is returned, which is needed for viajadorum_update_plan and viajadorum_get_trip_itinerary) and about error conditions such as invalid date ranges.

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%, so all five parameters are already documented with formats and examples, making 3 the baseline. The description adds only one small inferential link: the destination drives the auto-selected image, which gives 'destinationCity' extra meaning beyond 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?

The description states a specific verb and resource ('Crea un nuevo viaje') scoped to the user's Viajadorum account, and the added side effects (destination image, Círculo Íntimo inclusion, email notice) make it unmistakably distinct from viajadorum_update_trip or viajadorum_list_trips. It never names a sibling explicitly, so it stops short of full differentiation.

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 is only implied: the agent can infer this is the tool for creating a trip versus updating one. There is no explicit when-to-use/when-not guidance, no note that it should not be used to modify an existing trip, and no warning about preconditions despite the irreversible email side effect.

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 behavioral burden. It usefully discloses one important side effect: removal from Google Calendar when the plan was synchronized. However, it does not state whether deletion is permanent, whether permissions or confirmation are required, what happens to dependent data, or how missing plans are handled.

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, well-structured sentence that front-loads the primary action and then adds the important Google Calendar side effect. There is no redundant or filler wording.

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 destructive one-parameter tool with no annotations and no output schema, the description covers the core action and an external side effect. It remains incomplete on critical deletion behavior, especially irreversibility, confirmation requirements, and error handling.

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%, and the only parameter planId is already documented in the schema as the numeric ID of the plan to delete. The description adds no parameter-level meaning beyond what the schema provides, so the baseline 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 uses a specific verb and resource: 'Elimina un plan o actividad de un viaje en Viajadorum'. It also names the external side effect of removing the item from Google Calendar, which clearly distinguishes it from sibling tools such as viajadorum_add_plan and viajadorum_update_plan.

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 deletion purpose is clear, but the description gives no explicit when-to-use guidance, no mention of alternatives like viajadorum_update_plan, and no warning about when deletion should be avoided. Usage is implied rather than guided.

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 supplied, so the description carries the full burden; 'Consulta' reasonably implies a read-only informational tool, which is some disclosure. However, it says nothing about data sources, freshness, whether fare links are affiliate/generated, or what happens when required-for-feature inputs are omitted. For a low-risk read tool this is a moderate 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?

A single dense sentence that front-loads the tool name and then enumerates capabilities; no filler or repetition. It is information-rich but slightly over-packed for one sentence, making the feature structure harder to scan.

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 six optional parameters, zero required parameters, and no output schema, the description should explain how the optional inputs combine into distinct modes of use. It lists features but leaves the parameter-to-feature mapping and minimum viable call ambiguous, so an agent could invoke it partially and get unexpected results.

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 does add meaning by mapping parameters to features (IATA airports → mileage, seats/aircraft → cabin analysis), but it does not clarify the conditional relationships between optional params or what happens with zero params.

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 names a specific verb ('Consulta') and enumerates four concrete capabilities: country profile fields, geodesic mileage between IATA airports, seat/cabin analysis, and fare comparison links. This clearly separates it from the CRUD siblings (create_trip, update_plan, etc.), though the bundling of four functions under one tool slightly blurs what a single invocation does.

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?

There is no explicit when-to-use guidance, no statement of preconditions, and no explanation of which optional parameters activate which capability. An agent must infer that passing departureIata/arrivalIata triggers mileage while destinationCity triggers the profile, and must guess whether fare links require flightDate.

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 supplied, so the description carries the full behavioral burden. It clearly frames a read of the authenticated traveler's own data and, usefully, enumerates the data categories returned in lieu of an output schema. It does not state what happens when no profile exists, whether any write/side effect occurs, or any permission nuance beyond 'autenticado'.

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 front-loaded sentence that packs the resource and its returned contents with no filler. Slightly dense as an enumeration inside one clause, but every element listed earns its place given there is no output 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?

With no output schema and no annotations, the description compensates well by naming the returned data domains an agent would need to know. It is nearly complete for a parameterless read tool; only edge-case behavior (no profile, auth failure) 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 there is no parameter semantics to explain and the baseline of 4 applies. Nothing in the description misleads about inputs.

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?

Starts with a specific verb+resource ('Obtiene el perfil del viajero autenticado') and enumerates the concrete contents returned: residence city, passport state and expiry, Círculo Íntimo contacts, and the miles/points wallet. It is clearly distinct from all siblings, which are trip- and plan-oriented. It stops short of an explicit contrast statement, but no sibling overlaps this purpose.

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 phrase 'del viajero autenticado' implies the prerequisite that a session/user must be authenticated, which is the only usage hint given. There is no explicit when-to-use vs when-not guidance, though with zero parameters and no alternative profile tool among the siblings there is little routing ambiguity to resolve.

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 supplied, so the description carries the full disclosure burden. 'Devuelve' implies a safe read, but nothing is said about authentication, response size (it aggregates many entity types), behavior when the trip does not exist, or whether the destination guide is computed on the fly. For an aggregate read tool with zero annotation coverage this is a real 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?

One front-loaded sentence with zero filler; the long enumeration of returned entities is informative rather than padding. A brief second sentence on selection guidance would have been more valuable than nothing, but nothing present is wasted.

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 the right thing by listing the returned sections, so an agent knows what to expect from the response. However, it omits error behavior, response shape granularity, and how to source the tripId, leaving the definition only adequate for an aggregate read over many entity types.

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% with a single required numeric tripId already documented in the schema. The description adds no meaning beyond that — no hint about where tripIds come from or what happens with invalid ids — so the baseline of 3 applies.

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?

Names a specific verb and resource ('Devuelve el itinerario cronológico completo de un viaje específico') and enumerates the payload components — flights, hotels, restaurants, activities, checklist, miles, destination guide — so an agent knows exactly what it retrieves. It stops short of differentiating itself from siblings such as viajadorum_destination_and_flight_intel or viajadorum_list_trips, which overlap in subject matter.

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?

There is no guidance on when to call this instead of alternatives, no mention that list_trips is the way to obtain a tripId, and no note that destination_and_flight_intel covers part of the same ground. The description only states what it returns, leaving tool selection to inference.

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. It does disclose valuable return content beyond the name – plan summaries and unassigned bookings – and "Lista" implies a read-only operation, but it says nothing about authorization, ordering, volume, 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?

One sentence, front-loaded with the verb and resource, with the scope and the extra payload in parentheses. No filler, though the parenthetical plus the trailing clause make it slightly dense.

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 simple one-parameter read tool with no output schema, the description covers what is listed and what comes back alongside it. The remaining gaps (ordering, limits, auth context) are minor for this complexity level.

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% and the single enum parameter is already documented in the schema with its default. The description's mention of próximos/pasados/compartidos echoes the enum values and confirms what "all" aggregates, adding only marginal meaning beyond structured data.

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 ("Lista todos los viajes del usuario") and scopes it by naming the three categories it covers (próximos, pasados, compartidos), which separates it from siblings like viajadorum_get_trip_itinerary. It stops short of explicitly contrasting itself with those siblings, but the intent is 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?

Usage is only implied: an agent can infer this is the entry point for browsing trips before drilling into an itinerary, but the description never says when to call it versus viajadorum_get_trip_itinerary or viajadorum_get_traveler_profile, nor any prerequisite (e.g., needing an identified user).

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 and no output schema, so the description carries the full behavioral burden, yet it only restates the two operations. It says nothing about required permissions, whether adding a duplicate label is rejected or merged, what happens if itemId is unknown, or what the call returns.

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-formed sentence with the resource scoping front-loaded and the two operations clearly enumerated; nothing is wasted, though it could be split for readability.

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 6-parameter mutation tool with no annotations and no output schema, the description covers both operations adequately but omits error conditions, idempotency and return behavior. It is the minimum an agent needs to choose a mode, not enough to predict outcomes.

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%, so every parameter including the action enum, done, label, itemId and category is already documented in the schema. The description adds no format, default, or conditional detail beyond it, so the baseline 3 applies.

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?

Names a specific verb and resource ('agregar una nueva tarea a la lista de verificación de un viaje') plus the second mode (mark/unmark as completed). An agent can tell this touches trip checklists rather than itineraries or plans, though it never contrasts itself with the sibling plan tools.

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 two modes (add vs toggle) are named, which implicitly tells the agent which path to take, but there is no explicit when-to-use/when-not guidance, no prerequisites (e.g. an existing tripId, an existing itemId for toggle), and no forward reference to sibling tools.

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 supplied, the description carries the full burden and discloses almost no behavior. It does not state whether this is a partial/patch update (only supplied fields changed) or a full replacement, whether it is reversible, what permissions are needed, or how conflicts are handled — critical for a 16-parameter mutation tool.

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 front-loaded sentence with the verb and target first and the field list as a compact parenthetical. No filler, though the parenthetical enumeration is a somewhat thin substitute for real parameter semantics.

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, no output schema, and 16 parameters at 31% schema coverage, the definition is under-specified. An agent cannot tell from this text whether omitted fields are preserved, what the response contains, or what failure modes to expect.

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 31% across 16 parameters, so the description must compensate. Its parenthetical list loosely maps to roughly half the fields (horarios, fechas, título, dirección, costo, confirmación, notas) but omits venue, phone, website, currency, subtitle and planId entirely, and never clarifies that all fields except planId are optional.

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 ('Modifica') and resource ('un plan o actividad existente en el itinerario'), and enumerates the mutable field families in parentheses. The word 'existente' implicitly separates it from viajadorum_add_plan and viajadorum_delete_plan, though those siblings are never named.

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?

There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance; the agent must infer from 'existente' that this applies to already-created plans. Nothing says what to do if the plan does not exist, or whether creating a new one requires viajadorum_add_plan instead.

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. It does disclose a genuine side effect beyond the schema — accompanying travelers get notified — which is valuable, but it omits permission/ownership requirements, whether the update is partial (only tripId is required) or destructive to unpassed fields, and whether the notification can be suppressed.

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 front-loaded sentence with the mutation, the mutable fields, and the side effect stated in that order. No filler or repetition; the parenthetical list earns its space by doubling as parameter documentation.

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 6-parameter mutation with no annotations and no output schema, the description covers the field set and the notification side effect but says nothing about the response (updated trip object vs. confirmation), error modes for an invalid tripId, or what happens to fields left out. Adequate but with clear gaps an agent would want closed.

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 50%: trips dates have format hints, but name, description and destinationCity are bare strings. The description at least enumerates every updatable field, mapping them to real semantics, yet it adds no format, length, or validation detail for the undocumented half.

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?

Specific verb ("Actualiza") plus resource ("datos generales de un viaje existente") and an explicit field list (nombre, ciudad de destino, fechas, descripción). It clearly differs from create_trip, but it never names update_plan, the sibling that most plausibly overlaps, so the agent must infer the split between trip-level and plan-level edits.

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 is only implied: the word "existente" signals that a valid tripId is a prerequisite, and the field list tells the agent what this tool is for. There is no explicit when-not guidance and no mention of update_plan as the alternative for itinerary changes, leaving routing to inference.

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