PCBLT — Live Checks

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 reveals the tool's output type ('plain-language verdict'), specific checks performed ('Catches the common traps...'), and a critical limitation ('DKIM is probed at common selectors only, so a miss is not proof DKIM is absent'). This is exemplary transparency about edge cases and potential false negatives.

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, each packing important information: purpose, use cases, and limitations. It's front-loaded with the core purpose, has no fluff, and every sentence earns its place. The structure is ideal for quick agent comprehension.

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 output schema and no annotations, the description covers purpose, when to use, what it checks (SPF, DKIM, DMARC), common pitfalls, and caveats. It gives enough detail for an agent to decide whether to invoke it and interpret the result. The only minor absence is return format details, but 'plain-language verdict' is sufficient given the context.

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%, so the schema already documents both parameters. The description adds value by explaining the behavioral context: for 'selector', it clarifies that omitting probes common selectors and that a miss is not proof of absence. It enriches the meaning of the parameters without duplicating schema text.

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 starts with a specific verb ('Check') and resource ('a domain's live email authentication — SPF, DKIM and DMARC'), and clearly distinguishes it from sibling tools like check_security_headers or dns_lookup. It also specifies the output ('plain-language verdict') and scope (whether it is actually enforced), making the tool's purpose 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 description explicitly states when to use it ('Use for questions about mail being spoofed, landing in spam, or failing delivery, and to audit a domain's anti-spoofing posture'), providing clear context. It doesn't explicitly name when-not-to-use or alternatives, but the sibling tools are clearly distinct, so the usage guidance is strong.

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 that it fetches a URL, reports headers with explanations, and additionally flags weak configurations (short HSTS max-age, no includeSubDomains, CSP unsafe-inline/eval). This goes beyond a simple list, though it omits details like redirect handling or timeouts.

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, front-loaded with the primary action in the first sentence, and uses the second sentence to add use cases and extra capabilities. Every word contributes 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 simple one-parameter tool with no output schema, the description covers purpose, use cases, and output behavior thoroughly. It could mention potential limitations (e.g., follows redirects, timeout) but is complete enough for practical use.

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 input schema has 100% coverage with a description for the 'url' parameter, so the baseline is 3. The tool description adds no additional parameter-specific meaning beyond the schema, but also does not need to since the schema suffices.

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 action ('Fetch a URL and report which HTTP security headers it sets') with a specific resource (HTTP security headers) and enumerates the exact headers. It also distinguishes from sibling tools by focusing on security header auditing rather than email auth, DNS, or service status.

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 provides explicit use cases ('Use to audit a site's header posture or verify a header change is live'), giving clear context for when to invoke the tool. However, it does not mention exclusions or alternative tools, 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 provided, but description discloses key behaviors: data sourced from vendor status pages, reflects vendor-admitted status, and distinguishes 'no data' from 'operational'. This provides meaningful context beyond the raw 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?

Two sentences, front-loaded with the primary purpose, and every clause adds value—scope, usage, source, and data granularity. 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 tool with one optional parameter and no output schema, the description fully covers what the tool does, how it behaves, and when to use it. It is complete and well-suited to its simplicity.

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 already covers the 'service' parameter fully, including tracked services and the omit-for-all behavior. The tool description adds no additional parameter semantics, so baseline 3 applies due to 100% 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 reports current status of major services, and the 'Use when asked whether a service is down' phrasing directly addresses common use cases, distinguishing it from historical uptime tool sibling.

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?

Provides explicit when-to-use guidance ('Use when asked whether a service is down or having problems right now'). Does not explicitly name alternatives, but sibling names like service_uptime_history make the contrast clear.

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, description carries the burden. It discloses live query behavior and the NXDOMAIN vs no-record distinction, which is valuable context. It doesn't cover error handling or return format, but the tool is read-only and the key behavioral nuances are addressed.

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 sentences: purpose, usage context, behavioral distinction. Each sentence serves a distinct role, no redundant wording, and the most important info is front-loaded.

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 DNS lookup tool with full schema coverage and no output schema, the description covers purpose, when to use, and a key behavioral distinction. It doesn't describe the output shape, but the core usage and behavior are sufficiently 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?

Schema description coverage is 100%, so baseline is 3. The description lists record types but omits the COMMON option and its aggregate behavior, which the schema covers. No additional semantic value added beyond the 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?

The description uses specific verb 'look up' with resource 'live DNS records' and lists all supported record types. It clearly distinguishes this tool from siblings by focusing on DNS state, while other tools handle email auth, security headers, service status, 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?

Explicit 'Use whenever the real, current DNS state matters' followed by concrete scenarios (domain pointing, mail servers, resolution, propagation). It doesn't explicitly name alternatives or when-not-to-use, but the guidance is clear enough for correct tool selection.

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 excels: it discloses that results are non-verified sightings, that rows carry age, and provides a detailed affiliate disclosure explaining that Amazon links are tagged, marked 'affiliate': true, do not affect deal order, and that a 'disclosure' field must be relayed to the user.

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, each purposeful: purpose, usage, data caveat, and affiliate disclosure. It is front-loaded with the core purpose, and the affiliate disclosure, while detailed, is necessary for transparency and compliance.

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, usage, limitations, and affiliate disclosure, but lacks a full description of the output structure (e.g., fields like price, retailer, deal link). Given there is no output schema, a bit more detail on response fields would improve completeness, though the age and affiliate fields are already hinted at.

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 covers 100% of parameter descriptions, so the baseline is 3. The description adds minimal parameter-specific insight beyond schema; it mentions 'component type' and 'budget' in the usage line, mapping to category and maxPrice, but does not enrich parameter understanding further.

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: 'Search recently-sighted PC hardware deals aggregated from Slickdeals, r/buildapcsales and DealNews.' This clearly distinguishes the tool from siblings like price_check and ram_price_index by emphasizing 'recently-sighted' deals from specific sources.

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 states 'Use when someone wants current deals on a component type or under a budget,' giving a clear invocation context. However, it does not explicitly name alternatives or explain when not to use this tool (e.g., if verified live inventory is needed), though the caveat about sightings being non-verified implies it.

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 burden. It discloses return values (server version, UTC time) and explicitly states it has no other data. This is transparent for a health-check tool, though it lacks details on error handling or network 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?

Two sentences, front-loaded with purpose, and every word contributes. No fluff or repetition.

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 parameterless connectivity check with no output schema, the description fully covers purpose, return payload, and limitations. It is complete and clear.

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 and the schema is empty, so the baseline is 4. The description adds no parameter info, but none is 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?

The description clearly states 'Health check for the pcblt server' with a specific verb and resource, and specifies what it returns (server version, UTC time). It distinguishes itself from siblings like check_service_status by emphasizing its limited purpose.

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?

Explicitly says 'Use only to confirm connectivity' and notes it 'carries no other data', providing clear when-to-use and when-not-to-use guidance. However, it does not explicitly mention alternative tools, 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?

With no annotations provided, the description carries the full burden of disclosure. It clearly explains how the tool compares prices, notes the strength for RAM (per-GB daily index), discloses the fallback to matching deal headlines for other parts, and states it returns 'insufficient_data' rather than guessing. This is excellent transparency about limitations and 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 three sentences long and every sentence earns its place. It fronts the primary purpose, then provides usage guidance, then discloses limitations. There is no filler or repetition of schema 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?

Given the tool's simplicity (2 params, no annotations, no output schema), the description covers all essential aspects: what it does, when to use it, how it behaves with different inputs, and what it returns. It is complete without being verbose.

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 input schema provides 100% coverage with descriptions for both parameters. The tool description adds value by connecting the 'description' parameter to the tool's logic: RAM is compared per-GB against the daily index, while other parts match deal headlines. This gives the agent context to craft better parameter values beyond the schema's generic 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 uses a specific verb 'judge' and names the resource (asking price for a PC part). It clearly distinguishes this from sibling tools like ram_price_index (which likely just provides the index) and find_deals (which finds deals). The purpose is 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?

The description explicitly states when to use the tool: 'when someone asks is $X a good price for Y or wants a listing sanity-checked.' It also clarifies fallback behavior for non-RAM parts and returns insufficient_data rather than guessing. It does not name alternative tools explicitly, but the usage context is clear.

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 what is returned (blended dollars-per-GB, cheapest kits, movement) and notes that RAM pricing moves constantly, implying the data is current. It lacks details on data source or update frequency, but overall provides solid behavioral context.

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, well-structured, and front-loaded with the core function, followed by usage guidance and exclusions. Every sentence adds value with no filler or 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?

Given the tool's simplicity (one optional parameter, no output schema), the description is complete: it explains what data is returned, the supported segments, and the scope limitations. It sufficiently answers what to expect without requiring additional documentation.

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 100%, and the sole parameter 'days' is well-described in the schema. The description adds context about daily history and 7/30-day movement, but does not materially enhance parameter understanding beyond the schema, so baseline 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 clearly states the tool's purpose: current PC memory prices and their history, including blended dollars-per-GB, cheapest kits per segment, and 7/30-day movement. It distinguishes itself from siblings like price_check by explicitly focusing on RAM and excluding GPU/CPU/SSD.

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?

Explicit usage guidance is given: 'Use for any question about what RAM costs right now, whether memory prices are rising or falling, or whether to buy now or wait.' It also states limitations (only DDR4/DDR5 in 16/32GB kits, not GPU/CPU/SSD) and explains that training data cannot answer this.

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 the data is continuously recorded and covers the past, and explains the output composition (percentages and incident windows). However, it omits specifics like sampling frequency, exactly how degraded vs. major outage are defined, or any data delay/limitations for tracked services.

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 sentences: what it does, when to use it, and underlying data. Each sentence earns its place with no redundancy. The purpose and usage are front-loaded, making it easy to scan.

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 exists, but the description explains the return structure (percentages and incident window list) and the data source (continuously-recorded series). It lacks details on timezone, aggregation granularity, or response format, but for a simple history tool with 2 well-described parameters, it is reasonably 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?

Schema description coverage is 100%, so both service and days are already well-documented. The description adds example context ('this month' maps to days) but no new parameter syntax or edge cases beyond what the schema provides. Baseline 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 clearly states it provides service reliability over time with percentages and incident windows. It explicitly contrasts with a status page (sibling check_service_status), and example queries like 'how often has Vercel gone down this month' clarify the tool's distinct purpose.

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 explicitly says 'Use for questions a status page cannot answer' and gives concrete example use cases, effectively excluding real-time status checking. However, it does not name the exact alternative sibling tool, though check_service_status is implied by the 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 provided, the description carries the full burden and does well: it discloses hop-by-hop traversal, status code reporting, final destination, and the cross-host flag. It stops short of mentioning error handling or timeouts, but covers the core observable behavior effectively.

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 output, followed by use cases and a notable behavior flag. Every sentence adds value, 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 tool is relatively simple, and the description covers its primary behavior, use cases, and a safety-relevant flag (cross-host change). No output schema exists, but the description tells the agent what to expect. Minor gaps like response format details or failure modes prevent a perfect score.

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 100%, and both parameters (url with default scheme, maxHops with range) are already well-described in the schema. The description adds no additional parameter meaning ('maxHops' is not mentioned in the description), so a baseline 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 uses a specific verb ('Follow') with a clear resource ('URL's redirect chain') and states the exact output ('report every stop with its status code, plus the final destination'). It clearly distinguishes this tool from sibling network diagnostics (dns_lookup, ping, check_service_status) by focusing on redirect chain traversal.

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 lists three concrete use cases: investigating shortened/tracking links, debugging redirect loops, and verifying migration redirects. It does not mention when NOT to use the tool or name alternative tools, so it misses the 'exclusion' part of a 5-level score.

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