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

No annotations are provided, so the description carries the full disclosure burden. It never says whether the call consumes credits (note the sibling get_credits), requires authentication, what happens when no profile is found, or whether results are cached — all material for a lookup 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 that are front-loaded with the actionable verb and resource. The second sentence largely restates the first ('reverse lookup' vs 'find ... using'), so it is slightly redundant but not bloated.

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 does tell the agent the return is a 'B2B profile URL,' which is the most important return detail. It omits failure modes, credit cost, and whether a matched vs unmatched email behaves differently, leaving gaps for a tool whose siblings imply a metered lookup API.

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 0%, so the description must carry the meaning, and it does add the key qualifier that the input is a work email rather than a personal one (distinguishing it from the find_personal_email flow). It adds nothing about format validity or handling of malformed addresses beyond the schema's format hint.

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 B2B profile URL using work email address,' and the 'reverse lookup' framing positions it as the inverse of find_email. It is clear without opening the schema, though it doesn't explicitly name the sibling it differs from.

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

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

The 'reverse lookup' phrasing implies when to reach for it (you already have an email and want a profile), which contrasts implicitly with find_email. However, there is no explicit when/when-not statement and no named alternative, so 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?

With no annotations, the description carries the full behavioral burden. It adds useful context that the tool returns 'verified' addresses by combining multiple data sources with high accuracy, but it omits cost/credit implications, failure behavior when no email is found, permissions, and return structure.

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

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

