Fodda Brand Intelligence

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is covered. The description adds substantial behavioral context beyond annotations: it explains that the tool searches all knowledge graphs, returns a rich list of specific report components, includes external supplemental signals, and mentions a cost of $30 per report. It does not contradict any annotations and provides value about the aggregation scope and output, though it could disclose more about failure modes or result limits.

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

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

The description is a single paragraph, front-loaded with the core purpose and then enumerating return components and use cases. It is slightly longer than necessary due to the detailed list of outputs and the example queries, but every sentence adds value (purpose, returns, usage, cost). It is structured clearly, though a more compact phrasing would earn a 5.

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 high complexity (aggregating multiple graphs and signals) and the absence of an output schema, the description does a good job of explaining what the report contains, when to use it, and its cost. It does not explicitly address edge cases like brand not found or how to interpret the evidence timeline, but the provided information is sufficient for an agent to decide whether to invoke the tool and roughly what to expect.

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

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

Schema description coverage is 100%, so all five parameters are already documented with descriptions in the schema. The tool description itself does not add much parameter-specific detail; it only alludes to the default scope via 'searching ALL knowledge graphs' (matching graph_ids) and gives a brand_name example. Since the schema does the heavy lifting, a baseline of 3 is appropriate.

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

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

The description clearly states a specific action ('Build a complete Brand Intelligence Profile') with a distinct resource ('searching ALL knowledge graphs for a specific brand') and explicitly enumerates the return components (trend footprint, competitive landscape, etc.). It also differentiates itself from sibling tools by emphasizing it aggregates intelligence that would otherwise require many separate searches, making it unique among search_graph and get_evidence.

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 says 'Use when the query is about a specific company or brand' and gives three concrete example queries, which provides clear context for when to invoke this tool. It does not explicitly name alternative tools or exclusion criteria, but the examples and scope (all knowledge graphs) imply when this is preferable over a general graph search, so it earns a strong score but not a top 5.

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 idempotent, read-only, non-destructive. Description adds key polling behavior: recommended frequency and termination conditions (COMPLETE/FAILED), which goes beyond the annotation's coverage.

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

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

Two concise sentences: first states purpose and after-call dependency, second gives polling instructions. No redundancy, optimally 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 simplicity (1 param, no output schema), the description covers all needed aspects: purpose, when to use, polling pattern, and expected status values. No gaps.

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

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

Schema has 100% coverage for the single parameter 'job_id' with a clear description. The tool description does not add additional parameter semantics beyond confirming it's the ID from get_supplemental_context. Baseline score applies.

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

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

Description clearly states the tool checks if market data gathering is complete and retrieves results. It specifies the verb 'check', the resource 'supplemental status', and provides context that it should be called after get_supplemental_context, distinguishing it from siblings.

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 when to use (after get_supplemental_context) and how to poll (every 5-10 seconds until COMPLETE or FAILED). Provides clear usage instructions with no 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 already declare readOnlyHint=true and destructiveHint=false, indicating safety. The description adds that the tool returns a branded SVG that renders in chat, providing useful behavioral context beyond the annotations.

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

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

The description is concise with three sentences: purpose, chart types with brief explanations, and return format. 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?

Given no output schema, the description covers return type (SVG). It details all chart types and data structures. Missing error handling or validation, but acceptable for two-parameter tool.

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

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

Schema coverage is 100%, but the description adds significant value by detailing the JSON structure for each chart_type in the 'data' parameter, which is not fully specified in the schema description.

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

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

The description clearly states the tool creates presentation-ready data visualizations from research findings, with specific verb ('Create') and resource ('visualization'). It lists six distinct chart types, which differentiates it from sibling tools like 'brand_tracker' or 'get_capabilities'.

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

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

The description implies usage for generating visualizations of research data, and the list of chart types guides selection. It does not explicitly state when not to use or name alternatives, but the context is clear enough for an agent to decide.

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, idempotentHint, and destructiveHint. The description adds that it returns capabilities and pricing, which is helpful but does not disclose additional behavioral traits beyond the annotations.

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

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

Two clear sentences that front-load the purpose and usage. No wasted words, but 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?

Given the tool's simplicity (1 optional param, no output schema, rich annotations), the description adequately covers what the tool returns and when to use it. Could mention the return structure, but not essential.

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

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

Schema coverage is 100% and the parameter is simply described as 'Optional user identifier' in the schema. The description does not add meaning beyond the schema; baseline 3 is appropriate.

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

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

The description clearly states it returns capabilities/features/pricing, and explicitly says to call it for any question about what Fodda can do, distinguishing from siblings like brand_tracker or generate_visual.

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 says 'Call this for any question about what Fodda can do or what's available,' providing clear usage context. No explicit when-not-to-use, but the guidance is strong.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the $0.50 cost per lookup, the item fields (URL, location, brand names, date, category, formatted citation), and the direct-lookup-by-ID behavior. It does not over-explain beyond what annotations already provide.

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 focused sentences, front-loaded with the core purpose. It efficiently conveys what the tool returns, when to use it, and the cost — every sentence earns its place with no fluff.

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 a well-covered schema and annotations, the description fills the remaining gaps: it clarifies the relationship with search_graph, the output item composition, and the price. For a read-only lookup tool, this is complete enough 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?

