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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is known. The description adds value by listing the return fields, stating domain is the best lookup key, and providing examples of expected input phrasing. This goes beyond the annotations without contradicting them, though it omits edge case behavior (e.g., when neither param is provided).

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

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

The description is well-structured with a clear purpose statement, args list, returns list, and examples. It is front-loaded and avoids fluff, but the returns list is repeated twice (once in the opening sentence and again in the Returns section), creating minor redundancy. Still, each part is useful and it remains concise overall.

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

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

Given the simple 3-parameter tool, no output schema, and strong annotations, the description covers all essential aspects: purpose, expected inputs, output fields, and examples. It clarifies that at least one of domain/company_name should be provided, addressing a schema ambiguity. It leaves out error handling but that is not critical for this low-complexity enrichment 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 the baseline is 3. The description largely repeats the schema's parameter descriptions (e.g., 'domain (string, optional): Company website domain (best lookup key)' vs. schema's 'primary lookup key'). It adds examples of natural language inputs but no new semantic detail for parameter values or combinations.

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 enriches a company profile using Clay's data network and lists specific output fields (industry, employee count, revenue, tech stack, funding, description). This distinguishes it from sibling tools like clay_enrich_person (people enrichment) and zoominfo_search_company (search-oriented) through a clear verb+resource+method combination.

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 input guidance ('Provide domain (preferred) or company_name') and context that this is for enrichment via Clay. It does not explicitly name alternatives or exclusions, but the purpose is obvious enough that an agent could infer when to use it. This qualifies as clear context without explicit 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 read-only, idempotent, and non-destructive behavior. The description adds meaningful context about how the tool resolves lookups (e.g., email is the best lookup key, company_domain for disambiguation) and what it returns. This goes beyond the 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 well-organized with clear sections (main purpose, required-input guidance, args, returns, examples). Every sentence earns its place, and the formatting makes it easy for an agent to parse key information quickly.

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

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

The description covers the essential aspects: input requirements, output fields, and examples. There is no output schema, so the 'Returns' list is helpful. It is slightly incomplete in not addressing edge cases like no-match or multiple matches, but given the annotations and simplicity, it is largely sufficient.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by clearly grouping parameters, explaining the fuzzy-matching role of first/last name, and explicitly calling email the 'best lookup key'. Examples further illustrate parameter mapping, providing more than the schema alone.

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

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

The description clearly states the tool's purpose: to enrich a person's profile using Clay's data network, listing the specific fields returned (job title, company, email, etc.). It distinguishes from the sibling tool clay_enrich_company by focusing on a person rather than a company.

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 concrete usage guidance: it explicitly states that at least one of email, linkedin_url, or first_name+last_name+company_domain must be provided, and gives examples of natural-language inputs. However, it does not explicitly mention alternatives or when not to use this tool, so it falls just 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 indicate non-read-only, non-idempotent, non-destructive behavior. The description adds valuable context about asynchronous execution ('Enrichment runs asynchronously — results appear in your Clay table') and clarifies that the return is merely a submission confirmation. No contradiction with annotations.

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

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

The description is well-structured with a clear opening statement, Args section, Returns note, and Example. Every sentence contributes meaning, and it is concise without being underspecified.

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

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

The description covers the core trigger action, asynchronous behavior, prerequisite of obtaining the webhook URL, and return value. It lacks error-handling details or instructions on retrieving results, but these are not essential for a simple trigger tool given the output schema is absent.

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 3 is appropriate. The description lists the same parameter meanings as the schema and provides an example, but adds little beyond what the schema already specifies.

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

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

The description clearly states the tool's purpose: 'Send data to a Clay webhook to trigger a table-based enrichment workflow.' It identifies a specific verb, resource, and scope, and distinguishes itself from sibling tools like clay_enrich_person and clay_enrich_company by focusing on table-based enrichment sequences.

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

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

