Caribbean Data API — Tropical Autonome

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

The description mentions a price ('Prix : 0.500 USDC') and a parameter 'payment_tx_hash' implies a payment requirement, but it does not clearly state that payment is needed to execute. Annotations declare readOnlyHint=true, which is consistent with analysis but the cost aspect is under-disclosed.

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 very short (two sentences) and front-loads key outputs and price. It is efficient but could include more context without sacrificing brevity.

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 9 parameters, no output schema, and only readOnlyHint annotation, the description is incomplete. It lists some outputs but does not describe the analysis process, prerequisites, or return structure, leaving significant gaps for the 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?

Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema; it mentions output metrics but does not clarify the role of input parameters like 'consommation_annuelle_kwh' or 'cout_installation_eur'.

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 analyzes solar profitability, listing specific outputs (kWh, EDF OA revenues, IRR, credit 244W). The verb 'analyse' and resource 'rentabilité solaire' are specific, and it distinguishes itself from sibling tools (mostly 'get' operations) by being an analysis.

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 explicit when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives or prerequisites, leaving the agent to infer context from the tool name and sibling list.

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?

Annotation readOnlyHint=true indicates no state modification, but the description mentions a price and has a payment_tx_hash parameter, implying a payment requirement. The description does not clarify if the payment is a prerequisite or how it affects behavior. No additional behavioral traits beyond annotations.

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, very concise. However, the structure could be improved by leading with the action. The sentence front-loads context but omits a clear verb.

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 complex payment mechanism hinted, the description is incomplete. It does not explain what data is returned, how the payment works, or prerequisites like wallet setup.

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 one parameter described as 'Hash tx USDC Base.' The description mentions 'Prix : 0.010 USDC', linking to payment but not adding meaning beyond the schema. 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?

The description mentions 'Biodiversité Guadeloupe hotspot mondial' and lists species, ecosystems, and protected areas, implying data retrieval. However, it lacks an explicit verb (e.g., 'get' or 'retrieve'), relying on the tool name. The purpose is somewhat clear but not explicitly 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?

No guidance on when to use this tool vs siblings. The price (0.010 USDC) hints at a paid feature, but no when-to-use or when-not-to-use context 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?

The description adds no behavioral context beyond the readOnlyHint annotation. It does not explain side effects, authorization needs, or what happens when the optional parameter is provided.

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 but mixes disparate information (products, strategy, price) without prioritization. It is brief but not effectively structured for quick comprehension.

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 minimal description, the tool's return value and behavior are unclear. The description is insufficient for an agent to understand what data it will receive.

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 description ('Hash tx USDC Base.') is clear. The tool description adds no additional meaning, meeting the baseline for high 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?

The description is vague, listing market items and a price but not stating what the tool does (e.g., retrieves, lists, or queries). The verb is missing, making it unclear whether it fetches data or performs an action.

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 versus siblings like 'caribbean_get_marketplace_data' or 'caribbean_list_marketplace'. The description does not provide context for appropriate usage.

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 does not explain the role of the optional payment_tx_hash parameter, which is a key behavioral detail. While readOnlyHint indicates no state change, the description does not disclose if payment is required for data access, leaving ambiguity.

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 brief (one sentence and a fragment) but front-loads the main topic. It includes specific prices and details, though the structure could be improved for clarity.

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 should explain return values. It mentions prices but not format or structure, and the payment parameter's usage is unclear. This leaves significant gaps for an agent to invoke 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?

Schema coverage is 100% with a single parameter described as 'Hash tx USDC Base.' The description adds no additional meaning beyond that, so it meets the baseline but provides no extra value.

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 'Marché vanille caribéenne : prix...' clearly states the tool's subject and key data points (prices, regions, certifications). It distinguishes itself from siblings which cover different Caribbean topics, though it lacks an explicit verb (e.g., 'get' or 'retrieve').

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 versus alternatives. Sibling tools cover different domains, so context is implied, but no explicit when/when-not or prerequisite conditions are 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?

