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 provided, the description carries the full burden and does substantial work: it discloses that hard blocks are never averaged away, that billing is per component with cached components refunded, and that the exact figure is reported as billable_lookups. It omits details like authentication, rate limits, and empty-input behavior, but the disclosed cost and aggregation semantics are genuinely useful.

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: it front-loads purpose and output, then presents behavioral and cost context, with no filler. The prose is dense but efficient, and the billing condition earns its place because it affects how an agent predicts cost.

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 main output, hard-block behavior, and billing model, which is strong for a scoring tool. However, with no output schema and no annotations, it leaves strictness unexplained, contradicts itself on domain support, and says nothing about calling it with no identifiers. These gaps prevent it from being fully self-sufficient.

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, but it does not explain strictness or resolve the missing 'domain' parameter. It mentions IP, email, phone, and domain as combinable components, yet the schema contains no domain field, and strictness's range or effect is left undocumented. The per-component cost note adds some meaning but does not compensate for the low coverage and mismatch.

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

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

The description states a clear verb and resource ('Score an entire signup in one call') and describes the returned artifacts: a single weighted risk score, a verdict, and top contributing signals. It also distinguishes itself from sibling per-value tools with 'This is the tool to use when judging a person rather than a value.' However, it claims 'domain' is a component while the input schema has no domain property, which slightly muddies the stated 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?

The phrase 'This is the tool to use when judging a person rather than a value' gives an explicit selection heuristic compared to single-value sibling tools, and 'any combination' communicates the aggregate use case. It does not explicitly name siblings or list exclusion conditions, so it stops 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?

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.