LayerCall

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

With no annotations, the description carries the full burden for behavioral transparency. It discloses the output format and global scope, but does not explicitly state whether the tool has side effects, requires authentication, or imposes rate limits. The read-only nature is implied by 'validate' but not confirmed.

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 compact, using two sentences to state the purpose and return values. It is front-loaded with the action and resource, and every word earns its place without unnecessary detail.

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 no output schema and no annotations, so the description must be self-contained. It lists the return values but not their structure, and it omits any discussion of error cases, the strictness parameter, or potential edge cases. The description is concise but under-specified for a tool with three parameters.

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 schema already describes the phone and country parameters, so the description adds little beyond that. The strictness parameter (0-3) is completely undocumented in both schema and description, leaving the agent without guidance on how to set it or what it controls. With 67% schema coverage, the description should compensate but does not.

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's purpose with a specific verb and resource: 'Validate a phone number worldwide against its national numbering plan.' It also lists key return values (E.164, country, line type, risk score) and explicitly distinguishes itself from US-only tools and siblings that handle other entity types.

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 provides clear context by noting it works globally and not US-only, which implies when to use it. However, it does not explicitly mention alternatives or exclusion criteria, nor does it state when another tool (e.g., verify_email) would be more appropriate. The relevance is clear but the guidance is implicit.

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

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

With no annotations provided, the description carries the transparency burden and does well: it discloses the key behavioral limitation that clean results are weaker evidence than dirty ones because stealth tooling patches the declared signals. This is valuable interpretive context beyond the basic function.

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: the first front-loaded with the core function and signals, the second adding an important caveat. Every sentence earns its place with no redundancy or 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?

The description covers purpose and the key reliability caveat, but with no output schema it omits the actual return format or score scale, and lacks usage guidance. It is adequate for a moderately complex tool but leaves the agent uncertain about what the response will look like.

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

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

Although the schema already covers 100% of the parameters, the description adds meaning by linking 'ip' to timezone-versus-IP mismatch and 'device_id' to headless detection and automation frameworks. It explains how the parameters contribute to the scoring logic, going beyond the schema's basic 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 uses a specific verb ('Judge') and names the exact resource ('a browser fingerprint from /fp.js'), then enumerates the concrete signals it evaluates. This clearly distinguishes score_device from sibling scoring tools like score_ip and score_user by focusing on the device fingerprint.

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 explains what the tool does but gives no explicit guidance on when to use it versus alternatives, nor any exclusions. It does not say 'use when you have a device_id' or contrast with score_domain or verify_agent. Usage context is only implied by the tool's name and schema.

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 of behavioral disclosure. It does well by listing what data sources and checks are performed, and it explicitly clarifies the null semantics for 'newly_registered' to prevent misinterpretation. It doesn't mention output format or side-effect absence, but 'Profile' implies a read-only analysis, and the disclosed caveat is valuable.

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 compact and front-loaded, with two sentences that each earn their place. The first lists the tool's core capabilities, and the second provides a necessary edge-case clarification without any 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?

The tool has one parameter, no output schema, and no annotations, so the description must explain return behavior. It lists specific checks and the null caveat, but it never describes the actual output structure, score range, or how to interpret the domain risk score. This leaves a notable gap for an agent trying to use the result downstream.

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 schema already fully describes the only parameter ('domain') with a clear example. The description adds no extra parameter details, but since schema coverage is 100%, the baseline of 3 is appropriate; the description does not need to compensate.

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 ('Profile') with a clear resource ('a domain') and enumerates concrete data points (RDAP registration date, registrar, MX/SPF/DMARC, disposable-mail, risky-TLD). This clearly distinguishes it from sibling tools that target other entities like devices, IPs, or users.

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 makes the context obvious: use this tool to profile a domain's configuration and risk indicators. It doesn't explicitly state when not to use it or name alternatives, but the sibling list and the domain-specific focus provide enough context for an agent to select it appropriately.

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 transparency burden and provides meaningful detail: it discloses the detection categories (commercial VPNs with provider naming, proxies, Tor exit nodes, datacenter hosting) and the output contents (geolocation, ASN, 0-100 score, verdict). It does not mention permissions or rate limits, but for a read-only scoring tool this is a substantial 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 concise sentences, no filler, and the core action is front-loaded. Every clause delivers relevant information about detection scope and return values.

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?