Annotations indicate read-only (readOnlyHint: true). The description adds the price (0.030 USDC) which suggests a potential payment requirement, but it doesn't clarify if the payment_tx_hash parameter is mandatory or how it relates to cost. No contradiction with annotations, but transparency is incomplete.

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 concise, fitting key information into one sentence plus a price line. It is front-loaded with the main subject and avoids unnecessary words, though the price line could be integrated more naturally.

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, the description outlines what the tool provides (price, profile, potential) but does not specify the return format or behavior if payment is required. Partially complete for a read-only tool with one optional parameter.

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% for the single parameter. The description adds value by mentioning the price (0.030 USDC), which likely relates to the payment_tx_hash parameter, giving context beyond the schema's 'Hash tx USDC Base' 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 clearly states it retrieves Caribbean vetiver information for luxury perfumery, including price comparison, olfactory profile, and potential in Guadeloupe. It is specific and distinct from sibling tools which cover different domains like solar analysis, biodiversity, or marketplace data.

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 vetiver data retrieval but does not explicitly state when to use this tool versus alternatives or provide conditions. Since siblings are all on different topics, context is clear but no explicit guidance is given.

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 provide readOnlyHint=true, which is sufficient for basic transparency. The description adds context about credit types and price but does not disclose behavioral traits like data freshness or required authentication.

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, concise, and front-loaded with the subject. However, it could benefit from a more structured presentation of key information.

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 one optional parameter and no output schema, the description is incomplete. It fails to explain what the tool returns, how the parameter affects results, or typical use cases.

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 parameter 'payment_tx_hash' is described in the schema but not explained in the description. Its purpose (why a read-only tool needs a transaction hash) is unclear, and the description adds no value 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 clearly indicates it relates to Caribbean biodiversity credits, listing relevant standards (TNFD, Plan Vivo, etc.) and a price. This distinguishes it from sibling tools like caribbean_get_biodiversite (general biodiversity) and others.

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 versus alternatives or any prerequisites. The description does not mention context or exclusions.

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 indicate readOnlyHint=true, but the description adds a price mention without clarifying if payment is required to access data. It does not explain behavior beyond the annotation's safety hint, missing details on output format or access constraints.

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 compact list of keywords and figures, but it reads like a bullet-point summary rather than a coherent sentence. It is concise but lacks proper structure for easy parsing.

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?

Without an output schema, the description should clarify what the tool returns (e.g., a report, data object). It lists topics and a price but does not specify the nature of the output, leaving the agent uncertain about the result format.

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 one optional parameter described. The description does not add meaning beyond the schema's 'Hash tx USDC Base' and payment instructions hint. Baseline 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 mentions specific topics like 'crise eau Guadeloupe' and 'dessalement', indicating the tool provides water and sanitation data for the Caribbean DOM. However, it lacks a clear verb-action framing typical of 'get' tools, relying on topic keywords instead of stating 'Retrieves water crisis data'.

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 versus siblings like 'caribbean_get_biodiversite' or 'caribbean_get_irradiation_dom'. The description only lists content, without telling an agent when this tool is appropriate.

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 declare readOnlyHint=true, consistent with a read operation. The description adds context about contracts and price but does not disclose any additional behavioral traits beyond what annotations provide. It is adequate but not enhanced.

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 concise with three sentences covering key elements: region, contract duration, price. It is front-loaded with purpose. However, it could be better structured (e.g., bullet points) for clarity.

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, the description should indicate what the tool returns (e.g., tariff rates, contract terms). It mentions a fixed price but does not clarify if the response contains dynamic data or simply confirms that price. The tool is simple, but completeness is lacking for an AI agent to fully understand the 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% and the description repeats the schema's parameter explanation ('Hash tx USDC Base (0x+64hex). Absent = instructions paiement.'). No additional meaning is added beyond what the schema already provides. 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?

The description clearly states the tool provides EDF OA tariffs for solar energy in ZNI (French overseas departments) with contract details and price. It uses specific verb 'get' implicitly, resource 'tarifs', and scope 'solaire en ZNI', distinguishing it from sibling tools like caribbean_get_irradiation_dom or caribbean_get_fiscalite_244w.

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 for obtaining solar tariffs in specific regions but does not provide explicit guidance on when to use this tool vs alternatives, nor does it mention prerequisites or exclusions. It is clear enough for a user seeking those tariffs, but not for an AI agent deciding between similar 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?

