Fodda Deep Research

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, making the tool safe to poll. The description adds essential behavioral context: polling every 10 seconds until COMPLETE or FAILED, which justifies repeated calls.

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

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

Two concise sentences front-loaded with purpose and crucial usage instructions. Every 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?

For a simple polling tool with one parameter and no output schema, the description sufficiently covers invocation, polling strategy, and termination conditions. Minor omission: does not mention possible error handling or retry logic, but overall complete for the task.

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 full schema description coverage (100%). The description adds no new semantic value beyond what the schema already provides ('The Job ID returned by deep_research_topic'). Baseline score 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?

Description explicitly states the tool checks if deep research is complete and retrieves the report. It uses a clear verb ('Check') and resource ('deep research status'), and distinguishes itself by referencing the initiating tool and polling behavior.

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?

Clearly states when to use (after deep_research_topic) and provides polling frequency and termination conditions. Does not explicitly mention alternatives (like check_supplemental_status), but the guidance is sufficient for correct usage.

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

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

Annotations already show readOnlyHint and idempotentHint. Description adds polling behavior and expected statuses. No contradictions, but could mention behavior after completion 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?

Extremely concise: one purpose sentence plus clear usage directive. No redundant wording.

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 polling tool with one parameter and no output schema, the description covers key aspects: purpose, trigger, polling cycle, and end states. Could mention result format but not critical.

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 job_id description linking to get_supplemental_context. Description reiterates that but adds no new parameter details. Baseline of 3 appropriate.

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

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

States specific action ('check if market data gathering is complete and retrieve the results') and distinct resource (supplemental context). Context of use after get_supplemental_context differentiates from siblings like check_research_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?

Explicitly instructs when to call ('after get_supplemental_context'), how to use (poll every 5-10 seconds), and termination conditions (COMPLETE or FAILED).

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 autonomous behavior, pricing ($55/$100), automatic inclusion of earnings-call and macro data, and the requirement to avoid separate supplemental calls. This goes well beyond the annotations, which only mark it as read-only and open-world; no contradiction with readOnlyHint since launching research is not a write operation.

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 longer than ideal but front-loaded with the core purpose; every sentence adds information about usage, pricing, or integration. The pricing and 'no separate calls' note are necessary for correct invocation.

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 the research scope, output style, and cost, but omits whether the tool is asynchronous and how to retrieve results (no mention of a session ID or polling via check_research_status). Since there's no output schema and a sibling status-check tool exists, this is a meaningful 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 already covers all parameters, but the description adds critical guidance: query should be a short 5–15 word phrase and sub_themes should carry detail, and it maps mode/depth to pricing. This adds value beyond the schema definitions.

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 and resource: 'Launch an autonomous Deep Research session' combining graph and web research. It clearly distinguishes from sibling tools like check_research_status and search_graph by emphasizing autonomous multi-graph synthesis.

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: 'complex, multi-faceted questions that need both curated expert intelligence AND current web context,' with concrete examples. It also provides an exclusion: 'You do not need to call the earnings or supplemental tools separately before or after.'

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, destructiveHint. Description adds return format (branded SVG) and that it renders inline, which is helpful extra behavioral context. 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?

Concise, front-loaded purpose, enumerates chart types in structured way, 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?

Description covers purpose, chart types, and output format. With 100% schema coverage and no output schema, this is sufficiently complete for an agent to select and invoke the tool correctly.

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

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

Schema already fully describes parameters with 100% coverage. The main description lists chart types, which is redundant with the enum, but does not add new semantic meaning beyond schema.

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

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

Clearly states action (create visualization), resource (research findings), and outputs (branded SVG). Lists all chart types, distinguishing it from all 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?

No explicit when-to-use or when-not-to-use guidance. The description implies use for creating visuals but doesn't exclude or compare to siblings. Since all siblings are non-visual, it's somewhat clear but lacks direct guidance.

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 clear. The description adds that it returns costs, which is useful context. No further behavioral details are needed given the simple read operation.

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, no filler. Front-loaded with the main purpose and ends with actionable guidance.

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

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

For a simple read-only tool with one optional parameter, the description is nearly complete. It is missing specifics about the return format or structure, but that is not critical since there is no output schema and the tool's purpose is clear.

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

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

The only parameter (userId) has a description in the schema, and the description does not add additional meaning or usage details. With 100% schema coverage, a baseline of 3 is appropriate.

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

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

The description clearly states the tool returns Fodda's capabilities, features, offerings, and pricing. It distinguishes itself from sibling tools (e.g., deep_research_topic, get_evidence) by being the go-to tool for general information about what Fodda can do.

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 the agent to 'Call this for any question about what Fodda can do or what's available', providing clear when-to-use guidance without 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 set readOnlyHint and idempotentHint, and the description adds valuable behavioral context: pricing ($0.50 per lookup), the return format, and the requirement that node IDs must come from prior search results. It doesn't contradict annotations and enriches them, though it could mention error behavior for invalid IDs.

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, front-loaded with the core purpose, and every sentence adds value—return format, usage context, cost, and key constraints. No fluff or repetition.

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

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

