Klarix Intelligence Engine

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

Beyond the annotations (readOnlyHint=true, openWorldHint=true), the description discloses that it researches the live public web, tests claimed advantages against evidence rather than accepting them, and reports unsupported claims back instead of repeating them. This evidence-verification behavior is genuinely additive and shapes agent expectations about output reliability. It does not explicitly mention non-deterministic results across calls, but idempotentHint=false combined with live public web research covers that implication.

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 dense sentences front-load the purpose and then compress the deliverable list, identification options, and evidence-honesty behavior into tight parentheticals. Every sentence earns its place, and the structure mirrors how an agent should read it: what it does, what it returns, and how to identify 'us'.

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

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

For a complex 8-parameter research tool, the description covers purpose, output composition, side identification, and evidence handling, while the output schema and annotations cover the remaining details. The only notable gap is the absence of explicit differentiation from siblings like generate_displacement_playbook and get_competitor_battlecard, which partially overlap in outputs. Still, the description stands alone well enough to invoke correctly.

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

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

Schema description coverage is 100%, with every one of the 8 parameters carrying a meaningful description, including client_id override semantics and the our_advantages evidence-testing behavior. The description adds only a small pointer to the identification trio (our_domain, our_company_name, client_id), so the schema carries the parameter burden. A baseline 3 is appropriate given the schema's thorough coverage.

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

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

The description opens with a specific verb and resource, 'Compare YOUR company against a specific competitor or incumbent you want to displace', and enumerates a distinctive deliverable set: asymmetric advantages, defensive moats, a fixed four-dimension comparison matrix, talk tracks, landmines, and a three-step displacement strategy. This output list clearly differentiates it from siblings like get_competitor_battlecard and generate_swot_analysis even without naming them.

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 frames a concrete scenario, displacing a specific competitor in a live evaluation with spoken talk tracks and landmines for that event, which tells an agent when this tool is the right choice. It does not explicitly name alternatives or when-not-to-use conditions, but the displace-plus-live-evaluation framing provides clear context. The instruction to identify your side via our_domain, our_company_name, or client_id also orients the agent on which input path to take.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds no extra behavioral detail such as data freshness, external dependencies, ranking logic, or rate limits, but it does not contradict the annotations either. The event-type list is informative but not deeply behavioral.

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

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

The description is a single, front-loaded sentence that names the action, the object, relevant event categories, and the timeframe constraint. There is no filler or redundant phrasing.

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 8 parameters and an output schema, the description gives enough functional context but omits the 'first touch' concept mentioned in the title and does not explain how optional context parameters like client_id or our_domain shape results. The output schema and annotations cover some of this, but the missing title concept is a notable gap.

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

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

Schema description coverage is 100%, so the baseline is 3 and parameters are already well documented. The description's examples of inflection points add a little flavor to what 'triggers' means, but it does not add meaning beyond the schema for parameters like timeframe_days or target_domain.

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 ('Detect'), a clear resource ('account inflection points'), and gives concrete event examples (leadership changes, funding, hiring surges). It is clearly distinct from sibling tools like generate_swot_analysis or get_company_intelligence, though it does not explicitly name a sibling to differentiate from.

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

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

The description implies this tool is for finding recent interesting events about an account, but it provides no explicit guidance on when to choose it over get_company_intelligence, get_deep_research, or find_matched_prospects. There are no stated exclusions, prerequisites, or alternative conditions.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds meaningful context beyond that: it explains screening for buyer-vs-vendor role and corporate status, that withheld candidates are reported, and that results are raw similarity-ranked candidates rather than qualified accounts. This is useful behavioral nuance, though it doesn't cover runtime limits or error cases.

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 the core purpose, and every sentence adds value: the method, the screening behavior, the caveat about similarity, and the explicit next step. There is no filler or repetition of schema details.

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

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

Given the rich input schema, output schema, and annotations, the description is complete enough. It explains the high-level retrieval and screening behavior, clarifies the meaning of the similarity score, and tells the agent when to route to score_prospect_fit, which is all an agent needs to call 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?

Schema description coverage is 100%, so the schema carries the parameter meaning. The tool description adds no parameter-specific insight beyond what the schema already provides, so it meets the baseline but does not exceed it.

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: building a first-pass candidate list of B2B companies via semantic vector search. It also explicitly frames the output as a candidate net, not a qualified list, and names score_prospect_fit as the follow-up, which distinguishes it from sibling tools.

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

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

