mcp-knowledge

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

Annotations provide readOnlyHint and openWorldHint, indicating safe read behavior. The description adds that inputs are validated server-side. No contradiction between description and annotations. However, it does not elaborate on other behavioral aspects like processing time or result storage.

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 relatively short but includes a reference case example. It is front-loaded with the title. However, mixing French and English may reduce clarity for some agents. It could be more concise by removing the example and focusing on essential usage.

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 complexity (8 parameters, nested objects, no output schema), the description lacks completeness. It does not explain what the deliverable contains, how results are returned, or any post-processing steps. The absence of output schema description leaves a significant gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 13%. The description does not explain individual parameters; it only mentions 'documented case fields' and provides a reference case. Agents must infer parameter meaning from names and types alone, which is insufficient for complex nested objects.

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 an 'Architecte ABM' that returns a structured, audited deliverable for C-suite expertise (CMO). It includes a reference case to illustrate scope. This distinguishes it from sibling tools like 'abm_lookalike_account_finder' and 'account_expansion_mapper' which focus on specific sub-tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description implies it's for C-level ABM strategy but does not compare to similar tools or state prerequisites. Lacks when-not-to-use 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 already indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context: 'analyzes public web data including robots.txt and OpenGraph metadata' and returns a 'ranked list of potential targets with matching technologies and company attributes.' No contradictions 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 three sentences long, each serving a distinct purpose: stating the goal, explaining the analysis method, and specifying inputs and outputs. It is front-loaded with the most critical information and contains no redundant language.

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 complexity (4 params with nested objects, high schema coverage, existing output schema, and rich annotations), the description covers all essential aspects: purpose, data sources, input format, and output. It is complete enough for an agent to understand and use 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 high (75%), and the schema descriptions for parameters like 'top_customer_domains' are already detailed. The description briefly reiterates input types ('top customer domains' and 'desired firmographic filters') but does not add significant meaning beyond the schema. It's adequate but not exceptional.

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's purpose: 'discover 50 B2B accounts that closely match your top 10 customers' tech stacks and firmographics.' It uses a specific verb ('discover') and defines the resource ('lookalike accounts'). The tool is well-differentiated from siblings like 'account_expansion_mapper' and 'competitor_profiles' by focusing on lookalike discovery based on tech stacks and firmographics.

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 usage guidance: 'Input your top customer domains and desired firmographic filters to receive a ranked list of potential targets.' It implies when to use (for targeted ABM campaigns) but does not explicitly state when not to use or mention alternative tools. Given the sibling list, the context is sufficient for most agents to select appropriately.

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 openWorldHint, so the description's mention of server-side validation and returning a deliverable aligns with a safe, read-only operation. It adds some context but doesn't fully describe behavior beyond what annotations convey.

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 relatively short (three sentences), but it includes somewhat jargony phrases like 'Gapup agent-payable C-suite expertise (CRO)' which may not be helpful. Front-loading 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?

For a complex tool with 5 parameters (including nested objects) and no output schema, the description fails to explain return format or what the deliverable contains. It leaves significant gaps for an agent to use 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 description coverage is low (20%), and the description does not explain parameters or their roles. The schema has some descriptions, but the description adds no extra meaning, leaving many parameters underdocumented.

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 'Mapping d'expansion comptes' and mentions returning a structured, audited deliverable, with a specific reference case for B2B enterprise expansion. It gives a clear verb and resource, but the purpose could be more precise. Sibling tools like abm_architect or champion_mapping could overlap, but the description doesn't explicitly distinguish.

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 reference case implies it's for top strategic accounts in B2B enterprise settings, but no when-not-to-use or alternative tool 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 already mark readOnlyHint=true, so the description's mention of returning a deliverable aligns. It adds that inputs are validated server-side, but does not disclose other behavioral traits like potential async execution (via async parameter) or any 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?

The description is a few sentences and includes a reference case which adds some value but also verbosity. It is reasonably concise but could be more 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?

Given the tool's complexity (8 parameters, nested objects, no output schema) the description is insufficient. It does not explain the output format or return value structure, and lacks details on how to interpret the 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 only 13%, and the main description does not explain any parameters beyond a vague 'send the documented case fields'. The complex nested schema requires much more explanation for effective use.

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 produces a structured, audited ESG plan deliverable. It includes a reference case for context. However, it does not differentiate from similar sibling tools like esg_audit_multi or sustainability_report.

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 vs alternatives. Given the large number of ESG-related siblings, the lack of usage context or exclusions is a significant gap.

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

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

Discloses key behavioral trait: being asynchronous with timeout considerations, which annotations (readOnlyHint=true, idempotentHint=true) do not cover. Adds context about following NIST RMF protocols and output structure. No contradictions 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?

Four sentences, front-loaded with purpose and key constraints (async). Well-structured and concise, though could be slightly more compact by merging some 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?

With output schema present, description adequately covers inputs, async behavior, and output components (status, warnings, source references). Sufficient for a security tool with moderate 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?

Schema coverage is 100%, so description does not need to detail individual parameters. It adds high-level context about accepting 'model outputs or decision boundaries' and async usage, but does not provide meaning beyond schema for each 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 specifies it's an 'asynchronous risk assessment tool' for evaluating 'AI model resilience against adversarial inputs' following 'NIST AI RMF red-teaming protocols'. This clearly distinguishes it from sibling tools, which cover diverse domains like marketing, finance, and compliance, but not adversarial input testing.

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 states 'Requires async:true to avoid timeout errors' and mentions outputs include 'status, warnings, and source references'. Provides clear context for when to use async mode, but does not specify exclusions or alternative tools for similar tasks.

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 set readOnlyHint=true, indicating safety. The description adds behavioral details: uses Common Crawl data, outputs fraud probability score, suspicious IP list, and pattern analysis. No contradictions.

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 plus keywords. The first sentence immediately states the core purpose, with no wasted words. Ideal for quick agent scanning.

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 4 parameters (including nested objects) and an output schema, the description provides a solid high-level overview. It misses guidance on async usage, but the output schema likely covers return values.

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 lists only affiliate_network and date_range as inputs, ignoring async and threshold. Schema descriptions cover 75% of parameters, so baseline is 3. The description adds minimal value beyond schema for parameter understanding.

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 affiliate clickstream data to flag fraud patterns like duplicate IPs, rapid clicks, and device spoofing. It specifies the target user (CMOs) and distinguishes itself from generic fraud detectors by focusing on affiliate clickstream.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly targets CMOs for validating affiliate traffic quality, providing good context. However, it does not mention when not to use this tool or alternatives like the generic 'fraud_detector' or 'social_influencer_fake_follower_detector'.

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 readOnly, openWorld, idempotent hints. The description adds context about data sources (WITS, UNCTAD STAT) and the async option, which informs behavior beyond annotations. No contradictions.

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 three sentences, front-loaded with purpose and key details. It is concise but could be more structured (e.g., bullet points for outputs). Still efficient.

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

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