The input schema covers 100% of parameters with thorough descriptions, including explicit warnings for for_node_id (e.g., 'Node IDs are NOT sequential integers'). The description's phrase 'direct lookup by trend ID' reinforces the for_node_id semantics, but it doesn't add significant parameter-level detail beyond the schema, so the baseline of 3 applies.

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

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

The description opens with a specific verb+resource: 'Get the source articles, case studies, and statistics behind a specific trend.' It also explicitly distinguishes itself from text search ('not a text search tool') and references the workflow with search_graph, which sets it apart from sibling 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?

It gives explicit when-to-use guidance: 'Use after search_graph when you need the supporting proof behind a trend.' It also excludes the alternative of using it as a text search tool, clearly defining the boundaries.

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, idempotentHint, and destructiveHint as safe. The description adds valuable behavioral context: the 'Trend' label returns a 'full deterministic list' and contrasts with partial search results, enhancing the agent's understanding.

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 (two sentences plus a tip) and well-structured: first sentence states purpose, second gives examples, third provides a specific use case. No wasted words.

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

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

Given no output schema and simple parameters, the description covers purpose, usage, and a special case. It could mention pagination or limits but is sufficient for the tool's simplicity.

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 adds meaning beyond schema by listing example label values and explaining the 'Trend' label behavior, providing contextual enrichment.

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

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

The description uses specific verbs ('list') and resources ('brands, locations, technologies, audiences, or trends within a specific knowledge graph') and provides concrete examples, clearly distinguishing the tool from siblings like search_graph.

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 states when to use the tool (exploring graph contents) and gives a specific scenario for the 'Trend' label, including a hint about search returning partial results. It lacks explicit alternatives but provides clear 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?

Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context beyond annotations by stating 'Returns live data — not cached from session start', which clarifies data freshness. 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?

Three concise sentences: first states what the tool does and what it returns, second gives usage examples, third adds a behavioral note. Every sentence earns its place with no redundant or filler content.

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 parameterless, read-only tool with good annotations, the description covers all essential aspects: purpose, usage triggers, behavioral characteristic (live data). No missing elements given the simplicity of the tool.

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

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

The tool has zero parameters, so schema coverage is trivially 100%. Per guidelines, baseline is 4 when there are no parameters. The description does not need to add parameter information and correctly focuses on the tool's purpose.

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

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