It clearly identifies when to use the tool: for a first-pass candidate list before scoring. It also gives an explicit exclusion by warning that the similarity figure is not a fit score and that every account should go through score_prospect_fit before outreach.

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

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

Annotations already provide readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. It adds the output components but does not disclose process traits such as external research behavior or variability on repeated calls. 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 a single front-loaded sentence: it opens with the verb and deliverable, then lists the concrete sub-components. Every word earns its place, with no filler or repetition.

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

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

The tool has an output schema, fully described parameters, and safety-relevant annotations, so the description need not explain return values or parameter mechanics. The main gap is the missing usage-versus-sibling guidance, but overall the definition is sufficient for an agent to call 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?

Schema description coverage is 100%, and each parameter has a detailed explanation with examples and override semantics. The description itself adds no parameter details, so the baseline of 3 applies because the schema carries the burden.

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

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

The description states a specific action ('Generate') and a specific deliverable ('end-to-end competitive displacement playbook') with concrete components: switching cost mitigations, POC blueprints, and migration timelines. This clearly separates it from sibling tools like generate_swot_analysis or analyze_head_to_head, even without naming them.

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

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

No sentence explains when to use this tool versus alternatives such as generate_swot_analysis, analyze_head_to_head, or get_competitor_battlecard. There are no conditions, exclusions, or recommendations, so an agent must infer usage from the name alone.

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

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

The annotations already indicate readOnlyHint and openWorldHint, but the description adds valuable behavioral constraints: it enforces the Klarix voice contract, reports violations, writes only to job titles, and never emits contact details. This goes well beyond what annotations provide and clarifies the tool's exact output 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 four sentences, each carrying essential information: the core method, supported formats, enforced voice contract, and hard constraints. It is front-loaded with the primary purpose and contains no filler or redundant restatements of the title.

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 generative tool with a clear input schema, strong annotations, and an existing output schema, the description covers all necessary context. It explains the research basis, the deliverable formats, the compliance checks, and the boundary conditions (no contact details, no individual names). No critical behavioral gap remains.

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 meaningful semantics by explaining what each channel produces (3-step email, 3-step LinkedIn, 6 multivariant openers) and reinforcing the target_title constraint ('never to an individual'). This is genuine added 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 opens with a specific verb and resource ('Write cold outreach') and immediately differentiates the tool by its insight-first approach. It also enumerates the three concrete deliverable types (email sequence, LinkedIn sequence, multivariant openers), which clearly separates it from sibling analysis and research tools.

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

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

The intended use case is clear: generating cold outreach sequences across specific channels. While it does not explicitly name sibling tools to avoid, the channel breakdown and focus on outreach make the context obvious. It lacks an explicit 'when not to use' or direct alternative comparison, but the guidance is sufficient 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 declare readOnlyHint=true and openWorldHint=true; the description aligns by disclosing a 'deep multi-source web crawl' and adds the nuance that exploit vectors are added only after the tool determines whether you actually compete. It also promises evidence and consequence per entry, which annotations don't convey. It doesn't directly address idempotentHint=false, but nothing contradicts 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?

Five dense sentences, all substantive: the first defines the output and quadrants, the second promises evidence and consequence, the third adds exploit/counter-play, the fourth explains customization, and the fifth states the return type. No filler, no restatement of the title, and the most important information is front-loaded.

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

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

For an 8-parameter, open-world research tool, the description is nearly complete: it covers inputs, customization, behavioral nuances, and output format while the output schema and annotations carry the rest. It does not enumerate exclusion criteria, but no critical invocation information 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?

With 100% schema description coverage, the schema already documents each parameter thoroughly. The description adds only aggregate curation guidance ('Curate it to your own business with our_company_name, our_domain, our_differentiators, or a Klarix client_id') and the competitor_viewpoint override behavior, which is useful but not new per-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?

States the exact deliverable — a four-quadrant SWOT matrix for a company — and explains each quadrant's content plus the unique additions of exploit vectors and counter-plays. It also names the output format (markdown plus structured JSON). No sibling tool covers SWOT, so the definition clearly differentiates it.

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

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