With output schema present, the description adequately covers inputs, outputs (structured risk assessment, gaps, recommendations), and the async option. Missing details like rate limits or constraints on HS code length, but overall complete given tool 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?

Schema coverage is 100% so parameters are well-defined. The description reinforces the use of origin/destination countries and HS codes, and adds guidance for the async parameter (avoid timeout). However, it does not add significant new 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 clearly states the tool analyzes non-tariff trade barriers (NTBs) across African corridors using specific data sources, with input of origin/destination countries and HS codes, and outputs barrier mapping with severity and mitigation strategies. This is specific and distinct from sibling tools like 'africa_trade_finance_esg_rater' or 'africa_trade_preference_arbitrage'.

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 context (target user: COO) and notes the async option for timeout avoidance, but lacks explicit guidance on when to use this tool versus alternatives like trade barrier or finance tools. It does not mention exclusions 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 already indicate readOnlyHint, idempotentHint, openWorldHint. Description adds that the tool uses external data sources and returns a rating with breakdown. Notably includes async guidance: 'Pass async:true to avoid timeout', which is behavioral context beyond annotations. No contradictions.

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

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

Four short sentences, each serving a distinct purpose: data sources and input, output format, use case, async guidance. No redundancy or filler. Front-loaded with key action (evaluate ESG compliance). Every sentence earns its place.

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

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

Given the tool's complexity (ESG rating using external data), the description adequately covers purpose, input, output, and async behavior. Output schema exists for details. No mention of error handling or rate limits, but not critical for a read-only tool with idempotency.

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 baseline is 3. Description adds meaning by clarifying async usage ('to avoid timeout') and specifying that institutionName expects 'Full name or identifier'. Provides context for year range implicitly by mentioning assessment year, but schema already defines range. Overall adds 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?

Description explicitly states 'evaluate ESG compliance of African trade finance providers' using specific data sources (World Bank WITS, CDP climate disclosure data) and outputs 'an ESG rating with breakdown across environmental, social, and governance dimensions'. This clearly distinguishes it from sibling tools like supplier_esg_audit or esg_audit_multi by specifying target (African trade finance) and data sources.

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?

States 'Ideal for due diligence on trade partners or portfolio risk assessment', providing clear context for use. Lacks explicit when-not-to-use or explicit alternatives among siblings, but the description confines it to African trade finance providers, implying exclusion of other sectors.

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, idempotentHint, and openWorldHint. The description adds value by noting the potential for x402 timeout and requiring async:true, which is a behavioral trait beyond what annotations provide. No contradictions 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 concise with three sentences: main purpose, details, and a usage note. It front-loads the key information and avoids redundancy. However, it could be slightly tighter.

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 complexity, full schema coverage, and presence of an output schema, the description adequately covers purpose, data sources, output type, and critical async requirement. It is sufficiently complete for an agent to understand the tool's role.

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 descriptions for all parameters. The tool description does not add further meaning to individual parameters beyond the schema, but this is acceptable given the baseline of 3 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 clearly states it analyzes AGOA and EBA trade preference arbitrage opportunities for COOs, using specific data sources and returning structured analysis. It distinguishes the tool's purpose well, though it does not explicitly differentiate from sibling tools like 'africa_trade_preference_optimizer' or 'agoa_eba_intelligence'.

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 the target user (COOs evaluating export strategies) and includes a critical usage note about passing async:true to avoid timeout. However, it does not provide explicit when-to-use or when-not-to-use guidance relative to 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 declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, indicating safe, read-only behavior. The description adds no new behavioral traits beyond stating it 'analyzes', which aligns with annotations but does not provide additional detail.

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 (approximately 70 words) and front-loaded with the primary purpose. Subsequent sentences add value with data sources and use cases without 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?

Given the tool's complexity (6 parameters, 3 required, with output schema), the description adequately covers purpose, inputs, and sources. It does not need to explain return values due to the presence of an output 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?

Schema coverage is 100% and parameter descriptions are already detailed. The description reinforces the role of HS codes but adds no new semantic 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 states the tool's purpose: analyze AGOA/EBA duty savings opportunities with HS code-level trade route optimization. It specifies inputs and outputs and distinguishes from sibling tools like africa_trade_barrier_breaker and africa_trade_preference_arbitrage by focusing on optimization and duty savings.

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 context for when to use the tool, such as 'export market evaluation, supply chain optimization, and trade agreement compliance analysis,' but does not explicitly mention when not to use it or compare with 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds value by detailing the tool's sources (AGOA.info, EU EBA, etc.) and the scope of data (39 AGOA countries, 47 LDCs). It does not contradict annotations and provides useful context about the tool's knowledge base.

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 paragraph that efficiently conveys the tool's purpose, capabilities, and differentiators. It is front-loaded but could be slightly more concise (3 sentences). All information is relevant and earns its place.

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

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

Given the tool's complexity (5 parameters, 4 modes, trade data from multiple sources), the description is fairly complete. It covers all modes, mentions data sources and country counts, and notes the tool's specialization. It lacks explicit guidance on mode selection, but the schema covers that. Overall, an agent can understand the tool's capabilities and context.

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% description coverage for all 5 parameters. The description does not add new meaning beyond what the schema provides; it only generally mentions the four modes. The parameter descriptions in the schema are already detailed (e.g., enum values, examples for hs_code and country_iso). Thus, the description adds minimal semantic 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 clearly states the tool's purpose (intelligence on AGOA/EBA/GSP preferential trade programs for Africa) and lists specific capabilities: checking country/product eligibility, identifying export opportunities, and providing compliance rules. It also distinguishes itself from siblings by specifying the geographic scope (Africa→US/EU) and the number of encoded countries (39 AGOA + 47 LDCs EBA).

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 explains what the tool does but does not explicitly state when to use it versus alternatives. While it mentions 'Différenciateur Africa diaspora' to hint at its focus, there is no guidance on when not to use it or which sibling tool to choose for related but different tasks (e.g., tariff_arbitrage_finder, africa_trade_preference_arbitrage).

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 and idempotentHint. Description adds critical async requirement and mentions potential x402 timeout, which is valuable behavioral context 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?