The description provides clear context: it is for table-based enrichment workflows with custom sequences, and notes that the webhook URL is unique to each Clay table. However, it does not explicitly contrast with individual enrichment tools or state when not to use it, so it lacks explicit alternatives/exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds transparency about the specific data returned (metadata, topics, trackers, action items, interaction stats, speaker breakdown) and the response_format parameter's effect, which goes 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 well-structured and front-loaded: a two-sentence purpose, a usage tip, a compact Args list, a Returns summary, and illustrative examples. Every sentence earns its place 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 read-only getter with strong annotations (readOnlyHint, idempotentHint) and a fully described schema, the description covers all necessary context: what it does, how to find the required call_id, what it returns, and example invocations. No critical 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% with clear descriptions of both parameters. The description adds value beyond the schema by including natural language examples ('Analyze call 123456' -> call_id='123456') and stating the default for response_format, which helps agents map user intent to parameters.

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

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

The description opens with a specific verb and resource: 'Get detailed analytics for a specific Gong call' and lists concrete contents (topics, trackers, action items, talk ratios, speaker stats). This distinguishes it from sibling tools like gong_get_transcript and gong_get_call_stats.

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 gong_search_calls first to find call IDs', providing a clear workflow prerequisite. However, it doesn't mention when not to use this tool or compare to alternatives like gong_get_transcript, so it misses the full when/when-not criterion.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral context by specifying the exact return content in the 'Returns' line: total calls, average duration, direction breakdown, and top participants. This goes beyond the annotations and helps the agent understand what the call actually provides.

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

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

The description is well-structured: one clear main sentence, a use-case sentence, an Args list, a Returns line, and an example. It is not excessively verbose and front-loads the core purpose. The example is useful but could be trimmed; overall, it earns its keep.

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

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

The tool has no output schema, so the description bears the burden of explaining return values, which it does in the 'Returns' line. It also covers parameters and a practical example. Missing details like timezone handling or date-inclusivity are minor for an aggregate stats tool. The description is sufficiently complete given 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?

The input schema already has 100% coverage with descriptions for all three parameters. The description repeats the parameter semantics in an 'Args' section without adding meaningful new information beyond what the schema provides. Since schema coverage is high, 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's function: 'Get aggregate call statistics for a date range' with specific metrics (total calls, average duration, call breakdown). This distinguishes it from siblings like gong_search_calls and gong_get_transcript, which focus on individual calls or transcripts.

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 a clear use case: 'Useful for pipeline reviews and rep activity analysis.' It implies this is for aggregate data rather than individual-call queries, but it does not explicitly exclude alternatives or name when not to use it.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds context about the return format (timestamped sentences, speaker labels) and the response_format parameter, going beyond the 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 well-structured with a clear first line, compact argument list, and example. The only issue is minor redundancy where the return value is stated twice ('Returns timestamped sentences...' and later 'Returns: Timestamped transcript...'), but this does not significantly harm readability.

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

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

For a simple 2-parameter tool without an output schema, the description adequately covers the purpose, return structure, prerequisite workflow, and an example. It is sufficiently complete for an agent to invoke the tool correctly, though the exact output format could be more detailed.

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

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

Schema descriptions already cover both parameters at 100% coverage. The description adds an example mapping call_id to '123456' and restates the default value, offering practical clarity beyond the schema without introducing new 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 'Retrieve the full transcript of a specific Gong call' and distinguishes this from sibling tools like gong_search_calls and gong_get_call_details. The explicit mention of using gong_search_calls first reinforces its unique role in the workflow.

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 instructs to 'Use gong_search_calls first to find call IDs', providing clear context for when this tool should be used. While it does not enumerate alternatives or when-not-to-use scenarios, the workflow guidance is sufficient for correct tool 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?

Beyond the readOnlyHint=true and idempotentHint=true annotations, the description adds useful behavioral context: it explains the return structure (list of calls with metadata), the pagination cursor, and the response_format choices. It also includes practical examples of how to phrase queries. It does not contradict annotations, though it omits details like rate limits or empty-result 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 well-organized with clear sections but is slightly redundant: the return value is described twice (once in the opening paragraph and again in a dedicated 'Returns' line). It could be tightened by merging these statements, making it 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 5 parameters (2 required), no output schema, and sibling tools, the description provides sufficient context: it explains what the tool returns, includes examples for date parameters, and mentions pagination. It does not cover edge cases like empty results or rate limits, but it is complete enough for typical usage.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by providing ISO 8601 date examples (e.g., '2024-01-01T00:00:00Z'), clarifying the response_format enum and default, and offering a conversational mapping example ('Find all calls last week'). This enriches understanding beyond the schema's basic property descriptions.

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

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

