fundz

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false; the description reinforces this with 'Reversible and free' and adds product behavior not in the annotations ('shows up in their app and alerts'). Useful added context about effect and cost.

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 compact sentences, front-loaded with the core action, no redundant restatement of the name/title.

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

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

For a one-param mutation with full annotation coverage and no output schema, the description covers the action, effect, reversibility, cost, and input source. Minor gap: no pointer to the inverse remove_from_watchlist.

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% for the single 'company' param, and the description adds meaning beyond the schema by telling the agent the value can be a company id or slug drawn from any search result.

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 (save) and resource (company to the user's Fundz watchlist) with a clear clarifying synonym '(favorites)'. It is trivially distinguishable from the sibling remove_from_watchlist.

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?

Covers the input source ('company id or slug from any search result'), which helps an agent invoke it, but offers no explicit when-to-use/when-not guidance and never names remove_from_watchlist as the inverse. Usage is only implied.

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

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

Annotations already cover read-only, idempotent, non-destructive and open-world behavior. The description adds a genuinely non-structured trait: that reading costs no credits (contrasted with the paid reveal_contacts path), plus the fact that emails may be absent. No pagination or result-limit behavior is disclosed.

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

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

Three short sentences, front-loaded with the resource and returned fields, then the input provenance, then cost and the upsell path. No filler or repetition of schema content.

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

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

For a two-parameter read tool with no output schema, the description covers what is returned, where the input comes from, and the cost model. It is close to complete; only result-size/limit behavior is unaddressed.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema, including the id/slug format example. The description adds little parameter-specific syntax beyond implying the email filter via 'email where we have it'. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Get the people Fundz already holds for one company') and enumerates the returned fields. An agent can distinguish it from search_funding_rounds (which supplies the id) and from reveal_contacts (which enriches), so sibling differentiation is present.

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?

Explains where the 'company' argument comes from ('id or slug returned by search_funding_rounds and the other feeds') and points to reveal_contacts for the follow-up case of a contact with no email. It stops short of explicitly stating when not to call this tool, but the routing context 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the response is tier-dependent (on Strategic plans an alt-data layer of office expansions and USPTO trademarks is included), which affects what the agent will actually receive.

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

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

Two sentences with no filler. The breadth of the return payload is front-loaded and the usage condition is saved for the end, matching how an agent reads the definition.

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 carries the burden of describing return content, and it does so by category. Combined with full parameter coverage and annotations covering the safety profile, nothing needed to invoke it correctly is missing.

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

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

With a single parameter at 100% schema coverage, the schema already documents id vs slug. The description adds provenance the schema lacks — 'Takes the company id or slug from any search result' — telling the agent where to source the value, which is genuinely useful for chaining calls.

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 ('Everything Fundz holds on one company in a single call') and enumerates the returned content categories (firmographics, funding rounds, executive moves, acquisitions, SEC filings, trademarks). It explicitly distinguishes itself from list-style searches: 'Use this when the user asks about a specific company rather than for a list.'

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 ('when the user asks about a specific company') and contrasts with list retrieval, which is the right axis given siblings like search_funding_rounds and search_executive_changes. It does not name a specific sibling alternative for narrower company sub-resources (e.g., get_company_contacts), so it stops just short of fully explicit routing.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds value by disclosing the conditional upgrade link when the quota is exhausted and the monthly reset window, which is behavioral context the annotations do not carry.

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

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

A single front-loaded sentence that lists the three returned values 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?

With no output schema, the description usefully describes the return payload (remaining count, cap, conditional upgrade link), which is what an agent needs. Only minor gaps remain, such as whether values are counts or formatted strings.

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 zero parameters, so there is nothing for the description to disambiguate; baseline 4 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 states a concrete resource and the exact payload: remaining reveals, the monthly cap, and an upgrade link. That clearly separates it from the mutation sibling reveal_contacts, though it never names an alternative 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?

Usage is only implied — the mention of running out of reveals suggests this is a pre-check before calling reveal_contacts, but there is no explicit when-to-use or when-not-to-use statement.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that results are personalized and AI-scored, but says nothing about result volume, pagination, or whether the set changes within a day.

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 short sentences, zero filler, and the core purpose is front-loaded in the first clause before the return description.

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

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

With no output schema, the description carries the burden of describing the return and does so at a high level ('AI-scored companies'). It is adequate for a zero-parameter read tool, though volume and pagination behavior remain unstated.

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 zero parameters, so the baseline is 4. The description correctly indicates that inputs come implicitly from stored targeting preferences rather than from call arguments, which is useful framing beyond the empty schema.

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

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

States a specific verb and resource ('Get ... daily lead recommendations') and clarifies the return ('AI-scored companies that match your ideal customer profile'). It does not explicitly differentiate itself from siblings like search_funding_rounds or get_lead_detail, so it falls 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?

Implies usage context by tying output to 'your targeting preferences', which hints that get/update_targeting_preferences shape the result, but there is no explicit when-to-use statement, no exclusion, and no routing to alternatives such as search_* tools or get_lead_detail.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description contributes beyond that by enumerating the returned intelligence and noting the intake route comes with a source, which tells the agent this is a single-shot, self-contained lookup rather than something requiring follow-up calls.

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 core value and closed with the use case. The middle field list is long but each item is a distinct output the agent can rely on; 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?

There is no output schema, so the description must carry the return-shape burden itself, and it does by listing the metrics and intake data delivered. What is missing is only marginal: no note on depth limits, staleness, or behaviour for an unknown investor_id.

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

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

Schema coverage is 100% and the sole parameter's description already says "Investor id from search_investors." The tool description adds no format, range, or sourcing detail beyond that. Baseline 3 is appropriate when the schema fully carries parameter meaning.

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 spells out exactly what the payload contains: deal metrics (total deals, 90-day deals, companies backed, median round size, stage mix, first/last cheque) plus the firm's intake route and source. An agent can distinguish it from search_investors, which it implicitly pairs with via the investor_id lookup.

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 decision context: "Use this for 'should we approach them and how'." That routes the agent to this tool for outreach evaluation specifically. It stops short of naming when NOT to use it or pointing at a sibling for the raw search case, so it is not a full 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds important behavioral scope: it operates on one company 'in today's daily leads' and returns a rich set of fields, which is valuable context beyond the annotations, though it does not discuss rate limits, errors, or response format.

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

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

The description is two sentences and front-loads the main action. The first sentence is a long but purposeful enumeration of return contents; the second sentence gives usage context. Every clause earns its place, though the list is dense enough to be slightly heavy.

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 explain what the tool returns, and it thoroughly enumerates the scoring breakdown fields. Annotations cover the safety profile, the schema covers the single input, and usage is stated. An agent has enough to invoke and interpret 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?

There is one parameter and schema description coverage is 100%; the schema already explains 'Company name or organization id from today's daily leads.' The description repeats 'one company in today's daily leads' without adding format, constraints, or examples beyond the schema. Baseline 3 is appropriate when the schema carries parameter semantics.

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

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

The description states a specific verb and resource: 'Get the FULL scoring breakdown for one company in today's daily leads.' It enumerates the contents (match score, confidence, buying stage, forecasts, ML predictions, insights, play, contacts), which distinguishes it from the broader sibling get_daily_leads and from profile-oriented tools like get_company_profile.

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

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

It gives a clear trigger: 'Use this whenever asked why a lead scored what it did, or for the same depth the Fundz lead inbox shows.' That tells the agent when to choose this tool for explanatory depth, but it does not name a sibling alternative or state when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds real context beyond that: it costs one call from the daily API quota, and it may return empty when market activity is sparse. It does not discuss staleness or how far the looksback default extends practically, but the added value is substantive.

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, no filler, front-loaded with what the tool returns and how it differs from a pitch. Cost and sparse-result behavior are placed last as operational notes, which is the right ordering.

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-shape burden and does describe it (dated events plus the shared market themes they were matched on), along with cost and empty-result behavior. It is complete enough to invoke correctly, though it could say more about how adjacency/themes are determined.

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 parameters are documented in the schema, including the important note that company is the RECIPIENT and the 90-day default for lookback_days. The description adds no parameter-level detail beyond that, so the baseline of 3 applies.

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

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

States a specific resource and scope: recent activity (raised, hired, won contract, filed, expanded) among companies adjacent to a given company's market. This is clearly differentiated from the sibling point-queries like search_funding_rounds or search_executive_changes because it aggregates events by market adjacency rather than by a single event type. An agent can tell what it gets 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 situational purpose ("for opening outreach with a market update rather than a pitch") and a useful precondition about data volume ("returns few or no rows when little has happened"). It stops short of naming alternative tools or stating when not to use it, so it is clear context without explicit exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds a real behavioral constraint the annotations do not carry — that authentication must be a signed-in session rather than a plain API key. It stops short of describing return shape or whether the list is paginated or user-scoped beyond 'the user created'.

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, both front-loaded with the actionable fact: what is listed first, then how to use it and the auth requirement. Every clause carries information; there is 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?

For a zero-parameter, read-only list tool with no output schema, the description covers the three things an agent needs: what is returned (names plus the dimensions each filter targets), how the output feeds a sibling tool, and the authentication requirement. Nothing material is missing.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. The mention of filter contents (name, filter fields) describes the response payload rather than inputs, which is a small bonus but not parameter semantics.

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

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

States a specific verb and resource ('List the saved filters (saved searches) the user created') and immediately scopes it to the Fundz web app, with a parenthetical synonym so the agent can map it to the user's mental model. The content enumeration (series, investors, locations, industries, amount, company size, keywords) makes it unambiguous against siblings like get_targeting_preferences.

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

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

Explicitly tells the agent what to do with the result: 'Use a saved filter's name as the `saved_filter` argument of search_funding_rounds to run that exact search,' naming the sibling and the wiring between the two calls. It also states the prerequisite condition for use ('Requires signing in (not available with a plain API key)'), which is a genuine when-you-can-use-it rule.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds what preference categories are returned, but says nothing about auth requirements, whether preferences can be empty, or scope (per user vs. per workspace) despite openWorldHint=true.

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

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

A single front-loaded sentence naming the action first and the returned content second. Every clause earns its place; 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?

No output schema exists, so the description must hint at return contents, which it does by listing the four preference categories. It is nearly complete for a parameterless read tool, with only scope/format details missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 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?

Clear verb+resource: 'Get your current targeting preferences' states exactly what is retrieved, and it enumerates the preference categories (industries, locations, company sizes, buying signals). It does not, however, reference the closely named sibling update_targeting_preferences to distinguish read from write.

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

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

No when-to-use guidance, no prerequisites, and no mention of the obvious alternative update_targeting_preferences for changing these settings. The agent must infer that this is the read counterpart from the name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description usefully adds that results are scoped to sites 'you are monitoring' and enumerates the kinds of changes returned, but says nothing about pagination, result volume, or freshness/recency window.

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 short sentences, front-loaded with the action and scope. The trailing phrase 'and other modifications' is mild filler but overall the text is tight and earns its space.

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 tool with annotations covering safety, this is nearly sufficient, but with no output schema and no way to filter, the description should at minimum indicate the recency window and rough shape/volume of returned changes. That gap is not covered by any structured field.

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 at all, so the baseline is 4. There is nothing for the description to compensate for; it correctly avoids inventing parameter behavior that does not exist.

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 recent changes on monitored websites) with concrete content types (updates, new content, pricing changes). It is clearly distinguishable from siblings like search_products or add_to_watchlist, though it never explicitly names an alternative or scope boundary.

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

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

