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?

Annotations indicate readOnlyHint=true, suggesting no side effects, but the description mentions a price of 0.050 USDC, implying a potential cost or payment requirement. This is a behavioral contradiction. The description does not explain what happens when payment_tx_hash is provided or omitted.

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 (one sentence), which is concise, but it sacrifices clarity and completeness. It needs more structure and front-loading of the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description only lists examples of content (species, ecosystems) without explaining the format or structure of the response. An agent cannot fully understand what to expect from calling this tool.

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 only parameter, payment_tx_hash, has a minimal schema description ('Hash tx USDC Base.'). The tool description mentions a price but does not clarify whether this parameter is for payment or its relationship to the price. Schema coverage is 100% but adds no meaningful semantics beyond the literal parameter name.

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 is about Guadeloupe biodiversity (species, ecosystems, protected areas) but does not explicitly use a verb like 'get' or 'retrieve'. The name implies a read operation, but the description itself is a factual statement without a clear 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 is provided on when to use this tool versus its many siblings (e.g., caribbean_get_credits_biodiversite, caribbean_get_edna). There is no mention of context, prerequisites, or alternatives.

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?

Annotations indicate readOnlyHint=true, so the tool is read-only. However, the description mentions 'Prix : 0.050 USDC' and a payment_tx_hash parameter, which could imply a cost or payment requirement—creating confusion. The description does not clarify whether the tool requires payment or what '0.050 USDC' refers to.

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 (one fragmented sentence) but sacrifices clarity for brevity. It could be restructured to clearly state the tool's purpose and output without increasing length much.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, yet the description does not explain what the tool returns. It gives specific numbers (e.g., 'Marché 2.1 Mds$') but doesn't confirm these are the return values. The overall context is incomplete for an AI agent to understand the tool's 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?

The schema already describes the single parameter payment_tx_hash as 'Hash tx USDC Base' (100% coverage). The description adds no additional meaning beyond the schema; the mention of '0.050 USDC' might relate to the parameter but is ambiguous.

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 provides market data points ('Marché vanille caribéenne : prix Guadeloupe vs Madagascar vs Tahiti, récolte, certifications, canaux Dubai/Europe. Marché 2.1 Mds$. Prix : 0.050 USDC.') but does not state what the tool does. It reads like a content preview rather than a functional description. The verb 'get' in the name implies retrieval, but the description lacks a clear action statement.

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 its many siblings (e.g., caribbean_get_caye_marche, caribbean_get_caye_vetiver). There is no context about prerequisites, scenarios, or alternatives.

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 mentions a price of 0.050 USDC, implying a payment requirement, but annotations declare readOnlyHint=true, which is a contradiction. No further behavioral details are 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 concise but packs many terms without clear structure. It is front-loaded but could be more organized.

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?

While the description mentions topics and pricing, it does not explain expected return values or behavior, especially given the annotation contradiction.

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 description adds the context that the tool costs 0.050 USDC, which is not present in the schema parameter description. This provides meaningful additional information 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 the tool retrieves information about Caribbean vetiver for luxury perfumery, comparing prices and profiles. However, it does not differentiate from many sibling tools with similar names.

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 like caribbean_get_caye_vanille or caribbean_get_caye_marche.

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 a safe read operation. The description adds no additional behavioral context beyond stating a price, which is not contradictory. It does not disclose response format or side effects, but annotations suffice.

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 and front-loaded, but includes unnecessary details (listed standards and a static price) that may become outdated. It could be more direct about the tool's function.

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 one optional parameter and no output schema. The description fails to explain what the tool returns (e.g., a list of credits, market data) or the role of the payment_tx_hash parameter. This leaves significant gaps for an 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 coverage is 100% with one parameter described. The description does not explain the purpose of payment_tx_hash in the context of retrieving credits, leaving its role unclear. Baseline 3 is appropriate as the schema provides the basic 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?