The description clearly states the tool's function: 'Search for recorded calls in Gong within a date range.' It specifies a verb, resource, and scope. However, it does not explicitly differentiate from sibling tools like gong_search_calls_by_participant, despite the date-range focus being a distinguishing factor.

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 usage guidance: 'Use this to find calls for a specific time period, then use gong_get_call_details or gong_get_transcript for deeper analysis.' This tells when to use the tool and what to do next, but it lacks exclusions or alternative search methods, such as mentioning gong_search_calls_by_participant for participant-based searches.

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 that it 'Returns: List of calls the participant was on' and gives an example, but does not disclose behavioral traits like pagination, sorting, or error handling. It adds some value beyond annotations but not rich context.

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

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

The description is well-structured with a clear purpose sentence, a use-case line, an args list, a returns line, and an example. The example is helpful but adds length; overall, it is concise without being verbose. Every section serves a purpose, though the example could be trimmed slightly.

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

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

The tool has four parameters, no output schema, and annotations present. The description covers purpose, parameters, return type, and an example, making it complete enough for an agent to use correctly. It does not specify date-range inclusivity or pagination, but these are not critical given the simple read-only nature.

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

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

Schema coverage is 100%, so the schema documents all four parameters with descriptions. The description repeats the args but adds a natural language example mapping 'Find calls with john@acme.com in January' to specific date arguments. This example adds marginal value beyond the schema, but does not significantly deepen 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 opens with 'Find Gong calls where a specific person participated, identified by their email address,' which is a specific verb+resource+scope statement. It clearly differentiates from sibling tools like gong_search_calls by focusing on participant-based search via email. The title reinforces this, making 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 states 'Useful for pulling a prospect's or rep's recent call history,' providing clear context for when to use this tool. It does not explicitly mention alternatives or exclusions, but the use case is specific enough to guide selection. A more explicit reference to sibling tools would push this to 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, openWorldHint, idempotentHint, and non-destructive behavior. The description adds valuable beyond-annotation context: the use of the standard REST API without SNAP, the fallback behavior to the authenticated user's profile when no URL/member ID is given, and the specific return fields (headline, title, company, location). No contradictions with annotations.

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

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

The description is concise and front-loaded with the core purpose. Each section (API note, parameter guidance, args, returns, examples) earns its place. The examples are particularly useful and do not add redundancy beyond the schema.

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 tool with three optional parameters and no output schema, the description is complete. It covers all parameter combinations, explains the default behavior, lists the return contents, and includes practical examples. No important usage context 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%, so the baseline is 3. The description adds meaning by explaining the relationship between linkedin_url and member_id ('Provide either'), and the behavior when neither is given. It also provides a concrete example linking the phrase 'Get profile for linkedin.com/in/johndoe' to the exact linkedin_url 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 opens with a clear, specific verb and resource: 'Get LinkedIn profile information for a specific person.' It further distinguishes itself from sibling search tools by focusing on retrieving a single known profile via URL/member ID, and by noting it uses the standard LinkedIn REST API.

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

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

The description provides clear context on when to use the tool: provide a LinkedIn URL or member ID, or omit both to get the authenticated user's own profile. It includes concrete examples mapping natural-language requests to parameters. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls just 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 read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by specifying that it uses the standard LinkedIn REST API (no SNAP required) and by listing the return fields (company name, industry, size, HQ, website, specialties, description). This goes beyond the schema and annotations, though it does not discuss rate limits 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?

The description is well-structured and front-loaded: opening purpose, API note, parameter list, return fields, and examples. Each section is compact and serves a purpose. The examples are particularly valuable for grounding the tool's intent. No superfluous content or redundancy with the schema beyond what is useful for quick scanning.

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

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

Given the tool's complexity (9 parameters, 0 required, no output schema), the description covers all necessary aspects: a clear summary, full parameter semantics, return fields, and usage examples. It even includes a technical note about the API. This is sufficiently complete for an agent to select and invoke the tool without missing critical information.

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 has 100% description coverage, so the baseline is 3. The description adds value by consolidating parameters into a logical list (e.g., min/max_employees as 'size range') and by providing natural language to parameter mappings in the examples. This helps an agent translate vague user requests into concrete arguments, exceeding 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?