No when-to-use guidance, no prerequisites (e.g. that the user must have watchlist entries), and no routing to alternatives. 'Recent' is also left undefined, and with zero parameters the agent has no way to infer the time window or result scope.

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 destructiveHint=true, idempotentHint=true, readOnlyHint=false and openWorldHint=true, carrying the safety profile. The description only adds the clarifying synonym '(favorites)' and the fact that the watchlist is user-scoped. It does not say what removal destroys or whether it requires auth, so it adds marginal context over the annotations.

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

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

A single front-loaded sentence with zero filler. The action and resource lead, and the parenthetical clarification is compact.

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 mutation whose safety profile is fully covered by annotations and with no output schema to explain, the description is sufficient to call the tool correctly. 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 single 'company' parameter is fully documented as 'Company id or slug to remove'. The description adds no format, casing, or identification detail beyond the schema, so the baseline of 3 applies.

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

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

Specific verb+resource: 'Remove a company from the user's Fundz watchlist.' An agent can distinguish it from add_to_watchlist by the verb alone. It stops short of explicitly naming the sibling as the counter-operation, but the resource and scope are 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?

No when-to-use or when-not-to-use guidance, and no mention of add_to_watchlist as the inverse operation. Usage is only implied by the tool name, so an agent gets no explicit routing signal beyond the verb.

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 the annotations by disclosing the cost model: it consumes one of the user's monthly reveals, quantifies the allowance per plan (Strategic 600, Pro 150), and states that it reports remaining quota and upgrade path. This makes the non-idempotent, consumptive nature concrete, which the bare annotations (readOnlyHint=false, idempotentHint=false) 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?

