Fodda Synthetic Expert Consult

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

The description adds significant behavioral context beyond annotations: polling is free, typical duration is a few minutes, recommended polling interval is 15-30s. These details help the agent manage expectations and behavior. No contradiction with annotations (readOnlyHint, idempotentHint, destructiveHint all align).

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 defines purpose, second explains input and output, third gives practical polling guidance. No fluff, front-loaded, 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 polling tool, the description covers all necessary aspects: what triggers it (request_deliverable), what to pass (job_id), what it returns (status and artifact links), how often to poll (15-30s), and cost (free). No output schema needed as the description lists return fields. Complete for the use case.

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 parameters described). The description adds value by explicitly linking job_id to request_deliverable's response, which clarifies the parameter's origin. For userId, no extra context is given, but the schema description is sufficient. The tool name also implies the parameter semantics.

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 ('Poll') and resource ('deliverable status'), and explicitly ties it to the sibling tool 'request_deliverable' by referencing job_id. It specifies the output (status and artifact links), leaving no ambiguity about what the tool does.

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 clear context on when to use the tool: after request_deliverable, with job_id. It provides polling frequency guidance ('every ~15–30s') and typical duration ('a few minutes'). Although it doesn't explicitly state when NOT to use, the context is sufficient for correct selection.

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 are minimal (readOnlyHint=false, no safety profile), so the description carries the burden. It discloses the referral behavior and mandates third-person platform voice, the analyst_id/company auto-resolution, the cost note ('follow-ups cost less'), and the output shape (coverage status, source attribution, referrals). This is substantive behavioral disclosure beyond the empty annotation profile.

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?

Longer than average (five dense sentences with parentheticals), but every sentence carries actionable content — the referral voice rule and company auto-resolution are critical behavioral details. Core purpose is front-loaded in the first sentence. Slightly verbose but justified by density of information.

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

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

With no output schema and no safety annotations, completeness falls entirely on the description. It covers: how to find the right analyst (list_analysts), the full input pattern (analyst_id, company, session_id), the output characteristics (coverage status, attribution, referrals), and how to handle referrals. Nothing an agent needs to invoke it correctly is missing.

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 clear per-param descriptions. The description adds meaningful relational context above the schema: the 'brand-cmo'+company pairing, the auto-resolution of 'Nike CMO' to analyst_id+company, and the session continuation semantics with cost implications. This goes beyond baseline 3 by explaining parameter interdependencies.

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 a specific verb (consult), resource (named Synthetic Analyst expert), and mechanism (expert voice + curated knowledge graph). Explicitly distinguishes itself from 'generic search or standard graph queries' and explains the company-binding special case. An agent can tell exactly what this tool is for.

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?

Gives clear context: call list_analysts first to find the right ID, use session_id to continue multi-turn engagements, and omit session_id for one-off questions. Distinguishes from generic search/standard graph queries. Lacks explicit when-NOT-to-use guidance (e.g., when to prefer consult_human_agent or search_graph instead), so it doesn't earn 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?

All annotations are false, so the description carries the full behavioral burden — and it delivers: multi-turn session state, third-person platform voice for referrals, verbatim presentation rules for book_a_call, and the range of response elements (coverage status, source attribution, referrals). The behavior of a stateful, voice-aware consultation tool is thoroughly disclosed.

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

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

The description is long (~200 words) but front-loads critical purpose and differentiators early. Nearly every element earns its place — multi-turn behavior, booking, voice requirements, and referrals — though the opening clause about 'consent, participation, and curated knowledge graph' is slightly wordy and could be trimmed.

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 tool with no output schema and all-false annotations, the description robustly covers response shape (coverage status, attribution, referrals), booking side-channels, session continuation, and voice constraints. Minor gap: the response structure is enumerated but not fully specified (e.g., exact shape of coverage status values), but the description is sufficient to honor correct calling.

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

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

Schema description coverage is 100%, so the baseline is 3. The description re-states session_id behavior ('pass session_id back to continue') and analyst lookup (list_analysts first), but adds no syntax, format, or selection details beyond what the schema already 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?

Opens with a specific verb+resource ('Consult an authorized Human Agent (Digital Twin) expert') and immediately differentiates the tool from 'generic search or standard graph queries.' It also names the sibling prerequisite (list_analysts), making it easy for an agent to position this tool relative to its alternatives.

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 context: 'Call list_analysts first to find the right expert ID' and explains when to surface book_a_call ('when the user wants to hire or speak to the expert'). However, it contrasts itself with 'generic search or standard graph queries' without naming the closely-related sibling 'consult_analyst', leaving some ambiguity about when to pick one over the other.

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 convey readOnly, idempotent, and non-destructive behavior. The description adds useful operational detail beyond that: the output is a branded SVG that renders directly in the chat, and focal entities can be highlighted. No contradiction with annotations exists.

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

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