The description clearly states a specific verb and resource: 'Search for companies on LinkedIn by name, industry, size, or geography.' This distinguishes it from tools like gong_search_calls and linkedin_search_leads, but it does not explicitly differentiate from zoominfo_search_company, which also performs company searches. Overall 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 provides concrete examples ('SaaS companies in San Francisco' -> keywords='SaaS', geography='San Francisco') that imply how to use the tool, but it lacks explicit guidance on when to choose this tool over alternatives like zoominfo_search_company. There is no mention of exclusions or trade-offs, so usage context is only implied rather than directly stated.

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 safety profile (readOnly, idempotent, non-destructive). Description adds operational context: uses standard LinkedIn API (no SNAP), requires OAuth scopes, and has limited people-search depth compared to Sales Navigator. 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?

Well-organized with clear sections: purpose, API context, args, returns, examples. Front-loaded with the main action. Some redundancy with schema's parameter descriptions, but the streamlined Args list and examples are useful without being overly verbose.

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

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

For a tool with 11 optional parameters and no output schema, the description covers input semantics, return fields (name, headline, title, company, location, industry, URL), limitations, examples, and API prerequisites. This gives the agent sufficient context to invoke correctly and interpret results.

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

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

Schema covers 100% of parameters with descriptions, setting a baseline of 3. The description adds value through natural-language mapping examples (e.g., 'VP Engineering in Bay Area' -> title/geography) and a compact consolidated Args list that helps the agent translate user intent into parameters.

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

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

Specific verb+resource: 'Search for people/leads on LinkedIn' with enumerated filters (keywords, title, company, seniority, geography, industry). This clearly distinguishes it from sibling tools like linkedin_search_companies or linkedin_get_profile.

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 notes the limitation vs Sales Navigator and suggests combining with ZoomInfo/Clay for deep research. Also states API requirements (standard REST, OAuth scopes), giving agent guidance on when the tool is appropriate. Does not fully specify when-not-to-use but provides actionable 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 mark it read-only and idempotent. The description adds context by specifying the return value (config status per service) and that status depends on required environment variables. It does not contradict 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 four short sentences, front-loaded with the purpose, then return details, then usage guidance. Each sentence earns its place 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?

Given the tool's simplicity (no params, no output schema, no nested objects), the description is complete: it explains what it does, what it returns, the services involved, and when to use it. Nothing essential 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?

The tool has zero parameters, and the schema is empty. The description includes 'Args: None', which is sufficient and aligns with the baseline of 4 for no-parameter tools.

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 checks which sales intelligence services are configured and available, listing Gong, ZoomInfo, Clay, and LinkedIn. This distinguishes it from the many sibling query tools for those specific services.

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 to verify which tools are ready to use before running queries,' which provides a clear when-to-use scenario. However, it does not explicitly mention alternatives or when not to use it, though the sibling tool names imply that.

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 confirm read-only, idempotent behavior. The description adds the prerequisite workflow (search company first) and describes the output structure (hierarchical list of contacts with titles, departments, management levels). It does not disclose limitations like pagination, but given annotations cover safety, this is adequate and slightly above baseline.

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

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

The description is well-organized: an opening definition, prerequisite note, args list, return summary, and examples. The args list slightly duplicates schema descriptions but the overall structure is 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?

With no output schema, the description compensates by explaining what the return contains (hierarchical list with titles, departments, management levels) and giving examples. It covers the required company_id, optional department filter, and response_format, making it sufficiently complete for an agent to invoke.

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 100% coverage with descriptions for all three parameters. The description reinforces this with an args list and provides concrete examples mapping natural language to parameter values, adding practical value beyond the schema.

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

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