Three tight sentences: purpose first, trigger condition second, cost/completion behavior third. Every sentence carries distinct 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?

Covers the essentials for a metered spend action: trigger, cost, quota feedback, and upgrade path, which is meaningful given there is no output schema. It stops short of describing the returned shape or the no-result/error case, so it is 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?

Schema coverage is 100%, so both parameters (company, include_mobile) are already documented, including the mobile cost caveat. The description adds behavioral context about matching to sold titles but no additional parameter-level syntax or format 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?

States a specific action (spend a reveal to find and verify decision-maker emails) with a clear resource and scope ('matched to the titles they sell to'). It distinguishes itself from get_company_contacts by naming the sibling and the situation that selects it.

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

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

Explicitly gives the when-to-use trigger: 'Use this when get_company_contacts returns nobody, or nobody with an email.' It names the alternative tool and the exact condition that routes to this one, leaving nothing 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=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, covering the safety profile. The description adds no behavioral context beyond that, such as result ordering, pagination, or what happens when no filters are supplied (all params optional).

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 short sentences with the purpose front-loaded and the filter list following; there is no filler. Slightly sparse in that the 'deal type' filter named is not backed by a 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?

With 10 optional params, full schema coverage, and annotations covering the safety profile, the short description is minimally adequate. It omits any note about default behavior with no filters and about result limits/pagination, which an agent would want for a broad search 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 and the schema carries the parameter meaning. The description restates filter concepts but does not add format or syntax detail; it also mentions 'deal type' as a filter, which has no corresponding parameter in the schema, a small mismatch.

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 (Search) and resource (acquisition events) and lists the filterable dimensions, so an agent can distinguish it from siblings like search_funding_rounds or search_agreements. It does not, however, explicitly name any sibling or contrast its scope, so differentiation is inferred rather than stated.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of alternatives among the many search_* siblings. Usage context is only implied by the resource name.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond that — no pagination behavior, result caps, or scope limits — so it earns little credit on top of structured metadata.

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 short sentences, front-loaded with purpose then filter dimensions, with no filler. It is appropriately sized, though the second sentence largely duplicates schema content.

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

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

