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

Annotations declare readOnlyHint=true and openWorldHint=true, so the safety profile is already covered. The description adds genuine behavioral context beyond that: the output is a bounded 0–100 index and confidence scales with how many metrics are supplied, which tells the agent this is a tolerant, partial-input scoring call.

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 short sentences, front-loaded with what is produced before how to use it and how input affects confidence. No filler or restated 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?

With no output schema, the description carries the return-value burden and does so adequately: the 0–100 index and the '#1 growth constraint' output are named. It does not describe the shape of the remaining response fields, but an agent has enough 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 the metrics object already enumerates every accepted field with percentage-formatting rules, so the schema does the heavy lifting. The description's metric families ('stage-fit, confidence, NRR / CAC-payback / pipeline-coverage') roughly mirror those inputs but do not add syntax or format meaning 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?

States a specific verb and resource ('Scores a company's Revenue Readiness Index (0–100)') plus the input basis (operating metrics) and the headline output (score plus #1 growth constraint). This clearly separates it from siblings like get_portfolio_readiness_rollup, which aggregates rather than scoring one 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?

Gives concrete usage contexts ('screen a target or assess a portfolio company') and a practical rule for input handling ('Pass the metrics you have; more metrics = higher confidence'). It stops short of naming an alternative tool or an explicit when-not-to-use condition.

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, indicating safe read operations with flexible inputs. The description adds valuable behavioral context beyond annotations: the 50-company limit, performance expectation ('under a second'), and output structure ('individual scores plus aggregate statistics'). 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?

Two sentences with zero waste. First sentence establishes purpose and scope, second sentence describes output. Perfectly front-loaded with essential information, no 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 read-only batch scoring tool with good annotations and full schema coverage, the description provides adequate context about purpose, constraints, and output. The main gap is lack of output schema, but the description compensates by describing return values ('individual scores plus aggregate statistics'). Could be more specific about scoring methodology.

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 input schema fully documents the single parameter and its nested structure. The description adds minimal parameter semantics beyond the schema, only mentioning the 50-company limit which is already in the schema description. Baseline 3 is appropriate when schema does the heavy lifting.

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 specific action ('Score up to 50 companies at once'), the resource ('companies'), and the output ('gives each a tier and score'). It distinguishes from sibling tools like 'get_icp_fit_score' by emphasizing batch processing and ranking capabilities.

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

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

The description provides clear context for when to use this tool ('to rank a list in under a second') and implies it's for batch processing rather than single-company scoring. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.

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

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

Annotations indicate readOnlyHint=true and openWorldHint=true, which the description does not contradict. The description adds behavioral context by mentioning it 'combines multiple scoring engines' and outputs a verdict, which goes beyond annotations. However, it lacks details on rate limits, error handling, or performance characteristics that would be useful for an agent.

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

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

The description is front-loaded with the core purpose in the first sentence and efficiently lists outputs without redundancy. Every sentence adds value by clarifying scope and methodology, making it appropriately sized and well-structured for quick comprehension.

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 (16 parameters, no output schema) and annotations covering safety, the description adequately explains what the tool does and its comprehensive nature. However, without an output schema, it could benefit from more detail on the return format (e.g., structure of the verdict) to be fully 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%, so the schema fully documents all 16 parameters. The description does not add any parameter-specific details beyond what the schema provides, such as explaining relationships between parameters or usage tips. This meets the baseline for high schema 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 clearly states the tool's purpose with specific verbs ('run a full read on a deal') and resources ('deal'), listing the comprehensive outputs (fit score, persona match, risk flags, disqualification check, verdict). It effectively distinguishes from siblings by emphasizing it 'combines multiple scoring engines for a comprehensive assessment,' unlike more focused sibling tools like 'get_icp_fit_score' or 'get_disqualification_signals'.

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 context by stating it provides a 'full read' and 'comprehensive assessment,' suggesting it should be used for holistic deal evaluation rather than piecemeal analysis. However, it does not explicitly state when not to use it or name specific alternatives among the sibling tools, which prevents a perfect score.

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 only declare readOnlyHint and openWorldHint. The description adds the traits that actually matter for a paid, stateful tool: $3 per turn, one consultation turn per call, and that conversation state only persists via `history`. That is substantive disclosure beyond the structured fields.

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?

Front-loads the core action, then cost, then turn/history mechanics, then module selection. Four dense sentences with no filler and no 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?

No output schema exists, yet the description tells the agent what comes back (a domain-scoped answer). It covers cost, statefulness, continuation, and agent selection, leaving nothing an agent needs in order 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 coverage is 100%, so baseline is 3, but the description adds meaning the schema lacks: `history` is the mechanism for continuing a conversation ('pass prior turns as `history` to continue'), and `module` selects the expert. The enumerated module values largely duplicate the schema, so it is not a full 5.

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

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

States a specific verb ('Consult'), a specific resource ('domain expert agents'), and the output shape ('domain-scoped answer'). The consult-a-domain-expert action is clearly distinguishable from the surrounding get_*/generate_* siblings, so an agent can pick it correctly without opening schemas.

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

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

Gives real context: it may call free lookup tools but paid tools must be called directly, and continuation is done by passing prior turns as `history`. This effectively implies a when-not (for paid operations, call those tools directly). It stops short of naming sibling alternatives, so it falls just under 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 only cover readOnlyHint and openWorldHint. The description adds genuinely new behavioral facts: it can take up to a couple of minutes (latency), nothing is charged when no company has sourced evidence (a conditional billing model), and every piece of evidence is backed by a linked source page (output trust model). That is exactly the extra context annotations cannot carry.

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 tight sentences, front-loaded with the core purpose before the mechanism and the operational caveats. No filler, though the latency/billing sentence could be slightly more compact. Every sentence adds information.

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

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

With no output schema, the description carries the return-value burden, and it handles that by stating that every claim is backed by a linked evidence page. It also covers latency and cost. All five parameters are optional and schema-covered, so the remaining gap is minor (no guidance on result volume or how to narrow a search).

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 each of the five parameters is already documented in the input schema, including the 'defaults to the product saved on your account' behavior for companyName and productDescription. The description's mention of the saved product context repeats rather than extends the schema, so the baseline 3 applies.

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

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

States a concrete verb and resource: 'Finds real companies likely to buy your product', amplified by 'Searches the web for companies showing they have the problem you solve right now'. An agent can immediately tell this is a web-sourced prospect discovery tool, distinct from the get_*/list_* siblings. It stops short of explicitly naming any sibling, so it doesn't earn 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?

Usage is implied rather than prescribed: it explains the signal types it looks for (hiring, launches, funding, expansion) and that it runs against the saved product context, which tells an agent when this is the relevant tool. But there is no explicit when-to-use vs. an alternative, and no stated prerequisites (e.g. needing product context set first) beyond the soft 'uses the product saved on your account'.

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 only say readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds genuinely valuable behavior beyond that: per-tier pricing ($3/$12/$49), a free first ICP, an async 'up to a few minutes' duration, a job_id return, and persistence to the Andru library. Cost, latency, and persistence semantics an agent could not infer are all disclosed.

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

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

Front-loaded with the core action and examples, then packed with cost, latency, and return mechanics. Dense but every clause carries distinct information. Slightly congested with parenthetical pricing detail, but nothing is wasted.

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 the async job_id return and the follow-up get_asset call. Cost, latency, and save destination are all covered, so an agent has everything needed to invoke and follow through 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 coverage is 100% and the sole parameter's purpose is documented in the schema. The description still adds value by clarifying the value must come from list_assets and by giving example asset names, though it doesn't specify name format or handling of invalid names.

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 ('Generate an asset from Andru's catalog') and grounds it with concrete examples ('Board Presentation', 'Buying Committee Navigation'). It also distinguishes itself from siblings by naming list_assets as the discovery path and get_asset as the retrieval path.

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 routes the agent: find the asset name via list_assets, and retrieve the result via get_asset using the returned job_id. This gives clear context for the generate step. It stops short of stating when NOT to generate (e.g., cost gating or prerequisites), so it isn't a full when/when-not treatment.

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 useful content-scope context (what the brief contains), but says nothing about output format, latency, or the fact that portfolioId must belong to the caller beyond what the schema notes. Adds some value over annotations, but not rich behavioral detail.

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

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

Two tight sentences: the first front-loads the core purpose and contents, the second gives the audience/use-case. No filler, and the most important information leads.

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?

There is no output schema, so the description must carry return-value burden; it does so adequately by naming the brief's components (per-company performance, market context, cross-portfolio opportunities). Missing practicals such as format and whether the brief is persisted, but it is largely complete for a read-only report generator.

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 periodStart/periodEnd/periodType/portfolioId each documented and defaults stated in the schema. The description only alludes to 'a reporting period' and adds no syntax or format detail beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific verb (Generates) plus the resource (a board/LP-grade intelligence brief for a portfolio) and enumerates the contents (per-company performance, market context, cross-portfolio opportunities). The audience/use-case framing (PE/VC fund reporting) further narrows it against generic reporting siblings. An agent can tell this apart from get_portfolio_readiness_rollup or get_pre_brief without opening a schema.

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 scopes usage with 'For PE/VC fund reporting and quarterly reviews,' giving clear context for when to invoke it. It does not name any alternative tool or a when-not condition, so it stops short of full routing guidance.

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

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

Annotations indicate readOnlyHint=true and openWorldHint=true, showing it's a safe, generative operation. The description adds context about generating a comprehensive plan with specific components, which goes beyond annotations. However, it doesn't disclose behavioral traits like rate limits, processing time, or output format details.

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, efficient sentence that front-loads the core purpose ('Builds the account plan') and lists key components without unnecessary details. Every part of the sentence adds value, making it appropriately sized and structured.

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

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

Given the tool's complexity (5 parameters with nested objects) and lack of output schema, the description provides a good overview of what the tool generates. However, it could be more complete by hinting at the output format or depth of analysis, especially since no output schema exists to clarify return values.

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 parameters are well-documented in the schema. The description doesn't add specific meaning beyond the schema, such as explaining how parameters influence the plan generation. The baseline score of 3 is appropriate since the schema carries the parameter documentation 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 clearly states the tool's purpose: it 'builds the account plan' with specific components like stakeholder map, messaging needs, MEDDICC gaps, and unified story. It uses a specific verb ('builds') and resource ('account plan'), and distinguishes itself from siblings by focusing on comprehensive planning rather than scoring, classification, or profiling.

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 context by mentioning 'you'd normally spend a weekend on' and referencing a 'buying committee,' suggesting it's for complex sales scenarios. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_sales_blueprint' or 'get_pre_brief,' nor does it provide exclusions or prerequisites.

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

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

With annotations covering only the safety profile (readOnlyHint/openWorldHint), the description adds the behavioral details that matter: it is a polling call whose response changes shape (progress while building, full asset when complete), the payload format is markdown, the result is persisted to the Andru library, and there is no cost. These are traits an agent cannot infer from the schema or annotations.

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

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

Two tight sentences with no filler: the action and its prerequisite come first, followed by the state-dependent return behavior. Everything earns its place, including the trailing cost note.

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?

There is no output schema, so the description carries the return-value burden and does so by describing both possible responses (progress vs full markdown asset). For a one-parameter polling tool this is sufficient to call and interpret 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 the single parameter's description already states it is the job_id from generate_asset. The description adds no syntax, format, or lifecycle detail (e.g. expiry) beyond that, so the baseline of 3 applies.

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

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

States a specific verb (collect) and resource (asset) and ties it explicitly to the producing tool, generate_asset. This clearly separates it from siblings like generate_asset (which creates the job) and list_assets (which enumerates existing assets).

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?

Tells the agent when to call it (after generate_asset, with the returned job_id) and what to expect at each stage. No explicit when-not or alternatives are given, but the dependency on generate_asset makes the usage context unambiguous.

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

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

Annotations already indicate read-only and open-world hints, so the agent knows this is a safe, non-destructive query with flexible data. The description adds value by specifying the tool's design intent ('buyer-side agent evaluation') and the snapshot's content scope, but it does not disclose additional behavioral traits like rate limits, authentication needs, or caching behavior beyond the forceRefresh parameter in the schema.

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

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

The description is front-loaded with the core purpose in the first sentence and efficiently adds context in the second sentence. Every phrase ('machine-readable snapshot,' 'buyer-side agent evaluation') contributes meaning without redundancy, making it appropriately sized and zero-waste for a tool with clear annotations and 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?

Given the tool's complexity (retrieving a comprehensive product profile) and the presence of annotations (readOnlyHint, openWorldHint) and full schema coverage, the description is mostly complete. It outlines the snapshot's components and the tool's design intent. However, without an output schema, it could benefit from hinting at the return format (e.g., structured data like JSON), but this is a minor gap given the annotations provide safety context.

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

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

Schema description coverage is 100%, so the schema fully documents the three optional parameters (includeOutcomes, includeTrustSignals, forceRefresh) with their defaults. The description does not add any parameter-specific semantics beyond what the schema provides, such as explaining the implications of 'verified outcomes' or 'trust signals,' but this is acceptable given the high schema coverage, resulting in a baseline score of 3.

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

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

The description clearly states the specific action ('Returns a machine-readable snapshot') and resource ('what your product actually does and who it's for'), listing key components like capabilities, outcomes, trust signals, pricing, and integrations. It explicitly distinguishes this tool from siblings by noting it's 'Designed for buyer-side agent evaluation,' which none of the sibling tools mention.

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 for when to use this tool ('Designed for buyer-side agent evaluation'), which helps differentiate it from siblings focused on scoring, classification, or data retrieval. However, it does not explicitly state when not to use it or name specific alternatives among the siblings, such as get_icp_profile or get_persona_profile, which might overlap in purpose.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuine beyond-schema context: the output differs based on inputs (overlap/differentiation/fit vs. likely buyer concerns) and that the call is "Free", a useful cost trait. It doesn't cover latency or result ranking, keeping it short of a 5.

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

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

Front-loaded with the core purpose, then the input-driven behavior, then the alternative — three tightly ordered sentences with no filler. 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?

For a read-only comparison tool with fully documented parameters and no output schema, the description supplies the missing pieces: what the output represents and how it varies, plus the escape hatch to the asset-generation sibling. Nothing needed to invoke it correctly 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 coverage is 100%, so baseline is 3, but the description goes beyond the schema by explaining the conditional effect of `competitorFeatures` (what you get with vs. without them). The schema itself carries the infer-from-context guidance for the other params, which is strong.

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+resource and frames it precisely ("How you compare with a specific competitor, from the buyer's point of view"), which is distinct from sibling analysis tools like get_icp_fit_score or get_evaluation_criteria. It also names the sibling (generate_asset) it is not, so an agent can route without opening schemas.

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 conditions behavior on the presence of `competitorFeatures` and names the alternative route for a shareable output ("For a written comparison to share, generate the Competitive Positioning Framework with `generate_asset`"). Both the when-to-use and the alternative are 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 declare readOnlyHint=true and openWorldHint=true, indicating a safe, exploratory operation. The description adds behavioral context by explaining the three analysis layers (ICP fit, anti-pattern matching, churn patterns) and the actionable outcome ('tells you whether to keep investing or walk away'), which goes beyond annotations. However, it does not disclose details like rate limits, authentication needs, or specific output format.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by specific analysis details and outcome. It uses two efficient sentences with zero wasted words, each earning its place by clarifying the tool's function and value.

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

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

Given the tool's complexity (10 parameters, nested objects) and lack of output schema, the description is reasonably complete for a read-only analysis tool. It explains the analysis method and decision outcome, but does not detail the return format (e.g., score, reasons, confidence) or error handling, which could be important given the open-world hint.

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 fully documents all 10 parameters. The description does not add any parameter-specific semantics beyond what the schema provides, such as explaining how 'techStack' influences disqualification or how 'dealContext' affects the analysis. It only implies general usage of company and deal data.

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 with specific verbs ('find out', 'runs', 'tells you') and resources ('company', 'three layers of signal'), and distinguishes it from siblings by focusing on disqualification signals rather than scoring, classification, or prospecting. It explicitly answers 'whether to keep investing or walk away', which is unique among the listed 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 provides clear context for when to use this tool ('wasting time on a deal that won't close'), but does not explicitly state when not to use it or name alternatives among siblings. It implies usage for deal evaluation but lacks explicit exclusions or comparisons to tools like 'classify_opportunity' or 'get_icp_fit_score'.

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 only declare readOnly and openWorld, so the description must carry the behavioral load — and it does, disclosing the return shape (0-100 per dimension plus overall alignment), the scoring logic, and that the tool is free. It stops short of describing failure modes or latency, but the core behavioral picture is clear.

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 ordered as what-it-does, what-it-returns, what-to-pass, when-to-use — strongly front-loaded. Slightly dense with backtick-heavy parameter references, but no wasted sentences.

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 present, the description correctly compensates by explaining the return values (0-100 per dimension plus overall). Combined with the alternative-tool routing and the 'Free' cost note, an agent has enough to invoke this confidently; only minor gaps like required-vs-optional param framing remain.

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 already 100%, so the 3 baseline applies, but the description adds real value by linking specific parameters to specific outputs — buyerPainPoints drives pain coverage and requiredCapabilities drives capability fit. That causal mapping is not derivable from 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?

States a specific verb ("Scores") and resource (match quality against buyer needs), enumerates the dimensions covered (pain coverage, outcome clarity, capability fit, +3 more), and names the sibling it is distinct from. An agent can tell it apart from get_icp_fit_score without opening either schema.

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 routes usage: use get_icp_fit_score to decide whether a company is worth pursuing at all, and this tool 'once you know what the buyer needs.' Both the alternative and the selecting condition are stated outright.

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 (safe read) and openWorldHint=true (returns varied data). The description adds valuable behavioral context: it specifies the output is 'organized by memory type (What I Know, Patterns I've Noticed, How You Operate)' and that it provides 'accumulated intelligence.' This goes beyond annotations by detailing the structure and nature of the intelligence returned. 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 perfectly concise: two sentences that each earn their place. The first sentence defines the tool's purpose and output structure, while the second provides clear usage guidelines. No redundant information, well-structured, and front-loaded with essential information.

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

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

For a zero-parameter tool with readOnly and openWorld annotations, the description is quite complete. It explains what the tool returns (full context dump organized by memory types) and when to use it (priming revenue conversations). The main gap is the lack of output schema, so the description doesn't specify exact return format details, but it provides enough semantic context for effective use.

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 0 parameters, and schema description coverage is 100%. With no parameters to document, the baseline is 4. The description appropriately doesn't waste space on parameter details, focusing instead on the tool's purpose and output characteristics.

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: 'Get a full context dump of everything Andru knows about this founder — organized by memory type.' It specifies the resource (founder context), the verb (get), and the organizational structure (memory types). It also distinguishes from siblings by focusing on comprehensive founder intelligence rather than specific aspects like wellness, capability, or competitive positioning.

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

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

The description explicitly states when to use this tool: 'Used to prime any revenue conversation with accumulated intelligence.' This provides clear context for usage (revenue conversations) and implies it's for preparation rather than real-time analysis. It distinguishes from siblings by focusing on holistic founder context rather than targeted assessments like fit scores or disqualification signals.

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 real behavioral context beyond that: it discloses the degraded state where no activity/calendar data exists and the tool reports risk as unscored, which tells the agent how to interpret an empty result. It stops short of explaining how data becomes available or any latency/privacy considerations.

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

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

Two sentences, front-loaded with the tool's function and followed by the one non-obvious caveat about unscored risk. No filler, no restatement of the title, and every clause carries information.

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

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

With no output schema, the description responsibly characterizes the return values (risk score, specific recovery actions, 'not scored yet' state). It is nearly complete for a zero-required-parameter read tool; the only gap is the unexplained 'dashboard' mode, whose output shape the agent must infer from the schema.

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

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

Schema coverage is 100% and the single enum parameter 'mode' is fully documented in the schema (assessment vs dashboard). The description never mentions the mode switch or explains what 'dashboard' returns, so it adds no meaning beyond the schema. Baseline 3 applies.

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

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

The description names a specific verb and resource ('checks for early signs of burnout') and spells out the signal sources (work days, late nights, meeting load) plus the outputs (risk score and recovery actions). Nothing in the sibling list overlaps with this wellness/burnout function, so an agent can identify it unambiguously.

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?

Usage is implied by the purpose rather than stated: there is no explicit 'use when...' nor any alternative tool to route to. The one piece of guidance present is the data prerequisite ('Until Andru has your activity or calendar data, it says the risk is not scored yet'), which is a useful condition but not a full when-to-use statement.

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 indicate read-only and open-world hints, which the description doesn't contradict. It adds valuable context beyond annotations: 'No AI calls, instant results' clarifies performance characteristics, and 'scores them against who actually buys from you and why' hints at data-driven matching. However, it doesn't detail rate limits, authentication needs, or output format.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by clarifying details. Every sentence earns its place: the first defines the tool, the second adds scoring context and performance traits. No wasted words, making it efficient for an agent to parse.

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 (12 parameters, no output schema) and rich annotations, the description is mostly complete. It covers purpose, behavior, and context but could better explain output expectations (e.g., score format) or parameter interdependencies. The absence of an output schema means the description should ideally hint at return values, which it partially does with 'scores 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?

Schema description coverage is 100%, so parameters are well-documented in the schema. The description doesn't add meaning beyond the schema, such as explaining how parameters influence the score or which are most critical. It mentions '5 dimensions' but doesn't map them to parameters, so it meets the baseline for high schema 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 clearly states the tool's purpose: scoring a company against buyer profiles across 5 dimensions to determine if it's worth pursuing. It specifies the verb ('scores'), resource ('company'), and scope ('against who actually buys from you'), distinguishing it from siblings like 'get_icp_profile' or 'classify_opportunity' by focusing on fit evaluation.

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 for when to use it ('whether the company you're thinking about is worth your time') and mentions 'No AI calls, instant results' as a behavioral trait, but it doesn't explicitly state when not to use it or name alternatives like 'batch_fit_score' for multiple companies or 'get_disqualification_signals' for negative filtering.

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 open-world characteristics. The description adds valuable context about what information is returned (5 layers, 7 buyer questions, churn patterns) and the optional filtering capability, which goes beyond the annotations. 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 efficiently structured in two sentences: the first states the comprehensive return value, and the second mentions the optional filtering capability. Every element serves a purpose with no wasted words.

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

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

For a read-only query tool with good annotations and full parameter documentation, the description provides adequate context about what intelligence is returned. However, without an output schema, it could benefit from more detail about the return format structure.

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 fully documents all three parameters. The description mentions optional filtering to specific layers, which aligns with the 'layers' parameter but doesn't add meaningful semantic context beyond what's already in the schema descriptions.

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

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

The description clearly states the tool returns comprehensive ICP information with specific details about 'all 5 intelligence layers, the 7 critical buyer questions, and the patterns that predict churn.' It distinguishes itself from siblings by focusing on complete ICP profiles rather than specific aspects like fit scores, positioning, or disqualification signals.

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

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

The description implies usage for obtaining complete ICP intelligence but doesn't explicitly state when to use this tool versus alternatives like get_icp_fit_score, get_competitive_positioning, or get_disqualification_signals. No specific exclusions or prerequisites are mentioned.

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 safety and external-data scope are covered. The description usefully adds that signals are relevance-ranked and each carries a buyer impact and recommended action, but says nothing about freshness, source coverage, or rate limits beyond the read-only profile.

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

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

Two dense sentences: the first front-loads what the tool returns and its enrichment, the second covers usage. No filler and no 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 no output schema, the description reasonably compensates by enumerating returned signal categories and noting each has buyer impact and a recommended action. All five parameters are documented in the schema. The main gap is the absence of any sibling routing or exclusions.

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 all five parameters documented, so the schema does the heavy lifting. The description echoes the signal categories and relevance ranking, which loosely maps to signalType and minRelevance, but adds no syntax or formatting detail 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?

States a specific verb (surfaces) and resource (relevance-ranked industry signals) with the exact content types returned — trends, buyer pain, competitor moves, regulatory/tech shifts, hiring and funding. An agent knows precisely what comes back, though it does not name a sibling tool to distinguish itself from the surrounding get_* context 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?

Gives clear usage context: 'for deal/market context before a screen, or to time GTM moves.' This tells the agent when the tool is appropriate. It stops short of naming alternatives or stating when NOT to use it (e.g. vs get_competitive_positioning or get_pre_brief), so it is clear but not exhaustive.

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 open-world behavior, which the description does not contradict. The description adds value by specifying that it retrieves 'version history' and 'evolved over time,' providing context about what data is returned, but it does not disclose additional behavioral traits like rate limits, authentication needs, or pagination.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by illustrative examples that earn their place by clarifying use cases. It is appropriately sized with no wasted words, making it efficient and easy to understand.

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 (historical data retrieval), annotations cover safety (read-only) and data scope (open-world), and schema coverage is complete. However, without an output schema, the description could better explain return values (e.g., format of version history). It is mostly complete but has a minor gap in output details.

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 fully documents the parameters. The description adds semantic context by linking parameters to examples (e.g., 'metric' for category, 'mrr' for key), but it does not provide new information beyond what the schema already states. This meets the baseline for high 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 clearly states the tool's purpose with specific verbs ('Get the version history') and resources ('of a specific memory'), and it distinguishes from siblings by focusing on historical evolution rather than current states or other operations. Examples like 'What was my MRR 3 months ago?' reinforce its unique function.

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 for when to use this tool (to see how metrics, deal stages, or priorities have evolved over time), but it does not explicitly mention when not to use it or name specific alternatives among the sibling tools. The examples help guide usage but lack explicit 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 only declare readOnlyHint and openWorldHint, so the description usefully adds that the tool is free and enumerates the returned content categories, which matters because no output schema exists. It still doesn't disclose generation latency or determinism, but the added cost and return context is solid 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?

It is front-loaded with purpose, then returns, then parameter guidance, then routing, then 'Free.' Every sentence earns its place. The opening sentence is slightly overwrought but not wasteful.

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 8 parameters, no output schema and a read-only annotation profile, the description covers what the tool produces and when to reach for it, including cost. It is complete enough to invoke correctly, though it omits any note on output size or limits across the four MBTI variants.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine meaning: set mbtiCategory for a single communication style or omit it to get all four, which is not derivable from the enum alone. Inference guidance for vertical/targetRole is echoed in the schema, so no extra credit there.

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 the resource (messaging framework) and scope precisely: words adapted by buyer type, channel, funnel stage and communication style. It then enumerates the concrete outputs (value propositions, objection answers, voice variants, outbound templates). The first sentence is flowery, but the second grounds it well enough for an agent to distinguish it from siblings.

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

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

It explicitly routes to two alternatives with conditions: use get_persona_profile to learn who the buyer is, and get_pre_brief for one specific meeting. It also explains the optional mbtiCategory behavior (one style vs all four). It does not distinguish from generate_asset, a potential overlap, so not a full 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 declare readOnlyHint and openWorldHint, so the safety profile is covered. The description usefully adds what the response contains (communication preferences, empathy map, messaging angles), which is real context beyond the annotations, though it omits anything on data freshness or sourcing.

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, front-loaded sentence that leads with the purpose and then the returned value. Slightly salesy phrasing ("before they say yes", "7 AM") costs a little precision but nothing is wasted.

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

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

No output schema exists, and the description compensates by naming the return contents. For a read-only, open-world lookup with full parameter documentation, an agent has enough to call it correctly; only sibling routing is under-specified.

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

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

Schema description coverage is 100%, so every parameter including the required title and inference guidance for vertical/targetRole/productDescription is fully documented in the schema. The description adds nothing parameter-specific, so the baseline 3 applies.

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

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

States a specific verb (look up) and resource (persona profile), and names the returned content: communication preferences, empathy map, messaging angles. It does not distinguish itself from adjacent siblings like simulate_buyer_persona or get_icp_profile, 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?

"Before the call" implies the usage moment, giving implicit context for when to invoke it. However, there is no explicit when-not guidance and no mention of how it relates to alternatives such as simulate_buyer_persona, leaving the routing to inference.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavioral content: it commits to the concrete aggregates returned (avg readiness, at-risk count, customer-concentration risk) and the normalization guarantee ("comparable by construction"), which matters since no output schema exists. It is silent on pagination/limits and access errors beyond the schema's ownership note.

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

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

Two tight sentences, front-loaded with the what (scorecard) before the who (PE/VC operators). "Comparable by construction" is slightly jargon-heavy but carries real meaning about normalization; there is no padding.

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 correctly carries the burden of describing return content via its aggregate list, and the sole parameter is schema-documented. Adequate for an agent to call and interpret it, though it omits scope/size limits on "every portfolio company".

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

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

Only one parameter (portfolioId) and the schema already documents it fully at 100% coverage, including the ownership constraint. The description adds no syntax, format, or scoping detail beyond what the schema states, so baseline 3 applies.

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

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

States a specific resource (portfolio-wide scorecard of every portfolio company) and the ranking metric (Revenue Readiness Index), which implicitly distinguishes it from the company-level sibling assess_company_readiness. It stops short of explicitly naming an alternative tool, so the differentiation is inferred rather than stated.

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?

"For PE/VC operators monitoring a book" identifies an audience and a rough context, but gives no when-to-use/when-not-to-use condition and no routing against assess_company_readiness or generate_portfolio_brief. Usage is implied, not specified.

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 cover the safety profile (readOnlyHint=true, openWorldHint=true), so the bar is lower. The description still adds real behavior: it auto-resolves the calendar event, pulls buyer context, and discloses the exact contents of the generated brief — important since there is no output schema. "Writes" reads as "composes/drafts" for the user, consistent with a read-only get_ tool, so no contradiction.

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

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

Two sentences, purpose front-loaded before the how-to-use clause. The middle list of brief contents is dense but each item is informative. "so you don't walk in cold" is mild marketing filler, the only real trim available.

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 correctly carries the return-value burden by enumerating what the brief contains. All five parameters are schema-documented and annotations cover the safety profile, so an agent has enough to call it correctly. Minor gaps: no latency/cost or freshness notes on the calendar lookup.

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 five parameters including the auto-matching behavior of companyName and the eventId shortcut. The description's "say who you're meeting with" only restates the companyName semantics already in the schema, adding no format or precedence detail. Baseline 3 applies.

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

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

The description names a specific verb ("Writes your pre-call prep") and enumerates the concrete artifacts produced: talk track, buyer-tuned discovery questions, likely objections with rebuttals, and the meeting's single objective. It is far from a tautology. It stops short of naming or contrasting any sibling (e.g. get_persona_profile, get_account_plan), so it earns a 4 rather than 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?

It gives clear invocation context: "Just say who you're meeting with — Andru checks your calendar automatically," which tells the agent the minimal input needed and that calendar lookup is implicit. It does not state when-not to use it or point to alternative prep tools, so no exclusion guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read operations with potentially incomplete data. The description adds valuable context about what types of memories are available (episodic facts, semantic patterns, procedural habits) and the business domains covered, which goes beyond the annotations. No contradictions with annotations exist.

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 appropriately sized and front-loaded with the core purpose in the first clause. The second sentence adds useful filtering context without redundancy. While efficient, it could be slightly more structured for optimal clarity.

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 (querying accumulated insights with filtering), annotations cover safety and data completeness, and the schema fully documents parameters. The description provides good context about memory types and content, though without an output schema, it doesn't detail return values. It's mostly complete but could benefit from more explicit behavioral context.

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

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

Schema description coverage is 100%, with all parameters well-documented in the schema. The description mentions filtering by memory type and business domain, which aligns with the schema but doesn't add significant meaning beyond it. The baseline of 3 is appropriate given the comprehensive schema 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 clearly states the tool queries accumulated stakeholder understanding with specific content types (metrics, deal patterns, account history, decisions, behavioral insights) and mentions filtering capabilities. It distinguishes from siblings by focusing on 'revenue memory' rather than other tools like get_account_plan or get_capability_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?

The description implies usage for querying learned insights about a founder, but doesn't explicitly state when to use this tool versus alternatives like get_memory_history or get_founder_context. No exclusions or clear alternatives are provided, leaving usage context somewhat implied rather than explicit.

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 indicate read-only and open-world hints, but the description adds valuable behavioral context: it's a comprehensive generator tool that creates multiple artifacts (not just a single document). The description doesn't contradict annotations and provides insight into the scope and output nature beyond what annotations convey.

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, well-structured sentence that efficiently communicates the tool's comprehensive output. Every word contributes to understanding the tool's purpose without redundancy or unnecessary elaboration.

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 read-only/open-world annotations but no output schema, the description adequately conveys what will be produced. However, it doesn't specify format (e.g., document type, structure) or whether outputs are editable/templates, leaving some implementation details unclear.

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 all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions, so it meets the baseline expectation without providing extra semantic 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 clearly states the specific action ('Builds everything you need') and the comprehensive output (job description, comp structure, interview questions, ramp plan, activity targets). It distinguishes itself from siblings by focusing on sales hiring infrastructure rather than prospecting, classification, or other sales-related functions.

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 context ('to make your first sales hire') but doesn't explicitly state when to use this tool versus alternatives. No guidance is provided about prerequisites, timing, or comparison to other tools like 'get_icp_profile' or 'simulate_buyer_persona' that might be related to sales planning.

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 indicate read-only and open-world hints, but the description adds valuable behavioral context: it specifies the output includes 5 VCs with fit scores, explanations of interest, and approach guidance. This goes beyond annotations by detailing what the tool returns and its practical benefits, though it lacks explicit rate limits or data source disclosures.

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

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

The description is front-loaded with the core functionality in the first sentence, followed by a benefit statement. Every sentence earns its place by conveying essential information without redundancy, making it efficient and well-structured for quick understanding.

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 (matching VCs with scoring and explanations) and lack of output schema, the description provides a good overview of what to expect. However, it could be more complete by specifying output format details or error handling, though annotations cover safety aspects adequately.

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 input schema already documents all parameters well. The description does not add meaning beyond the schema, as it doesn't explain how parameters like 'productDescription' or 'arrRange' influence the matching process. Baseline score of 3 is appropriate since the schema handles parameter documentation adequately.

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 with specific verbs ('Finds', 'scores', 'explains', 'tells') and resources ('5 VCs', 'investment thesis', 'your company'). It distinguishes itself from siblings by focusing on VC matching with fit scoring and approach guidance, unlike tools like 'get_icp_fit_score' or 'discover_prospects' which have broader or different scopes.

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 for usage ('Saves weeks of investor research'), implying it's for startup fundraising preparation. However, it does not explicitly state when not to use this tool or name alternatives among siblings, such as 'get_syndication_status' for post-investment tracking or 'classify_opportunity' for general opportunity assessment.

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 only declare readOnlyHint and openWorldHint. The description adds real behavioral context: it is 'Free', and each entry carries business outcome, price tier, data requirement, and same-day-generatability. This tells the agent what it gets back and that no cost is incurred, going beyond the safety profile annotations provide.

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

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

Front-loaded with the core action and scope in the first clause, then supplemental detail on entry contents and the follow-up call. The pricing enumeration (Tool $3, Framework $12, Decision $49) is slightly dense but earns its place by signaling tiering. No wasted sentences.

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 carries the return-value burden and does so by enumerating what each entry contains. Combined with the routing to generate_asset and the free/cost signal, this is nearly complete; only pagination behavior is unaddressed.

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 group, limit, query, and available_only. The description adds no syntax or format detail for these parameters beyond what the schema supplies, so the baseline of 3 applies.

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

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

States a specific verb ('Search') and resource ('Andru's catalog of sales, hiring, fundraising and buying assets') with concrete scope ('139 deliverables'). It distinguishes itself from the sibling generate_asset by routing the agent there as the next step, so an agent knows this is the discovery step rather than the generation step.

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

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

Gives clear usage context: search the catalog, then 'call generate_asset with the asset's name.' This establishes the intended workflow. However, it gives no explicit when-not guidance and never mentions get_asset (the likely sibling for retrieving a single asset), so alternatives are only partially disambiguated.

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

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

The description adds valuable behavioral context beyond annotations: it explains that the system 'automatically versions previous values,' which clarifies persistence and versioning behavior. Annotations indicate this is a write operation (readOnlyHint: false) with open-world data (openWorldHint: true) and non-destructive (destructiveHint: false), and the description aligns with this by describing saving/compounding without contradictions.

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

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

The description is front-loaded and concise with two sentences that efficiently convey purpose and usage without wasted words. Every sentence adds value: the first defines the tool's function, and the second provides context and behavioral insight.

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 (6 parameters, write operation) and rich annotations, the description is mostly complete but lacks details on output or error handling. It covers purpose, usage, and key behavior (versioning), but without an output schema, it could benefit from mentioning what happens after saving (e.g., confirmation).

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 description does not provide additional parameter semantics beyond what the input schema already covers. With 100% schema description coverage, the schema fully documents all parameters, so the baseline score of 3 is appropriate as the description adds no extra parameter details.

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 with specific verbs ('Save a revenue insight, decision, metric, or pattern into Andru's memory') and resources ('memory'), and it distinguishes from siblings by specifying this is for saving/compounding insights rather than retrieving them (unlike get_memory_history or get_revenue_memory).

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 with 'Use after any deal decision, ICP refinement, metric update, or strategic pivot,' giving clear context for when to invoke this tool. It implicitly distinguishes from retrieval-focused siblings by emphasizing saving/compounding rather than getting data.

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?

Goes beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=true) by explaining that Andru actually reads the homepage, that the context persists and is reused, and that it is free. It never states what happens to previously saved context on a re-call, which is the notable remaining gap for an idempotent-claimed write.

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?

Short, front-loaded, and every sentence carries information (purpose, inputs, persistence effect, retrieval mode, cost). The telegraphic fragments are efficient, though the ordering of 'Free' at the very end is a small afterthought.

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 appropriately covers both the write path and the read-back path (call with no arguments), which is what an agent needs to use this tool correctly. Missing only edge-case behavior such as overwrite semantics or how long ingestion of a website takes.

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 of the four parameters is already documented with examples in the schema. The prose adds only the mutually-exclusive intent of website vs. productDescription, not new format or constraint detail, so baseline 3 applies.

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

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

States a specific verb and resource: it sets the product context that Andru persists. The description makes the intent unmistakable and clearly separates it from the read-side siblings (get_*) by framing it as the one-time write that feeds all later calls.

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 lays out the two input paths (website vs. short product description) and adds a third no-argument mode for inspecting what was saved, plus 'every later call uses it'. It omits an explicit when-not-to-use or routing against a sibling, so it stops 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 declare this is mutating and open-world, but the description adds genuinely non-derivable facts: the $5 charge, the 25-turn cap, the session lifecycle, and the scored-debrief ending. These are important behavioral traits an agent cannot infer from structured fields. It doesn't explain what happens on turn exhaustion or session expiry, keeping it from a 5.

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

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

Three sentences, front-loaded with the purpose followed by mechanics and pricing. The 'Andru acts as...' sentence is slightly promotional but carries the role-play framing. No wasted sentences, though it could be tightened.

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, multi-mode tool with no output schema, the description covers the session workflow, cost, turn limit, and debrief path adequately. It leaves the exact return shape of each mode unstated, but the schema carries the mode semantics, so the definition is largely 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%, so every parameter is already documented in the schema (mode, session_id, message, etc.). The description's 'reply turn by turn with the session_id' reinforces the reply flow but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb and resource: it simulates a buyer persona ('Andru acts as key decision-makers') for deal preparation. The purpose is clear and distinct from pure data-retrieval siblings. It stops short of naming alternatives like get_persona_profile or get_pre_brief, so an agent gets no explicit sibling differentiation.

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?

Clear context is given: use it to 'Prepare for a key meeting with the buying committee,' with a concrete three-step workflow (open, reply turn by turn, end with the debrief phrase). There are no explicit exclusions or named alternatives, so it lands at clear-context-but-no-routing rather than full 5.

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