Despite no output schema, the description explains what each evidence item includes, when to use the tool, and critical usage rules. It lacks error-handling details (e.g., what if no evidence found) but is otherwise complete for a simple read-only lookup with rich annotations.

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%, with detailed parameter descriptions for graphId and for_node_id. The tool description reiterates the node_id constraint but adds no new parameter semantics 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 the tool retrieves source articles, case studies, and statistics behind a specific trend, with full citations. It specifies the output fields and explicitly distinguishes itself from text search tools by framing this as a direct lookup by trend ID, effectively differentiating it 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 says to use it 'after search_graph when you need the supporting proof behind a trend' and clarifies it is not a text search tool. This provides clear when-to-use guidance and alternatives, making the usage context unambiguous.

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, destructiveHint as safe/read-only. Description adds useful behavioral context: it returns a deterministic list for Trends (unlike search) and lists all values for a given label. 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?

Description is relatively concise with clear front-loading of purpose. Two sentences provide examples and a specific usage tip. Could be slightly tighter, but it's well-structured and each 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 no output schema, description adequately explains that the tool returns a list of values for the specified label. It doesn't detail pagination or format, but for a straightforward listing tool this is acceptable. Companion list_graphs and search_graph siblings provide 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 coverage is 100% so baseline is 3. Description adds significant meaning: explains label values (e.g., 'Brand', 'Location'), gives examples of graph IDs, and clarifies that property is optional with default behavior. This goes beyond what the schema alone 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?

Description explicitly states it lists specific categories (brands, locations, etc.) within a knowledge graph, with concrete examples like 'what brands are in the retail graph?'. It distinguishes from sibling search_graph by noting that for labels like 'Trend', this returns a complete deterministic list vs partial search results.

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?

Clearly says 'Use to explore what a graph contains' and provides example queries. It also advises using label='Trend' for complete trend lists in industry-report graphs, implying this tool is preferable over search for exhaustive results. However, it does not explicitly state when not to use the tool or name 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, idempotentHint=true, destructiveHint=false. The description adds value by noting the tool returns 'live data — not cached from session start', which is useful behavioral context beyond what annotations provide. 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?

Two sentences: first states purpose and data returned, second provides usage examples and a behavioral note. Every sentence is informative and earns its place. Highly efficient 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 simplicity (no parameters, no output schema), the description covers all essential aspects: what the tool does, what data it returns, when to use it, and a key behavioral trait (live data). 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?

