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

Annotations only cover read/write and world scope; the description adds the crucial information that the call is paid, must be preceded by a quote, can be capped, and that output includes a 0-100 index, stage fit, confidence, and the #1 growth constraint. It also discloses the quality tradeoff (more metrics = higher confidence), which is behavioral context beyond structured data.

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 tight sentences: purpose, trigger, return shape, alternative, and payment note. Front-loaded with the verb and scope, and every clause carries actionable information with no filler.

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

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

No output schema exists, yet the description names the return fields (index, stage fit, confidence, top constraint). With a nested metrics object fully described in schema and the paid/quote flow explained, an agent has everything needed to call this 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 the parameter list including the nested metrics vocabulary is already fully documented. The description reinforces the 'pass what you have' semantics and the quote-before-run flow but adds nothing about individual parameter syntax or formats. Baseline 3 for a schema-rich tool is appropriate.

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

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

States a specific verb and resource ('score one company's revenue readiness from its operating metrics') and describes the produced artifact (Revenue Readiness Index). It explicitly separates itself from get_portfolio_readiness_rollup for the portfolio-wide case, so an agent can choose between them 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 an explicit trigger ('use this when the person wants to score one company's revenue readiness'), names the alternative tool for the multi-company case, and adds a required pre-step ('Check the price with quote before running'). No ambiguity about when or how to invoke.

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 real value by disclosing the return shape (per-company tier and score plus totals), which is essential given there is no output schema. It omits what happens past the 50 limit and whether an ICP profile must exist first.

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 tight sentence with the use case front-loaded before the mechanics. Slightly awkward colon construction, but every clause carries information and 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?

For a one-parameter, read-only batch tool with no output schema, the description covers purpose, batch limit, and return contents. Only minor gaps remain — the source of the ICP and behavior on oversized inputs — which are not blocking for correct invocation.

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

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

Schema description coverage is 100%, with every nested company field (domain, revenue, industry, techStack, painPoints, etc.) documented in the schema itself. The description adds only the max-50 constraint, which is already stated in the schema, so it contributes nothing beyond structured data — baseline 3.

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

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

States a specific verb and resource — scoring/ranking a list of companies against an ICP, capped at 50. The word 'list' implicitly distinguishes it from the single-company scoring siblings, but no sibling is named explicitly (e.g., get_icp_fit_score), so differentiation is left to inference.

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 a clear situational trigger ('Before outreach, choosing where to spend time') and a condition (list of companies up to 50). It does not name alternatives such as get_icp_fit_score for a single company, nor state when-not to use it, 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 only supply readOnlyHint and openWorldHint, so the description adds real value by disclosing the shape of the result (the four possible verdicts) and one hard limitation (it cannot confirm a champion). It does not say how much of the input is required vs. optional or how confident/enriched the read is when params are sparse, which keeps it below 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?

Two sentences, front-loaded with the usage trigger before the output description and the sibling redirect. It is dense with enumerations but each clause carries information; the only slight drag is the run-on list of verdicts embedded mid-sentence.

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 job of explaining what comes back, and it does so by listing the components and the four possible calls. With 16 mostly optional parameters and light annotations, a note on how thin inputs degrade the read would make it fully complete, but nothing essential is missing.

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

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

Schema description coverage is 100% and the schema already explains inference expectations for vertical, targetRole, and productDescription. The description adds no parameter-level guidance beyond what the schema 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?

The description names a specific action (produce one read on buyer readiness), enumerates the outputs (fit score, ICP match of the people involved, risk flags, fit check) and states the terminal verdict set. It also explicitly differentiates itself from get_icp_fit_score, 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?