Annotations declare readOnlyHint=true, confirming a read operation. The description adds no further behavioral context—such as authentication requirements, payment flow, or response format—beyond the data content. No contradiction with annotations.

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 short sentence with a price line, conveying core information without redundancy. It is appropriately sized for the tool's simplicity.

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 one optional parameter, the description omits important context such as whether payment is mandatory, how to obtain the transaction hash, and what the output format contains (e.g., dataset fields). The price mention adds context but leaves gaps.

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?

Input schema has one optional parameter with full description coverage ('Hash tx USDC Base.'). The description does not elaborate on the parameter, so no additional meaning is provided beyond the schema. Baseline 3 applies due to 100% schema 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?

The description clearly states it provides marine eDNA data from Guadeloupe, specifying the source (MNHN 2021-2022), content (300+ fish species, 21 cetaceans), and price. This distinguishes it effectively from sibling tools focused on other domains like solar analysis, biodiversity, or market data.

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 a paid use case (price mentioned) but provides no explicit guidance on when to use this tool versus alternatives. The topic differentiation from siblings is clear, but exclusions or prerequisites (e.g., need for a payment transaction) are not stated.

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 indicate read-only, which aligns with the description. The description mentions a price but does not clarify whether payment is required or how it works, leaving behavioral ambiguity.

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 dense, packing information into one line. It could be more readable with separate sentences, but it avoids unnecessary verbosity.

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 lacks information about the return value or output format. It does not explain the optional parameter's role regarding the price. With no output schema, these gaps significantly reduce 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?

The schema describes the payment_tx_hash parameter. The description mentions a price, which may relate to the parameter, but does not explicitly connect them. The link is implied but not confirmed.

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 lists specific financing programs (TIC, BPI, ADEME, FEDER) and mentions a price, indicating the tool provides information on renewable energy financing aids in DOM. However, it lacks an explicit verb like 'retrieve' or 'get', reducing clarity slightly.

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 is provided on when to use this tool versus its many siblings. The description does not explain selection criteria or context for usage.

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 indicate readOnlyHint=true, so description adds little extra behavioral context. Price mention implies paid usage but no details on auth or limitations.

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 but mixes unrelated details (rates, forms, price). Could be more structured but length is acceptable.

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 description only vaguely hints at 'cas pratiques'. Agent cannot infer what data is returned, making it incomplete for selection and 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 covers the single parameter 'payment_tx_hash' with description. Description adds no extra meaning beyond schema, so baseline score 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?

Description mentions 'Crédit d'impôt 244 quater W DOM' with rates and forms, suggesting tax credit info, but lacks a clear verb like 'get' or 'retrieve'. Purpose is inferred rather than explicit.

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 versus siblings like 'caribbean_get_financement_dom' or 'caribbean_get_credits_biodiversite'. Missing contextual or conditional usage hints.

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 declare readOnlyHint=true, and description adds pricing context but does not clarify behavioral implications like payment handling or external requests.

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?

Relatively concise at three lines, but includes pricing info that may be extraneous; structured as a list of data points.

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?

Description lists key data items but lacks details on output format or use cases; sufficient given simple input 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?

Input schema has 100% coverage with description for the sole optional parameter; description does not add significant meaning beyond 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 clearly states it provides agricultural land prices and related data for French overseas departments, distinguishing it from sibling tools that cover other domains like solar analysis or biodiversity.

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 versus alternatives; lacks explicit context or conditions for use.

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?

Beyond the readOnlyHint annotation, the description discloses a cost of 0.030 USDC and implies that providing a payment_tx_hash is optional; omission triggers payment instructions. This adds behavioral context about required payment for full access.

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 concise, covering key data points in three sentences. It is front-loaded with the core subject and avoids redundancy. However, the dense packing of information may reduce readability for some agents.

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 lists content categories but does not specify output format or structure. Given the lack of an output schema, the agent lacks details on what the tool returns, though it is adequate for basic decision-making.

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?