Three concise sentences plus keywords. Front-loaded with core purpose and target audience. Every sentence adds value without 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?

Has output schema to cover return values, description explains key inputs and async need. For a 6-param tool with 3 enums, it provides sufficient context 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?

With only 17% schema coverage, description lists key inputs (severity, AI system type, affected stakeholders) but does not detail all parameters like incident_type or incident_description. Adequate but not comprehensive.

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?

Clearly states it generates EU AI Act incident response playbooks with regulator notification templates for risk management teams. Distinct from sibling tools like ai_act_training_data_audit and incident_response_evidence_collector.

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 identifies use case: high-risk AI system breaches requiring formal EU notification. Also mandates async usage to avoid timeouts. Lacks explicit when-not-to-use or alternatives, but clear enough.

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, openWorldHint, and idempotentHint. The description adds context about using EUR-Lex and OECD sources but does not disclose additional behavioral traits such as rate limits or that it is a simulation, not an official determination.

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

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

Three sentences covering purpose, sources, and input/output. Efficient and front-loaded with key information, 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 tool's complexity and presence of an output schema, the description covers core aspects. It could mention that it is a simulation and not legally binding, but overall it is sufficient for an agent to understand the tool's role.

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 all parameters described. The description loosely maps inputs (systemDescription, intendedUse, riskLevel) but adds minimal new meaning beyond what the schema provides.

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 simulates EU AI Act regulatory sandbox submissions and provides structured feedback on compliance, risk levels, and documentation. It distinguishes itself from sibling tools like ai_act_incident_response and ai_act_training_data_audit by focusing on sandbox simulation.

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 legal teams and AI developers but does not explicitly state when to use this tool versus alternatives like ai_act_incident_response or ai_act_training_data_audit. No exclusions or when-not scenarios 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 already provide readOnlyHint, openWorldHint, idempotentHint. Description adds specifics: bias detection, regulatory risk assessment, and outputs (compliance score, bias metrics, warnings, references). Also mentions async behavior. No 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?

The description is concise with no wasted words, front-loaded with the main purpose, and structured as clear sentences covering inputs, outputs, and usage tip.

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 4 parameters, output schema exists, and complexity, the description covers essential context: inputs, outputs, use case, and async advice. No gaps for agent 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?

Schema coverage is 50%. Description explains dataset_id (Hugging Face ID or URL) and optional risk_threshold, but does not detail async or include_bias_metrics. Adds meaning beyond schema for dataset_id but not fully.

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 audits AI training datasets for EU AI Act compliance with bias detection and regulatory risk assessment, and distinguishes from sibling tools like ai_act_sandbox_simulator and ai_governance_full_report by focusing on training 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?

