AgniGateway Marketplace

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

No annotations provided, so description carries full burden. It implies a read operation but does not disclose if it modifies data, rate limits, or behavior on unavailability. Minimal disclosure.

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?

Single sentence, no fluff. Could include more context but structure is efficient.

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?

No output schema and no annotations. Description lacks details on return value, behavior, or error handling. Incomplete for a tool that likely returns availability status and price.

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% (source_id described). Description adds no extra meaning beyond schema; just restates 'specific offer'. Baseline 3 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?

Description clearly states it checks availability and price for a specific offer, which distinguishes it from sibling tools like get_bundle (bundles) and search_travel (broad search).

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?

No guidance on when to use this vs alternatives, no prerequisites or exclusions mentioned. Sibling tools are listed but no differentiation.

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 provided, the description bears the full burden of behavioral disclosure. It reveals that the tool returns a bundle_value_score and merged summary, implying a read-only computation. However, it does not clarify if the operation triggers side effects or has any prerequisites, which 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?

The description is composed of two concise sentences. The first sentence clearly states the tool's action and scope, and the second specifies the return values. Every word serves a purpose, and no unnecessary information is included.

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 tool has only 2 parameters, no output schema, and no annotations, the description provides adequate context: purpose, input (hotel_source_id), optional filter (addon_types), and output summary. However, it does not explain the 'bundle_value_score' or how the bundle is composed, which could leave some ambiguity for an AI agent.

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?

Since schema description coverage is 100%, the baseline is 3. The description adds context by listing example addon types (co-working pass, airport transfer), but the schema already describes the addon_types parameter with similar examples. The description does not significantly enhance understanding 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 uses a specific verb 'Get' and clearly identifies the resource ('composed bundle for a hotel'). It details what is included (hotel product plus matching addon services) and what is returned (bundle_value_score and merged summary). This clearly distinguishes it from sibling tools like check_availability or initiate_booking.

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 the tool is used for bundling hotel with addon services, but does not explicitly state when to prefer it over siblings (e.g., check_availability, get_offer_detail). No guidance on when not to use it or alternative tools is provided.

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 is very short and does not disclose any behavioral traits beyond the action (e.g., side effects, permissions, or performance). However, for a simple retrieval tool, the lack of detail is acceptable but not excellent.

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 sentence that is front-loaded and contains no superfluous information. Every word 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?

With no output schema, the description does not explain what 'full enriched details' includes. For a tool with only one input parameter, it is somewhat complete, but more detail on the return content would improve contextual completeness.

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 parameter 'source_id' is described in the schema as 'Offer source_id from a search_travel result'. The description adds no extra semantic meaning beyond what the schema provides, so a 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 clearly states the action ('Get'), the resource ('full enriched details for a specific travel offer'), and the required input ('by its source_id'). It distinguishes itself from siblings like 'search_travel' (which returns offers) and 'check_availability' (which checks availability).

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 after 'search_travel' to get details for a specific offer. It does not explicitly state when not to use or alternatives, but the purpose is clear enough given the sibling tool names.

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?

Discloses logging for commission tracking and that a link is returned. No annotations provided, so description carries the burden. Could be more explicit about not finalizing the booking (user completes later). Adequate but not rich.

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 sentences that efficiently cover purpose, side effect, and output. No fluff, front-loaded.

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 tool with one parameter and no output schema, the description is sufficient. It states purpose, behavioral trait, and return value. Minor gap: error handling or prerequisites could be added.

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% for the single parameter source_id. Description adds no extra meaning beyond the schema. 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?

The description clearly states it generates a tracked affiliate booking link for an offer, logs the transaction, and returns a booking_url. This distinguishes it from siblings like check_availability and get_offer_detail.

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?

No guidance on when to use this tool vs alternatives. Missing prerequisites or conditions (e.g., must check availability first). Implies usage for booking but lacks explicit context.

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 exist, so the description carries the full burden. It discloses return enrichments (digital nomad scores, wifi quality) but does not explicitly state it's a read-only search operation, nor mention any side effects, rate limits, or authentication needs.

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-load the purpose and then list key output features. No unnecessary words, but could be slightly more structured with bullet points. Efficient and clear.

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 no output schema and a nested input object, the description provides useful context about return values (enriched results, digital nomad scores). It covers the main purpose and key outputs, though lacks details on pagination or error conditions.

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 67%, so baseline is 3. The description adds no additional meaning beyond what the schema provides (e.g., query is natural language, limit default/max). Nested filters are described in schema but not further explained in description.

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 explicitly states the verb 'Search', resource 'travel offers', and scope 'hotels, tours, bundles'. It also highlights distinctive return features like 'digital nomad scores, wifi quality, direct booking links', clearly differentiating from sibling tools which are more specific operations.

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 use for natural language searching but provides no explicit guidance on when to use this vs siblings like check_availability or get_offer_detail. No when-not-to-use or alternatives are mentioned, leaving it to the agent to infer.

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