Clearly implies when to use it: to research a company and produce competitive strategy customized to your own business or a Klarix client. However, it never explicitly names sibling alternatives or states when not to use it, such as when a battlecard or head-to-head analysis would be more appropriate.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds what the output covers, but it does not disclose any behavioral caveats such as reliance on public web signals, data completeness, or how the multi-threading strategy is derived. No contradiction exists, but the description adds only modest behavioral context beyond annotations.

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

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

A single, dense sentence that front-loads the core action and resource, then compactly lists the key outputs. Every part earns its place, with no filler or repeated schema content.

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

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

Given an output schema, full parameter documentation, and read-only annotations, the description is largely sufficient for an agent to understand what will happen. The main gap is the lack of sibling differentiation and usage guidance, which matters in a crowded tool list, but the core invocation context is complete.

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

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

Schema description coverage is 100%, and all seven parameters already have detailed, meaningful descriptions. The tool description adds no parameter-level semantics beyond naming the output categories, so the 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 ('Map') and a specific resource ('internal buying committee'), and enumerates the four seats plus deliverables (title patterns, pain points, objections, multi-threading strategy). It is clearly about buying-committee mapping, but it never distinguishes itself from sibling research tools like get_company_intelligence or get_deep_research, so it stops short of a 5.

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 no guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites. 'For an account' is only a scope statement, not a usage rule. The agent is left to infer that this is for account-level buying-committee research without knowing which sibling tool to prefer.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds meaningful behavioral context: it synthesizes from live public web sources, includes dated buying signals and stated unknowns, and guarantees source URLs for every claim. This goes beyond what the annotations alone convey, though it does not discuss edge cases like source unavailability or citation failure.

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

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

The description is two sentences with no filler: the first sentence delivers the core purpose and output components, and the second enumerates focus areas. Information is front-loaded and every clause earns its place.

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

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

Given the rich input schema, output schema, and annotations, the description covers the essential behavioral contract: what it synthesizes, which focus areas are supported, the cited nature of the output, and key constraints like leadership roles only. Nothing critical is missing 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?

Schema description coverage is 100%, so the schema already documents domain and focus_areas including the default and the 'leadership' specifics. The description reinforces the focus-area list and 'roles only' constraint, adding marginal interpretive value but not significantly surpassing 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 names a specific verb and resource: synthesize an executive one-pager on a company from live public web sources. It enumerates the output components (snapshot, findings per focus area, dated buying signals, deal risks, stated unknowns) and states every claim carries a source URL, making the tool's function concrete and distinguishable from sibling research tools.

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

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

The description implies usage: call this when a cited executive one-pager on a company is needed, with focus areas controlling depth. However, it does not explicitly state when to prefer this over siblings like get_deep_research or get_market_landscape, nor does it list any exclusions or alternative conditions.

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 annotations by disclosing methodology: SWOT is 'from their point of view', the battlecard uses 'buyer-reported reality', and 'every claim cites a public source.' It also exposes override semantics through the client_id schema description ('Explicit arguments always override it') and the live/non-idempotent nature via 'live' and openWorldHint. No contradictions with annotations.

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

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

Three sentences carry the full scope: output contents, sourcing guarantee, optional customizations, and selling outcome. The core purpose is front-loaded, and every clause adds information without redundancy or 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 six parameters, annotations, and an output schema, the description covers what the tool produces, how it sources claims, optional targeting, and how to customize for a company. It also clarifies the client_id fallback behavior. Nothing critical for an agent 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 description coverage is 100%, so each parameter is already documented in detail. The main description adds useful grouping—optional params 'curate it to your own business'—but does not provide significant new per-parameter semantics beyond the schema. Baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource ('Build a live sales battlecard for a competitor domain') and enumerates the concrete outputs: SWOT from competitor POV, marketing-vs-reality gap, landmines, and talk tracks. This clearly distinguishes it from sibling tools like generate_swot_analysis or analyze_head_to_head by emphasizing the battlecard and talk-track angle.

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

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

The description implies when to use the tool ('battlecard', 'talk tracks your seller can actually defend') and explains optional customization, but it never explicitly contrasts it with sibling tools such as generate_swot_analysis, analyze_head_to_head, or generate_displacement_playbook. An agent has to infer the boundary from the battlecard framing rather than being given direct selection 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?

Beyond the readOnly/openWorld annotations, it discloses that every finding includes a citation and implication, that executive names are allowed only when cited and contact details are never included, and that risk analysis surfaces explicit unknowns. This gives an agent accurate expectations for output content and policy.

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 prose is dense but organized around dimensions, then depth behavior. It loses a point because the final depth sentence largely duplicates the depth parameter's schema description, which is redundant next to structured data.

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

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