The description uses the verb 'Check' with a specific resource ('current user's account status'), enumerates exact fields (API call balance, plan, graphs, profile info), and naturally distinguishes from all listed sibling tools which serve different purposes (e.g., get_capabilities, check_supplemental_status).

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 explicit example queries ('how many API calls do I have?', 'what plan am I on?') that clearly indicate when to use this tool. It does not explicitly mention when not to use it or suggest alternatives, but the context is well-defined and sufficient given that sibling tools have clearly distinct purposes.

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 and idempotentHint; description adds context about returning 'curated editorial connections' and dependency on prior search, without contradiction.

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

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

Concise, front-loaded with purpose, each sentence adds value with no redundancy.

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

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

Covers prerequisite, usage context, and parameter semantics; lacks return format details, but tool is read-only and output schema is absent, so adequate.

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%; description adds critical context for seed_node_ids (must be actual IDs, not guesses), lists relationship_types, and notes defaults for depth/limit, exceeding baseline.

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

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

Description uses specific verbs ('Discover what's connected') and explicitly contrasts with search_graph ('search alone wouldn't surface'), clearly distinguishing this tool from siblings.

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 when to use ('after search_graph') and prerequisite ('Requires node_id from a prior search_graph result'). Lacks explicit 'when not to use', but guidance 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 indicate read-only, non-destructive. Description adds context on output (lifecycle stage, signal strength, geographic scope) and prerequisite (node_id from search_graph), which is useful beyond annotations.

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

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

Two concise sentences, front-loaded with purpose. Each 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?

Given schema coverage, annotations, and sibling tools, the description fully informs the agent about prerequisites, usage context, and expected output. No gaps.

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

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

Schema coverage is 100%, baseline 3. Description adds important constraints on nodeId (must come from search_graph, not guess or invent), which is not in schema description. This enhances agent 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 retrieves the full profile of a specific trend, including list of attributes. It differentiates from search_graph by specifying it provides deeper detail on a single trend.

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 says to use when deeper detail is needed after search_graph summary, and requires node_id from prior search_graph. This provides clear when-to-use and 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?

Beyond annotations (read-only, open-world), the description discloses parallel fan-out across sources, return format (categorized blocks with source attribution/metadata), pricing ($10 per query), and workflow dependency on search_graph. This adds substantial behavioral context that aids agent decision-making.

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 efficient, front-loaded with core purpose, and includes important notes on pricing and workflow. There's minor redundancy in repeating the 'thin/empty coverage' trigger, but overall 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?

With no output schema, the description adequately covers return format (categorized blocks with source attribution/metadata), source variety, pricing, and workflow integration. It doesn't address potential rate limits or error scenarios, but given the annotations and schema richness, it's sufficiently complete 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?

Schema description coverage is 100%, so the schema already explains all parameters. The description itself adds minimal parameter-level detail beyond the schema (e.g., examples or domain handling are already in schema descriptions). Baseline 3 is appropriate since the description doesn't significantly enhance 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 a specific action and resource: retrieving supplemental market data from 80+ authoritative sources. It distinguishes itself from siblings by positioning as a 'standard layer' and explicitly relating to search_graph, making its unique role evident.

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 when-to-use conditions ('curated coverage is thin, empty, or when the query is explicitly demand/attention-shaped') and references search_graph's coverage annotation. It lacks explicit when-not-to-use or named alternatives, but the context is clear and actionable.

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, idempotentHint, and destructiveHint false. The description adds context about access control ('the user can access') and details what is returned (IDs, descriptions, authors, sectors, signal counts, topic coverage), going beyond the bare safety profile. It does not mention edge cases like empty results, but the annotations lower the bar.

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 two sentences with no filler. The first sentence states the action and output contents; the second gives usage timing and downstream value. Every sentence earns its place and the structure is optimally front-loaded.

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

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

For a simple list tool with no output schema, the description fully covers purpose, usage context, and return metadata. It also clarifies the relationship to other tools via graphId, making it a complete entry point for a session.

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 only parameter userId has a clear description. The tool description doesn't add extra parameter-level detail, but it is consistent with 'user can access' and the schema already covers semantics, so baseline 3 is appropriate.

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

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

The description uses a specific verb 'List' with a clear resource ('expert knowledge graphs') and scope ('the user can access'). It distinguishes itself from sibling tools like search_graph by positioning as a discovery step before searching, with explicit mention of returning graphId parameters for other 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 gives explicit usage timing: 'Use FIRST in any session to discover available sources before searching.' It also explains downstream utility ('needed for graphId parameters in other tools'), making it clear when this tool should be invoked relative to 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, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds 'clean text' and 'structured text' as output details, but does not disclose edge cases like non-HTML handling, URL accessibility, or authentication requirements. No contradiction with annotations, but the description does not go far beyond them.

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, each carrying distinct value: the core action, the intended use case, the return format, and the price. There is no redundant or filler wording, and the main verb 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?

For a simple URL-to-text tool, the description covers what it does, when to use it, and what to expect back ('structured text ready for analysis'). With strong annotations (read-only, idempotent, open-world) and no output schema, this is adequately complete. The price point is an extra useful detail.

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%: both url and userId have descriptions. The description adds 'any URL' and 'structured text' context but does not explain userId beyond the schema. Baseline 3 is appropriate when the schema handles parameter documentation well.

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 'Extract clean text content from any URL' with a specific verb and resource. It also says 'Returns structured text ready for analysis', which clarifies the output. This distinguishes it from sibling tools that focus on graph operations or searches.

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 says 'Use this when a user shares a link (competitor site, news article, client brief, trend report) and wants to cross-reference it against Fodda knowledge graphs.' This provides clear context. It does not mention alternatives or exclusions, but none of the sibling tools serve the same URL-reading purpose, so this is sufficient.

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 destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it returns cited evidence, source attribution, lifecycle stage, not generic web summaries, searches all accessible graphs in parallel by default, and costs $20 per query. This goes beyond annotations but could still include rate limits or error behavior for a 5.

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 five sentences long and packs useful details: scope, output, default behavior, use cases, and price. It is front-loaded with the core purpose and every sentence contributes, though it is slightly verbose compared to simpler tools. Still well-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?

For a read-only search tool with a rich 100%-covered schema and clear annotations, the description is complete: it explains purpose, output format, default parallel search, cost, and use cases. No output schema exists, but the description sufficiently covers return values (trend data with evidence and lifecycle stage).

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

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

Input schema has 100% coverage with detailed descriptions for all 8 parameters. The description adds minimal parameter-specific value, only reinforcing that omitting graphId searches all accessible graphs and providing a few graphId examples. Since the schema already does the heavy lifting, a 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 finds trends, signals, and expert insights across 100+ curated knowledge graphs, specifying both the verb and the resource. It distinguishes itself from generic web search by emphasizing curated, cited evidence and lifecycle stages, which separates it from sibling tools like get_node or list_graphs.

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 use cases (market trends, competitor analysis, innovation signals, consumer behavior, cultural shifts) and recommends the default behavior when graphId is omitted. However, it does not explicitly mention when not to use this tool or reference alternative sibling tools, so it stops short of a 5.

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