With 100% schema coverage and a single optional parameter, the description adds no further meaning to the parameter beyond what the schema's description already provides. The baseline 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 identifies the tool as providing import/export information for Caraïbes, specifically customs flows of Guadeloupe, opportunities in Dubai, logistics, and certifications. It distinguishes from sibling tools that cover different domains like solar or biodiversity. However, French language may impede clarity for non-French agents.

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 explicit guidance on when to use this tool versus alternatives. The description lacks conditions, prerequisites, or exclusions. The agent must infer usage solely from the topic.

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 provide readOnlyHint=true, but description adds payment context (price, payment_tx_hash). It clarifies that absence of hash returns payment instructions. However, it does not disclose output format, rate limits, or post-payment behavior. The contradiction between readOnlyHint and payment is mild; the tool may be read-only after payment validation.

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 concise sentences in French, front-loading the key data (GHI, PVOUT, regions, data sources, included formula, price). No wasted words; every sentence adds 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?

No output schema is provided, yet the description fails to specify the return format (units of GHI/PVOUT, how the formula is returned, or how to distinguish between payment instructions and data). For a tool with payment and data retrieval complexity, this is insufficient.

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 describes the single parameter payment_tx_hash with type and format. The description adds meaning by stating 'Absent = instructions paiement' and linking to the tool's overall purpose (irradiation data). Schema coverage is 100%, so the description enriches rather than duplicates.

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 returns solar irradiation data (GHI, PVOUT) for specific French overseas departments, including a kWh production formula and price. The name 'get_irradiation_dom' aligns perfectly, and it distinguishes from sibling tools like 'caribbean_analyse_solaire' which likely performs analysis.

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 versus alternatives. No mention of prerequisites (e.g., need for payment) or when to choose other solar or Caribbean tools. The description implies a payment workflow but does not explain decision criteria.

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=true and openWorldHint=false, covering safety and scope. Description adds useful context: the tool is free and provides an overview, which complements the annotations without contradiction.

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 that front-loads the purpose and includes key details (list of tools, URLs, free, recommended). No wasted words.

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, read-only, zero-parameter tool, the description fully covers its purpose and usage context. No additional information (e.g., output format) is necessary given the low complexity.

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?

Tool has zero parameters with 100% schema coverage. Baseline score for no parameters is 4. Description does not need to add parameter information.

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 provides an overview of the marketplace with a list of tools and discovery URLs. The phrase 'point de départ recommandé' differentiates it from similar sibling tools like caribbean_list_marketplace by emphasizing it as the starting point.

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 recommends using this tool as a starting point ('point de départ recommandé'). While it doesn't list when not to use it, the context is clear given the zero-parameter nature and sibling tools for specific data.

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 annotation readOnlyHint=true already indicates no side effects. The description adds that data is fresh each call and mentions a price of 0.030 USDC, which is extra context but not critical for safety. No contradiction with annotations. The description does not elaborate on other behaviors like rate limits or auth requirements, so transparency is adequate but not enhanced beyond annotations.

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 brief (three sentences) and conveys the core purpose, filters, and freshness. Including the price adds useful but non-essential information. It is well-structured and front-loaded with the main function. One could argue the price could be omitted, but it remains relevant for cost-aware agents.

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 no output schema and a simple read-only purpose, the description adequately covers its functionality. It specifies the data source, location, filters, and pricing. The context is sufficient for an agent to invoke it correctly, though it does not detail pagination behavior beyond parameter descriptions.

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%, meaning all parameters have descriptions in the schema. The high-level description repeats parameter names (nature, année, pagination) but does not add meaning beyond what the schema provides. Thus, it meets the baseline for a tool with complete schema documentation.

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 retrieves real-time public contracts (marchés publics) for Guadeloupe (971) from the official DECP database. It specifies the number of contracts (4,400+) and available filters, distinguishing it from sibling tools like caribbean_get_caye_marche which focus on different domains. The verb 'get' is implied, and the resource is explicitly 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?