The description mentions biodiversity credits and standards like TNFD, Plan Vivo, Verra, and a price, but it does not clearly state the action the tool performs (e.g., retrieving a list of credits or current prices). The purpose is vague and does not differentiate from sibling tools like caribbean_get_biodiversite.

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 use this tool versus alternatives. No context about prerequisites, exclusions, or typical use cases 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?

Annotations declare readOnlyHint=true, and the description does not contradict that. However, the description mentions 'Prix : 0.050 USDC' and the schema indicates a payment hash may be needed, implying a paywall. This behavioral trait is not disclosed in the description, leaving the agent unaware of potential payment requirements.

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 unstructured string of keywords and phrases, not a coherent sentence. It is under-specified and poorly formatted, lacking clear front-loading of core purpose.

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 exists, yet the description does not explain what the tool returns. It hints at topics (water crisis, projects, price) but does not specify the output format or content, leaving the agent uncertain about the tool's deliverable.

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%; the schema already explains the parameter (payment_tx_hash) as a USDC transaction hash or absence means payment instructions. The description adds no further 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 mentions 'Eau et assainissement DOM' and specific topics like Guadeloupe water crisis, indicating the tool provides information about water and sanitation in French overseas departments. However, it lacks a clean statement of what the tool does (data retrieval), instead listing keywords. It is distinguishable from siblings by domain, but the purpose is vague.

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 (e.g., caribbean_get_financement_dom). The description does not mention use cases, prerequisites, or 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 already declare readOnlyHint=true, so the tool is read-only. The description adds that it returns tariff info and contract terms, but does not disclose behavior when the optional payment_tx_hash parameter is provided (e.g., returns payment instructions). 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 very short (one line with three fragments) and front-loaded with the key purpose. However, it could benefit from a sentence explaining the parameter's effect on output.

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 tool with one optional parameter, the description covers the core data and territory. However, it lacks explanation of the return format (no output schema) and the exact impact of the payment_tx_hash parameter. This leaves the agent uncertain about what 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 coverage is 100% for the single parameter. The description adds value by explaining the conditional behavior: 'Absent = instructions paiement', clarifying what happens without the hash. This goes beyond the schema's type 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 the tool retrieves EDF OA tariffs for solar energy in French overseas departments (ZNI), specifying contract duration and price. It distinguishes itself from sibling tools, none of which target tariff 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 is provided on when to use this tool versus the many siblings (e.g., caribbean_analyse_solaire, caribbean_get_fiscalite_244w). The description does not mention prerequisites or alternatives.

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 annotations declare readOnlyHint=true, but the description mentions 'Prix : 0.100 USDC' and the input schema includes an optional 'payment_tx_hash' parameter, implying a payment step that contradicts read-only behavior. The description does not clarify whether payment is required or what the tool actually does with the hash.

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, which is concise but lacks structure. It front-loads the data content but bundles the price at the end without clarity. It could be more efficient by separating concepts.

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 optional parameter, no output schema), the description fails to specify what is returned, the data format, or any access conditions. The contradiction between readOnly annotation and payment implication leaves the agent confused about the tool's 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% for the single parameter. The description adds price context ('0.100 USDC') but does not explain the parameter's role or whether it is needed for data access. The parameter description in schema ('Hash tx USDC Base') is adequate, so the tool description adds marginal 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 specifies 'Données eDNA marines Guadeloupe MNHN 2021-2022', clearly identifying the data source and content (300+ fish species, 21 cetaceans, eDNA protocol). The tool name 'get_edna' reinforces the retrieval action. However, it does not explicitly state the verb (e.g., 'retrieve' or 'download') and does not distinguish from many sibling get_* 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?

There is no guidance on when to use this tool versus alternatives like 'caribbean_get_biodiversite' or other Caribbean data tools. The description mentions a price but does not explain usage context or prerequisites.

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, indicating a safe, non-destructive operation. The description adds a behavioral detail: 'Prix : 0.050 USDC' implies a cost per invocation. However, it does not explain return format or typical response, leaving some aspects unclear.

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, consisting of a single sentence plus a price. Every word provides content: the domain, aid programs, and cost, 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?

Without an output schema, the description should clarify what the tool returns (e.g., list of programs, details, eligibility). It only lists aid programs and cost, leaving output expectations 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?