Even without an output schema, the description lists all key return fields and detection categories, which is sufficient for an agent to understand what it will receive. Combined with a clear and complete input schema, the tool is adequately 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 100%: both 'ip' and 'strictness' are already described with examples and threshold semantics. The description adds no extra parameter-specific detail, so the baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Risk-score an IPv4 or IPv6 address.' It clearly differentiates from sibling tools by naming the exact entity type (IP address) and the output (risk score, verdict), making its purpose 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?

Usage is implied through the tool's entity-focused description and the naming pattern of sibling tools (score_device, score_user, score_domain). However, it does not explicitly state when to prefer this tool over alternatives or provide any 'when not to use' 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?

With no annotations, the description carries the full burden. It does disclose the output components and the hard-block aggregation behavior, which is valuable. However, it claims 'domain' is an accepted component when no such parameter exists, and it omits behavior for edge cases like providing no parameters. This is a noticeable transparency 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?

The description is three sentences, front-loaded with the core action, and every sentence earns its place. It covers purpose, output, a key behavioral rule, and usage context with no redundancy or fluff.

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 description covers the tool's purpose, return values, aggregation principle, and when to use it, which is reasonable given no output schema. However, it misses important parameter semantics such as the 'strictness' scale, and the misleading 'domain' reference creates an incomplete picture. For a tool with five optional parameters and no output schema, this is only marginally adequate.

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 only 20% (phone_country), so the description must compensate. It does identify IP, email, phone, and domain as combinable inputs, but 'domain' is not a parameter, and 'strictness' is completely ignored. The description adds minimal semantic value for the actual parameters and even introduces a non-existent one, failing to compensate for the low schema 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?

The description clearly states the tool scores an entire signup with multiple signals and returns a weighted risk score, verdict, and top signals. It also distinguishes from sibling tools like score_ip and score_domain by framing it as 'judging a person rather than a value.' However, it ambiguously lists 'domain' as an input component even though the schema does not include a domain parameter, introducing some confusion.

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 explicitly states when to use this tool: 'This is the tool to use when judging a person rather than a value.' It also frames the whole-signup nature as an alternative to single-value scoring tools, giving clear contextual guidance without needing to name each 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?

With no annotations, the description carries full responsibility. It discloses the return values (true/false plus identity and purpose), the absence of score/verdict, and the crucial requirement that the input must be the request the agent made to the caller. These are meaningful behavioral details beyond the schema.

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

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

The description is four sentences, front-loaded with the core purpose, then covering output, unique value, and invocation requirement. While slightly wordy, every sentence contributes useful information and the structure is logical.

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 explain return values, which it does clearly. It also covers the tool's place among siblings, the caller's policy role, and the critical input condition, making it complete for an agent to select and 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 schema has 100% parameter coverage, so the baseline is 3. The description adds value by instructing the caller to pass the agent's original request and noting that the signature covers method, authority, and path, which clarifies how to set url and headers correctly.

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 cryptographically verifies a Web Bot Auth signature (RFC 9421), using a specific verb+resource. It distinguishes itself from sibling tools by emphasizing it is the only check that 'proves rather than infers,' making its purpose unique.

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 when to use this tool: when you need proof of agent identity rather than an inference from user-agent or scoring. It mentions that the policy decision is the caller's, but does not explicitly exclude alternatives or name specific sibling tools, leaving a small 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?

With no annotations, the description carries the full burden of behavioral disclosure. It transparently lists the checks performed and the output format (0-100 risk score, allow/review/block verdict), which significantly clarifies tool behavior. It does not mention side effects or rate limits, but for a read-only verification tool this is less critical.

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 entire description is a single sentence, front-loaded with the primary action and packed with specific checks and output details. Every phrase contributes value, achieving high information density without 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 two-parameter tool, the description covers the core purpose, checks, and return values, which is adequate. However, the unexplained 'strictness' parameter and the absence of an output schema leave contextual gaps about how to interpret results and configure the tool. It is minimally complete but not comprehensive.

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 50%: 'email' is described in the schema, but 'strictness' has no description and is not explained in the tool description. The description does not clarify how strictness affects the risk score or verdict, leaving a semantic gap that the description fails to bridge.

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 ('Check') and resource ('an email'), then enumerates six distinct validation dimensions (syntax, MX records, disposable providers, role accounts, homograph lookalikes, domain age). This makes the tool's purpose unmistakable and clearly differentiates it from sibling tools like score_domain or score_ip, which target other 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?

The description implies usage context (email risk assessment) but provides no explicit guidance on when to choose this tool over siblings, nor any exclusion criteria or prerequisites. It lacks 'use this when' language and does not mention alternatives, so usage context is only implicit.

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