For a fully-optional-parameter search tool with complete schema coverage and rich annotations, the description is minimally sufficient. It lacks any guidance on defaults (e.g., the 20-result limit), result handling, or how to choose among sibling search tools, which an agent would need to call it well.

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 with examples. The description only restates three of the eight filter dimensions (type, company names, date range) and adds no syntax or default information 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?

States a clear verb (search) and resource (partnership agreements and strategic alliances), and the filter dimensions are named. It is distinguishable from siblings like search_acquisitions and search_funding_rounds, but the description never explicitly contrasts with them.

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

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

No guidance on when to use this tool versus the many sibling search_* tools, and no mention of prerequisites or typical workflows. The only usage signal is an implied one from the filter list.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds no behavioral context such as result ordering, pagination, or result caps, leaving it at the minimum viable level for an annotated 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?

Two short sentences, purpose front-loaded, no padding. The second sentence wastes a little space on facets ('deadline', 'portal') that are not actual parameters.

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 nine fully documented parameters, no output schema, and complete annotations, the description is adequate but not complete: it omits real filters like days, limit, industry, keywords, location, and company_name while citing two non-existent ones. An agent could still invoke it correctly from the schema alone.

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 does not add format or syntax detail beyond the schema, and its mention of 'portal' and 'deadline' points to filters that do not exist among the nine parameters, so it neither helps nor hurts materially.

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 ('Find crowdfunding campaigns') and enumerates search dimensions, which distinguishes it from the sibling search_funding_rounds. However, it names 'deadline' and 'portal' as searchable facets even though no such parameters exist, slightly muddying the picture.

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

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