It gives a concrete trigger ('after a first conversation'), an explicit boundary ('It doesn't confirm a champion; that takes asking the person'), and names the alternative for the narrow case ('For a quick fit score only, use get_icp_fit_score'). When-to-use, when-not, and alternative are all present.

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?

Adds substantial context beyond the annotations: the call is paid, it may itself invoke lookup tools, it is single-turn so continuation requires passing `history`, and cost control flows through quote/quoteId/maxAmountCents. These are non-obvious behavioral traits for a read-ish, open-world, paid tool that the readOnlyHint=false and openWorldHint=true flags only hint at.

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?

Dense but front-loaded: routing rule, then behavior, then parameters, then cost warning. Nearly every clause earns its place; the only weak spot is the opening 'Any step,' fragment, which is less informative than what follows.

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, yet the description says the return is a natural-language domain-scoped answer, covers the fallback-tool role, conversation continuation, and the payment/quote flow. That is everything an agent needs to invoke it safely and 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; the description goes above it by explaining the conversational model ('one turn per call; pass prior turns as history to continue') and giving module values that map the abstract expert router to concrete domains. It doesn't re-explain quoteId/idempotencyKey, but the schema already does that well.

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: routes an open question to a named domain expert and returns a natural-language answer. It distinguishes itself from concrete siblings by naming module values ('market-clarity', 'deal-acceleration'), though the opening phrase 'Any step, when no other tool fits' is a bit diffuse before the concrete statement arrives.

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?

Explicit routing rule ('when no other tool fits', 'the person asks an open question for one of Andru's domain experts'), explicit constraint (tools that cost money must be called directly, not via the agent), and explicit prerequisite (check price with quote before running). An agent knows exactly when and when not to use it.

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

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

Annotations only declare non-read-only, open-world, non-destructive; the description goes much further by disclosing latency ('up to a couple of minutes'), cost model (paid, quote first, maxAmountCents guard), and a quality guarantee ('only companies with sourced evidence are returned' with page links). These are exactly the traits an agent needs before committing to a paid, slow 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?

Front-loads the purpose and when-to-use in the first sentence, then layers in latency, cost, and guarantees. Dense but every clause carries information; the only minor cost is that cost/payment caveats are packed at the end.

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 still explains the return contract (only sourced-evidence companies, evidence linked to pages) and the cost/latency envelope for a slow paid operation. It could say more about result volume or shape (e.g., how many companies, fields per record), which is the remaining gap.

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

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

Schema coverage is 100%, so baseline is 3; the description adds value by explaining that companyName and productDescription default to the product saved on the account, which clarifies why zero parameters are required. It does not add much on industry/targetMarket/coreCapability beyond what the schema already says.

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 — searching the web for real companies showing the problem the product solves — plus the concrete signals checked (hiring, launches, funding, expansion). An agent can distinguish this from preview_company or batch_fit_score, which operate on known companies rather than discovering new ones.

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 a clear triggering condition ('needs new companies to sell to, for example when their pipeline is thin') and a prerequisite chain ('check the price with quote before running'). It does not explicitly state when NOT to use it or name a discovery alternative, 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?

Beyond the annotations, the description discloses that the asset is built from Andru's company knowledge, saved to the user's library, takes up to a few minutes, and is asynchronous: it returns a job_id that must be passed to get_asset to receive markdown. This is strong behavioral context for a non-read-only, open-world generation tool.

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 purpose, then usage context, then persistence and async behavior. Every sentence contributes actionable information, and the examples clarify acceptable asset inputs without 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?

For a generation tool with no output schema, the description explains the return value (a job_id), the retrieval path (get_asset), the output format (markdown), and the expected latency. Combined with full schema coverage and annotations, an agent has enough information to call and follow up correctly.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds useful examples for the asset parameter and contextualizes prospect assets, but it does not materially expand the meaning of prospectCompany or prospectContact beyond the schema descriptions. The baseline 3 is appropriate.

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

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

The description states a specific generation action for an asset from Andru's catalog and distinguishes it from the prerequisite list_assets and follow-up get_asset. An agent can understand what the tool produces without opening the 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?

It gives explicit triggering context: use this when the person picked an asset from Andru's catalog, and it names list_assets as the way to find that asset. It also explains the follow-up retrieval call. It does not state when not to use it or compare against the sibling generate_portfolio_brief, so it falls short of the full 5 criteria.

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 and openWorldHint=true; the description adds what the agent actually needs: the call is slow ("takes a few minutes"), returns a job_id rather than the brief, is paid, and the price must be quoted first. That async + billing behavior is invisible from annotations or 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?

Front-loaded with the oversight use case and tightly packed with distinct information — no filler sentences. The first sentence is long and clause-heavy ("for a period: what Andru's work across the companies found..."), which slightly slows parsing, but nothing is redundant.

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 async, paid, zero-required-parameter tool with no output schema, the description covers the full lifecycle: inputs or fallback, latency expectation, job_id return, retrieval via get_asset, and price control via quote. An agent can invoke and follow through correctly without further information.

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

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

Schema coverage is 100%, so baseline is 3; the description adds meaning by explaining the companies/portfolioId interaction and the no-input fallback where Andru proposes companies from the firm's website for confirmation. It doesn't add format guidance for periodStart/periodEnd or the quoteId/maxAmountCents linkage beyond what the schema already states.

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 (written brief on portfolio companies' go-to-market activity) and enumerates the contents: targets/opportunities/overlaps, public GTM news, market signals, with sources. It also draws an explicit negative boundary ("Not a financial or performance report"), which separates it from get_portfolio_readiness_rollup and financial 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?

Names the actor and situation precisely ("when a PE or VC operator wants..."), specifies the required input paths (companies or portfolioId) and the fallback when neither is supplied. It also routes to sibling tools explicitly: quote before running, get_asset to retrieve the result.

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

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

Annotations declare write-like, open-world, non-destructive behavior, and the description adds substantial context beyond that: it is paid, takes 1–3 minutes, returns a job_id for later retrieval via get_asset, returns a link with a short summary, and reuses plans from the last 30 days unless refreshed. It also sets a caution that the committee and champion should be treated as a map to confirm with each person. 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 front-loaded with the usage condition, then proceeds through output, caching, latency, payment, and follow-up in a logical sequence. Every sentence contributes operational detail; there is no filler.

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

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

For a complex, paid, asynchronous, open-world tool with no output schema, the description covers what the agent needs: when to invoke, what the output looks like, how long it takes, how to retrieve it, how caching affects behavior, and the payment prerequisite. Nothing essential is missing.

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

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

Schema description coverage is 100%, so the schema already defines all six parameters. The description still adds meaningful workflow context around quoteId and maxAmountCents by telling the agent to check the price with quote before running, and it implies the caching behavior tied to the refresh parameter. That extra guidance lifts it above the baseline 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 states a specific verb and resource: it builds an account plan for a target account. It enumerates the concrete contents of that plan — buying committee map, fit opportunities, likely champion, messaging, next steps — so an agent can distinguish it from generic asset or brief tools without opening the 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?

The description gives a clear condition: 'Use this when the person wants a plan for a specific target account.' It also explains the cached-result behavior and a prerequisite workflow (check price with quote, then call get_asset with the job_id). It stops short of naming when-not-to-use or an explicit sibling alternative for a different task, so it is strong 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 declare readOnlyHint and openWorldHint, so safety is covered; the description adds genuinely useful behavior: this is a polling call, it returns progress in-flight and full content in markdown when complete, and results are persisted to the user's Andru account. It does not describe timeout, error, or failed-job behavior.

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

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

It is a single dense sentence, but it is front-loaded with the triggering condition and then branches into each return case. Every clause carries information; the nested colons make it slightly hard to parse on first pass.

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 well: it distinguishes in-progress versus completed responses and specifies the shape of each result type (full markdown, or link plus summary). An agent has enough to call it and interpret what comes back.

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 schema already documents job_id as coming from generate_asset, generate_portfolio_brief, or get_account_plan. The description restates the same origin information, adding no format or usage nuance beyond the schema, 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 action (collect a finished result) and enumerates exactly what kinds of artifacts come back: an asset, a brief, or an account plan, each tied to its producing sibling. It is clear what the tool returns, though the name 'get_asset' undersells that it also retrieves briefs and plans, so the description has to work a bit to correct the impression.

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 a concrete triggering condition: use it when the person asks whether something Andru started is done. It also clarifies the polling semantics (progress while building, full result when done). It does not name an alternative retrieval path such as list_assets, so the boundary with siblings is only partially drawn.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds context about the tool's framing ('diligence for the buyer') and grounding in the account's ICP, but does not disclose rate limits, auth needs, or detailed output format beyond the high-level summary.

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

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

The description is three sentences, front-loaded with the usage trigger, followed by a clear behavioral summary and grounding context. Every sentence contributes directly to understanding when and how to use the tool.

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 analysis tool with no output schema, the description adequately explains what the tool produces ('where the alternative fits this buyer better, where the person's product does, and questions that help the buyer decide'). It omits details like output format or length, but the core value is conveyed.

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

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

Schema description coverage is 100%, with detailed per-parameter guidance (e.g., how to infer vertical, targetRole, productDescription). The description adds no additional parameter meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description states a specific scenario and what the tool does: 'Treats it as diligence for the buyer: where the alternative fits this buyer better, where the person's product does, and questions that help the buyer decide for themselves.' This clearly distinguishes it from generic analysis tools, but it does not explicitly contrast with siblings like get_market_signals or get_icp_fit_score.

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 explicit when-to-use conditions: 'Use this when a buyer is weighing another option, or the person asks how they compare with a named alternative.' No when-not-to-use or alternative tools are named, so it falls short of a 5.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context by stating that the tool returns one of four fit levels with reasons and by guiding how to handle a negative result.

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 the usage trigger, followed by a precise explanation of the check and return shape, then a short guidance sentence for negative outcomes. Every sentence contributes.

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

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

For a 10-parameter, read-only tool with no output schema, the description gives the trigger, core mechanism, and return cardinality. It still leaves the four level names unspecified and does not differentiate from overlapping sibling scoring tools, but the complete schema and annotations fill most remaining gaps.

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

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

Schema description coverage is 100%, so the schema already documents all 10 parameters in detail, including inference guidance. The description adds no parameter-level semantics beyond referring generally to checking the company.

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

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

The description uses a specific verb and resource: it checks the company against the account's ICP and an anti-fit profile, then returns one of four fit levels with reasons. This clearly states what the tool does, though it does not explicitly distinguish itself from sibling scoring tools such as assess_company_readiness or get_icp_fit_score.

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 a clear trigger: use when a deal has stalled or the person wonders whether the buyer is ready. However, it does not state when not to use it or name alternatives, which matters given overlapping 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 cover the read-only and open-world traits, and the description adds the return structure: 0-100 sub-scores for pain coverage, outcome clarity, capability fit plus three more dimensions and an overall score. That is real value beyond annotations and there is no output schema. It does not describe failure modes or what to do with low scores.

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 situation and the core inputs, then the return value, then the alternative. Slightly dense in the return sentence but 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?

No output schema exists, so the description's summary of the returned sub-scores is necessary and mostly sufficient. For a 7-parameter read-only scoring tool with full schema coverage and read-only annotations, this is close to complete; only interpretation guidance is missing.

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

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

Schema coverage is 100%, so all seven parameters are already documented in the schema. The description only calls out two of them (buyerPainPoints, requiredCapabilities) by name, adding at most emphasis rather than meaning. 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 ('checking what the buyer said they need against what the person offers') and describes the output shape. The comparison to the get_icp_fit_score sibling makes the boundary clear 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?

Explicit trigger ('after discovery', 'when the person knows what a buyer needs') and an explicit alternative ('To check whether a company is a fit at all, use get_icp_fit_score'). An agent can route to the correct tool on that alone.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful return grouping ('What I Know,' 'Patterns I've Noticed,' 'How You Operate'), but does not discuss freshness, source, limitations, or how open-world behavior applies.

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 short and mostly front-loaded with the usage trigger. The opening phrase 'The context behind every step' is slightly vague but does not obscure the actionable guidance.

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

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

For a zero-parameter, read-only retrieval tool with no output schema, the description does enough: it states the trigger and outlines the returned categories. It could be stronger by clarifying how it differs from sibling memory/profile tools, but it is sufficient to call the tool correctly.

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

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

The tool has zero parameters, so there is no parameter-level ambiguity. The description does not need to compensate for missing schema 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 resource: stored context about the person and their company, including profile, product, and memory. It distinguishes this from generic identity lookup by framing it as 'what Andru knows about them,' though it does not explicitly name overlapping sibling tools such as whoami or get_memory_history.

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 an explicit trigger: use when the person asks what Andru knows about them or their company. It does not state when not to use it or name alternatives, but the primary usage condition is clear.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond that: the scoring runs in seconds, evaluates 5 named dimensions, and returns an A–D tier with per-dimension reasons, which tells the agent what to expect back. It stops short of explaining how the account ICP is sourced or what happens when signals are missing.

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: trigger first, then what it evaluates and returns, then the sibling alternative. No filler and nothing buried.

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 12-parameter, no-output-schema tool, the description covers trigger, scoring dimensions, and return shape (A–D tier plus reasons). It doesn't address how the 12 mostly optional inputs combine or what the score degrades to when context is thin, which is the main remaining gap.

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

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

Schema description coverage is 100% and the schema itself carries strong inference guidance for vertical, targetRole, and productDescription, so the schema does the heavy lifting. The description adds nothing about which inputs matter most or how partial data affects the score, 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 (scores one company's fit against the ICP) and immediately scopes it to a single company, contrasting with batch_fit_score. An agent can distinguish it from get_icp_profile or assess_company_readiness without opening any 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?

Gives an explicit trigger ('when the person asks whether one company is a good fit, before they reach out or spend more time') and names the alternative tool plus the condition that selects it ('For many companies at once, use batch_fit_score'). Both the when and the when-not are present.

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 readOnlyHint=true and openWorldHint=true already covering safety, the description adds non-obvious behavior: the first ICP may still be building, and the agent should ask again in a minute. It also enumerates the returned ICP components, though it does not discuss auth or rate limits.

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 usage trigger, followed by the return contents and the retry edge case. Every sentence adds useful information, with no filler or repetition.

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

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

For a zero-parameter read-only tool with no output schema, the description supplies the trigger, the returned ICP components, and the eventual-consistency retry behavior. That is enough for an agent to invoke it correctly and interpret the initial empty state.

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

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

The tool has zero parameters, so there are no parameter semantics to document. The baseline score for a parameterless tool is 4, and nothing in the description creates ambiguity about inputs.

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?

It states a specific action and resource: returns the account's ICP, scoped to buyers, metrics, concerns, readiness signals, and non-fit accounts. It does not explicitly name sibling tools like get_icp_fit_score or get_persona_profile, but the described output is conceptually distinct enough for an agent to tell what this tool is for.

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

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

The description gives concrete triggers: when the person asks who their ideal customer is, who isn't a fit, or needs to explain who buys from them and why. It does not state when not to use the tool or explicitly point to alternatives among the many sibling tools.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds real behavioral context beyond that: results are relevance-ranked, each signal carries an impact statement and a recommended action, and — importantly — it discloses the empty-state behavior ('if the account has no Market Pulse yet, it says so'), which is exactly the kind of precondition an agent needs.

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 usage trigger before describing output. The middle sentence is long but every item in the parenthetical earns its place by defining scope. No filler or restatement of the title.

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

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

With no output schema, the description carries the burden of describing the return shape, and it does: ranked signals each with impact and recommended action, plus the no-Market-Pulse case. All five params are optional with no required inputs to explain. Only a brief note on pagination/truncation relative to the limit cap is missing.

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

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

Schema coverage is 100%, so all five optional parameters are already documented with ranges, defaults, and an enum. The description's prose list of signal categories loosely mirrors the signalType enum and 'relevance-ranked' hints at minRelevance, but it adds no syntax, format, or interaction detail 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?

States a specific resource (market signals) and enumerates the exact content returned: trends, buyer pain, competitor moves, regulatory and tech shifts, hiring and funding. An agent can distinguish this from siblings like get_competitive_positioning or get_disqualification_signals based on that content list, though no sibling is named explicitly.

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?

Opens with an explicit trigger: 'Use this when the person asks what's changing in their market or their buyers' markets, or needs a reason a buyer might act now.' That is a concrete use context, but there are no exclusions or named alternatives for adjacent questions (e.g. competitive positioning vs. market movement).

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 that the lookup is scoped to a single saved key over time, but says nothing about what the history contains, whether it can be sparse or truncated, or how far back it reaches - meaningful gaps for a history tool.

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

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

One front-loaded sentence with no filler, and the trigger condition plus examples are exactly what an agent needs. It devotes the entire budget to usage and never states in plain terms what is returned, so it is efficient but not perfectly balanced.

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?

A two-parameter read-only lookup with full schema coverage and clear annotations needs little more than the trigger condition, which is provided. The one remaining gap is the return shape (a sequence of prior values with timestamps), which has no output schema to fall back on.

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 both required parameters are documented with examples in the schema, so the baseline is 3. The description loosely echoes the categories ('metric', 'deal stage or priority'), but those examples do not match the schema's own example ('account'), adding little and slightly muddying the category vocabulary.

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 resource and scope: the change-over-time history of a single saved metric, deal stage or priority, made concrete with two example questions. An agent can distinguish it from get_revenue_memory (current values) by the 'over time' framing, though it never names the sibling or says explicitly that it returns a timeline.

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 opens with an explicit trigger ('Use this when the person asks how one ... changed over time') and backs it with two representative utterances, which is strong routing guidance. It does not state when-not-to-use or name an alternative tool for the 'current value' case, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-context traits are covered. The description adds useful behavior context: output is buyer-responsive messaging derived from the account's ICP, but it does not discuss limitations, generation variability, or auth/rate 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?

Four sentences, front-loaded with the use case and followed by output, source, and alternatives. The examples are brief and help disambiguate multi-buyer use, with no obvious 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?

The tool is read-only/open-world with no output schema, so the description needs to explain likely returns; it does by naming the buyer-specific messaging components. It leaves some optional-parameter interplay and output structure to the rich schema, making it strong but not exhaustive.

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 carries defaults, enums, and inference instructions for all seven parameters. The description only mentions channel, funnel stage, and buyer in passing, adding no syntax or precedence details beyond the schema, so baseline 3 is appropriate.

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

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

The description gives a concrete job—turning an account's story into one buyer's terms—and lists the returned components: what the buyer responds to, the problem in their words, and the concerns they need answered. It explicitly separates this from get_persona_profile and get_pre_brief, so an agent can identify the resource and its role.

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 opens with the triggering condition ('when the person needs...'), includes example scenarios such as a first executive note or the same point for the CFO and IT lead, and routes the agent to get_persona_profile for buyer identity or get_pre_brief for meeting prep. This is explicit when-to-use and alternative guidance.

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

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

Beyond readOnlyHint/openWorldHint, the description discloses the data source (the account's ICP) and, importantly, the epistemic status: it is a starting hypothesis to confirm with the real person, not a conclusion. That is genuinely useful context the annotations cannot convey. It stops short of 5 because it doesn't say what happens when the ICP is thin or unknown.

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 trigger, then the return payload, then the caveat, then the routing alternative — four short, non-redundant sentences with no filler. Every sentence changes how an agent would use the tool.

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 the four content classes it produces. Combined with 100% parameter coverage and the safety annotations, an agent has everything needed to call it correctly and interpret the result.

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

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

Schema description coverage is 100%, so the parameters carry their own semantics, including inference instructions for vertical, targetRole, and productDescription. The description only echoes the ICP framing ('that buyer from the account's ICP') and adds no format or precedence guidance 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 ('Returns Andru's starting picture of that buyer from the account's ICP') and enumerates the returned content (metrics, worries, objections, message), so an agent knows exactly what it gets. It differentiates from get_pre_brief but leaves the very similar siblings simulate_buyer_persona and get_evaluation_criteria unaddressed, keeping it 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?

Explicit trigger ('when the person asks what a specific buyer role cares about... or why that person isn't responding') plus an explicit alternative and its selecting condition ('To prepare for one specific meeting, use get_pre_brief'). Nothing about when to reach for this tool is left 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 declare readOnlyHint=false and openWorldHint=true but say nothing about billing; the description fills exactly that gap by flagging the tool as Paid with a mandatory quote step. It also discloses the comparison semantics ('comparable across companies'), which is behavioral context an agent needs to interpret results. Minor omissions: no mention of the 30-minute quote hold, idempotency, or the maxAmountCents cap that the schema carries.

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: use case first, return contents second, payment prerequisite last. The 'Portfolio oversight:' prefix is a small category tag but no sentence is redundant or padded.

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 the per-company index, the average, at-risk count, and concentration risk. The paid/quote flow is also covered. It could still say more about cost variability or what happens when portfolioId is invalid, but nothing critical for correct invocation is missing.

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

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

Schema description coverage is 100%, so every parameter is already documented in structured form — baseline 3. The description adds nothing about portfolioId sourcing (whoami), quoteId, idempotencyKey, or maxAmountCents beyond what the schema already says, though its 'comparable across companies' note helps interpret results.

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 — a portfolio-level readiness 'scorecard' — and explicitly scopes it to 'across all their portfolio companies,' which cleanly separates it from the single-company sibling assess_company_readiness. It also names the concrete output (Revenue Readiness Index per company, average, at-risk count, concentration risk).

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 a clear triggering persona and situation ('PE or VC operator wants a scorecard across all their portfolio companies, or asks which company is most at risk') plus a prerequisite workflow ('Check the price with quote before running'). It stops short of stating when NOT to use it (e.g., a single company → assess_company_readiness), so the exclusion is only implicit.

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?

Adds real context beyond the annotations: the output is explicitly labelled as Andru's assumptions to correct, and there is a documented fallback (leave out the room and Andru replies with six buyers to choose from). It does not contradict the annotations, which flag a non-read-only, open-world tool. It says nothing about persistence, cost or latency of the generation call, which keeps it below 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-loads the trigger and the default condition before describing the output shape, so the key routing information comes first. The middle sentences are dense, and the parameter recap partially repeats the schema, but none of it is filler.

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

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

With no output schema, the description carries the job of explaining the return value, which it does well, and it also covers the fallback path. The omission of stage (required for a deal meeting) and companyName leaves a small completeness gap for a 6-parameter tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a little procedural framing around the meeting inputs and the omitted-room behaviour, but it never mentions the stage or companyName parameters, and the schema does more work than the prose does.

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

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

Opens with a specific verb, resource and trigger ('prepare for an upcoming meeting'), then describes exactly what comes back: what the meeting is for and what each person in the room thinks going in. It reads clearly against siblings such as simulate_buyer_persona and generate_portfolio_brief.

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?

States when to use it ('the person has a specific upcoming meeting or call and wants to be ready'), calls itself the default for 'prepare me for my call', and names the alternative plus the condition that selects it ('To talk with the buyers before the meeting, use simulate_buyer_persona with the same brief').

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 that results come from things 'Andru has saved,' implying a persisted, accumulated store rather than a live lookup, which is useful context. It says nothing about result volume, ordering, or the relationship to memory history, so it stays at a baseline 3.

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 'Learning from every deal:' preamble is marketing framing that does not help tool selection and delays the actual trigger phrase. The run-on sentence listing content types is dense but does convey information; one editorial pass would remove the fluff and front-load the 'use when' clause.

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

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

With zero required parameters, no output schema, and full schema descriptions, the definition covers the trigger and the filterable axes adequately. What is missing is any disambiguation from get_memory_history and any hint about what a result looks like, which matters for a search tool with an open-ended result set.

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 enum values carry their own descriptions (including the episodic/semantic/procedural gloss), so the schema does the heavy lifting. The description's 'Filter by category, key pattern or memory type' merely restates the three parameter names and adds no syntax or combination guidance beyond the schema.

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

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

The description enumerates the resource contents clearly (metrics, deal patterns, account history, decisions, habits Andru has saved), which tells the agent what is being retrieved. However, it never states the verb directly ('search' only appears in the title) and never distinguishes itself from the sibling get_memory_history, which sounds nearly identical in purpose.

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 an explicit trigger: 'use this when the person asks what they decided, learned or recorded before.' That is a clear usage condition an agent can pattern-match against. It stops short of exclusions or naming the alternative (get_memory_history) that would make the routing decision 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?

Adds real value beyond annotations: discloses that the call is paid and that the price must be checked via quote first — critical for a non-read-only, open-world tool. It doesn't cover timeout/expiry of the quote or what happens on failure, but the cost-gating workflow is the key disclosure.

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 trigger condition, then the deliverables, then the payment prerequisite. Slightly dense and the opening clause ('hand the path they've proven to a first seller') is a bit ornate, but no sentence 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 usefully enumerates what comes back, and it covers the paid prerequisite. An agent has enough to invoke it correctly; only edge cases (quote expiry, failure semantics) are left to 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 description coverage is 100%, so every parameter is already documented, including inference hints and the idempotency/maxAmountCents safeguards. The description only implicitly links arrTarget to the activity targets and adds no parameter-level 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+resource and enumerates the concrete deliverables (job description, comp structure, interview questions, 90-day ramp plan, activity targets tied to ARR goal), which makes it unmistakably distinct from siblings like generate_asset or get_account_plan.

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 a clear triggering condition ('when the person is planning a sales hire') plus the sub-questions it answers (what role, how to pay, how to interview, how to ramp). No explicit exclusions or named alternatives are stated, but the use case is 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 only say readOnlyHint=false, openWorldHint=true, destructiveHint=false; the description goes well beyond them by disclosing that this is a live web search taking about 30 seconds, capped at 3 firms, that only evidence-backed firms are returned, and that the call is paid with a quote-first pricing gate. That is exactly the context an agent needs before spending the user's money.

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 usage decision before any mechanics, and nearly every clause carries information (result cap, evidence requirement, source link, latency, pricing). The parentheticals stack up in the second sentence, costing a little readability.

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

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

With 7 parameters and no output schema, the description still conveys the return shape (up to 3 firms, each with a recent deal or stated focus plus a source URL), the latency, and the billing guardrails. Nothing an agent needs to call this correctly and safely is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by explaining why quoteId exists (check price with quote first) and setting the expectation that stage/vertical/product info is inferred from conversation. It also bounds the result set to 3, which shapes how maxAmountCents should be reasoned about.

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 — finds up to 3 VC firms actively investing in companies like the user's, each with sourced evidence — and frames it as 'fundraising, not selling', which separates it from the sales-facing siblings like discover_prospects and get_icp_fit_score. An agent can route to it without opening the 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?

Gives an explicit trigger ('when the person is raising money and asks which investors to talk to') and an explicit exclusion ('not selling'). It also states the prerequisite workflow: check the price with quote before running, which maps to the quoteId parameter.

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, and the description adds real substance beyond them: what each result entry contains (identity, business outcome, price, data dependency, same-day generability) — which matters since there is no output schema. It does not discuss result ordering, relevance ranking, or what happens with zero matches.

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?

Leads with the usage trigger, then the purpose, then the return shape, then the next step — a coherent progression. It is slightly padded: the inline deliverable examples overlap with the query keyword examples in the schema, and "the person" is repeated awkwardly, but no sentence is disposable.

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 search with no output schema, the description covers entry fields, catalog breadth, and the downstream generate_asset call, which is enough to invoke it correctly. Missing is any note on relevance/pagination behavior beyond the limit parameter already in 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 description coverage is 100%, so every parameter is already documented in the schema, including the group enum and the "can be generated today" semantics of available_only. The description only loosely echoes those ideas ("whether it can be generated today") without adding syntax, defaults, or interaction rules between query and group. Baseline 3 is appropriate.

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

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

States a specific verb and resource with scope: "Searches Andru's catalog of 139 sales, hiring, fundraising and buying assets." The search-vs-retrieve distinction from get_asset is implicit in "Searches" and reinforced by the explicit handoff to generate_asset, so an agent can separate it from the sibling retrieval 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 concrete, situational triggers (deliverable for a meeting the person won't attend, business case for the CFO, someone asking what Andru can make) and names the follow-up call to generate_asset. It does not say when NOT to use it — e.g. when the asset name is already known and get_asset is the cheaper call — 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 declare readOnlyHint=false and destructiveHint=false; the description is consistent with that and adds a genuinely non-obvious behavior: 'Saving an existing key keeps the previous value in its history,' i.e. it is an upsert with retained history. It does not cover return values or whether confidence/memoryType affect merging, leaving some gap.

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 the action and the trigger condition, and every clause adds information. The single long sentence with stacked colons is slightly unwieldy, which costs it a point.

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 6-parameter write tool with full schema coverage, no output schema, and annotations covering the safety profile, the description covers what to save, when to save, and key-reuse behavior. The one notable omission is what the tool returns (e.g., the stored memory id/history reference), which would help an agent confirm the write.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by tying the key parameter to upsert/history behavior, which the schema does not say. Nothing is said about confidence or memoryType semantics beyond the enum descriptions already provided.

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

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

The description uses a concrete verb+resource ('Writing down what each deal taught' → saving a revenue insight) and enumerates the kinds of content it holds: deal decisions, win/loss reasons, ICP refinements, metric updates, strategic pivots. An agent can distinguish this from get_revenue_memory by the verb alone, though the description never names that sibling explicitly.

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 an explicit trigger: 'use this when the person asks you to remember something about their revenue,' followed by concrete example cases that map to the category enum. There are no exclusion conditions or named alternatives, so it falls short of a 5.

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

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

Goes well beyond readOnlyHint/openWorldHint: it discloses the asynchronous two-call pattern (a preview_id is returned, call again with it to collect the read), the ~1 minute latency, and that no account is needed. It even describes the downstream handoff where the preview_id carried into signup_start turns the read into the user's first ICP — context no annotation or schema conveys.

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 trigger and beneficiary are front-loaded before any mechanics, and every sentence carries information. The style is choppy ('Send the website. No account needed.') and slightly chatty, but no sentence is expendable.

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 it: the three content areas of the read are enumerated, plus the preview_id handle and how to collect the result. An agent has everything needed to make both calls 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 real meaning: 'Send the website' identifies the first-call input and 'call again with it to collect the read' explains that previewId is the second-phase key rather than a filter. That sequencing is not obvious 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+resource (preview a company's website read for its buyers) and spells out what the result contains: who the company sells to, the deciding buyers, and site-versus-need gap. The pre-signup framing ('before they have an Andru account') also separates it from account-dependent siblings like assess_company_readiness and get_pre_brief.

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 an explicit trigger ('Before any outreach') and a clear prerequisite state (person has no Andru account yet, just wants a preview of how the site reads). It does not name a specific alternative tool for the case where the person already has an account, so the boundary is implied rather than routed explicitly.

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 readOnly/openWorld, but the description adds substantive behavior: it returns price, free-call coverage, wallet balance, remaining key spend, and a quote_id valid for 30 minutes. It also discloses the price-hold window and how the quote is redeemed, which the annotations cannot 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 critical precondition ('Before spending on the person's behalf') is front-loaded and each sentence adds value. The return-value list is dense but purposeful; only minor tightening is possible.

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, and the description fully enumerates the return payload plus the quote_id lifecycle, which is exactly what an agent needs to act on the result. It is complete for this tool's complexity.

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

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

Schema coverage is 100% and both 'tool' and 'arguments' are already documented. The description restates their role ('Send the tool name and its arguments') but adds no format or edge-case guidance beyond 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 specific verb+resource ('Get the price of a call') and frames the purpose in terms of the user's need and the agent's spend decision. An agent can distinguish it from sibling get_* data tools because it is explicitly about pre-costing a paid call.

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

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

Gives explicit when-to-use conditions ('when the person asks what a call would cost, or before running a paid tool') and a follow-up rule ('Pass quote_id with the call to pay the quoted price'). Nothing is left to inference for the agent.

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

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

The annotations already disclose a non-read-only, open-world, idempotent operation. The description adds useful context beyond that: it saves and remembers product information, triggers an approximately 3-minute process, produces a product description and first ICP, and is reused by later calls. It does not clarify overwrite behavior or failure modes, keeping it below 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?

The description is front-loaded with the triggering condition and is tightly structured. Each sentence adds operational value: when to use it, what to send, what gets produced, how long it takes, and how to inspect the saved result.

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 setup tool with full schema coverage and annotations, the description covers the essential context: purpose, trigger condition, inputs, side effects, timing, and no-argument inspection behavior. It leaves a small gap around whether calling again updates or overwrites existing product context, and what the immediate response looks like.

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 explains each parameter. The description still adds value by framing website and productDescription as alternatives and by explaining the no-argument behavior for inspecting saved context. It does not discuss vertical or targetRole, but the schema covers those.

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 gives a specific verb and resource: tell Andru what the company sells so it can save a product description and generate a first ICP. It implicitly distinguishes this from later retrieval tools by saying 'Every later call uses it,' but it does not explicitly name siblings such as get_icp_profile, so it falls short of full 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?

It clearly states when to call: when the person tells you what they sell, or Andru does not know the product yet. It also says to send a website or product description once, and that calling with no arguments shows what Andru has saved. It stops short of naming alternative tools or explicit when-not conditions.

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

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

The description discloses behavior beyond the annotations: Andru emails a 6-digit code and an Approve button, the caller must handle either code verification or approval polling, and the resulting key is returned through signup_status. It also explains the initial spend limit default, which is important operational context for an otherwise non-read-only tool.

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 trigger condition and the core action, then follows the branching flow efficiently. It is mostly concise, though the final sentence about spend limits is slightly tangential and not tied to any input parameter.

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 multi-step sign-up flow with no output schema, the description covers the key branches and the verification/polling sequence well. It does not explicitly state what signup_start itself returns, though the need for request_id in the next step is implied.

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 all five parameters are already well documented by the input schema. The description reinforces that the email is where the code goes, but it does not add meaningful semantics for website, foundVia, agentName, or previewId beyond what the schema already says.

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

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

The description states a specific action: starting Andru sign-up or sign-in by sending the person's email. It clearly distinguishes this tool from the follow-up siblings signup_verify and signup_status by explaining which path to take depending on whether the user reads a code or taps Approve.

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

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

It explicitly says when to use this tool: when the person asks to sign up for or sign in to Andru from here. It also names the alternatives and the exact conditions for choosing signup_verify versus signup_status, including polling signup_status until it returns the key.

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 flag readOnlyHint=false with no guidance, but the description carries the full behavioral load: it enumerates the three outcomes ('waiting' with a retry-after hint, the API key delivered once and needing to be saved, and 'expired'). That retry and one-time-display information is exactly what an agent cannot get from 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?

One compact block: context, precondition, action, then the three possible results in the order the agent will encounter them. Parenthetical clarifications ('shown once; save it', 'ask again after the number of seconds it gives') each prevent a concrete failure mode rather than 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 must describe returns and it does so completely for all three states, including the retry cadence for the pending case. An agent has everything needed to call it and act on any response.

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 requestId property is already documented as coming from signup_start. The description's 'Send the request_id' restates the schema without adding format, sourcing, or validation detail, 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?

The description makes the operation concrete: poll sign-up status after signup_start for the case where the user approves via email button rather than dictating a code. It implicitly distinguishes itself from signup_start and signup_verify, though the verb+resource framing ('check signup status') relies on the title rather than the prose.

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 states exactly when to call (after signup_start, when the person taps the approval button instead of reading a code) and the alternative path is named by contrast. There is no inference required to pick this over the sibling flow 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 only declare it is a non-read-only, non-destructive, closed-world write; the description usefully adds that it consumes a one-time email code and produces a credential (an API key) as its side effect. It doesn't cover failure behavior for an expired or wrong code, which matters for a verification step.

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 the sequencing precondition and ending with the return value. The leading 'Getting set up:' label is mild filler but costs little.

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 discloses the key return value (API key) that an agent needs to proceed. For a 2-required-param, non-destructive flow tool this is largely sufficient; only error/retry semantics are absent.

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

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

Schema description coverage is 100%, so both required params and the optional foundVia/agentName are already documented in the schema. The description only restates 'send the email and the code' and says nothing about the optional attribution or agent-naming fields, so it adds little beyond structured 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?

States a specific action (complete sign-up by submitting the emailed code) and a concrete outcome (returns an Andru API key for this agent). It explicitly positions itself in the signup_start → signup_verify sequence, so an agent can distinguish it from signup_start and signup_status immediately.

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 a clear precondition: use it after signup_start, when the human reads back the 6-digit code. What's missing is the fallback path — nothing says what to do if no code arrived (presumably signup_status) or what to do when verification fails.

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 it is not read-only, open-world and non-destructive; the description adds substantial context beyond that: free vs. paid modes, a 10-briefs-per-day cap, a 25-turn session limit, the exact phrase that ends the session and produces a scored debrief, and a pre-charge price check. These are exactly the operational facts an agent needs before invoking a paid, session-based tool.

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 eligibility condition, then what the tool does, how to end it, the alternative, and the cost — a sensible ordering dense with signal. It is compact for an 18-parameter multi-mode tool, though a few clauses (the two pricing sentences, the quoted trigger phrase) 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 a complex multi-mode, paid, session-oriented tool with no output schema, the description covers the dominant flow (brief → play → debrief) and its cost gate. The secondary modes (meetings, list, brief) are only handled in the schema, which is acceptable at 100% coverage, but return values are not described at all and the description is silent on what a session response contains.

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 all 18 parameters carry their own descriptions, including mode enums, stage/stageId meanings, and idempotency behavior, so the schema does the heavy lifting. The description adds only light framing — that a session opens from a brief and continues via replies until the debrief phrase — rather than explaining parameter interactions beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource — role-playing the buyers who will be in the room, with Andru writing a brief then playing them in a 25-turn Deal Prep session — and explicitly separates this from get_pre_brief, the written-brief-only sibling. An agent can tell this apart from every other tool in the list without opening the 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?

Gating is explicit: "Use this only when the person asks to talk with, or play out the meeting with, the buyers." An alternative is named with the condition that selects it (get_pre_brief for the brief alone), and the pricing precondition (check quote before running) is given. Nothing is left 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 does add useful context on what is returned and implies spending thresholds exist ('without asking'), which matters behaviorally. It does not cover failure modes (e.g., what happens with an invalid or expired key) or the format of the response, so it goes beyond annotations but without much depth.

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

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

One sentence for usage plus one for returns, with the usage trigger front-loaded. The returns clause is a long run-on list, though each item is meaningful and not 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?

Because there is no output schema, the description carries the burden of describing the return value, and it enumerates the returned fields including the portfolios, which are nested in practice. It omits error conditions and whether the returned limit figures are currency amounts or call counts, a small remaining gap for a zero-parameter tool.

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

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

The tool takes no parameters and the description correctly presents it as argument-free, so there is no parameter semantics to explain. Baseline 4 applies for a zero-parameter tool.

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 enumerates the exact contents returned: account, key name, spend limits for the day and month, wallet balance, free calls left, and portfolios with ids. No sibling in the tool list overlaps with this introspection role, so the scope is unambiguous.

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

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

Gives a clear trigger condition: use it when the person asks what the key or connection can spend or how much is left, and front-loads the context 'before spending on the person's behalf'. It does not name alternative tools or exclusions, but no sibling plausibly competes with this one.

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