Only one parameter (payment_tx_hash) with 100% schema description coverage. The description does not mention the parameter or provide additional semantic context beyond the schema, which already explains it as a transaction hash.

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 resource ('aides financement ENR en DOM') and lists specific aid programs, making it clear that this tool provides renewable energy financing aid information for French overseas departments. Among siblings, it is distinct as it focuses specifically on financing aids for energy in 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?

No explicit guidance on when to use this tool versus alternatives. The description lacks context about prerequisites, exclusions, or use cases, leaving the agent to infer from the title and sibling names alone.

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 indicates readOnlyHint=true, which is consistent with the tool retrieving information. The description adds the price (0.100 USDC), which is behavioral context not in annotations, but does not disclose other traits like authentication or rate limits.

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 (two lines) but mixes languages and lacks a clear action statement. It provides key facts concisely but 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?

No output schema exists, and the description only hints at the content (rate, form, cases) without specifying the response structure. The payment parameter is mentioned as optional, but the description implies a cost, creating ambiguity about whether payment is required. This leaves an agent guessing about the return format and prerequisites.

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 only parameter, payment_tx_hash, is documented in the schema with a description. The tool description does not elaborate on this parameter or explain its role (e.g., payment verification). With 100% schema coverage, the description adds no additional 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?

The description states the tool is about a specific tax credit (244 quater W DOM) and gives technical details (rate, retrocession, form). However, it lacks an explicit action verb like 'Get details on' and reads more like a title than a functional description. It distinguishes from siblings by the specific tax credit code.

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 the many sibling tools (e.g., for other Caribbean topics). There is no mention of prerequisites, alternatives, or 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 indicate readOnlyHint=true, but the description mentions a price ('Prix : 0.050 USDC') and a payment parameter, implying potential cost or transaction requirement. This behavioral trait is not explained clearly. The description should state whether payment is required to get data or just for certain features.

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 includes many specifics (prices, acronyms). It could be more concise and structured for easier parsing by an AI agent.

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, yet the description does not explain what the tool returns. Mentions 'cas pratiques' but unclear if that is the output. Missing information on payment flow and expected response 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 description coverage is 100%, so the schema already documents the payment_tx_hash parameter. The tool description does not add additional meaning or constraints to the parameter.

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 agricultural land prices and specific topics like SAFER and FEADER, but does not explicitly state 'retrieves' or 'gets' data. It reads like a summary rather than a clear purpose statement. Compared to sibling tools like 'caribbean_get_biodiversite', it lacks distinction.

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, but the description does not help the agent choose. Missing context like 'for land price queries' or 'for agricultural planning'.

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 the description adds cost context ('Prix : 0.050 USDC') but does not elaborate on payment behavior or output variations based on the parameter. No contradiction exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and key details. Every piece serves a function, though it is dense with 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?

The description outlines output content (customs data, opportunities, logistics, certifications) but omits behavioral context about the payment parameter affecting output. No output schema exists, so more detail would be beneficial.

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 tool description does not add parameter information beyond the schema. 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?

The description clearly states the tool provides import/export information for the Caribbean, specifically Guadeloupe customs data, Dubai opportunities, logistics, and export certifications. It is distinct from sibling tools that focus on other domains like solar 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?

The description provides clear context about the tool's content but no explicit guidance on when to use it vs. alternatives. No exclusions or comparisons are 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 indicate readOnlyHint: true, but the description mentions a price of 0.020 USDC without clarifying how payment is handled or if the tool behaves differently when payment_tx_hash is provided vs absent. No details on rate limits, output format, or other behavioral traits.

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 the essential information (data type, regions, sources, formula, price). It is front-loaded and concise, though the use of French may affect readability for non-French users.

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 having few parameters, the description lacks details on the output format (e.g., JSON, CSV) and how the included formula is delivered. The payment mechanism is also vague. An output schema is absent, so the description should compensate.

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 clear description of the single parameter. The tool description adds no further parameter context, but the schema already explains the parameter adequately. 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 it provides solar irradiation data (GHI and PVOUT) for specific French overseas departments, with data sources and an included formula. This distinguishes it from other tools like caribbean_analyse_solaire, though it does not explicitly compare.

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 implies use for obtaining irradiation data but lacks any when-not-to-use or alternative suggestions.

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?

