RTBlint

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context beyond these by declaring the tool as 'experimental' measurement protocol, noting it is 'Part of the Ad Context Protocol (AdCP 3.1) specification,' and specifying which metric IDs it produces. This enriches the agent's understanding without contradicting the annotations.

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: a one-line purpose, a when-to-use directive, and a protocol/spec note. It is front-loaded and every sentence contributes essential information without repetition 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?

Given the rich output schema, full parameter documentation, and strong annotations, the description is complete enough. It explains the tool's role in the pipeline, names specific outputs, and identifies the protocol specification. However, it could briefly mention that the output schema details the return structure, but the output schema itself already covers that, so it earns a solid 4.

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 baseline is 3. The description itself does not elaborate on parameter semantics beyond the schema; it mentions metric IDs in the context of output, not parameters. Since the schema already thoroughly documents all 6 parameters, the description adds no additional value here.

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 'AdCP protocol discovery' and clearly states it returns 'the AdCP releases this agent speaks and the bid-stream conformance metrics it computes.' This uses a specific verb (discovery/returns) and resource (AdCP releases/metrics), distinguishing it from sibling validation tools like validate_bid_request.

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 directs when to use the tool: 'Call this first when wiring rtblint into an agentic buying pipeline.' It also links to sibling tools by naming the metrics produced by validate_bid_request and validate_bid_response. However, it does not explicitly state when not to use it or name an alternative for this discovery role, 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds meaningful context by specifying the version range (2.0 through monthly 2.6 snapshots) and the build-specific nature of the list. This goes beyond the structured annotations without contradicting them.

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 states the core function, the second provides usage guidance. It is front-loaded, with no filler or repetition. Every sentence earns its place.

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 list/discovery tool with no parameters, a clear output schema, and strong annotations, the description adequately covers what the tool does, when to use it, and the expected scope. There are no missing pieces that would hinder correct 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?

The tool has zero parameters, and the schema is empty. With a parameter count of 0, the baseline is 4; the description need not explain parameter meanings. It focuses on the purpose, which 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 identifies the action ('List every OpenRTB version id'), the resource (versions this build can validate against), and the scope (from 2.0 through monthly 2.6 snapshots). It also distinguishes this discovery tool from the validate_* siblings by framing it as a prerequisite for them.

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: 'Call this before pinning version on a validate_* tool.' This provides clear context and establishes a relationship with the sibling tools. However, it does not explicitly state when not to use it or mention alternatives beyond the implicit validate_* family.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context about what validation is performed (lifecycle, tmax plausibility, enums, full OpenRTB validation) and that payloads are treated as protobuf JSON. This goes beyond the annotations without contradicting them.

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: the first sentence states the primary purpose and key validation areas, the second clarifies the protobuf JSON dialect. Every clause adds value with no redundancy or fluff, making it highly efficient.

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 validation aspects thoroughly and is complemented by annotations and an output schema. It could be slightly more explicit about when to choose this over sibling tools, but for a validation tool with rich annotations and output schema, it is substantially 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 adds meaningful context for the payload parameter by explaining that carried payloads are protobuf JSON and validated in that dialect, and that both the bid request and bid response inside the envelope are fully validated. This goes beyond the schema's simple field 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 ('Validate') and names the exact resource ('ARTF RTBRequest envelope'), then enumerates the validation dimensions (required members, lifecycle, payload coherence, tmax plausibility, enums, OpenRTB validation). This clearly distinguishes it from sibling tools like validate_bid_request and validate_bid_response by focusing on the envelope and its carried payloads.

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 clear it is for validating an ARTF RTBRequest envelope, including its carried bid request and bid response. It implies that standalone bid request/response validation should use sibling tools, but it does not explicitly state when-not-to-use or name alternatives. Context is clear but lacks explicit 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable context about apply=true causing mutations to be written and revalidated, reporting introduced findings, which goes beyond the annotations without contradicting them.

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 dense but well-structured, front-loaded with the primary purpose followed by specific validation checks, conditional behavior, and usage guidance. It's slightly long but every sentence adds meaningful information 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?

With an output schema present and full parameter coverage, the description sufficiently covers the tool's purpose, usage context, conditional apply behavior, and the specific validation paths. It's complete for an agent to understand when and how to invoke it, though slightly more detail on return structure could be added.

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%, so all parameters are described in the schema. The description adds context about the validation logic and the relationship between payload and rtb_request, but doesn't provide additional parameter-level meaning beyond what the schema already gives, so it stays at baseline.

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 an ARTF RTBResponse mutation set against its RTBRequest, listing specific checks like envelope id echo and semantic path resolution. It distinguishes itself from sibling validators by focusing on mutation sets and referencing the orchestrator use case.

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 'Call this before proposing mutations to an orchestrator,' giving a clear when-to-use directive. The specific focus on ARTF RTBResponse mutation sets implies when this is appropriate versus other validators, though it doesn't explicitly exclude alternatives.

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?

Annotations already declare read-only, idempotent, non-destructive behavior, so the bar is lowered. The description adds value by disclosing the return structure (issues with rule ids, severities, JSON paths), which is not present in annotations. It does not contradict annotations and provides useful context beyond the safety profile.

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 verb and resource, and the second sentence adds a precise return-value detail. Every word contributes; 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?

Given the rich annotations, detailed parameter schema (100% coverage), and presence of an output schema, the description is complete enough for an agent to select and invoke the tool. It covers purpose, return format, and the version-scoped nature without unnecessary elaboration.

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 fully documents all parameters including their enums, defaults, and specific meanings. The tool description adds no additional parameter semantics, so it stays at baseline 3 as calibrated by the rubric.

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 an OpenRTB 2.x bid request JSON payload against a tracked spec version, and explicitly describes the return format (structured issues with rule ids, severities, JSON paths). This distinguishes it from sibling tools like validate_bid_response and validate_artf_request by focusing on bid requests.

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 context is implied rather than explicit: the description implies it's for bid request validation, but it doesn't explicitly state when to use it over alternatives like validate_bid_response or validate_artf_request, nor does it mention any exclusions or prerequisites. The schema provides some guidance via version and dialect descriptions, but the tool description itself lacks explicit when/when-not 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral context beyond those: it specifies what cross-validation checks (impid, mtype, adm markup, dealid, seat, and currency coherence), that it returns structured issues with rule ids, severities, and JSON paths, and that dialect/profile affect validation. This goes beyond the annotation baseline and provides genuine transparency.

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 two-sentence description is front-loaded with the core validation purpose, then includes the optional cross-validation and output format. Every sentence earns its place, with no redundancy or fluff. It is concise while remaining informative.

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 moderate complexity (5 params, optional bid_request cross-validation) and the presence of a full output schema plus rich annotations, the description covers purpose, optional behavior, and return structure without needing to repeat schema details. It is 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?

Schema description coverage is 100%, so the baseline is 3. The description adds extra meaning for the bid_request parameter by listing the specific fields cross-validated, which is not present in the schema description. It also clarifies that 'tracked spec version' means version-specific validation possible. This lifts it above baseline.

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 validates an OpenRTB bid response JSON payload against a tracked spec version, and mentions optional cross-validation against the originating bid request. This distinguishes it from sibling tools like validate_bid_request, which validate requests. The verb 'Validate' plus specific resource and version scope makes the 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 implies use for bid response validation and explains the optional cross-validation use case with a bid request. It does not explicitly name alternative tools like validate_bid_request or state when not to use this tool, but the context and sibling tool names make the intended usage clear. Thus it earns a 4 rather than 5.

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