For a complex research tool, it covers the input domain, the five research areas, output expectations (citations, implications, unknowns), and depth trade-offs. The presence of an output schema covers return structure, so nothing needed to select or invoke the tool 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 description coverage is 100%, so the schema already documents domain, depth, and focus_topics adequately. The description adds no new parameter-level semantics; it merely restates the depth default from 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 opens with 'Exhaustive intelligence probe on a company' and enumerates five concrete research dimensions, giving a specific verb, resource, and scope. The dimensions and 'cited' framing differentiate it from narrower siblings like teardown_tech_stack or generate_swot_analysis, even without naming them.

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 provides internal depth-selection guidance ('Defaults to depth standard... request comprehensive...') but never states when to choose this tool over sibling research tools. There are no exclusions or alternative routing cues, so an agent gets no help choosing between get_deep_research and get_company_intelligence.

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 readOnly and openWorld behavior, and the description adds useful context: results are drawn from live public sources, output ends with buyer shifts and entry wedges, and both markdown and structured JSON are returned. The optional pricing-benchmark flag is also framed as a speed trade-off. 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?

Three sentences front-load the core action and scope, then enumerate outputs and return format. Every clause contributes meaning and there is no filler or repetition of schema boilerplate.

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 3-param tool with a full output schema and strong annotations, the description covers scope, method (live public sources), deliverable types, and the main option. An agent has enough information to invoke it correctly; the only gap is explicit sibling routing, which is already captured under usage_guidelines.

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 three parameters. The description mostly restates the same semantics, such as skipping pricing queries for speed, without adding material parameter-level detail; no compensation is needed at this coverage level.

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 ('Map'), a specific resource (a competitive landscape for an industry or vertical), and enumerates concrete deliverables: incumbents vs disruptors, positioning quadrants, pricing, narrative themes, and entry wedges. This clearly differentiates it from sibling company- or product-level tools like get_competitor_battlecard or teardown_product_spec.

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 intended use is clear from the description, but it never explicitly states when to use this tool instead of a sibling, nor when not to use it. Selection is left to inference from the 'industry or vertical' scope rather than being explicitly routed.

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 readOnlyHint and openWorldHint annotations already signal a non-mutating, externally informed tool, and the description adds substantial behavioral context: it uses live public web evidence, cites every claim, scores roles rather than individuals, and returns no contact details. The 'live public web evidence' claim also usefully explains the idempotentHint: false annotation without contradicting any annotation.

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 tightly structured: the first sentence front-loads the core scoring mechanics and threshold, the second explains the evidence base, and the final sentences cover customization and privacy constraints. Every sentence earns its place, with no filler or repetition of the tool name.

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 an output schema, detailed parameter descriptions, and strong annotations, the description is nearly complete for a scoring tool. It covers the scoring axes, threshold, evidence source, citation behavior, customization options, and privacy boundary. The only notable gap is that it does not explicitly state what happens when neither client_id nor icp_description supplies an ICP, which could matter for an agent deciding whether a valid call requires one of them.

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% parameter coverage, so the baseline is 3. The description adds genuine meaning beyond the schema by explaining how client_id can supply the ICP and make icp_description optional, and how our_company_name, our_domain, and our_differentiators curate the score toward 'how YOU win.' It does not add much for vertical or ideal_tech_stack, but the schema descriptions are already sufficient.

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 object — 'Score a company against your ICP' — and immediately names the five weighted axes, the 1-10 scale, and the 7+/10 pursue threshold. It also sets clear boundaries versus sibling tools by noting it 'Judges roles, never individuals' and 'returns no contact details,' making its purpose and distinct scope 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 gives clear context for when the tool applies: scoring a prospect company against your ICP using live public web evidence, and curating the score with your own company details or a Klarix client_id. It does not explicitly name alternative sibling tools or state when not to use this tool, so it stops short of full routing guidance, but no exclusions are needed for the core use case.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint; the description adds substantial behavioral detail beyond that: it queries multiple indexes, merges duplicates, ranks by citation count then recency, returns specific fields including a verbatim abstract extraction, and discloses the keyless rate-limit escape hatch. No contradiction exists between description and annotations.

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

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