Annotations provide readOnlyHint=true, but the description adds little behavioral context. Mention of payment_tx_hash and 'Prix: 0.050 USDC' hints at a payment mechanism, yet the tool is marked read-only. No clear statement of return format or side effects.

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 dense block of numbers and prices without clear separation. Lacks front-loading of the tool's purpose. Could be restructured to be more concise and readable.

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, and the description does not indicate what the tool returns (e.g., report, dataset, instructions). The presence of a payment parameter without explanation raises completeness concerns for a read-only tool.

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%; the single parameter payment_tx_hash is fully described in the schema. The description does not add extra clarification 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 mixes context ('190 000 t/an, 85% artisanale', species prices) but does not clearly state the tool's action or what it retrieves. The name implies 'get', but the text reads like a data summary. Purpose is vague.

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 the many sibling tools (e.g., caribbean_get_biodiversite, caribbean_get_marches_publics). No comparison or context 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 already declare readOnlyHint=true. The description adds context about cost (0.050 USDC) and that missing payment_tx_hash returns payment instructions, which is useful but does not conflict with readOnlyHint.

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 front-loads the main subject and lists key data points efficiently. However, it is somewhat dense and could benefit from structuring.

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 outlines the data content (42k companies, 6 sectors, etc.) but lacks information about the output format or structure. Given no output schema, more detail would be beneficial.

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 does not add meaningful semantic detail beyond the schema's parameter description. The mention of price is tangential.

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's subject as economic intelligence for Guadeloupe SMEs, but lacks an explicit verb like 'retrieve' or 'get'. The name includes 'get', compensating somewhat.

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 (e.g., caribbean_get_tourisme_guadeloupe). The description does not mention any specific conditions or alternatives.

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; description adds that it costs 0.020 USDC and references a payment transaction hash. However, it does not clarify if payment is required or what happens without the hash. The description adds some behavioral context but leaves 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?

One dense sentence that front-loads the key information. Could be clearer for non-French speakers, but it's reasonably concise.

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 does not explain what the tool returns (e.g., text, PDF, steps), nor how payment works if the hash is omitted. Without an output schema, this is a significant gap. The tool appears moderately complex (paid, conditional), but the description lacks essential details.

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 parameter (payment_tx_hash) as a USDC hash. The description adds the cost (0.020 USDC), which provides meaning beyond the schema. Schema coverage is 100%, so baseline is 3, but the extra cost detail raises it to 4.

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 specifies the tool's purpose: providing the procedure for solar panel grid connection in Guadeloupe (8 steps, delays). It distinguishes from siblings which cover other topics like biodiversity, market, water, etc.

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 siblings. Usage is implied from the topic (solar connection), but no exclusions or alternatives are mentioned.

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, and the description adds a price (0.050 USDC) and hints at optional payment via payment_tx_hash, providing behavioral context beyond annotations. It does not detail potential side effects, but as a read-only tool, that's acceptable.

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 compact (two sentences) and front-loaded with key data points. However, the first sentence is a run-on list, slightly reducing clarity. It is reasonably concise but could be better structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the data content and pricing context, but lacks details on return format (e.g., JSON structure, pagination) since there is no output schema. It is sufficient for basic understanding but incomplete for an informed 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?

The sole parameter (payment_tx_hash) is fully described in the input schema (100% coverage). The tool description adds no additional meaning, 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 lists tourism data content (visitors, accommodations, etc.) but does not explicitly state the tool's action (e.g., 'retrieve' or 'get'). The name 'get_tourisme' clarifies the purpose, but the description itself is a data summary rather than a clear functional statement.

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 sibling tools (e.g., caribbean_get_biodiversite, caribbean_get_marches_publics). The description does not differentiate usage contexts or mention alternatives.

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.