There is no guidance on when to choose this over search_funding_rounds, search_investors, or other siblings, and no mention of prerequisites or exclusions. The agent must infer usage entirely from the name and domain.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds nothing behavioral beyond that—no mention of result caps, pagination, default lookback windows, or data freshness—leaving it as pure purpose restatement.

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

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

Two tight sentences, front-loaded with the entity type and followed by the filterable dimensions. Nothing 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?

Annotations cover safety and the schema fully documents inputs, but there is no output schema and the description says nothing about what results contain or how many are returned by default. For a nine-parameter search tool, that is adequate but thin.

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 nine parameters are already documented in the schema. The description names a subset of them (role, change type, company, date range) but adds no syntax, enum values, or defaults beyond what the schema states. 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 ('Find') and resource ('executive appointments and departures'), which cleanly separates it from sibling searches over acquisitions, funding rounds, SEC filings, etc. An agent can identify the entity type 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 lists filter dimensions but gives no when-to-use guidance, no prerequisites, and no routing to or from alternatives like get_watchlist_changes or search_major_events. Usage is only inferable from the tool name and filters.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so safety is covered. The description adds real value beyond them: data provenance (Form D filings) and the freshness angle (deals appear before public announcement), which tells the agent what kind of information it is getting.

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

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

Two tight sentences with the core resource and source front-loaded before the usage clause. Every phrase carries weight, though the quoted use-case list is slightly 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?

For a 3-param, no-output-schema read tool with rich annotations, the description supplies the data source, the returned fields, and the intended workflow. It does not describe result ordering or pagination behavior, but the essential call context is present.

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 limit, min_amount, and company_name are already documented, making 3 the baseline. The description loosely maps the output fields (fund name, target or raised amount) to those parameters but adds no syntax or filtering nuance 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 resource (new investment funds raising capital), the data source (SEC Form D filings), and the fields surfaced (fund name, target/raised amount, the filing). An agent can distinguish this from search_funding_rounds and search_investors because it explicitly scopes to fund vehicles rather than company rounds or investor entities.

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 use cases ("who is raising a fund", LP and allocator work, catching a new vehicle before announcement), which clearly signals when to reach for it. It stops short of naming an alternative sibling or a when-not condition, so it is strong context without explicit routing.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false). The description adds genuine behavioral context beyond that: filtering is applied server-side and total_count reflects the filtered total, which informs how an agent should interpret results. No output schema exists, so this return-shape hint carries real weight.

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 compact sentences, front-loaded with the resource and its feed origin, followed by the filtering and server-side semantics. Every clause carries information; only minor redundancy between the filter list and the schema keeps it from a 5.

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 tool with no output schema, the description supplies the source-of-truth feed, the filtering dimensions, the saved-filter pathway, and the meaning of total_count. Annotations cover safety, and the schema covers parameters, so the remaining coverage is adequate; only explicit when-to-use 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 description coverage is 100% and every parameter is documented in the schema with examples, so the baseline is 3. The description's filter list ('company name, industry, location, keywords, series, amount and date window') merely restates categories already fully specified in the schema, adding no syntax or format detail.

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 (Search) and resource (funding rounds), and grounds it with a concrete reference ('the same feed as app.fundz.net/fundings'). It does not distinguish itself from the many sibling search_* tools (acquisitions, crowdfunding, agreements), so an agent gets a clear purpose but no 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 enumerates the available filter dimensions and notes that saved filters can be run by name, referencing get_saved_filters, which implies usage. However, it never states when to prefer this tool over alternatives like search_investors or get_daily_leads, and gives no exclusions or prerequisites.

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

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

