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 that the tool *simulates* searches across LLM providers and performs multi-step analysis, which signals non-determinism and likely expense. However, it says nothing about permissions/auth needs, runtime, rate limits, or whether results are persisted — meaningful gaps for what is clearly a heavy analytical 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?

The purpose sentence is front-loaded and dense with real information. The trailing 'Args:' block is Python-docstring style and somewhat redundant in framing, but given the 0% schema coverage it earns its place by supplying examples and optionality markers.

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?

An output schema exists, so return values need not be described. For a complex multi-stage analysis tool the description covers what is computed and what inputs matter, but it omits operational context — how long a run takes, whether results are cached, and any auth or quota constraints — which an agent would want before invoking it.

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, and it does: it documents all four parameters with inline examples ('Pytch', 'AI PR agent', 'fintech') and marks website and competitors as optional. What it does not explain is how the competitors list is used (presumably for comparative SOV) or what format a website URL should take, so it stops short of full coverage.

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

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

Opens with a specific verb+resource ('Audit brand visibility in AI answers') and then enumerates the concrete sub-operations: simulating LLM searches, checking citation, computing AI Share of Voice, extracting media outlets, and matching journalists. This is clearly distinct from siblings like check_domain_deliverability and search_journalists, so an agent can route correctly 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?

Context is implied by the purpose statement — you use this when you want to know how a brand shows up in AI-generated answers — but there is no explicit when-to-use, when-not-to-use, or comparison to alternatives such as get_project_results. Prerequisites (e.g. whether a PR project must exist first) and rough cost/latency expectations are absent.

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. It discloses that a live DNS audit runs and that a score and warmup schedule are generated, but it does not state whether the operation is read-only, what permissions or rate limits apply, or whether any side effects occur.

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?

Well front-loaded and appropriately short for a tool definition. The enumerated checks are efficient and informative. The '(F6 Block)' label and the 'Args:' block are slightly extraneous but do not distract from the core purpose.

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?

An output schema exists, so return values need not be explained. The description covers purpose, audit method, and both parameters sufficiently for invocation. It only misses explicit usage conditions or execution constraints (e.g., read-only nature, rate limits).

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: `domain` is documented as accepting a domain name or email address with examples, and `selector` is marked optional with example DKIM selectors, adding clear meaning beyond the bare 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 ('Check domain email deliverability') and enumerates the concrete checks performed (SPF, DMARC, DKIM, MX, DNSBL) plus outputs (health score, warmup schedule). This clearly distinguishes it from the PR/journalist siblings, none of which relate to email deliverability.

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 purpose implies when to use it (validating a domain's email setup), but there is no explicit when-to-use, when-not-to-use, or alternative comparison. Since the sibling tools are unrelated, missing alternatives is low-risk, but guidance remains 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. 'Get' implies a read operation, but it does not explicitly state read-only behavior, permission requirements, pagination limits beyond the parameter name, or failure behavior for invalid project IDs.

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 purpose is front-loaded in one clear sentence, followed by a compact Args section. There is no redundant text, though the Args formatting is slightly terse.

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

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

The tool has an output schema, so return values need not be explained, and the two parameters are at least described in the text. However, the absence of annotations leaves gaps around read-only semantics, pagination, and when to choose this tool over siblings.

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 explain that project_id is a UUID in Pytch and that limit controls how many contacts to fetch, covering both parameters meaningfully, though it omits the default limit value and any maximum bounds.

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 retrieval action and enumerates the returned data: media contacts, pitch status, and response activity for a project. It is distinguishable from siblings like search_journalists and list_pr_projects, though it does not explicitly name 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?

Usage is implied by 'for a project' and the required project_id, making it clear this is for fetching results tied to an existing project. However, there is no explicit guidance on when to use this versus list_pr_projects or search_journalists, nor any 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 are provided, so the description carries the full burden. It usefully discloses the PYTCH_API_KEY requirement and that only active campaigns are returned, but says nothing about pagination, rate limits, or whether results are 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 with the core operation front-loaded and no wasted wording.

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

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

The tool is simple with no parameters and an output schema, and the description covers the key operational requirement (PYTCH_API_KEY) and active-only scope. It is nearly complete, though it does not discuss result size or pagination.

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

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

The tool has zero parameters, so parameter semantics are not a concern and the baseline is 4.

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: list active PR campaigns and projects for the authenticated user. It does not explicitly distinguish itself from siblings such as get_project_results, 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?

It implies usage by specifying active campaigns and the authenticated user, but gives no explicit when-to-use guidance, exclusions, or alternatives to siblings like get_project_results.

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 load, and it discloses the one non-obvious trait: results are limited to 'verified' journalists, implying a curated index. It says nothing about match semantics (exact vs. fuzzy keyword), result ordering, or whether the limit is a hard cap or paginated, which are the behaviors an agent most needs.

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

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

The opening sentence is front-loaded and complete, and the Args block earns its space because the schema has zero field descriptions. Slight redundancy remains (limit's default is repeated from the schema), but nothing is 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 simple three-parameter read tool with an output schema covering return values, this is close to sufficient: purpose, all params, and the 'verified' qualifier are stated. The remaining gap is behavioral — ordering, matching, and result-cap semantics — which an agent must guess.

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, and it largely does: it explains that topic is a keyword or beat with four concrete examples, that outlet is an optional publication filter with examples, and that limit defaults to 10. It does not say whether topic accepts multiple values or how partial matches are treated.

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 verified tech and business journalists') plus the three filter dimensions (beat/topic, publication, limit). That is enough to distinguish it from the siblings listed (deliverability check, brand visibility, project listing/results), which serve entirely different jobs.

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: an agent can infer this is the lookup step for finding press contacts, but the description states no explicit when-to-use, prerequisites, or what to do if no verified match exists. There is no named alternative because no sibling overlaps, so nothing is actively misleading.

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