The description mentions 'en temps réel' and 'Données fraîches à chaque appel', indicating real-time use. It lists filter options (nature, année, pagination) but does not provide explicit guidance on when to use this tool versus alternatives, nor does it state when not to use it. The usage context is implied rather than explicit.

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 indicate readOnlyHint=true. The description adds behavioral context: real-time data, 31k+ contracts, official DECP, filters, and pricing. No contradictions. It provides useful behavior beyond annotations, though it does not explain return format or pagination.

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 concise, using a single informative sentence with key details (scope, count, locations, filters, price). It front-loads the main purpose. Could be slightly more structured, but no unnecessary words.

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 6 parameters, readOnlyHint, and no output schema, the description covers core functionality, scope, filters, and cost. The absence of explanation for the 'payment_tx_hash' parameter is a minor gap, but the schema provides a basic description.

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?

Input schema has 100% coverage with descriptive parameter explanations. The description reinforces the use of filters (departement, nature, annee) and explicitly mentions pricing as non-parameter context. The payment_tx_hash parameter is not explained, but the schema covers it.

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 the tool retrieves real-time public contracts from all DOM overseas departments, specifying the exact departments and data source (DECP). This clearly distinguishes it from the sibling 'caribbean_get_marches_publics', likely for a single DOM.

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 implicitly suggests usage for accessing multi-DOM public contract data, and includes pricing (0.025 USDC) as a cost guideline. However, it does not explicitly state when to use this over sibling tools, nor 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?

Annotations readOnlyHint and openWorldHint already indicate safe read operation. Description adds valuable context about 25% commission, which is relevant behavioral info beyond annotations.

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 concise sentences, front-loaded with purpose and prerequisite. No redundant text.

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 gives sufficient context: explain prerequisite, commission, and parameter examples. Complete for its 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 descriptions already cover parameters, but description provides concrete examples for slugs and payment hash, adding practical 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?

Description uses a specific verb "Accède" and resource "données d'un fournisseur tiers de la marketplace", clearly distinguishing from many sibling tools that target other domains (e.g., solar, tourism).

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 instructs to use caribbean_list_marketplace first to discover slugs, and mentions a commission. Does not explicitly state when not to use, but context is clear.

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 readOnlyHint: true annotation already indicates no side effects. The description adds some context about payment (0.020 USDC), but does not clarify whether payment is required or how it affects behavior. No contradiction with annotations, but the description could be more transparent about the role of payment.

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 one dense sentence mixing factual data, prices, and a payment value. It lacks structure and front-loading of the core purpose. A more concise and organized presentation would improve 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?

The description fails to explain what the user will receive as output (e.g., structured data, report). Given the optional payment parameter and lack of output schema, more detail is needed about the behavior when payment_tx_hash is present vs. absent, and what the returned data represents.

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 100% description coverage for its single optional parameter. The schema itself already explains the parameter's meaning and default behavior. The tool description does not add any additional semantic value beyond what the schema provides, so the baseline score 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?

The description communicates the tool's focus on artisanal fishing data in the Caribbean, including production volume, species prices, regulations, and export. It is specific and differentiates from sibling tools like caribbean_get_biodiversite by topic. However, the lack of a clear verb (e.g., 'Get') and the cluttered presentation slightly reduce clarity.

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 explicit guidance on when to use this tool versus alternatives. The optional parameter 'payment_tx_hash' hints at a payment mechanism, but the description does not explain the context or prerequisites for using the tool. The inference from the parameter description is not part of the main description.

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?

Beyond the readOnlyHint annotation, the description discloses a behavioral trait: the tool requires payment (0.020 USDC) and explains that omitting the payment_tx_hash yields payment instructions. This adds useful context about how the tool operates.

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 packs key information (company count, sectors, profiles, price) concisely. It is front-loaded with the main subject, though the structure is 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?

Despite lacking an output schema, the description adequately explains what data the tool returns (economic intelligence on SMEs, sectors, pain points, networks) and how payment works. This is sufficient for an agent to understand tool behavior.

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 description in the schema already explains the hash format and default behavior. The tool description adds no additional parameter explanation, so the baseline 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 indicates the tool provides economic intelligence on Guadeloupe SMEs, covering 42,000 companies, 6 key sectors, and business networks. While the verb is implicit, the scope is specific and distinct from sibling tools like caribbean_get_tourisme_guadeloupe.

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 is provided on when to use this tool versus alternatives or when not to use it. The description does not mention prerequisites, such as requiring payment, nor does it differentiate from similar 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?