The description is compact and well-front-loaded: purpose first, chart-type list second, output behavior third, focus usage last. Every sentence earns its place and there is 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?

The data parameter is a free-form JSON string with six materially different schemas, and there is no output schema, so the description must carry the data-format burden. It only gives high-level parenthetical sketches like From→To transitions and network of related trends, and the schema's claim that chart-specific schemas are documented is not actually backed by the tool description. An agent would struggle to construct valid JSON for many chart types.

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, but the description adds real semantic value by explaining what each chart_type enum value means and how the focus field behaves. It does not supply full JSON structures for every chart type, but it meaningfully improves parameter understanding beyond the bare 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 that the tool creates a presentation-ready data visualization from research findings and enumerates six distinct chart types, so an agent can tell what function it performs. It does not explicitly contrast with sibling tools, but none of the listed siblings appear to be visualization tools, so ambiguity is low.

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 clear context for when to use it: when research findings need to become a visual chart, and it lists the available chart modes for selection. It never states when-not-to-use or names alternative tools, so it stops short of full routing 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?

The description adds that the output includes main offerings and usage instructions, which is genuinely behavioral information beyond the read-only/idempotent annotations. It doesn't explain response structure or whether the optional userId affects output, but the annotation already covers safety and the description conveys what the tool tells the 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?

Two sentences and front-loaded: the first sentence states what it returns, the second gives the usage rule. The string of synonyms is mildly redundant, but not a meaningful waste of tokens and still succeeds in covering the concept of capabilities.

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 zero required parameters, a single optional userId, no output schema, and a short capability/help role, the description fully covers what the agent needs to call it correctly. It explains the returned content, usage intent, and relationship to 'what's available. Nothing important is left unsaid.

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

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

The schema already documents the single optional 'userId' parameter with a clear description, and schema coverage is 100%. The tool description adds no extra meaning about how userId influences the returned capabilities, so parameter-semantics sits at the 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?