Annotations already declare readOnly, idempotent, open-world and non-destructive, so the bar is low. The description adds real behavioral context beyond them: the index covers only investors who 'have actually written cheques in the Fundz deal data,' which tells the agent something about result recall and data provenance.

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

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

Two tight sentences with no filler. The capability and coverage claim come first, and the return-value handoff to the next tool is front-loaded where the agent needs it.

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 what is essential: what it searches, the corpus it searches, and that the output is ids for get_investor_profile. Safety semantics are already supplied by annotations.

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

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

Schema coverage is 100%, so both the query matching style (partial names like 'sequoia', 'a16z') and the limit range are already documented in the schema. The description adds no further syntax or matching nuance, 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?

Specific verb+resource ('Find investors by name') with an explicit scope (37,000+ firms and angels). It also distinguishes itself from the many other search_* siblings by naming its downstream counterpart, get_investor_profile.

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

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

States that results are ids meant to be passed to get_investor_profile, which establishes a clear two-step workflow. It stops short of an explicit when-not rule (e.g., call get_investor_profile directly if you already hold an id), but the routing 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 already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuine context beyond that: the data provenance (SEC filings) and the fact that each result carries a plain-English description and a category. It stops short of documenting result volume or pagination, hence not 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, zero filler, and the core content description is front-loaded ahead of the sibling-routing clause. Every clause earns its place.

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

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

With no output schema, the description correctly spends its words on what a result contains (plain-English description plus category), which is what an agent needs to interpret results. It is nearly complete for a search tool whose parameters and safety profile are fully covered elsewhere, though it says nothing about result ordering or volume behavior.

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

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

Schema coverage is 100%, so all four parameters are already documented with defaults and a max. The description adds only a loose enumeration of category values, which is marginal beyond the schema's own examples. 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 resource (material corporate events drawn from SEC filings) and describes the returned shape (plain-English description plus category). It explicitly distinguishes itself from the sibling search_sec_filings, so an agent can route 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?

Gives an explicit when-to-use rule ('scan for what materially happened') and names the alternative plus the condition that selects it ('when the user wants the filings themselves'). 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, openWorldHint, idempotentHint and destructiveHint=false, covering the safety profile. The description adds nothing behavioral beyond that – no mention of default result count, sorting, pagination, or the fact that all parameters are optional and the search runs against an open corpus.

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 short sentences, front-loaded with the resource and then the filter dimensions. No filler, though the second sentence overlaps heavily with what the schema already conveys.

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 eight-parameter, zero-required search tool with no output schema, the definition is minimally adequate. It does not state defaults (e.g., limit default of 20 is only in the schema), how results are ordered, or what an empty keyword search returns, leaving the agent to guess at the retrieval envelope.

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 with type and example values. The description restates three of the eight filters (launch_type, product_category, company_name) without adding syntax, default, or interaction detail, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Find product launches and updates') and enumerates the primary filter dimensions, which distinguishes it from sibling tools like search_funding_rounds or search_acquisitions. Minor gap: it omits several available filter dimensions (days, limit, industry, location, keywords), so the scope picture is partial.

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

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