The description is two short, front-loaded sentences with no filler. It immediately states the action and resource, then adds relevant sourcing/accuracy context.

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 four-parameter tool with no annotations, no output schema, and 0% schema description coverage, the description is too thin. It does not explain the domain parameter, output format, failure cases, or cost, leaving significant gaps for an agent to invoke it confidently.

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 0%, so the description must compensate. It conceptually covers first_name, last_name, and company_name, but the optional 'domain' parameter is not mentioned at all, leaving one of four parameters unexplained in both the schema and description.

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 clear verb and resource: find a verified email address for a person at a company. It implicitly distinguishes professional emails from personal ones, which differentiates it from the sibling find_personal_email, but it does not explicitly name or contrast alternatives.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as validate_email, find_personal_email, or social_to_work_email. The description gives a basic input context ('person's name and company') but no exclusions, prerequisites, or routing advice.

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 no annotations, the description carries the full burden. It discloses only that pagination is supported; it says nothing about credit consumption (relevant given the get_credits sibling), auth requirements, rate limits, or result freshness for what appears to be an enrichment/lookup 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?

Three tight sentences with the core action front-loaded and no filler. Structure is good, though the middle sentence leans on marketing phrasing ('target organizations') that adds little operational value.

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

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

For a simple two-parameter lookup with no output schema, the description adequately conveys purpose and return contents (roles, contact info). It is thin on credit cost and how results differ from the many sibling lookup tools, which limits an agent's ability to choose 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 0%, so the description must compensate. It never names company_name or limit; 'Supports pagination for large companies' only loosely gestures at the limit parameter and gives no range, default, or format guidance.

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 employees of a specific company') and enumerates what it returns (team members, roles, contact info). It is distinguishable from siblings like find_email or search_profile, though it never explicitly says how it relates to 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 when-to-use guidance or alternatives are named despite a crowded sibling set (find_email, find_personal_email, search_profile, find_role). 'Discover team members... within target organizations' hints at prospecting use but does not state conditions or 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?

No annotations exist, so the description carries the full behavioral burden. It discloses only that pagination is supported; it says nothing about authentication requirements, rate limits, result caps, or what a match returns. For a 9-parameter search tool with zero annotation coverage, that is a substantial 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?

Two tight sentences with the search scope front-loaded before the capability note. No filler, though the second sentence is generic enough that it earns less than its length suggests.

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 9 parameters, no output schema, and no annotations, the description is the only behavioral source and it is thin. An agent cannot tell what the matching semantics are (exact vs substring), whether filters are ANDed, what a response looks like, or how pagination terminates.

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 0% across 9 parameters, so the description must compensate but only names four concepts (company, title, location, experience level) and gestures at pagination. country_id, company_website, and job_description have no semantic explanation anywhere; the enum values for experience_level are likewise undocumented.

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 ('Search for job postings') and enumerates the criteria dimension it covers (company, title, location, experience level). It does not differentiate itself from the sibling find_role, which an agent would plausibly reach for on similar intent.

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 routing against alternatives such as find_role or get_job_types. 'For comprehensive job market research' gestures at intent but gives no condition that selects this tool over a sibling.

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?

No annotations are provided, so the description carries the full behavioral burden and largely fails to. It says nothing about credit consumption (notable given the sibling get_credits), rate limits, whether all three inputs can be combined, what happens on a miss, or what the response contains.

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 first sentence is tight and front-loaded. The second sentence is marketing filler that consumes half the description without adding operational value.

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

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

With no annotations, no output schema, and 0% parameter description coverage, the description should be doing much more. It omits cost, failure behavior, input combination rules, and return shape for a lookup tool in a crowded sibling 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 0%, so the description must compensate: it names all three inputs (profile URL, work email, personal email), which maps cleanly onto the three undocumented properties. However it gives no format, precedence, or fallback semantics, leaving the schema's bare definitions under-explained.

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 (mobile phone numbers), and enumerates the input methods. This distinguishes it from the email-focused siblings like find_email and find_personal_email by the resource it returns, though it doesn't call that distinction out 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?

No guidance on when to choose find_mobile over find_email, find_personal_email, or email_to_profile, nor on which input to prefer when several are known. The closing sentence ('for better outreach and communication') is promotional and adds no selection 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?

No annotations are provided, so the description carries the full burden. It doesn't disclose whether this is a read operation needing authentication, potential rate limits, privacy/legal caveats, or what happens if no personal email is found. For a lookup tool with no structural safety hints, this is a significant 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?

Two sentences, no fluff. The main action is front-loaded, followed by usage context. Every sentence earns its place.

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

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

Given one simple parameter and no output schema, the description covers what it does and when to use it. However, it omits behavioral details like error handling, coverage, or alternative fallbacks, which an agent would need for reliable 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 coverage is 0%, so the description must compensate. It mentions 'B2B profile URLs' which clarifies the expected input type for profile_url, but doesn't specify format, domain restrictions, or examples. This adds meaning beyond the bare schema, warranting a 4 rather than a 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?

Specific verb+resource: 'Find personal email addresses from B2B profile URLs.' This clearly distinguishes it from sibling find_email (which likely finds professional emails) and social_to_work_email. The purpose is unambiguous.

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

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

States when to use it: 'when professional emails are not available.' This is a clear context cue. However, it does not explicitly name the alternative (e.g., find_email) or state exclusions like rate limits or coverage limitations, 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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no auth requirements, no rate limits, no pagination, no result shape, no error behavior. Only the word 'search' weakly implies a read-only lookup.

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 but the second sentence ('Targeted search for particular job titles or functions within organizations') largely restates the first, consuming space without adding information. It is neither bloated nor information-dense.

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 four undocumented parameters, no annotations, and no output schema, the description leaves the agent without the behavioral and parameter context needed to call this correctly. A search tool with an identifier-alternative parameter set needs more explanation than this.

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 0% across four parameters, so the description must compensate, but it does not. It never clarifies that job_title is required, nor that company_name, company_domain, and company_profile_url are alternative company identifiers rather than combinable filters.

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 clear verb ('Find') and resource ('roles/positions within a company'), so an agent knows what the tool returns. However, it offers no differentiation from siblings like find_employees, search_profile, or find_email, which also operate on people and companies.

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 guidance, no prerequisites, and no mention of alternatives such as find_employees for broader people search. The agent must infer the right tool 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?

With no annotations, the description carries the full behavioral burden and mostly fails to: it never states that this is a read-only operation, whether any auth/quota constraints apply, what happens with an invalid or expired ad URL, or how fresh the 'performance insights' are. The word 'Get' weakly implies a read, but nothing confirms it.

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 verb and resource come first and the enumerated contents follow. Nothing needs to be trimmed or reordered.

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

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

For a tool with no annotations, no output schema, and an undocumented input, the description is too thin: it omits how ad_url is sourced, omits any routing versus search_b2b_ads, and gives no return-shape or failure behavior to compensate for the missing structured metadata.

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 a single parameter (ad_url) with 0% schema description coverage, and the description never mentions it, so it does not explain what the URL should point to, how to obtain it, or whether it must come from search_b2b_ads. The schema supplies only the name and URI format, leaving the semantics of the input largely unstated.

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 ('Get') and resource ('detailed information about a specific B2B ad') and enumerates the payload (campaign information, creative details, performance insights). It is clear on its own, but it never distinguishes itself from the obvious sibling search_b2b_ads, so an agent gets no explicit signal on when to pick one over the other.

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: 'a specific B2B ad' hints that the tool is the detail lookup following a search, and the required ad_url suggests a prior discovery step. There is no explicit statement of when to use this versus search_b2b_ads, no prerequisites, and no 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?

With no annotations provided, the description carries the full behavioral burden, yet it discloses nothing about authentication, rate limits, error behavior, or whether both parameters are optional (required count is 0). Only the verb 'Get' implies a read operation; 'comprehensive' hints at breadth but is not concrete behavior.

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

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

The first sentence is front-loaded and informative, but the second sentence is generic promotional filler rather than guidance, so it does not fully earn its place. Overall the description is short but partially wasted.

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

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

No output schema and no annotations exist to offset the description, which leaves unresolved how the two identifier parameters are used (and which to prefer), what the response contains beyond a list of categories, and any behavioral constraints. For a research/data-retrieval tool this is under-specified.

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

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

Schema description coverage is 0% and neither parameter (company_name, company_domain) is mentioned in the description. The description adds no meaning, syntax, or guidance on how the two identifiers relate or what happens when both are omitted, leaving a genuine gap for a 2-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?

The description uses a specific verb ('Get') with a concrete resource ('funding information, financials, competitors') tied to the tool name, so the agent knows it retrieves company funding data. However, it does not differentiate itself from a sibling like search_company, which plausibly overlaps in scope, and 'company insights' is a vague catch-all.

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 second sentence ('Essential for investment research, competitive analysis, and business intelligence') lists broad use cases but never says when to use this tool versus alternatives such as search_company, nor any prerequisites or exclusions. This is marketing framing rather than actionable 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?

No annotations are supplied, so the description carries the full burden. It discloses the core behavior - it returns a count of credits rather than mutating anything - but says nothing about auth requirements, rate limits, or whether the balance is plan-scoped or resets. For a zero-side-effect read tool this is adequate but thin.

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 followed by the reason to call it. No filler, no repetition 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 tool with no output schema, the description covers what it does and roughly what comes back ('number of available API credits'). Only minor details (exact return shape, auth prerequisite) are unstated, which is low-risk here.

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. The description correctly implies no inputs are needed.

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 ('Check the number of available API credits') plus the account scope ('your LeadMagic account'). This is unmistakably distinct from every sibling tool, which all perform email/profile/company/job lookups rather than account-level quota inspection.

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

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

Gives clear context for when to reach for it ('monitoring usage and planning API calls'), so an agent knows this is a pre-flight/quota-check tool. There are no competing siblings to exclude, so the absence of explicit when-not guidance is not a real gap.

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?

No annotations are provided, so the description carries the burden. 'Retrieve list of available countries' implies a safe, side-effect-free read of static reference data, which is adequate for a zero-parameter lookup, but it does not describe the result shape (names vs. ISO codes), ordering, or whether the list is exhaustive or cached.

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 core action and followed by a single value statement. Every sentence earns its place 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?

For a zero-param reference lookup with no output schema, the description is nearly complete. The only meaningful omission is the return format (how country values are represented), which matters if the result feeds into another tool's filter, but overall it is sufficient to invoke correctly.

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

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

The tool takes zero parameters, so there is no parameter semantics to convey and the baseline is 4. The description correctly implies no input is needed beyond the call itself.

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 ('Retrieve list of available countries') scoped to job filtering, so an agent immediately knows what comes back. It does not explicitly distinguish itself from the sibling get_job_types, which is the same reference-data pattern, so it stops short of a 5.

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

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

'Essential reference data for geographic job searches and market analysis' implies the usage context and suggests pairing with job search tools, but it never states when to call this versus alternatives or any prerequisite. Usage is implied rather than prescribed.

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 no annotations, the description carries the full burden, and it does identify this as static reference data (implying a safe, read-only lookup). It does not disclose the return shape or whether the list is exhaustive/cached, but for a zero-parameter lookup the remaining risk is low.

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 that are front-loaded with the core action. The second sentence partially restates the first's purpose, but there is no filler or 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 simple lookup with no params, no annotations, and no output schema, the description covers the essential purpose but never describes the return format (e.g., array of strings vs. objects), which the agent must guess. It is adequate but not fully complete.

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

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

The tool takes zero parameters, so the baseline of 4 applies. The description correctly signals there is no filtering input to supply.

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

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

States a specific verb and resource ('Retrieve list of available job types') and clarifies the content is reference data. It does not explicitly differentiate from the analogous sibling get_job_countries, but the resource is unambiguous.

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

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

The phrase 'for filtering' and 'filtering job searches by employment type' implies the usage context, suggesting it feeds into job-search tools like find_jobs. However, it names no alternative or explicit when-to-use/when-not condition, leaving usage 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?

No annotations are provided, so the description must carry the full behavioral burden. 'Search' implies a read-only operation, but there is no mention of permissions, rate limits, return format, or whether the operation is safe. The description adds no concrete behavioral traits beyond the implied read nature.

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 first sentence is efficient and front-loaded with the key purpose. The second sentence ('Analyze business-to-business advertising campaigns and professional marketing strategies') is vague filler that restates the obvious and does not earn its place.

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

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

For a search tool with no annotations and no output schema, the description should provide more context. It lacks usage guidance relative to siblings, parameter details, and any indication of return values. The definition is functional but incomplete for an agent to invoke it confidently.

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 0%, so the description must compensate. It does map the two parameters to 'company's domain or name', giving semantic meaning to company_domain and company_name. However, it omits format details, requiredness, or whether one parameter can be used alone, leaving significant gaps.

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 (B2B Ads), and clarifies the query basis (company domain or name). However, it does not differentiate this tool from siblings like search_google_ads, search_meta_ads, or get_b2b_ad_details, leaving ambiguity about its unique scope.

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

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

There is no explicit guidance on when to use this tool versus alternatives, nor any conditions or prerequisites. The description implies it is for searching B2B ads, but stops short of outlining when a user should choose this over similar search 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?

No annotations are provided, so the description carries the full burden. It usefully discloses what the response contains (employee count, locations, industry, metadata), but says nothing about read-only safety, rate limits, auth requirements, or pagination — and with zero required parameters it doesn't clarify whether a bare call is valid.

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 action and the accepted inputs. The phrase 'comprehensive business intelligence' is mildly promotional but the rest of the second sentence earns its place by naming returned fields.

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-parameter lookup with no output schema and no annotations, the description covers inputs and a rough return overview, which is the minimum viable. It leaves open whether parameters are combinable, whether at least one is required, and how results are ranked or limited.

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 0%, so the description must compensate. It names all three lookup keys (domain, name, profile URL), which maps cleanly onto profile_url, company_name, and company_domain, but adds no format details (URI vs. bare domain), combinability, or required-ness guidance.

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 ('Search for detailed company information') and enumerates the three lookup keys and the return content. It does not differentiate itself from siblings such as get_company_funding or search_profile, so it stops short of a 5.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives among the many sibling search/lookup tools. The agent must infer that this is the company-level entry point.

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?

No annotations are provided, so the description carries the full behavioral burden and largely fails it: nothing about whether the call consumes credits (a real concern given get_credits is a sibling), rate limits, result volume, or what a hit vs. miss looks like. Only 'search' implies a read operation, which is minimal 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?

Two short sentences with the concrete capability front-loaded and no padding. The second sentence's 'creative content, and campaign insights' adds flavor but little operational value.

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

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

With no annotations, no output schema, 0% schema description coverage, and two optional mutually-ambiguous parameters, the description should clarify selector semantics and return shape. It leaves the agent without enough to call the tool confidently, especially on whether to pass both parameters at once.

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 0% for two parameters, so the description must compensate and only partially does: it maps company_domain and company_name to 'domain or name' but never says whether they are alternatives or combined, which is preferred, or accepted formats (bare domain vs URL).

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 first sentence names a specific verb and resource ('Search for Google Ads') and gives the two accepted keys ('company's domain or name'), which lets an agent distinguish it from sibling ad tools like search_meta_ads and search_b2b_ads. The second sentence drifts into vague benefit language ('campaign insights') rather than defining the tool further.

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 phrase 'Analyze competitor advertising strategies' implies the intended use case, but there is no explicit when-to-use, no exclusion, and no guidance on choosing this over search_meta_ads or search_b2b_ads in the sibling set. Usage is inferable but not stated.

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

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

No annotations are provided, so the description carries full behavioral disclosure burden. 'Search' implies a read-only operation, but the description says nothing about authentication needs, result limits, pagination, or what kinds of ad data are returned.

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 definition is short and front-loads the core search action. The second sentence, 'Discover social media advertising strategies and creative campaigns,' is vague marketing framing rather than actionable guidance, so it does not fully earn its place.

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

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

For a simple two-parameter search, the description covers the basic purpose and inputs, but it omits usage distinctions from related ad-search siblings and does not explain return behavior despite having no output schema or annotations.

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

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

Schema description coverage is 0%, so the description usefully maps the two inputs to company domain or name. However, it does not clarify whether either parameter is sufficient, whether both are required, or what format each should take.

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: search Meta (Facebook/Instagram) Ads, with the input basis (company domain or name). It clearly differentiates from search_google_ads by naming the ad platform, though it does not explicitly mention sibling alternatives.

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 the search basis but provides no guidance on when to use this tool versus search_google_ads, search_b2b_ads, or get_b2b_ad_details. There are no prerequisites, exclusions, or conditions for choosing this tool.

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?

No annotations, so description carries full burden. It discloses a rate limit (300/min), which is valuable, but doesn't state authentication requirements, error behavior, or whether the extraction is deterministic. For a read-only fetch with no annotations, a 3 is fair – some behavioral context, but gaps remain.

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 action and followed by extraction details and rate limit. No wasted words, though the rate limit could be integrated more smoothly.

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 single-parameter tool with no output schema, the description covers the main action and rate limit, but misses authentication, error cases, and output format details. Not fully complete for an agent to invoke correctly without uncertainty.

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 0%, so the description must compensate. It implies the parameter is a profile URL and gives an example (LinkedIn), which adds minor clarity. However, it doesn't specify URL format constraints, required domains, or error handling for invalid URLs. Baseline 3 as per rules when schema is weak.

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 full profile details from B2B profile URL') and clarifies what is extracted (work history, education, company details). It is distinguishable from siblings like find_email or search_company, which operate on different resources.

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 explicit when-to-use guidance or alternatives. The description implies usage by requiring a profile URL, but doesn't say when to prefer this over, say, email_to_profile or social_to_work_email. No exclusions or context provided.

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 no annotations provided, the description carries the full burden. It states the basic conversion but omits operational traits such as permissions, rate limits, credit costs, verification status, and empty-result behavior.

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

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

The description is two concise sentences and front-loads the main action. The second sentence largely restates the first rather than adding new information, so it is efficient but not perfect.

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 no annotations, so the description should explain return values and operational context. It does not describe the output format, failure cases, cost, or verification behavior, leaving the definition incomplete for an enrichment tool.

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

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

Schema description coverage is 0%, so the description must compensate. It identifies profile_url as a B2B/social profile URL, which adds meaning, but provides no examples, platform restrictions, or format details beyond the schema's URI type.

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 and resource: find work email addresses from B2B profile URLs. It does not explicitly differentiate itself from sibling tools like find_email or find_personal_email, 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?

The description implies the use case by mentioning B2B profile URLs and work emails, but gives no explicit when-to-use guidance or alternatives to sibling tools such as find_email, find_personal_email, or email_to_profile.

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?

No annotations exist, so the description carries the full burden, and it does disclose meaningful behavioral detail about the analysis returned (MX records, catch-all detection). However it says nothing about cost/credit consumption (notable given the sibling get_credits), rate limits, or whether validation is a read-only operation.

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 primary action front-loaded and the analytical outputs listed second. No filler, though the second sentence is somewhat of a feature list.

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 and no annotations, the description does a reasonable job conveying what the tool returns, but it leaves the two optional name parameters undocumented, provides no usage context relative to siblings, and omits any credit/auth notes for a tool that presumably consumes credits.

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 0% and the description only addresses the email input implicitly. The first_name and last_name parameters are completely unexplained in both the schema and the description, leaving an agent guessing why they would be supplied to a validation call.

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 ("Validate an email address") plus a secondary capability (retrieving company info) and names the concrete analyses performed (validity, MX records, catch-all detection). It does not explicitly differentiate itself from close siblings like find_email or find_company, 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?

There is no when-to-use, when-not-to-use, or alternative-tool guidance. An agent must infer that this is the post-lookup verification step rather than the lookup itself; nothing in the text routes it away from find_email.

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