There are zero parameters, and schema coverage is trivially 100%. The description correctly omits any parameter details. Baseline for 0 parameters is 4, and no additional information is 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 uses a specific verb ('Check') and resource ('current user's account status'), listing concrete data points (API call balance, plan, graphs, profile). It clearly distinguishes from sibling tools like get_capabilities or list_graphs by focusing on account-specific 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 explicitly states when to use the tool by giving example user queries ('how many API calls do I have?', 'what plan am I on?'). While it doesn't provide explicit when-not-to-use or alternative tool mentions, the context is sufficiently clear for an AI agent to select correctly.

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 idempotentHint. The description adds that results are 'curated editorial connections' and 'cross-domain links that search alone wouldn't surface,' 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?

Four focused sentences that front-load the most important information: what it does, when to use it, and a key constraint. 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 no output schema, the description adequately explains the nature of results (curated connections) and prerequisites. It covers the essential context for a graph exploration tool with well-documented parameters.

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 good parameter descriptions. The description adds critical guidance for seed_node_ids, stressing they must be actual node_ids from search_graph, not guessed integers. This is valuable 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 discovers connections (brands, technologies, locations, cross-domain links) to a specific trend, distinguishing it from search_graph by highlighting curated editorial content not found via web search.

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

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

Explicitly instructs to use after search_graph, maps territory around a trend, and provides examples like finding connected brands or cross-domain relationships. It also notes the prerequisite of having a node_id from a prior search_graph result.

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, destructiveHint, and idempotentHint; description adds that it retrieves detailed properties, which is consistent. 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?

Two sentences, each earning its place: first states purpose, second gives usage guidance. 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 good annotations, full schema coverage, and the simple nature of a read-only detail retrieval, the description is complete. No output schema, but properties are listed.

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 reinforces that node_id must come from search_graph and not be guessed, adding value 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?

Clearly states 'Get the full profile of a specific trend' and lists included properties (lifecycle stage, signal strength, etc.), distinguishing it from sibling 'search_graph' which returns summaries.

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 'Use when you need deeper detail on a single trend after search_graph returned a summary' and notes the prerequisite of a prior search_graph result. Does not mention 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?

Beyond the annotations (readOnlyHint, openWorldHint, destructiveHint), the description discloses that it fanned out across 80+ sources in parallel, returns categorized data blocks with source attribution and metadata, and charges $10 per query. The note about calling after search_graph adds workflow context. 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?

Four concise sentences. The first sentence states the core purpose, the second gives usage triggers, the third explains data sources and output, and the fourth adds a sequencing note and price. Every sentence carries useful information with no filler.

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

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

No output schema exists, but the description still covers the core behavior: parallel retrieval from 80+ sources, categorized blocks with attribution/metadata, and cost. It omits details like return structure taxonomy or error behavior, but overall it is complete enough for an agent to decide when to invoke this tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds minor context for the query parameter with examples ('search volume, economic series, or census data') and the demand/attention-shaped concept, but does not provide additional meaning for geo, brands, domain, userId, or graph_ids beyond their 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 identifies the tool as a layer for macro, institutional, and real-time market data, and states it 'retrieves data from 80+ authoritative sources... Returns categorized data blocks.' It distinguishes from siblings by explicitly directing use 'when curated coverage is thin, empty' and 'call after search_graph indicates thin/empty coverage via its coverage annotation,' naming the alternative 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?

Provides explicit when-to-use conditions: 'Call this tool when curated coverage is thin, empty, or when the query is explicitly demand/attention-shaped (e.g. to get search volume, economic series, or census data).' Also gives a sequencing directive: 'call after search_graph indicates thin/empty coverage via its coverage annotation,' which clarifies the relationship to 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, idempotentHint, and destructiveHint false, covering safety. The description adds context that results are scoped to 'the user can access' (permission-filtered) and that it returns graph metadata needed for graphId parameters in other tools, which is useful behavioral information 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 two sentences and front-loaded with the core purpose, followed by usage guidance and downstream value. No unnecessary words or restatements, 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?

For a simple listing tool with one optional parameter, rich annotations, and no output schema, the description covers purpose, content scope, and usage timing. It is complete for an AI agent to select and invoke the tool correctly.

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

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

The input schema covers the single optional userId parameter with 100% description coverage, explaining automatic authentication for non-trial users. The tool description adds no additional parameter semantics, so the 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 states a specific verb and resource: 'List all expert knowledge graphs the user can access', and details the returned fields (IDs, descriptions, authors, sectors, signal counts, topic coverage). It distinguishes from siblings by framing itself as the session-first discovery tool before searching, which separates it from search_graph and deep_research_topic.

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 FIRST in any session to discover available sources before searching', offering clear when-to-use guidance. It does not name alternative tools directly, but the 'before searching' cue implies its role relative to search-related siblings. No when-not-to-use exclusions are provided, 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.

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

Annotations already provide readOnlyHint and idempotentHint, so the safety profile is covered. The description adds useful beyond-annotation context: it returns 'structured text ready for analysis' and discloses the price ($20 per URL lookup), which is important operational information. It doesn't cover edge cases or rate limits, but with annotations the bar is lower.

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 four short sentences, each earning its place: purpose, usage context, output nature, and price. It is front-loaded with the core action and avoids 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?

For a simple read tool with no output schema, the description explains the use case and return format ('structured text ready for analysis'). It doesn't detail edge cases or authentication requirements, but given the tool's simplicity and rich annotations, it is largely complete. Slightly more detail on output limitations would push it to 5.

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 both parameters (url and userId). The description adds no parameter-specific detail beyond what the schema states, so the baseline of 3 is appropriate.

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

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

The description clearly states the verb 'Extract clean text content from any URL' and identifies the resource (URL). It also gives concrete use cases (competitor site, news article, client brief, trend report) and distinguishes itself from sibling tools like search_graph or get_node by focusing on external URL extraction.

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 this when a user shares a link... and wants to cross-reference it against Fodda knowledge graphs.' This gives clear context for when to invoke the tool. It does not explicitly mention alternatives or exclusions, so it falls 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.

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 known. The description adds value by specifying output characteristics (trend data with cited evidence, source attribution, lifecycle stage) and the $20 per query cost. 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: purpose, return characteristics, and usage guidance with price. Every sentence carries unique information and the most important facts come first. No filler.

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 an 8-parameter tool with no output schema, the description gives a strong overview of what to expect (trend data, cited evidence, lifecycle stage) and the cost. It doesn't detail pagination, result limits, or output formatting beyond the schema, but the schema covers parameter behavior. The description plus schema provide sufficient context for an agent to decide and call.

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, so the description doesn't need to compensate. The main description adds a helpful note about graphId omission behavior, but this is already in 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 states a specific action ('Find trends, signals, and expert insights') applied to a well-defined resource ('100+ curated knowledge graphs'). It clearly differentiates from generic web search by highlighting cited evidence, source attribution, and lifecycle stage, making its purpose unmistakable.

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 lists use cases ('market trends, competitor analysis, innovation signals...') and recommends omitting graphId to search all graphs. It implies comparison to web search but doesn't name an alternative tool within the organization; the schema's query parameter does direct users to get_supplemental_context for sub-national queries. Good context overall, but not exhaustive exclusions.

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