Annotations already indicate readOnlyHint=true, so the description adds minimal behavioral context beyond stating it is free. No details on side effects, authentication, or rate limits are given, which is acceptable given the annotations.

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, clear sentence that front-loads the main action. It is concise without being overly terse, though it could possibly benefit from more structure.

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's simplicity (one parameter, no output schema, and read-only annotation), the description is complete enough. It lists the returned fields and notes the tool is free.

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 schema already describes provider_slug with an example. The description adds no additional meaning beyond the schema's documentation.

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 returns the complete card of a provider, listing specific contents (description, endpoints, price, verification status). It uses a specific verb and resource, distinguishing it from sibling tools that target different resources.

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 does not provide guidance on when to use this tool versus alternatives. It only mentions it is free, which hints at cost but not usage context. No when-not or alternative names are 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?

Annotations indicate readOnlyHint=true, confirming no side effects. The description adds that there is a price (0.010 USDC) but does not explain how payment works or what the output format is, leaving gaps in understanding the tool's 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 a single concise sentence that front-loads the core purpose and includes key details (steps, delays, price) without unnecessary words.

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 one optional parameter requiring payment. The description does not clarify the return value format, that payment is required, or how the payment hash is used. Given the complexity of a paid information retrieval tool, the description is incomplete.

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 100% coverage with a description for the only parameter (payment_tx_hash). The description does not add any further semantic information about the parameter beyond 'Hash tx USDC Base.'

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 that the tool provides the procedure for connecting to the solar network in Guadeloupe, including 8 steps and real delays. The name and description uniquely identify it among siblings like caribbean_analyse_solaire.

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 explicit guidance on when to use this tool versus alternatives like caribbean_analyse_solaire. The description only states what it does without contextualizing when it is appropriate.

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 context about data fields (e.g., '870 000 visiteurs') and mentions a price ('0.025 USDC'), but does not explain behavioral traits beyond what annotations (readOnlyHint=true) already provide. The payment parameter is described in the schema, not expanded here, and no contradiction with annotations is evident.

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 dense sentence listing multiple data points. While it contains relevant information, it is somewhat cluttered and could be better structured 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?

Given the absence of an output schema, the description partially compensates by listing some return fields (e.g., visitor numbers, labels, market flows). However, it does not fully describe the response structure, leaving gaps about the format or additional data.

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 parameter is fully documented. The description adds the price ('0.025 USDC') but otherwise repeats information already in the schema (payment_tx_hash). No additional semantic value is provided for parameter usage.

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 lists specific data points (visitor count, labels, market flows, etc.) for sustainable tourism in Guadeloupe, making the tool's purpose clear. However, it lacks an explicit action verb like 'retrieves' or 'provides,' relying on the tool name 'get_' to imply the operation.

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 is provided on when to use this tool versus sibling tools (e.g., caribbean_get_peche_artisanale). There is no mention of prerequisites, alternatives, or when not to use it, leaving the agent to infer context solely from the tool name.

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 indicate readOnlyHint=true. The description adds that the tool is 'Gratuit' (free), which is a behavioral trait. However, no additional constraints or side effects are disclosed. Since annotations cover the read-only nature, the description provides minimal extra behavioral context.

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 extremely concise: a single sentence that conveys the core functionality and a key attribute (free). It is front-loaded with the action and resource. Every word serves a purpose 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 simple list tool with no parameters and no output schema, the description adequately specifies what it lists (active providers, endpoints, prices) and a behavioral note (free). It does not mention potential limits like pagination or whether the list is exhaustive, but given the tool's simplicity, it is largely complete.

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 zero parameters and schema description coverage is 100% (trivially). The description adds no parameter information because none exist. Baseline 3 is appropriate as the schema already satisfies the need.

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 the verb 'Liste' (list), the resource 'fournisseurs actifs de la marketplace caribéenne', and the information returned ('endpoints et prix'). It also mentions 'Gratuit' (free), differentiating it from sibling tools like caribbean_get_marketplace_data which likely retrieves specific data.

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 provides no explicit guidance on when to use this tool versus alternatives. It only mentions 'Gratuit' as a potential advantage, but does not specify scenarios or exclusions. The purpose is clear enough that agents can infer use, but better guidance would improve decision-making.

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