The description clearly states the tool retrieves an org chart for a company from ZoomInfo, specifying it shows reporting hierarchy, departments, and management levels. It is easily distinguished from sibling tools like zoominfo_search_company (search companies) and zoominfo_get_tech_stack (technology stack).

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 instructs to use zoominfo_search_company first to obtain the company ID, giving a clear prerequisite. It does not, however, contrast with alternative tools or state when not to use this tool, so it is not a perfect 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 signal read-only, idempotent, and non-destructive behavior, so the description doesn't need to repeat that. It adds useful context: the tool returns categorized technology lists, accepts an optional format, and requires one of two identifiers. This goes beyond annotations by clarifying input constraints and output structure.

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 front-loaded with the core purpose, followed by parameter details and examples. The examples are useful but could be trimmed without losing essential meaning. It is well-structured with clear sections (description, args, returns, examples), earning a high score for efficiency.

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 that the tool has only 3 simple parameters, full schema coverage, and strong safety annotations, the description adequately covers what the agent needs: purpose, input alternatives, output summary, and an example. It doesn't include edge cases like what happens if both company_id and domain are provided, but that is a minor gap. The presence of sibling tools gives enough context to distinguish usage.

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 provides 100% coverage of all three parameters with descriptions and defaults. The description adds value by stating that company_id or domain are alternatives (one must be provided) and by giving examples, but it does not add detail beyond the schema's parameter descriptions. Baseline 3 is appropriate since schema fully documents parameters.

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

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

The description opens with a specific verb phrase ('Get the technology stack used by a company') and delineates categories (CRM, marketing automation, etc.), which clearly states the tool's function. It also implicitly distinguishes itself from sibling tools like zoominfo_search_company by focusing on tech stack rather than general company search or contact/org data.

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

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

The description explains that you can provide either company_id or domain, effectively saying when to use each identifier and that they are alternative inputs. It also gives example queries mapping natural language to parameters. However, it does not explicitly state when to prefer this tool over siblings like zoominfo_search_company, though the scope (tech stack) is implied.

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 non-destructive behavior. The description adds value beyond annotations by specifying return fields (employee count, revenue, industry, location, description) and the utility of the returned company ID for subsequent tools. 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?

Well-structured with an upfront purpose, followed by return details, Args summary, and examples. The Args section is slightly redundant with the schema but front-loads key information. No redundant prose; each section contributes.

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

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

Given the tool's complexity (10 optional params, no output schema), the description covers search criteria, return types, and follow-up usage. It includes examples and pagination controls. Could mention error handling or default response format, but these are adequately implied by schema 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% and the Args section largely mirrors schema descriptions. However, the description adds practical examples ('Find Acme Corp' -> company_name='Acme') and clarifies relationships like min/max employees as a range, going beyond raw schema.

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

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

The description clearly states it searches the ZoomInfo database for companies using specific filters (name, domain, industry, size, revenue), returning firmographic data. It distinguishes from siblings like zoominfo_search_contact (people) and zoominfo_get_org_chart/tech_stack (follow-ups) by focusing on company 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?

The description gives clear context for when to use this tool: to search companies and obtain company IDs for further ZoomInfo operations. It mentions follow-up tools (zoominfo_get_org_chart, zoominfo_get_tech_stack), but does not explicitly state when not to use it or compare with alternative search tools like clay_enrich_company or linkedin_search_companies.

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 cover readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is established. The description adds return fields and response formats, but does not disclose rate limits, data freshness, authentication requirements, or other behavioral caveats. Given the strong annotation coverage, a 3 is appropriate.

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

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

The description is well-structured with a clear summary, use cases, parameter list, and examples. However, the return fields are listed twice ('Returns contact details...' and 'Returns: Contact name...'), which is mildly redundant and prevents a perfect score.

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

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

For an external search tool with 11 parameters and no output schema, the description covers purpose, usage, all parameters, and return fields, and it provides practical examples. It could be more complete by explicitly distinguishing when to use this tool versus sibling contact-enrichment tools, but overall it is quite thorough.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value with concrete examples like 'Find VP of Sales at Acme' -> job_title='VP Sales', company_name='Acme' and enumerates valid management_level values. These examples go beyond the schema descriptions and help clarify parameter usage.

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 'Search the ZoomInfo database for contacts by name, title, department, company, or management level' — a specific verb + resource + filter criteria. This clearly distinguishes it from sibling tools like zoominfo_search_company, which focuses on companies rather than contacts.

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 'Use for prospecting, building contact lists, or enriching CRM records,' giving clear usage context. However, it does not mention when not to use it or how it compares to alternatives like linkedin_search_leads or clay_enrich_person, so it falls short of a perfect 5.

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