No guidance on when to use this tool versus the many sibling search_* tools, and no exclusions or prerequisites. The agent must infer that this is the product-launch search channel purely from the name.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds useful context about the data source (SEC 8-K) and an AI summary layer, plus the scope constraint 'Public companies only,' but says nothing about pagination, rate limits, freshness, or the AI summary's reliability.

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 resource and its distinguishing feature (AI summary), followed by usage triggers and a scope constraint in three tight sentences. No filler or redundancy.

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

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

For a read-only search with no output schema, annotations covering safety, and full schema coverage of three optional params, the description is nearly complete: purpose, content, usage, and scope are all present. It lacks only differentiation from sibling event searches and any note on result ordering or freshness.

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 days, limit, and company_name are already documented in the schema with defaults and bounds. The description adds no parameter-level meaning (e.g., interaction between days and limit, or partial-match behavior), 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 ('Recent SEC 8-K filings with a plain-English AI summary') and enumerates the event types covered (leadership changes, material agreements, results, restructuring). It is clear what the tool returns, but it does not explicitly differentiate from overlapping siblings such as search_major_events, search_executive_changes, or search_agreements, which cover similar event categories.

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

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

Gives concrete usage triggers: 'what did company X just file' and 'to scan a window for material events.' It also states a scope limit ('Public companies only'). However, it names no alternatives and no when-not-to-use exclusions, leaving the agent to infer how it differs from the event-specific sibling searches.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds almost no behavioral context beyond the name — it does not say whether disabling wipes settings, whether delivery_time is persisted when emails are off, or what the response confirms. 'Daily' is the only new fact, and it largely restates the title.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though its brevity is partly a symptom of the thin content rather than evidence of sharp editing.

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 two-parameter mutation tool with no output schema, the description plus full schema coverage and annotations is enough to invoke it correctly. It is still incomplete on the effect side: nothing explains the relationship between `enabled=false` and the optional `delivery_time`, which is the one ambiguity an agent could hit.

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

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

Schema description coverage is 100%, including an explicit note that `enabled` is true-to-enable/false-to-disable and the allowed delivery_time values. The description adds nothing beyond the schema, so the baseline 3 is appropriate.

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

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

States a specific verb pair (enable/disable) and a specific resource (daily email notifications), with scope made explicit as 'your leads and updates'. It does not name a sibling or disambiguate against the other mutating tools (add_to_watchlist, update_targeting_preferences), but the function is unmistakable.

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

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

The description gives no when-to-use context, no prerequisites, and no alternatives. It never says whether toggling off preserves preferences, or whether this is the only route to change notification cadence. An agent can only infer the trigger condition from the tool name.

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 destructiveHint=true, idempotentHint=true, openWorldHint=true and readOnlyHint=false, so the safety profile is largely carried by structured data. The description adds the natural-language parsing behavior and instant-scoring option, but crucially does not say whether updating replaces or merges existing filters, which matters most given destructiveHint=true.

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 primary capability (natural language) before the alternative (direct fields). Minimal waste, though the second sentence's example slightly overlaps the schema's own example.

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 only hints at return behavior via the request_instant_scoring note. For a destructive mutation tool, the missing explanation of replace-vs-merge semantics leaves a meaningful gap, though annotations cover safety.

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 with examples. The description reiterates the field categories (industries, locations, employee sizes, buying signals) without adding format or constraint detail 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?

The description states a specific verb+resource (update targeting preferences) and adds a distinguishing mechanic (natural-language ICP parsing). It does not name the read-only sibling get_targeting_preferences, but the write intent 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?

It implicitly clarifies two usage modes (free-text ICP vs direct field specification), which is useful context. However, it never states when to use this versus get_targeting_preferences or get_saved_filters, nor any prerequisites.

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