The description specifies the verb ('Returns') and a clear resource ('Fodda's main capabilities... and how to use them'). The phrase 'Call this for any question about what Fodda can do or what's available' sharpens the purpose and makes it easy to distinguish from data-access siblings like search_graph or 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?

It explicitly states when to call the tool ('for any question about what Fodda can do or what's available'), giving a clear trigger condition. It does not name sibling alternatives or describe when not to use it, but the context is strong enough for a help-like capabilities 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 provide readOnlyHint, idempotentHint, and destructiveHint. The description adds important behavioral context: it is a direct ID-based lookup, not a search, and it returns citations and attribution. 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 compact sentences with purpose first, output contents second, usage guidance third, and the non-search disclaimer last. Every sentence earns its place and no space is wasted on restating schema fields.

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?

Since no output schema exists, the description compensates by describing what returned evidence items contain, including citations and publisher attribution. The usage context is clear, though a tiny gap is that the phrase 'trend ID' is not explicitly mapped to the for_node_id parameter, leaving it to the schema to make that connection.

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

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

The schema description coverage is 100%, so the schema fully documents each parameter. The description adds the conceptual framing of a trend-ID lookup, but does not repeat parameter-level details; this aligns with the baseline of 3.

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 a specific verb (Get), resource (supporting evidence behind a trend), and exactly what each item includes: source URL, location, brand names, publication date, category, and citation. The description clearly distinguishes the tool from search_graph with the 'direct lookup by trend ID — not a text search' note.

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?

Gives explicit timing: 'Use after search_graph when you need the supporting proof behind a trend.' It also explicitly excludes text-search usage and positions itself as a follow-up lookup. This leaves no ambiguity about when to select it over siblings.

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 convey readOnly, idempotent, and non-destructive behavior, so the description does not need to repeat that. It adds the useful context that the result is 'full deterministic', which goes slightly beyond the annotations, but it does not describe response shape, limits, or other behavior.

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

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

The description is compact, front-loaded with purpose, and each sentence contributes meaning. The examples are relevant and the contrast with search is stated efficiently without unnecessary words.

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

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

For a read-only, idempotent listing tool, the description gives an adequate mental model: what it lists, how to formulate the label, and when to prefer it over search. There is no output schema, but the tool is simple enough that the description effectively guides usage. The only minor gap is not specifying the return shape.

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 parameters are already well documented. The description adds one useful semantic: calling with label='Trend' returns the complete list. It does not add any additional explanation beyond the schema for graphId, userId, or property.

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 with a specific verb and resource: 'List all brands, locations, technologies, audiences, or trends within a specific knowledge graph.' Examples like 'what brands are in the retail graph?' make the scope crystal clear. It also differentiates itself from search by calling out 'full deterministic list' versus 'partial 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?

The description explicitly directs users to use this tool to explore graph contents and to call with label='Trend' when a complete list is needed. It also contrasts with 'search may return partial results', implying a search alternative, though it does not name the exact sibling to avoid.

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 specify readOnlyHint=true and idempotentHint=true. Description adds value by stating 'Returns live data — not cached from session start,' which is a behavioral detail 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?

Three sentences, each purposeful: first defines purpose, second gives usage cues, third adds transparency. No redundancy or superfluous text.

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

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

For a zero-parameter tool with no output schema, the description sufficiently covers what the tool does, when to use it, and what it returns. Complete in its 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?

No parameters, so schema coverage is 100%. Description adds value by enumerating the output fields (balance, plan, graphs, profile), which compensates for the lack of an output 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 the tool checks the current user's account status, listing specific data points (balance, plan, graphs, profile). Distinguishes from siblings like get_capabilities and get_evidence by focusing on the user's own account.

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 example queries to guide usage ('how many API calls do I have?'). Lacks explicit exclusions or alternatives, but the context is clear enough for an agent to select this tool 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 already declare readOnlyHint true, idempotentHint true, and destructiveHint false, so the description does not need to repeat safety behavior. The description adds meaningful context: the results are 'curated editorial connections' rather than raw search output, and there is a strict dependency on prior search_graph results. This goes beyond the structured annotations without contradicting 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 front-loaded with the core purpose and only four sentences. However, it contains mild redundancy: 'that search alone wouldn't carefully surface' and 'that web search cannot provide' say essentially the same thing. Overall the structure is good and each sentence contributes, but trimming the duplicate claim would be 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?

For a tool with 7 parameters and no output schema, the description gives the essential workflow context: call it after search_graph, uses valid node_ids, and explains why it is useful. The schema richly documents parameters and enums. The main gap is that the description does not specify the output shape or format of the 'connections' returned, which would be helpful especially since no output schema exists. Otherwise the context is adequate for selection and invocation.

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

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

Schema description coverage is 100%, so every parameter is already thoroughly explained in the schema. The description reinforces that seed_node_ids must come from a prior search_graph result, but this is already explicitly documented in the input schema. The description does not add new parameter-level meaning beyond what the schema provides, justifying the baseline score.

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 a specific verb and resource ('discover what's connected to a trend') and explicitly enumerates what the tool surfaces: brands, technologies, locations, and cross-domain links. The phrase 'curated editorial connections that web search cannot provide' clearly distinguishes it from search_graph and other sibling tools. This is not a tautology or vague restatement of the name.

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 clear, actionable guidance: 'Use after search_graph' and lists specific use cases such as mapping territory, finding connected brands, or understanding cross-domain relationships. It also states the hard prerequisite of requiring a node_id from a prior search_graph result. It does not explicitly name exclusion scenarios or alternatives like get_node or get_evidence, so it falls just short of the highest bar.

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?

With annotations declaring readOnlyHint, idempotentHint, and destructiveHint false, the safety profile is already clear. The description adds valuable context about the return fields and the provenance requirement for node_id, explaining that IDs must come from search_graph and not be guessed. 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 concise sentences with no filler: the first lists the return fields, the second gives the usage context, and the third states the key prerequisite. Each sentence earns its place and 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 has no output schema, the description compensates by listing the main return fields and noting 'all properties'. It also provides the critical usage context and prerequisite. However, it doesn't describe the exact output structure or possible failures, which would be helpful but is not a major 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 100%, including nodeId, nodeId with anti-guessing guidance, graphId with list_graphs reference and examples, and userId. The description provides no additional parameter semantics beyond what the schema already defines, 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 clearly states the verb 'Get' and the resource 'full profile of a specific trend', then enumerates the key attributes: detailed description, lifecycle stage, signal strength, geographic scope, and all properties. It also differentiates from search_graph by noting it is for deeper detail on a single trend, making the tool's 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 says to use it when deeper detail is needed 'after search_graph returned a summary' and requires a node_id from a prior search_graph result. This gives clear context and a prerequisite, though it doesn't explicitly state when not to use the tool or list alternative siblings beyond search_graph.

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, covering the safety profile. The description adds meaningful context beyond annotations by specifying that the tool lists both human agents and synthetic analysts, clarifying the scope of outputs. It does not describe return format or pagination, but the annotation coverage lowers the burden.

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, front-loaded with the primary purpose in the first sentence. The second sentence adds usage guidance without redundancy. Every phrase earns its place, making it highly concise and 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 simple list tool with one optional parameter and no output schema, the description adequately covers the tool's function and distinguishes it from querying. It gives enough context for an agent to select and invoke the tool correctly, including examples of expected content.

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

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

The input schema has one optional parameter 'userId' with a description, giving 100% schema coverage. The tool description does not mention this parameter, but the schema fully documents it. Per the baseline, with high schema coverage the description need not add parameter details, so 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 uses a specific verb 'Lists' and clearly identifies the resource: available human agents and synthetic analysts. It provides concrete examples (e.g., brand-cmo, brand-ceo, Anu Lingala), which disambiguates the tool from siblings like consult_analyst. The purpose 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?

The description explicitly tells when to use this tool (to list analysts) and when not to: 'To query a company-specific synthetic expert... consult brand-cmo' implies using a different tool (likely consult_analyst). It gives a clear alternative path, though it does not name the sibling tool directly, which prevents 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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the return content (IDs, descriptions, authors, sectors, signal counts, topic coverage) and its role as a prerequisite, but does not elaborate on pagination or error behavior.

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

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

Three concise sentences, front-loaded with the action and output, then usage guidance. No redundancies; 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 read-only list tool with rich annotations and a fully described schema, the description clearly states what it does, when to use it, and what it returns. It is sufficiently complete for an agent to select and invoke it 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 schema covers the only parameter (userId) with a full description, achieving 100% coverage. The description does not add anything about parameters, but the schema does the heavy lifting, 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'), identifies the resource ('expert knowledge graphs'), and defines scope ('the user can access'). It also enumerates the returned attributes (IDs, descriptions, authors, sectors, signal counts, topic coverage), distinguishing it from sibling tools like search_graph and get_node.

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 FIRST in any session to discover available sources before searching', providing clear timing and implying precedence over search tools. It also notes the metadata is needed for graphId parameters in other tools, reinforcing its role as a prerequisite.

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 well beyond the annotations by disclosing that work runs in the background, that a job_id is returned, that the price is charged on acceptance, and that research is included at no separate charge. This gives an agent clear expectations about side effects and workflow.

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 dense but every sentence earns its place: purpose, required inputs, background workflow, billing model, and an illustrative example. The most important usage information is front-loaded, and there is 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 a tool with no output schema, the description fully explains the return value (job_id), how to obtain final artifacts (polling check_deliverable_status until 'completed'), and cost implications. It also gives enough context about attachments and brief format for an agent to invoke it 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 already specifies all parameters with 100% coverage. The description reinforces which fields are needed and adds a concrete example brief, but it does not substantially extend the schema-level meaning of the parameters. 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: it commissions a finished, skill-based document from an analyst. It gives concrete examples of deliverables (marketing plan, deck review, trend briefing) and distinguishes the long-running background task from sibling tools by referencing check_deliverable_status and list_analysts.

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 context: choose this tool when a finished document is needed, provide a brief and offering, then poll with check_deliverable_status. It does not explicitly contrast with consult_analyst or other sibling tools, so it stops short of a full when-not-to-use explanation.

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 carry the safety profile (readOnlyHint=true, destructiveHint=false), so the description's job is to add context beyond that. It does: it discloses output composition ('trend data with cited evidence, source attribution, and lifecycle stage — not generic web summaries') and a significant runtime behavior ('searches ALL accessible graphs in parallel'). This is meaningful behavioral context an agent needs before calling, and it doesn't repeat 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?

Three sentences do the full job: what it finds, what the output is AND what it is not, and the recommended invocation chain. The 'not generic web summaries' contrast assignment is given before the use-case list. Every sentence earns its space — well front-loaded for an agent.

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

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

For a 9-parameter tool with no output schema, the description covers the essentials: the semantics of the output (trends, evidence, attribution, lifecycle), the default search behavior across all graphs, and the use cases. The schema covers all parameter-level details. It could be '5' if the description referenced the output shape or the graphs available, but given the schema is fully self-descriptive and the omission is partial, a '4' is appropriate.

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 9 parameters (mode enum, graphs precedence rule, unavailable_graphs reporting, graphId examples). The description adds no new per-parameter semantics except reaffirming missing graphId searches all graphs, which the schema already states. Baseline 3 is appropriate — no gaps but no added 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 uses a specific verb and resource ('Find trends, signals, and expert insights across 100+ curated knowledge graphs covering retail, beauty, tech, food, travel, sports, and 30+ specialist domains') and clearly differentiates the output from generic web search ('not generic web summaries', 'curated expert intelligence outperforms web search'). It does not explicitly name and distinguish sibling tools, but the contrast with web search and the explicit return payload (citations, source attribution, lifecycle stage) give a strong positional identity.

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?

Spells out concrete use cases: 'market trends, competitor analysis, innovation signals, consumer behavior, cultural shifts'. It also gives a strong default-behavior guideline ('If graphId is omitted, searches ALL accessible graphs in parallel (recommended default)') that tells the agent how to invoke it by default. No exclusions or sibling alternates are named, so '5' is not justified, but the guidance is clear enough for selection.

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