Four sentences, each earning its place: purpose, sources and ranking, return payload, and rate-limit note. The most decision-relevant information is front-loaded, and there is no redundant restatement of title or 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 tool with four parameters and an output schema, the description covers inputs, source behavior, ranking, deduplication, return fields, and operational constraints (keyless rate limit). An agent has everything needed to invoke it correctly without inferring hidden behavior.

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 four parameters. The description adds context about default merging behavior and the ranking order, but it does not significantly elaborate on parameter formats beyond what the schema already provides, so the 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?

States a specific verb and resource: 'Retrieve verifiable academic and engineering literature' from Semantic Scholar and arXiv. The purpose is anchored to a concrete outcome ('so a claim can cite a resolvable DOI instead of a vendor blog post'), and the described scope clearly differentiates it from the sales-oriented sibling tools.

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

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

The description gives clear context: use when a technical claim needs a verifiable academic citation rather than a vendor source. It does not explicitly name alternatives or exclusion conditions among siblings like get_deep_research, but the intended scenario is stated plainly enough to guide 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 already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered by structured data. The description adds useful behavioral context by disclosing deliverable-specific traits: verified images/diagrams, datasheet links, certifications, and displacement seams. It does not fully explain how verification is performed, but given annotation coverage, the additional disclosure is meaningful.

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

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

The description is a single sentence led by the action and object, with the deliverable list placed early. 'Institutional-grade' is mild filler, but the rest is dense and informative. It is concise without sacrificing the tool's distinctive output details.

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

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

For a complex 10-parameter tool, the description plus full parameter descriptions and an output schema provide enough for an agent to select and invoke it correctly. It could go further by explaining how the optional 'our_*' inputs feed displacement-seam analysis, but that is not essential because the schema already documents each parameter's role.

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

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

Schema description coverage is 100%, and each parameter already has rich, actionable descriptions (e.g., target_domain, spec_category enum, client_id loading context, product_name_or_model fallback to flagship offering). The description adds some framing like 'displacement seams' and the range of physical/software domains, but it does not need to compensate for schema gaps since there are none.

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

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

The description states a specific action ('Deconstruct') and resource class ('physical hardware device, battery pack, medical system, or software API') and names concrete outputs: technical specification table, exact units, tolerances, verified images/diagrams, datasheet links, certifications, and displacement seams. This clearly differentiates it from siblings like teardown_tech_stack, which would target a technology stack, and generate_displacement_playbook, which focuses on playbooks rather than specifications.

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

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

The description implies the use case: deep product teardown into an institutional-grade specification table with verified artifacts. However, it never explicitly says when to choose this tool over alternatives such as teardown_tech_stack, analyze_head_to_head, or generate_displacement_playbook, and it provides no exclusions or conditions for 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 readOnlyHint=true and openWorldHint=true, so the description is not responsible for safety disclosure. The description adds only outcome-level context (displacement vulnerabilities) and the title hints at a confidence distinction (confirmed vs inferred), but it does not explain confidence levels, data-freshness, or that results may be based on live research. 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?

One tightly worded sentence delivers the verb, resource list, and intended analytical outcome; the key scope ('account's technical infrastructure') is front-loaded. No filler, redundant clauses, or irrelevant caveats. The title adds the confidence/displacement framing without bloating the description.

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 rich input schema (8 documented params), output schema, and read-only/open-world annotations cover most operational facts an agent needs. The main gap is placement: no indication of when to choose this over adjacent tools like generate_displacement_playbook or teardown_product_spec. That keeps it at a solid but not fully complete level for a tool of this complexity.

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

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

Schema description coverage is 100%, with each of the 8 parameters having descriptive text (e.g., target_domain, focus_areas, our_differentiators). The tool description itself adds no parameter-level meaning, so it appropriately stays at the baseline. Nothing is missing because the schema already carries the burden.

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 ('Deconstruct') with a precise resource list ('technical infrastructure, dev tools, cloud providers, AI/data stack') and a named outcome ('identify displacement vulnerabilities'). This clearly marks the tool as a stack-analysis action rather than a product-spec or playbook tool. The title's 'confirmed vs inferred + displacement angles' reinforces the distinctive scope.

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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternatives, despite 14 siblings such as generate_displacement_playbook or get_deep_research. It is inferable from the title and resource that this is for tech-stack teardown, which is enough for a minimum-viable score. But the description leaves the agent to infer how it relates to adjacent research and playbook tools.

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