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

No annotations are provided, so the description carries full burden. It discloses the env var requirement and the output decision levels, but lacks details on how signals are combined, error handling, rate limits, or what happens if no signal is provided.

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 concise with a clear front-loaded summary and a list of parameters. However, there is slight redundancy between the first paragraph and the docstring.

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

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

Given the complexity (4 parameters, no output schema, no annotations), the description covers the main purpose and inputs but lacks details on combination logic, error scenarios, and response structure. Adequate but with gaps.

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

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

Schema coverage is 0%, so the description must compensate. It provides basic descriptions for each parameter (ip, email, phone, url) but does not specify format or validation rules. The default empty string is mentioned but not 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?

The description clearly states the tool calculates a combined fraud risk score from multiple signals and returns a decision level (ALLOW/MONITOR/REVIEW/BLOCK). It distinguishes from sibling tools that perform individual checks (e.g., ip, email, phone, url).

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 to provide at least one signal and lists the optional parameters. It mentions the required environment variable IPQS_API_KEY. However, it does not explicitly say when to use this composite tool vs the individual sibling tools, or specify 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 must fully disclose behavior. It states outputs (breach count, risk level, etc.) and requires an API key, but lacks information on rate limits, error handling, or potential consequences like API costs. For an external API-dependent tool, this is insufficient.

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 concise with three sentences. It front-loads the purpose, then lists outputs, then notes the API key requirement. No unnecessary words, but could be slightly more structured with bullet points.

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 a simple single-parameter tool with no output schema and no annotations, the description covers basics. However, it lacks details on expected return format when no breach is found, error scenarios, or rate limits. Adequate but not fully complete for an external API 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 adds minimal meaning: 'email: Email address to check for breach exposure.' This clarifies the parameter type but does not provide format/validation details, leaving agents with inadequate 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?

The description clearly states the tool checks if an email address has been exposed in known data breaches using HaveIBeenPwned. This differentiates it from sibling tools like tool_check_email_risk which likely checks other risk factors.

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 mentions the requirement of HIBP_API_KEY but does not provide guidance on when to use this tool over alternatives like tool_check_email_risk or tool_calculate_composite_risk. No explicit when-to-use or when-not-to-use context.

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. It discloses the return values (fraud score, validity, etc.) and the requirement of an API key, but lacks details on side effects, rate limits, or error handling.

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 concise with three sentences plus an argument list. It front-loads the purpose and efficiently includes return values and a requirement. No superfluous 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?

Given two parameters and no output schema, the description covers the inputs, outputs, and a key requirement. It is nearly complete, but missing details on error conditions or output format could be improved.

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%, but the description adds meaning for both parameters: email is for validation, strictness has a range and default. This compensates well for the lack of schema descriptions.

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

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

The description clearly states 'Check an email address for fraud risk, disposable services and spam traps', providing a specific verb and resource, and it distinguishes itself from sibling tools like tool_check_ip_reputation and tool_check_phone_risk.

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

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

The description implies usage by stating 'Check an email address', but it does not explicitly provide when to use versus alternatives or when not to use. No guidance on prerequisites beyond the API key.

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

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

No annotations provided, so description carries full burden. It discloses use of third-party API (IPQS), required environment variable, and explains that strictness parameter controls detection strictness. It does not mention rate limits or caching, but core behavioral traits are covered.

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?

Description is 6 sentences with no fluff. Starts with main purpose, then return values, then requirement, then parameter details. Information is front-loaded and well-organized.

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 no output schema, description fully explains return values (fraud score, risk level, flags). Covers all necessary aspects: purpose, behavior, prerequisites, parameters. No missing critical information for an IP reputation check 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%, but the description includes an 'Args' section explaining both parameters: ip_address (IPv4 or IPv6) and strictness (integer 0-3 with default 1). This adds significant meaning beyond the bare schema types.

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?

Description clearly states the tool checks IP for fraud risk, proxy, VPN, Tor, bot activity. The verb 'Check' and specific resource 'IP address' make purpose clear. Distinguishes from siblings which check other types (email, phone, URL) by name and context.

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?

Description implies usage context (when needing to check IP reputation) but does not explicitly state when to use vs alternatives or when not to use. It provides a prerequisite (IPQS_API_KEY) which is helpful for usage, but lacks explicit selection 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 provided, so the description must carry the full burden. It discloses that an external API is called (via API key) and what the tool returns. It does not mention rate limits or error handling, but for a read-only validation tool this is adequate. The description is transparent about the external dependency.

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 very concise—6 sentences covering purpose, outputs, prerequisite, and parameters. It is front-loaded with the core action and structured logically. No unnecessary words.

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

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

Given two parameters, no output schema, and no annotations, the description is complete. It explains the tool's purpose, what it returns, a required environment variable, and parameter formats. An agent has enough information to use 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?

With schema description coverage at 0%, the description fully explains the parameters: phone should be in E.164 or local format with example, and country defaults to US. This adds critical meaning beyond the schema's type-only definition.

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

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

The description clearly states the tool validates a phone number and checks for fraud risk, VoIP, and prepaid indicators. It specifies the return fields, making the purpose unambiguous. The sibling tools (e.g., tool_check_email_risk, tool_check_ip_reputation) are for different data types, so this tool is well-distinguished.

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 mentions a prerequisite (IPQS_API_KEY env var) and provides a registration link. While it does not explicitly state when to use this tool versus alternatives, the sibling tool names imply usage contexts. Some guidance on when not to use is missing, but the purpose is clear enough.

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 provided, so description carries full burden. Discloses return values (risk score, safety flags, domain info) and required env var. Does not mention rate limits or error handling, but is adequate for a simple check 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?

Concise, front-loaded description. Three sentences plus an Args block with parameter clarifications. No redundant information.

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

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

No output schema, but description lists return types. Parameters are fully explained. The tool is simple and self-contained; the description provides all necessary context for agent invocation.

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

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

Schema description coverage is 0%, so description compensates fully. For 'url' it adds 'Full URL to check (include https://)' and for 'strictness' it adds 'Detection strictness 0-3, default 1', providing meaning beyond schema field names.

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

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

Explicitly states 'Check a URL for phishing, malware, spam and other threats,' with a specific verb and resource. Clearly distinguishes from sibling tools that check email, IP, phone, etc.

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?

Mentions required env var IPQS_API_KEY and provides a link to get a free API key. Does not explicitly exclude alternatives, but the tool's specific focus on URLs implies appropriate context.

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 adds some behavioral detail by listing what is returned (tool list, API key status, links). It does not disclose if authentication is required or side effects, but the tool is likely read-only.

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 concise, with two short paragraphs that front-load the purpose. Every sentence adds value; no waste.

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 parameter-less tool without output schema, the description covers the key aspects: what info is returned. Minor omission: no mention of whether an API key is required to call this 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?

No parameters exist; schema coverage is 100%. The description provides context about what the tool returns, which is useful given the empty parameter list. Base score 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 clearly states the verb 'Get' and the resource 'information about this server, available tools and API key setup instructions', which is distinct from sibling tools that focus on specific risk checks.

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 guidance on when to use this tool versus alternatives; no mention of prerequisites or exclusions. The context of sibling tools suggests it's for initial setup, but this is not stated.

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