Provides context of use: 'Ideal for pre-deployment risk evaluation' and advises using async to avoid timeout. Does not explicitly state when not to use or list alternatives, but gives clear usage direction.

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` contradicts the description, which indicates the tool submits an async job and triggers computation, thus modifying state (creating a job and caching results). The description does not clarify this discrepancy, making it misleading for an agent.

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 front-loaded with the main purpose and provides essential details in a structured bullet list. While slightly verbose in French, it is well-organized and each sentence adds value. Could be slightly trimmed but efficient overall.

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 complexity (async, webhook, output schema exists), the description covers all necessary aspects: what it does, what it returns initially, how to get results, caching, and optional webhook integration. It explains the 7 output components without relying on output schema 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?

Schema coverage is 100%, so the baseline is 3. The description adds little meaning beyond the schema—it mentions required parameters but does not elaborate on format, constraints, or usage tips for any parameter. No extra semantic 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 clearly states the tool performs a full EU AI Act audit, classifies risk tiers, and produces 7 specific outputs. It distinguishes itself from the sibling tool `ai_governance_full_report_result` by being the async submission endpoint, and from `ai_governance_pilot` by being the full report.

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 poll with `ai_governance_full_report_result` or register a webhook via `webhooks_manage` for callbacks. Mentions cache duration (7 days) and provides a disclaimer. Offers clear when-to-use guidance compared to synchronous 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 show readOnlyHint, idempotentHint, destructiveHint. Description adds specific statuses (pending, completed, failed, not_found), expiration TTL (24h), and content of completed report, going well 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 sentences cover purpose, statuses, content, and usage hint. Front-loaded with purpose, no redundancy. Every part earns its place.

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

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

With output schema existing, description covers polling behavior, statuses, and hints. Schema coverage is 100% for the single parameter. Complete for a poll-result 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?

Only one parameter (job_id) with 100% schema coverage. Description adds the prefix 'aigfr_' for validation, adding 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 states it polls the result of an async job, distinguishing it from the async version and other tools. Verb 'Poll' is specific, and resource 'result of ai_governance_full_report_async' is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises calling after the eta_seconds hint from the async tool (~90s). Explains statuses and expiration (24h TTL). Lacks explicit '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 already provide readOnlyHint=true, indicating no side effects. The description adds that inputs are validated server-side and returns a deliverable, but does not disclose rate limits, authentication, or failure behaviors. It is consistent with annotations and adds some context, so a score of 3 is appropriate.

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 sentences) and front-loads the name, but the jargon and lack of structure reduce clarity. It is concise but not particularly informative.

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 presence of sibling tools and complex input schema with no output schema, the description is incomplete. It does not explain the output structure, how 'pilot' differs from 'full_report', or how to handle the async option. The agent lacks context to use 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 description coverage is only 20% (only 'async' parameter described). The description does not explain the complex nested parameters (company, aiUseCases, targetFrameworks) beyond a vague 'send the documented case fields'. The reference case provides a hint but not a clear mapping to input fields.

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 performs AI governance piloting and returns a structured, audited deliverable, with a specific reference case. The verb 'pilotage' and mention of 'RISK' indicate a risk-focused assessment, distinguishing it from full report tools. However, the exact nature of the output is not fully clear, and the jargon 'Gapup agent-payable C-suite expertise' may confuse 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 siblings like 'ai_governance_full_report_async' or 'ai_act_training_data_audit'. The description mentions 'reference case' but does not specify optimal scenarios or prerequisites. An agent would struggle to decide between governance tools based on this 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?

Annotations declare readOnlyHint=true, and the description confirms a read-only operation by stating it 'returns a structured, audited deliverable.' It also notes server-side validation, adding some behavioral context. However, it does not disclose the deliverable format, pagination, or any side effects, which would be desirable given no output schema.

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

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

The description is three sentences of moderate length, but the inclusion of a reference case (Buffer Inc) could be considered extraneous. It is front-loaded with the title line but lacks clear structure (e.g., bullet points or separate sections). Adequate but not exemplary.

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 complexity (5 parameters, 3 required, nested objects, no output schema), the description is insufficient. It does not explain the return format, result interpretation, or the meaning of the deliverable. Without an output schema, the description should cover these; it does not.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 20% (only 'async' and 'focus' have descriptions). The description adds no parameter-level details, only a vague instruction to 'send the documented case fields.' It fails to compensate for the missing schema descriptions of the three required parameters (company, signals, employees).

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 returns a structured deliverable for detecting at-risk employees ("détection des at-risk parmi 80 FTEs") and references a specific case. It distinguishes from siblings like 'churn_defender' by targeting C-suite retention. However, the French phrasing may reduce clarity for English agents, and the purpose could be more 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?

The description provides no guidance on when to use this tool versus alternatives. It only mentions server-side validation and to 'send the documented case fields,' which does not help the agent decide between this and sibling tools like 'talent_intelligence' or 'enps_auto'.

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, openWorldHint, idempotentHint, and destructiveHint false. Description adds valuable behavioral context: 24-hour cache, no API key required, data sources (public awards, redacted stats), and the note about private awards not being accessible. No contradictions.

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?

Description is well-structured with a concise overview, bulleted mode list, and clear notes on confidentiality and cache. Every sentence adds value, and the most important information is front-loaded.

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

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

Given the tool's complexity (6 parameters, 2 enums, output schema exists), the description covers purpose, modes, data sources, limitations, cache, and authentication comprehensively. It is complete enough for effective tool 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 coverage is 100%, so baseline is 3. Description adds examples for the 'query' parameter (e.g., 'Yukos', 'Russia') and explains the three 'mode' enum values in context. This provides incremental value over the schema descriptions, but the schema already describes parameters adequately.

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 tool provides 'commercial arbitration intelligence' with specific audience and coverage of 8 major institutions. It explicitly lists three distinct modes, making the purpose unambiguous and differentiated from sibling tools like legal_clause_extractor.

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?

Description explicitly states target users (litigation lawyers, M&A teams, etc.) and provides detailed instructions for each mode. It also notes the limitation that most awards are confidential and provides cache and authentication info, giving clear guidance on when and how to use the tool.

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=true. The description adds that it returns a structured, audited deliverable and that inputs are validated server-side, but provides no details on auth needs, rate limits, or side effects beyond what annotations imply.

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 verbose and unstructured, mixing French and English with bullet points in a single paragraph. It includes a reference case that is not essential, sacrificing conciseness for detail.

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 6 parameters with low coverage, the description fails to explain the return structure, pagination, or how to interpret the deliverable. It remains incomplete for a tool of this 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?

With only 17% schema description coverage, parameters like domain and focus are mentioned only indirectly via examples (e.g., 'domain appears in questions). Parameters exclusions, scope_cidrs, and async lack any explanation in the description, leaving the agent underinformed.

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 monitors attack surface for a domain, listing concrete questions it answers (e.g., assets with critical CVEs, email phishing risk). However, it lacks a succinct verb and does not differentiate from siblings like cyber_risk_auditor or vuln_exploitability_forecast.

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?

Examples of when to use the tool are provided (e.g., M&A due diligence, CISO report), but no explicit when-not or alternative tools are mentioned. The context implies security assessment but leaves exclusion unclear.

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 mark this as readOnly and openWorld. The description adds little beyond a reference case and server-side validation note. No disclosure of auth needs, rate limits, or behavioral 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 reasonably concise (~50 words) but contains jargon ('Gapup agent-payable C-suite expertise') that may confuse an agent. The structure is a single paragraph with no clear separation of purpose, usage, or examples.

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 complexity (6 params, nested objects, no output schema), the description is incomplete. It does not clarify the deliverable structure, required fields priority, or success criteria for the pre-flight audit.

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 low (17%), and the description does not explain any parameter semantics. It merely states 'send the documented case fields', relying entirely on the schema, which is insufficient given the six parameters with nested objects.

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 'Pré-audit comptable' and 'returns a structured, audited deliverable', giving a general sense of a pre-audit readiness check. However, it lacks a precise verb-resource statement and does not differentiate from hundreds of sibling tools, many of which could relate to audits or finance.

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 only usage hint is 'send the documented case fields', which is an instruction on input, not a selection criterion.

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, idempotentHint, and openWorldHint. The description adds valuable behavioral context: it uses external data sources (World Bank, ECB SDW) and provides specific negotiation levers. No contradictions 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 three concise sentences plus a keyword line. It is front-loaded with the purpose and clearly structured. The keyword line is slightly redundant but not detrimental.

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 read-only analysis tool with output schema, the description adequately covers inputs (fees, country), process (benchmarking), and output (recommendations). The async parameter is explained in the schema. No major gaps given the tool's nature.

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 detailed parameter descriptions. The tool description adds minimal extra meaning beyond the schema—it mentions input fees and bank country context but does not elaborate on syntax or constraints. 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 states the tool analyzes bank fee structures and provides negotiation recommendations. It specifies inputs (current fees, bank details) and outputs (benchmark comparisons, cost reduction levers). The CFO-focused positioning and keywords differentiate it from sibling tools like treasury_optimizer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when one has bank fees and wants to negotiate, and states it's ideal for treasury optimization. However, it does not explicitly mention when not to use this tool or suggest alternative tools for related tasks (e.g., broader treasury analysis).

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. Description adds that it is 'live', 'audited', and inputs are validated server-side, but these are minor additions. No destructive hints or further 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?

Description is short and front-loaded with the key term. However, the reference case adds length without essential clarity. Could be slightly more 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?

No output schema and the description only vaguely mentions a 'structured, audited deliverable'. For a tool with nested objects and 5 parameters, more detail on expected outputs and parameter relationships is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 20%. The tool description does not explain the parameters beyond 'send the documented case fields'. Required fields like 'ourOffer', 'competitor', 'dealContext' lack semantic guidance. Async is explained in schema but not in description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description states 'Fiche de combat live' (live battle card) and mentions returning a structured, audited deliverable for C-suite expertise. However, it does not differentiate from sibling tools like 'battle_plan', and the purpose could be more specific about the exact output.

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 such as 'battle_plan' or 'competitive_deep_dive'. The reference case is illustrative but does not set usage boundaries 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 indicate readOnlyHint and openWorldHint. The description adds that inputs are validated server-side and returns an audited deliverable, which is consistent and provides some behavioral context 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 (two sentences) and front-loaded with the tool's purpose. The second sentence adds context about reference and validation, but the overall structure is effective.

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 11 parameters, no output schema, and limited description, the tool definition lacks completeness. It does not describe the deliverable's format, success criteria, or how to interpret results, 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?

With 9% schema description coverage and 11 parameters, the description does not explain any parameter meanings. It only references 'documented case fields' without elaboration, failing to compensate for the schema's lack of descriptions.

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's function as a marketing battle plan that returns a structured deliverable, referencing a specific case. It distinguishes itself as a C-suite expertise tool, but does not explicitly differentiate from siblings like 'brand_builder' or 'marketing_roi_dashboard'.

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 reference case implies a scenario but does not mention alternatives among the many marketing-related sibling tools.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds that it uses HuggingFace's leaderboard and returns structured metrics and trends, providing useful context beyond annotations. No 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?

Three sentences, no wasted words, front-loaded with the primary action. 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?

Given the tool has 4 parameters with full schema coverage and an output schema, the description adequately covers purpose, inputs, and output nature. It is complete for an agent to understand and invoke 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%, so baseline is 3. The description says 'Accepts model identifiers or output samples' which maps to modelId and outputSamples, but adds little meaning beyond the schema descriptions.

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 tracks bias amplification in LLM outputs using fairness metrics from HuggingFace's model leaderboard. It specifies the target persona (risk assessment) and differentiates from siblings like hallucination_confidence_meter by focusing on demographic/gender/racial bias.

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 indicates it's designed for risk assessment personas and accepts model identifiers or output samples. While it doesn't explicitly exclude alternatives, the context is clear enough for an agent to decide when 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, openWorldHint, and idempotentHint, which the description supports. The description adds valuable behavioral context, such as analyzing against regulatory benchmarks and returning structured compliance insights with source references, but does not mention the optional async parameter or detailed output format.

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 three sentences long, front-loaded with purpose and role, and contains no unnecessary information. Each sentence adds value: target user, what it does, and when to use it.

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 presence of an output schema and full parameter coverage, the description provides sufficient context for an agent to understand the tool's functionality and decide on its use. It covers purpose, inputs, and outputs, but could be improved by noting the async behavior or filtering capabilities.

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 all parameters. The description does not add extra meaning beyond the schema (e.g., how parameters like issuerSector influence analysis), but it does not need to since the schema is complete. A score of 3 reflects the baseline expectation.

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's purpose: to assess bond covenant ESG compliance against BIS and ECB standards. It identifies specific risk areas (carbon emissions, governance, social impact) and distinguishes from similar siblings like 'bond_covenant_monitor' by focusing on ESG compliance.

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 positions the tool for CFOs and suggests use cases ('pre-issuance due diligence or ongoing monitoring'), but it does not provide explicit guidance on when not to use it or mention alternative tools. The usage context is implied rather than clearly defined.

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 beyond annotations by mentioning use of real-time data and output including compliance status, metrics, and SEC references. It aligns with readOnlyHint and idempotentHint. No contradictions.

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

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

The description is a single, well-structured paragraph that front-loads the core purpose. It includes keywords for searchability without being verbose.

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 output schema exists, the description sufficiently covers inputs, ratios analyzed, and intended use case. It does not discuss limitations or prerequisites, but the information is adequate for typical use.

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 explains the ticker and optional covenant thresholds (e.g., leverage and coverage ratios), adding meaning beyond the schema. The async parameter is not highlighted, but schema coverage is moderately high.

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 monitors bond covenant compliance by analyzing specific ratios (leverage and interest coverage) using real-time financial data. It distinguishes itself from sibling tools like 'bond_issuance_optimizer' by focusing on monitoring rather than optimization.

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 explicitly targets CFOs for proactive debt management and regulatory compliance, indicating when to use it. However, it does not specify when not to use or mention alternative tools, which could improve clarity.

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 state readOnlyHint and openWorldHint. The description adds that inputs are validated server-side and returns an audited deliverable, which is helpful but does not fully disclose behavior like execution time, async support (hinted by async param), or error handling.

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 (3 sentences) but the first sentence is redundant with the tool name. It front-loads a marketing phrase ('Gapup agent-payable C-suite expertise') but lacks clear structure. Could be more direct.

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 nested input objects and no output schema, the description fails to explain the returned deliverable structure or how to interpret results. Incomplete for the tool's 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?

With only 25% schema description coverage, the description should compensate but only says 'send the documented case fields' without explaining specific parameters. No additional semantics beyond the schema are provided.

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 it returns a 'structured, audited deliverable' and references Stripe Series A 2012, giving some sense of purpose. However, it does not clearly distinguish from sibling tools like 'ftg_business_plan' or specify the exact output format.

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 reference case is implicit but not actionable. No when-not-to-use or prerequisite information 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 provide readOnlyHint and openWorldHint. The description adds minimal context ('audited deliverable', 'inputs validated server-side') but does not disclose significant 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?

The description is concise but mixes French and English, and lacks structured formatting. It includes a helpful reference case 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?

Given the complexity (nested objects, 5 parameters, no output schema), the description is insufficient. It does not explain the return format, error handling, or provide usage examples.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 20%, and the description does not explain the parameters. It merely says 'send the documented case fields' without adding meaning to the nested objects (founder, brand, target, etc.).

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 is a brand architect tool for C-suite CMO expertise, returning a structured deliverable. However, it does not explicitly differentiate from sibling tools like 'positioning_strategist' or 'brand_equity_voice_share_calculator'.

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. It briefly mentions C-suite CMO expertise but lacks when-not-to-use or alternative references.

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, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful behavioral context: it mentions using Common Crawl and Wayback Machine, and warns about potential timeouts via the async hint. However, it does not detail rate limits, pagination, or whether results are cached, which would enhance transparency.

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

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

The description is three concise sentences: first defines the action, second lists inputs and outputs, third states use case and a tip. No fluff, every sentence adds value. Well-structured and front-loaded.

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

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

Given the tool's complexity (5 params, nested objects, output schema), the description covers main purpose, data sources, outputs, and a usage hint. However, it misses the include_forums parameter entirely. Since output schema exists, return values need not be explained, but the missing parameter is a notable gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 20% (only async and time_range have descriptions). The description lists three inputs (brand, competitors, time_range) but provides no additional meaning beyond their names. It omits the include_forums parameter entirely. While it partially compensates for the low coverage, it does not fully explain parameter formats or behaviors.

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 calculates brand equity voice share for CMOs, specifies data sources (500K+ articles from Common Crawl and Wayback Machine), and lists exact outputs (voice share percentage, sentiment distribution, top sources). This distinguishes it from siblings like brand_builder or competitive_deep_dive by focusing on voice share metrics.

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: 'Ideal for competitive benchmarking and brand visibility tracking.' It also gives a practical tip ('Pass async:true to avoid timeout'), but does not explicitly state when not to use this tool or mention alternatives, leaving room for ambiguity.

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 openWorldHint=true, indicating the tool is read-only and handles unknown inputs. The description adds behavioral context: it is an AI-powered CFO-level analysis, returns a structured deliverable, supports async execution, and validates inputs server-side. No contradictions 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 front-loaded with the main purpose but is verbose, containing multiple example questions and a reference case. Some sentences are list-like, and the overall length could be reduced without losing clarity. It earns its sentences, but not all are essential.

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 complexity (4 parameters, nested objects, no output schema), the description provides a good overview of capabilities and examples but lacks detail on return format (only 'structured, audited deliverable') and does not explain all parameters or their usage (e.g., focus, notes). It is adequate but not fully 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?

Schema coverage is low (25%), with 4 parameters: async, focus, entity, budgetContext. The description only hints at some fields (company, period, budget amounts) via examples but does not explicitly map them to parameters or explain their semantics beyond what the schema provides. This fails to compensate for the low 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 the tool performs budget variance analysis and provides a structured, audited deliverable. It gives example questions and a reference case, distinguishing it from siblings like margin_doctor_finance or financial_model_3statement by focusing specifically on budget vs. actual variance with narrative explanations, corrective actions, and forecasting scenarios.

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 outlines when to use the tool (for variance analysis, driver explanations, corrective actions, forecasting, board memos, quick wins) and mentions input validation. However, it does not explicitly state when not to use it or provide alternatives from the sibling list, so guidance on exclusions is absent.

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, idempotentHint, and destructiveHint. The description adds significant behavioral context beyond these: 'All processing is local -- no external API calls, instant response, privacy-preserving' and 'Diversity signals are first-name proxies ONLY with mandatory ethical WARNING.' These details disclose important operational 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 lengthy paragraph (around 150 words). While it front-loads the purpose, it could be more concise and better structured (e.g., bullet points for criteria and output). It is not overly verbose but lacks the brevity that would earn a higher score.

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 complexity (5 parameters, nested objects, output schema), the description is comprehensive. It explains the output format (overall score, matched/missing skills, red flags, etc.) and covers key behavioral aspects (privacy, local processing). The presence of an output schema reduces the need to describe return values in detail, but the description still provides sufficient context.

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 input schema already documents all parameters. The description summarizes the scoring criteria but does not add new meaning beyond what the schema provides. The narrative helps contextualize, but the baseline of 3 is appropriate given 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 starts by clearly stating the tool's purpose: 'AI-powered candidate screening and ranking for recruiters...' It specifies the verbs (screening, ranking) and resources (job description, candidate resumes). The detailed breakdown of criteria and output distinguishes it from sibling tools like 'talent_intelligence', which likely focuses on different aspects.

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 explains when to use the tool (for screening and ranking candidates with a job description) and outlines the criteria used. However, it does not explicitly state when not to use it or mention alternative tools. The context of many diverse sibling tools implies its specific use case, but explicit guidance would improve clarity.

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 and openWorldHint, establishing safe read-only behavior. The description adds that the tool returns an 'audited deliverable' with server-side input validation. This is consistent and adds some context beyond annotations, but does not significantly expand behavioral disclosure.

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

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

The description is relatively brief but uses mixed languages and jargon (e.g., 'Gapup agent-payable C-suite expertise'). It is front-loaded with the tool's purpose but lacks clear structure. Some sentences are fragmented.

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 complexity (7 parameters, nested objects, no output schema), the description is highly incomplete. It does not explain the return format, how to use the async parameter, or the expected structure of 'documented case fields.' The agent would likely need additional information to invoke this 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 description coverage is only 14%, and the description adds no information about individual parameters. It merely says to 'send the documented case fields,' leaving the agent to infer the meaning of all 7 parameters from the schema alone, which is insufficient.

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 is for capacity planning, targeting CHRO/senior management, and returns a structured deliverable. The reference case provides concrete context. However, it does not explicitly differentiate from a large set of sibling tools, but the topic is specific enough.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives. No prerequisites, exclusions, or comparisons to siblings are provided. The description assumes the agent knows the tool's role.

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 the tool is non-destructive and may use external data. The description adds 'server-side validation' and 'audited deliverable', but does not disclose costs, rate limits, 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 relatively short but includes extraneous details like the reference case. It is front-loaded with the purpose, but the mixed French/English and jargon reduce 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 the complex nested input schema and no output schema, the description fails to explain the deliverable format or how to interpret results. The agent lacks information about what the tool returns, which is critical for a tool that produces a structured report.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 20% (only the async parameter described). The description says 'send the documented case fields' but does not elaborate on the meaning of the nested object properties, leaving the agent to infer from names alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description indicates the tool provides a financing strategy and returns a structured deliverable, but it is vague about the exact action and output. It mentions a reference case but does not clearly differentiate from siblings like cap_table_strategist or deal_structurer.

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 lacks explicit guidance on when to use this tool versus alternatives. The reference case implies SaaS context but no when-not-to-use or exclusion criteria 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 (readOnlyHint=true, openWorldHint=true) already cover safety and external data use. Description adds server-side validation and reference case, but does not contradict annotations. No further behavioral details.

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

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

Three sentences, front-loaded with purpose. The reference case example adds value but could be shortened. Generally 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 tool has complex nested parameters (company, currentCapTable, plannedRounds) and no output schema. The description lacks detail on return format, expected results, or how to interpret the deliverable. Insufficient for effective use.

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 low (17%). The description does not add meaning to parameters beyond the schema; it only refers to 'documented case fields' without elaboration.

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 tool is a cap table strategist for fundraising, returning a structured deliverable. However, it does not differentiate from sibling tools like capital_strategy or ma_deal_screener.

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 vs alternatives. Only mentions server-side validation of inputs, but lacks context on prerequisites or exclusion 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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds accuracy and output details but fails to mention the async parameter behavior or any potential rate limits or computational delays. This gap reduces transparency.

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

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

The description is front-loaded with the main purpose but includes unnecessary fluff (e.g., 'Delivered by Émilie, the AI Sustainability lead'). While informative, it could be more concise by removing extraneous details.

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 complex tool with 8 parameters and nested objects, the description covers the return values (emissions breakdown, reduction levers, etc.) but omits details on input parameters and the async workflow. With an output schema, return value explanation is acceptable, but input guidance 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?

Schema description coverage is only 13%, meaning most parameters lack descriptions. The description only vaguely mentions 'company profile and its activity data' without detailing parameters like scope1Sources, scope3Activities, reductionTargets, or the async flag. It does not adequately compensate for the low 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?

Description clearly states it calculates a company's GHG footprint under GHG Protocol with specific accuracy and return details. It distinguishes itself from sibling tools like carbon_roadmap by specifying scope 1+2+3 and CSRD focus.

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 lists when to use: for CSRD compliance, green-finance, supplier ESG scorecards. However, it does not mention when not to use or provide specific alternatives, though the 'when to use' 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 already declare readOnlyHint=true, so the description adds value by noting inputs are validated server-side. However, it does not disclose behavioral traits like response time, pagination, or potential errors. The deliverable content is also left vague.

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, but it is not front-loaded with critical information. It starts with a French title-like phrase, then says 'Returns a structured, audited deliverable'. The reference case and validation note are helpful but could be positioned better.

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 is complex with 8 parameters including nested objects, and no output schema exists. The description does not explain the output format, how parameters interact, or what constitutes a successful result. It is insufficient for the tool's 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?

Parameter schema coverage is only 13%, meaning most parameters lack descriptions. The description says 'send the documented case fields' without explaining any parameters. This fails to compensate for the low schema coverage, leaving the agent without guidance on what inputs are needed.

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 it 'returns a structured, audited deliverable' for a carbon roadmap, which is somewhat clear. However, it does not distinguish from sibling tools like 'carbon_footprint_calculator' or 'sustainability_report'. The verb 'returns' is passive and lacks an action-oriented verb.

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. There are no when-to-use or when-not-to-use statements, nor any exclusions or prerequisites. The description is purely about what the tool does without usage context.

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

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

The annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds that inputs are validated server-side and the tool returns a 'structured, audited deliverable'. This provides some behavioral context beyond what annotations offer, but it does not detail any potential side effects or dependencies (e.g., rate limits, required permissions). 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 relatively concise but includes a specific reference case (Spendesk × Decathlon) that, while illustrative, adds length without being essential for understanding the tool's core function. The main purpose is front-loaded, but the reference case could be moved to a separate example field.

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 complexity (nested objects, 4 parameters, no output schema, low schema coverage), the description does not sufficiently explain the input structure or output format. It promises a 'structured, audited deliverable' but does not specify its shape or contents. The openWorldHint annotation suggests external context may be required, but the description provides little to fill that gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 25% schema description coverage, the description fails to explain the purpose of key parameters like 'deal', 'knownContacts', and 'sellerContext'. It merely says 'send the documented case fields' without elaborating on the fields themselves. The async parameter is documented in the schema, but the description adds no parameter-level insight.

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 is for 'Cartographie du champion' (champion mapping) in the context of C-suite sales expertise. It mentions returning a structured, audited deliverable and provides a specific reference case (Spendesk × Decathlon) that illustrates its output. However, it could be more explicit about what 'champion mapping' entails and how it differs from other sales tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives. It instructs to 'send the documented case fields' but does not indicate prerequisites or scenarios where champion mapping is appropriate compared to sibling tools like 'deal_coach' or 'competitive_deep_dive'.

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 provide readOnlyHint, idempotentHint, and openWorldHint. The description adds meaningful context: it explains it uses GitHub PR metadata and Snyk vulnerability data, and outputs structured categories with confidence scores. It does not contradict 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?

Three sentences, no fluff. Purpose is front-loaded, methodology and inputs follow. 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?

Given the complexity (5 params, low schema coverage) and presence of an output schema, the description covers the main intent and key inputs. It could mention the async parameter and explain snyk_org_id/time_range_days for full completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 20%. The description mentions pr_url and incident_id as inputs but does not explain snyk_org_id or time_range_days. It adds some meaning beyond the schema by linking pr_url to GitHub metadata, but fails to cover all parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific purpose: classifying root causes of change failures for CTO-level incident analysis. It distinguishes from siblings by focusing on change failure root cause, different from general vulnerability scanning tools like cve_security_lookup or dependency_vulnerability_scan.

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 says 'Ideal for post-mortem analysis and change risk assessment,' providing clear usage context. It does not explicitly exclude other uses or name alternatives, but the context is sufficient for an agent to infer when 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 declare readOnlyHint=true and destructiveHint=false, which the description supports by stating it fetches live data. The description adds key behavioral details: proxy dependency for some platforms, data freshness (30-day sales, 12-month price history), and data quality notes (live vs curated fallback). No contradictions.

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?

Well-organized with bullet lists for modes and input formats. Some redundancy (platform list repeated in description and schema), but every sentence adds useful context. Could be slightly more concise by avoiding repetition of platform names, but still efficient for the complexity.

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 complexity (5 modes, 6 platforms, proxy requirements, multiple input formats), the description covers all critical aspects: use cases, mode descriptions, data sources, input syntax, and limitations. Output schema exists, so return values are not needed. Complete for an agent to select and invoke 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 covers all 5 parameters with descriptions. The description adds substantial value beyond schema: explains input formats for seller_profile and price_history, describes mode-specific outputs (e.g., 'returns title ZH/EN, price CNY + USD estimate'), and clarifies platform defaults. Schema coverage is 100%, but the description enriches meaning significantly.

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?

Clearly states it provides Chinese e-commerce intelligence, listing specific use cases (ZH diaspora, import-export, brand enforcement, etc.) and five distinct modes with descriptions. The verb 'covers' and detailed platform list make the purpose very clear, differentiating it from general market data 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?

Provides explicit guidance on when to use each mode and includes critical constraints: proxy requirement for domestic platforms, fallback without proxy, and input format examples. However, it does not explicitly differentiate from sibling tools like 'china_market_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?

Despite annotations already marking readOnlyHint=true, the description adds critical behavioral details: proxy requirement (AICI_RESEARCH_PROXY_URL), async mode (job_id return), and data source limitations (Eastmoney/CSRC/SSE blocked from datacenter IPs). This fully informs the agent of operational 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 well-structured with bullet points for modes and input formats, and is front-loaded with the purpose. However, its length (multiple paragraphs) could be trimmed for efficiency—every sentence is useful, but overall detail is high.

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 complexity (4 modes, multiple input formats, proxy dependencies, async option), the description covers all necessary context: data sources, limitations, required environment variable, and job polling. The existence of an output schema means return values need not be detailed.

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% description coverage, but the description enriches parameter meaning by detailing field contents for each mode (e.g., company profile includes USCC, SOE flag; market includes P/E ratio). This adds value beyond the schema's short descriptions.

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 'Chinese capital market intelligence' and enumerates specific assets (A-Shares, H-Shares, ADRs) and four concrete modes (company, market_quote, sector_overview, regulatory_filing). This provides a specific verb+resource+scope, distinguishing it from generic data tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies that this tool should be used for Chinese market data queries, but does not explicitly state when to use it over sibling tools like india_market_data. It provides context about data sources and proxy requirements, but no comparative guidance 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 already declare readOnlyHint and openWorldHint. The description adds minimal behavioral context mentioning server-side validation and a structured deliverable, but does not elaborate on side effects, authorization needs, or cost implications.

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 but lacks clear structure; it combines purpose, a reference case, and input instruction in a single sentence. While concise, it could be better 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?

Given the complexity of the tool (nested objects, no output schema), the description is incomplete. It does not explain the return format, how to interpret the deliverable, or supply enough context for correct use.

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 only 20% schema description coverage, the description should compensate by explaining key parameters. Instead, it only references 'documented case fields' without detailing them, adding 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 the tool is for churn analysis/anti-churn via the title and reference case. However, it lacks explicit differentiation from similar sibling tools like 'renewal_optimizer', and the verb is implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool vs. alternatives, nor any exclusion criteria. It only instructs to send documented case fields, leaving the agent without context for appropriate invocation.

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 behavioral details: cached 7 days, SLA ≤20s, data sources (Open-Meteo CMIP6, IPCC AR6 Atlas, NOAA SLR), and output types (multi-scenario comparison, probability, business impact signals). No 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?

The description is a single paragraph but well-structured with purpose first, then details on scenarios, metrics, outputs, sources, and use cases. It is information-dense without being overly verbose.

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 complexity (6 parameters, nested objects, existing output schema), the description covers all essential aspects: scenarios, horizons, metrics, location, output types, sources, use cases, caching, and SLA. No gaps identified.

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 description adds meaning: default metrics ('all' implied), location format clarification ({city, country?} or {lat, lon}), and scenario 'all' generates multi-scenario comparison. These details go 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 explicitly states it provides long-term climate projections by IPCC scenario for any location, listing scenarios, metrics, outputs, and use cases. It clearly distinguishes from other climate tools by focusing on scenario-based projections.

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 specifies use cases (TCFD/CSRD physical risk, due diligence, insurance, infrastructure planning) and technical limits (cache 7 days, SLA ≤20s). It does not explicitly mention when not to use or alternative tools, but the 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 already declare readOnlyHint=true and openWorldHint=true. The description adds that it returns a structured, audited deliverable and that inputs are validated server-side, which is useful. However, it does not disclose other behavioral traits such as rate limits, authentication needs, or how async polling works (though the async parameter is described in input schema).

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

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

The description is verbose and includes many repetitive example questions. It lacks a clear structure, mixing French and English. The reference case is helpful but could be integrated better. Every sentence should earn its place; several sentences could be condensed.

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 complexity (8 params, 4 required, no output schema), the description is incomplete. It does not describe the output format in detail, nor does it explain all parameters. The reference case gives a partial example but does not cover all use cases. Additional context about evidence sources or limitations would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 13%, so the description should compensate. The description implies the meaning of 'topic' and 'evidence_focus' through the example questions, but it does not systematically explain all 8 parameters. For instance, 'max_studies' and 'date_range_years' are not mentioned, and there is no mapping between parameters and the reference case.

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 returns a structured, audited deliverable for clinical evidence briefs, covering GRADE ratings, key trials, safety signals, etc. It provides several example questions that illustrate its purpose. However, it does not explicitly differentiate from sibling tools like clinical_pharma_intel, but the purpose is specific enough.

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 lists example queries that indicate when to use the tool, but it does not provide guidance on when not to use it or mention alternative tools. There is no explicit context for selection among siblings, which is important given the large sibling set.

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 goes beyond annotations by detailing data sources (ClinicalTrials.gov, EU CTR, OpenFDA, FAERS), cache durations, SLA (≤16s p95), signal detection logic (P0/P1/P2), and the optional OPENFDA_API_KEY effect. No contradiction with annotations (readOnlyHint=true).

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 lengthy but well-organized with sections, bullet points, and clear terminology. Information is front-loaded with the purpose. A few sentences could be trimmed (e.g., listing all siblings), but it remains efficient for the complexity.

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 complexity (5 modes, signal detection, SLA, caching, optional API key) and the presence of an output schema, the description is complete. It covers data sources, performance, filtering options, and result interpretation without needing additional context.

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, each parameter already has a description. The tool description adds nuances like mode-specific applicability and signal detection, but does not significantly enhance parameter understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides clinical and pharmaceutical intelligence with five distinct modes (trials, pipeline, approvals, recalls, adverse_events), specifying the target users (biotech analysts, hedge funds, etc.) and differentiating from sibling tools by domain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.