Trillboards DOOH Advertising

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

With no annotations provided, the description carries the full disclosure burden. It successfully documents the 24-hour expiry of the activation_key, specifies the return structure (targeting object with iab_segments), and explains that it generates segment parameters for DSP bid requests. Minor gap: does not clarify if re-activation is idempotent or if there are rate limits.

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?

Excellent structure with clear section headers ([AdCP Signals], WHEN TO USE, RETURNS, EXAMPLE). Information is front-loaded with the core purpose in the first sentence. No redundant text; every sentence earns its place. The example is appropriately scoped to clarify usage without being verbose.

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 zero schema descriptions, no annotations, and no output schema, the description compensates well by documenting return values (activation_key structure, targeting object fields) and providing usage scenarios. Minor deduction for failing to document the 'destinations' parameter and omitting error handling or prerequisite information (e.g., screen registration requirements).

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

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

Schema description coverage is 0%, requiring the description to compensate. The EXAMPLE section demonstrates semantics for signal_type ('audience'), parameters (income/lifestyle object), and screen_ids. However, the 'destinations' parameter (a complex nested array with seat_id and platform fields) is completely undocumented in the description, leaving a significant semantic gap.

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 explicitly states the tool 'Activate[s] an audience signal for DSP targeting' and specifies it generates 'IAB Audience Taxonomy 1.1 segment parameters.' The verb (activate), resource (audience signal), and scope (DSP targeting) are clearly defined, distinguishing it from sibling tools like get_signals or cross_signal_correlate.

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?

Contains an explicit 'WHEN TO USE' section with three specific scenarios: 'Converting audience signals into actionable targeting parameters,' 'Generating IAB segment IDs for programmatic bid requests,' and 'Creating reusable targeting configurations.' This provides clear guidance on when to select this tool over 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?

No annotations provided, so description carries full burden. Explains the computational algorithm (trailing mean/stddev calculation), discloses the exact return structure including anomalies array with z_score/direction fields and baseline statistics, and mentions 'suggested_next_queries' for follow-up behavior. Lacks explicit read-only declaration or rate limit warnings, but the detailed return contract compensates significantly.

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?

Excellent structure with clear section headers (WHEN TO USE, RETURNS, EXAMPLE). Information is front-loaded with purpose and algorithm. No redundant text; each section serves distinct needs (use cases, return contract, invocation patterns). Appropriate length for the tool's complexity.

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 5 parameters, no output schema in structured fields, and no annotations, the description achieves completeness through detailed RETURNS section documenting the exact anomaly object structure, baseline metadata, and follow-up suggestions. Algorithm explanation and multiple use cases cover behavioral complexity sufficiently for agent invocation.

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

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

Schema has 0% description coverage. Description compensates partially through detailed examples showing metric='face_count', threshold_sigma=2.0, etc., which infer parameter purposes. However, lacks explicit parameter definitions (e.g., no direct explanation that 'metric' is the field name to analyze), relying entirely on contextual inference from examples and algorithm 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?

Opening sentences specify the exact statistical method (z-score based anomaly detection using trailing mean/standard deviation) and the core action (detect anomalies in observation patterns). Distinguishes from siblings like query_observations or get_analytics by emphasizing statistical deviation detection rather than raw data retrieval.

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 'WHEN TO USE' section lists four concrete scenarios (audience pattern monitoring, equipment anomalies, commerce/vehicle patterns, outlier moment detection). Includes two detailed usage examples showing different parameter combinations for retail audience vs vehicle detection, providing clear invocation patterns.

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. It compensates well by documenting the return structure (success, processed, failed, total_earnings, errors) and disclosing the financial side effect ('total_earnings credited'). However, it lacks mention of idempotency guarantees, rate limits, or authorization requirements for the batch operation.

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?

Excellent structure with clearly demarcated sections (purpose, WHEN TO USE, RETURNS, EXAMPLE). Information is front-loaded and scannable. Every sentence serves a distinct purpose—no redundancy or verbosity.

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 lack of output schema, the RETURNS section adequately documents response fields. The example provides concrete usage patterns. However, with 0% schema coverage and nested object complexity, the description should explicitly define the impression object fields rather than relying solely on the example.

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

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

Schema description coverage is 0%, requiring the description to compensate. While the example demonstrates the JSON structure, the description fails to explain what 'fingerprint' (device identifier?), 'ad_id', or 'duration_seconds' semantically represent. No parameter meanings are defined beyond the example values.

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 explicitly states 'Record multiple impressions in a single request (up to 100)'—a specific verb + resource with clear batch scope. This effectively distinguishes it from the sibling tool 'record_impression' (singular) by emphasizing bulk processing capabilities.

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?

Includes a dedicated 'WHEN TO USE' section with three specific scenarios: bulk reporting from offline periods, efficient batch processing, and device sync after offline status. This provides explicit guidance on when to prefer this over the single-record alternative.

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, yet description carries full burden excellently: discloses Gemini AI involvement, lists specific ML models available (BlazeFace, YOLOv8-nano, etc.), details deployment_status outcomes ('generated' | 'pushed' | 'push_failed'), warns of CPU cost via estimated_fps_impact, and documents side effects of profile generation/pushing.

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?

Well-structured with clear headers (WHEN TO USE, RETURNS, EXAMPLE). Front-loads the core purpose. Length is substantial but justified by complexity of ML configuration domain. Each section earns its place, though RETURNS section is verbose.

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 description provides extensive RETURNS documentation covering profile structure, timing configuration, and data fields. Compensates for missing annotations with behavioral details. Minor gap: could explicitly document parameter formats rather than relying solely on examples.

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 has 0% description coverage. Description compensates partially via two detailed JSON examples showing screen_id format (MongoDB ObjectID), intent string patterns, and auto_deploy boolean usage. However, lacks explicit parameter definitions or format specifications outside of examples, leaving some semantic ambiguity.

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?

Opens with specific action ('Configure what a screen should sense') and mechanism ('using natural language'), immediately distinguishes from sibling query tools like get_signals or query_observations. Explicitly names the AI backend (Gemini) and target resource (sensing profiles).

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?

Contains explicit 'WHEN TO USE' section with four concrete scenarios (setting up new screens, changing venue detection, special events, translating business intent). Lacks explicit 'when not to use' or direct comparison to siblings like query_observations, but provides strong contextual 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. It successfully discloses that campaigns start in 'draft' status (mutation side-effect) and documents the return structure (campaign_id, status, budget, etc.) compensating for the lack of output schema. It lacks disclosure of auth requirements, rate limits, or error conditions, preventing a perfect score.

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 optimally structured with clear section headers (WHEN TO USE, RETURNS, EXAMPLE) that front-load decision-making information. No sentences are wasted; the example is concrete and immediately follows the conceptual explanation. Length is appropriate for the complexity (12 parameters, nested objects).

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 complex creation tool with 12 parameters, nested objects, no annotations, and no output schema, the description provides strong contextual support through the return value documentation and working example. It adequately compensates for missing structured metadata, though explicit parameter documentation would achieve full completeness.

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

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

With 0% schema description coverage, the description must compensate significantly. The EXAMPLE section demonstrates realistic usage of 8 parameters (name, budget_cpm, daily_budget_usd, venue_types, targeting, creative_url, dates), providing implicit semantics. However, it fails to explain 4 undocumented parameters (screen_ids vs venue_types distinction, creative_type enum values, total_budget_usd vs daily budget logic, or targeting sub-field semantics), leaving gaps the agent must infer.

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 clear, specific action: 'Create a new advertising campaign targeting DOOH screens.' It specifies the verb (create), resource (advertising campaign), and distinct scope (DOOH/digital out-of-home screens), effectively distinguishing it from siblings like create_media_buy or create_experiment.

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 'WHEN TO USE' section explicitly lists three scenarios for tool selection. Critically, it states 'Use update_campaign to set status to active,' explicitly naming the next-step alternative and clarifying the campaign lifecycle (draft → active), which prevents confusion about whether this tool immediately activates campaigns.

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

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

No annotations provided, so description carries full burden. States it 'Sets up' experiments and returns an object with status, indicating persistence. However, lacks disclosure of side effects, idempotency behavior, prerequisites (e.g., whether campaign_id must exist), or error conditions for invalid DMA combinations.

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?

Excellent structure with clear headers (WHEN TO USE, RETURNS, EXAMPLE). Front-loaded purpose statement. No redundant text; each section serves distinct function. Example JSON is appropriately scoped to illustrate usage without verbosity.

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?

Strong coverage given no output schema: RETURNS section documents the return object structure. Addresses the complexity of 8 parameters with statistical concepts via example. Minor gap: does not mention prerequisite that campaign_id should exist or relationship to get_incrementality for analysis phase.

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

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

With 0% schema description coverage, description partially compensates via the EXAMPLE (shows 6/8 parameters) and WHEN TO USE (mentions holdout %, MDE, power). However, target_alpha is only in the example with no explanation, and critical terms like 'DMA' and 'MDE' are not defined. Adds some meaning but insufficient for full semantic understanding.

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?

Opens with specific verb 'Create' and resource 'incrementality experiment', clearly distinguishing from sibling tools like create_campaign or create_media_buy. Explicitly lists the three experiment types (geo-holdout, ghost ads, PSM) that match the schema enum, clarifying 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?

Contains explicit 'WHEN TO USE' section with three specific scenarios including timing (before/during campaign) and configuration contexts. Lacks explicit 'when not to use' or reference to sibling get_incrementality for reading existing experiments, but provides strong contextual 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 must carry full behavioral burden. It successfully discloses return values (media_buy_id, creative_deadline) and the targeting mechanism, but omits critical operational details like idempotency, error conditions, authentication requirements, or billing implications.

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?

Well-organized with clear section headers (WHEN TO USE, RETURNS, EXAMPLE). Information is front-loaded with the core purpose first. The JSON example is lengthy but justified given the 0% schema coverage. Minor redundancy exists between the opening sentence and RETURNS section.

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 high complexity (8 params, nested objects) and absence of output schema, the description adequately compensates by documenting return fields and providing a concrete input example. However, it falls short of fully documenting all input parameters or error handling scenarios.

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

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

Schema description coverage is 0%, requiring the description to compensate. The JSON example effectively illustrates the semantic structure of core parameters (buy_spec, creative) showing expected field names and formats. However, it fails to document several parameters (brand, packages, start_time/end_time) leaving significant gaps.

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 explicitly states it creates a 'media buy (campaign)' targeting 'DOOH screens' using an 'AdCP buy specification.' The [AdCP Media Buy] prefix and DOOH focus clearly distinguish it from the generic sibling create_campaign.

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?

Includes a dedicated 'WHEN TO USE' section with three specific scenarios (programmatic DOOH buys, DSP trading desk agents, automated workflows). However, it lacks explicit 'when not to use' guidance or named alternatives like create_campaign.

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

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

No annotations provided, so description carries full burden. Compensates well by documenting all 8 available event triggers with human-readable conditions, and discloses return values (webhook_id, secret, status). Missing explicit retry policies or permission requirements, but event catalog and return structure are thoroughly covered.

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

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

Well-structured with clear section headers (WHEN TO USE, AVAILABLE EVENTS, RETURNS, EXAMPLE). Front-loaded one-liner summarizes purpose. Length is justified given zero schema documentation—every section adds necessary context that structured fields omit.

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?

Comprehensive for a 4-parameter mutation tool with no output schema. Covers critical path (event types, required params via example, return structure). Minor gaps on rate limits and full optional parameter documentation, but sufficient for correct invocation given the complexity.

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 has 0% description coverage. Description compensates effectively: AVAILABLE EVENTS explains the 'events' array enum values; EXAMPLE demonstrates 'url' format and 'secret' usage for HMAC signing. Only gap is the optional 'description' parameter which is undocumented.

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?

Opens with specific verb 'Create' + resource 'webhook subscription' + context 'real-time events.' The action clearly distinguishes from sibling tools like list_webhooks, delete_webhook, and test_webhook through the creation semantics.

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?

Contains explicit 'WHEN TO USE' section with three concrete scenarios (real-time notifications, external integrations, monitoring ad playback). Lacks explicit 'when-not-to-use' or direct sibling comparisons, but the contextual scenarios provide strong implicit 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?

Discloses critical dual-path behavior (pre-computed insights vs ad-hoc computation from observation_stream) and extensively documents return structure (statistical measures, confidence intervals, metadata). However, with no annotations provided, it omits safety classification (read-only status), computational cost warnings, or rate limiting behavior for the ad-hoc computation path.

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?

Well-structured with clear sections (purpose, mechanism, when to use, returns, examples). Front-loaded with specific purpose statement. Lengthy but justified given lack of output schema and 0% parameter coverage. RETURNS section is verbose but necessary substitute for missing output schema.

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 high complexity (statistical correlation analysis), 0% schema coverage, and absence of output schema, the description achieves high completeness. It documents the complex return structure extensively (correlation metrics, confidence intervals, interpretation), provides two full usage examples, and explains the underlying data source logic.

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

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

Schema description coverage is 0%, requiring description compensation. Examples demonstrate signal_a/signal_b are signal identifiers (e.g., 'attention_score') and show filters usage (venue_type, daypart), but nested filter properties (time_range format, dma_code semantics) remain undocumented. Examples partially compensate but don't fully close the documentation gap.

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?

Excellent specificity with clear verb ('Discover correlations'), resource ('different signal types'), and mechanism (pre-computed table vs ad-hoc observation_stream computation). Opening example immediately clarifies scope with concrete use case (ad fill rate vs attention at QSR venues).

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 'WHEN TO USE' section lists four specific scenarios (understanding relationships, finding behavior-outcome correlations, discovering hidden patterns, validating hypotheses). Lacks explicit 'when not to use' or direct sibling comparisons (e.g., vs query_observations for raw data), but examples effectively demonstrate appropriate use cases.

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

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

No annotations are provided, so the description carries the full disclosure burden. It effectively communicates the 'soft-delete' nature (critical for a destructive-looking operation) and documents return values (success, device_id, message) despite no structured output schema. Missing side effects on associated campaigns or recovery procedures.

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?

Excellent structure with clear sections (main description, WHEN TO USE, RETURNS, EXAMPLE). Information is front-loaded with the critical 'soft-delete' behavior stated immediately. No redundant or wasted text.

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 single-parameter mutation tool, the description is comprehensive: it explains the soft-delete behavior, usage contexts, and return structure. Could be improved by mentioning error scenarios (e.g., device not found) or side effects on active campaigns associated with the device.

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

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

Schema coverage is 0% with no parameter descriptions. The description compensates partially through the EXAMPLE section showing device_id: 'lobby-kiosk-old', which implies the ID can be a human-readable string. However, it lacks explicit parameter documentation (e.g., whether it's a UUID, serial number, or friendly name).

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 'Soft-delete a device from the partner account,' providing a specific verb (soft-delete), resource (device), and scope (partner account). It clearly distinguishes from siblings like get_device, list_devices, and register_device through the specific soft-delete semantics.

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?

Includes an explicit 'WHEN TO USE' section with three specific scenarios (decommissioned devices, test cleanup, relocation). However, it lacks explicit 'when not to use' guidance or alternatives (e.g., suggesting a 'deactivate' sibling tool for temporary removal instead of deletion).

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

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

No annotations provided, so description carries full burden. Documents return values (success boolean, webhook_id, message) which is helpful given no output schema exists. However, fails to disclose critical behavioral traits for a destructive operation: does not warn that deletion is permanent, explain what happens to pending deliveries, or mention required permissions.

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?

Well-structured with clear section headers (WHEN TO USE, RETURNS, EXAMPLE). Each section earns its place - RETURNS is necessary given no output schema exists. Slightly verbose but appropriately so for a tool with zero schema documentation.

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 single-parameter destructive operation with no annotations and no output schema, the description adequately covers purpose, usage scenarios, return structure, and usage example. Would be improved with a note about operation permanence, but otherwise complete for the complexity level.

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

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

Schema coverage is 0% (no description field for webhook_id parameter). Description provides an EXAMPLE section showing the expected format 'wh_mmmpdbvj_8b7c5a59296d', which adds value beyond the raw pattern regex. However, lacks explicit parameter definition explaining that webhook_id is the unique identifier of the webhook to be deleted.

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 the specific action 'Delete a webhook subscription' - clear verb + resource combination that immediately distinguishes it from sibling tools like create_webhook, update_webhook, or list_webhooks.

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?

Includes explicit 'WHEN TO USE' section with three concrete scenarios (removing unneeded webhooks, cleaning up old integrations, removing test webhooks). Lacks explicit 'when not to use' guidance or alternative suggestions (e.g., when to prefer update_webhook over deletion).

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 clearly explains what information the tool returns (operation details, parameters, request_body, responses, linked_error_codes) and provides a concrete example of usage. However, it doesn't mention potential limitations like rate limits, authentication requirements, or error handling for invalid inputs.

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 well-structured with clear sections (purpose, usage guidelines, returns, example) and every sentence adds value. It's appropriately sized for a tool with two parameters and no annotations, with no redundant information.

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

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

For a tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description provides complete context. It explains what the tool does, when to use it, what it returns, and includes a concrete example showing parameter usage. This is sufficient for an agent to understand and invoke the tool correctly.

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

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

With 0% schema description coverage for the two parameters (path and method), the description compensates fully by providing an example that shows exactly how to use these parameters: path as the endpoint path string and method as the HTTP method. The example demonstrates the expected format and usage context.

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 specific verbs ('describe a single API operation') and resources ('parameters, response shape, and error codes'). It distinguishes itself from sibling tools like 'list_endpoints' by focusing on detailed inspection of individual endpoints rather than listing 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 includes an explicit 'WHEN TO USE' section with two specific scenarios ('inspecting an endpoint's full contract before calling it' and 'discovering which error codes an endpoint can return and how to recover'), providing clear guidance on when this tool should be selected over 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?

With no annotations provided, the description carries full burden. It successfully documents return values (success, device_status, next_heartbeat_seconds) and timing recommendations in the RETURNS section. However, it lacks disclosure of idempotency, rate limiting, failure handling, or side effects on server state beyond the basic success indicator.

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?

Excellent structure with clearly demarcated sections (main description, WHEN TO USE, RETURNS, EXAMPLE). Every sentence serves a distinct purpose. The front-loaded purpose statement followed by specific usage contexts creates an efficient information hierarchy appropriate for the tool's complexity.

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 simple flat schema (5 parameters, no nesting) and absence of structured output schema, the description compensates well by documenting return values in the RETURNS section and providing a concrete invocation example. Completeness would be perfect with explicit parameter descriptions, but the combination of example and usage guidelines provides sufficient context for invocation.

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

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

Schema description coverage is 0%, requiring the description to compensate. The EXAMPLE section provides implicit semantic context (fingerprint as device identifier, status values like 'playing', uptime_seconds format), but lacks explicit parameter definitions. It adequately compensates for basic understanding but doesn't fully document constraints or meanings for all five parameters.

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 opening sentence uses a specific verb ('Send') with clear resource ('heartbeat signal') and purpose ('report its status'). It effectively distinguishes from sibling CRUD operations like register_device, get_device, and delete_device by emphasizing the ongoing health-monitoring aspect versus lifecycle management.

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 explicit 'WHEN TO USE' section provides precise guidance including frequency (every 30-60 seconds) and specific scenarios (health monitoring, playback reporting, error reporting). This clearly defines invocation timing and distinguishes from alternatives like register_device (initial setup) or get_device (retrieval).

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

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

No annotations provided, so description carries full burden. Provides detailed 'RETURNS' section disclosing output structure (screens array with location/venue/audience fields, total counts, online status) and explains real-time data availability ('when available'). Lacks error handling or rate limit 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?

Well-structured with clear sections (purpose, WHEN TO USE, RETURNS, EXAMPLE). Front-loaded with specific purpose statement. Length is appropriate given complexity and lack of schema annotations. Example is concrete and illustrative without being verbose.

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?

Comprehensive coverage for a 4-parameter discovery tool with nested objects. Compensates for 0% schema coverage and missing output schema by documenting return values and semantics in the description. Provides sufficient context for an agent to construct valid invocations and understand results.

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 has 0% description coverage, but description compensates via 'WHEN TO USE' (explaining venue_types values like retail/transit, location options like city/state/radius) and concrete 'EXAMPLE' showing exact syntax for audience_profile, location, and venue_types parameters. Covers primary use cases effectively despite not documenting every nested field (e.g., lat/lng).

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?

Opens with specific verb+resource: 'Discover available DOOH screens in the Trillboards network.' Clearly distinguishes from sibling 'list_devices' (which likely lists registered/owned devices) by specifying this queries available inventory in the broader network for media buying purposes.

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?

Contains explicit 'WHEN TO USE' section with four specific scenarios (venue type filtering, geographic filtering, audience profiling, inventory overview). Lacks explicit 'when not to use' or named alternatives (e.g., distinguishing from 'list_devices'), but the contextual 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 provided, the description carries the full burden and discloses: (1) data type transferred ('MAID hashes'), (2) idempotency ('Creates or reuses'), (3) detailed return status codes ('synced', 'credentials_missing', etc.), and (4) specific output fields with semantics (maidCount vs accepted). Lacks rate limiting or retry behavior details.

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?

Excellent structure with clear visual hierarchy (main description → WHEN TO USE → RETURNS → EXAMPLE). Every section earns its place; the RETURNS documentation is particularly valuable given the lack of output schema. No redundant or filler text.

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?

Comprehensive coverage for a 2-parameter integration tool. The description documents input parameters via example, explains behavioral side effects (DSP segment creation), details return values (status codes and counts), and lists all supported DSP destinations, fully compensating for missing annotations and schema descriptions.

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 has 0% description coverage, but the description compensates effectively: the 'EXAMPLE' block demonstrates parameter usage, 'Supported destinations' documents the enum values, and contextual sentences ('campaign's exposed cohort', 'specified DSP') imply the semantics of both required parameters.

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 precise action ('Export'), resource ('exposed audience cohort'), and purpose ('for retargeting'). It clearly distinguishes from sibling 'export_dataset' by specifying this is for DOOH-exposed audience activation rather than general data export.

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 'WHEN TO USE:' section explicitly lists three specific scenarios: activating DOOH-exposed audiences, pushing to specific DSPs (TTD/DV360/Meta), and measuring cross-channel lift. This provides clear selection criteria against alternatives like 'get_campaign_performance' or 'export_dataset'.

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

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

No annotations provided, so description carries full disclosure burden. It explicitly details the k-anonymity algorithm (k=5, suppressing groups with fewer than 5 observations) and privacy protection behavior. Also describes the return structure (data array, metadata object, suggested_next_queries) which compensates for missing output schema. Lacks rate limits or timeout characteristics, preventing a perfect score.

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?

Well-organized with clear section headers (WHEN TO USE, RETURNS, EXAMPLE) that front-load critical information. Length is justified by the complexity (4 dataset types, privacy algorithm, nested filters) and absence of output schema. Each section earns its place, though the RETURNS section is verbose due to lack of structured output schema.

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 high complexity (k-anonymity, multiple dataset types, nested filter objects), zero schema descriptions, no annotations, and no output schema, the description achieves comprehensive coverage. It explains return values, parameter semantics via examples, dataset type distinctions, and privacy behavior—sufficient for correct agent invocation.

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

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

Schema description coverage is 0%, requiring heavy description compensation. The description maps filter parameters to semantic concepts (time, geography, venue type, observation family) and provides extensive enum value descriptions for the dataset parameter (4 types with explanations). Examples demonstrate nested structure usage, though explicit documentation of filter object internals (e.g., time_range having start/end) is implied rather than stated.

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

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

Description opens with specific verb+resource ('Export observation data as a structured dataset') and immediately distinguishes scope with filtering capabilities and k-anonymity features. The dataset type enumeration (observations, audience, vehicle, cross_signal) clearly differentiates this from sibling tools like query_observations (simple queries) and export_cohort (cohort-specific exports).

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?

Contains explicit 'WHEN TO USE' section with four concrete scenarios (external analysis, ML/reporting, vehicle/commerce data, correlation analysis) that clearly delineate appropriate contexts. These scenarios help agents distinguish between this export tool and analytics/query siblings.

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

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

No annotations provided, so description carries full burden. Discloses technical implementation (768-D vectors, multi-modal observation data, pgvector cosine similarity), return structure (similarity scores 0-1, evidence_grade), and data source (MomentEmbeddingService). Missing operational constraints (rate limits, latency), but strong algorithmic 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?

Well-structured with clear headers (WHEN TO USE, RETURNS, EXAMPLE) and front-loaded purpose statement. Technical details (768-D vectors, pgvector) provide necessary context but add length. No wasted sentences, though could condense embedding service implementation details.

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?

Comprehensive for a complex search tool lacking annotations/output schema. Documents return structure (data array with observation_id, similarity, payload), metadata fields, and follow-up suggestions. Covers multi-modal data sources and similarity methodology. Missing only operational/constraint details given the complexity.

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 has 0% description coverage for 4 parameters, requiring heavy description compensation. While 'query' is well-explained ('natural-language description of the target moment') and demonstrated in examples, the other three parameters (limit, venue_type, min_similarity) are completely undocumented in the description text. Only partial compensation achieved.

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 ('Find') + resource ('audience moments') + mechanism ('embedding similarity search') and scope ('historically similar... across the screen network'). It clearly distinguishes from siblings like 'semantic_search_observations' by emphasizing multi-modal embeddings and historical moment retrieval versus general content search.

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?

Includes explicit 'WHEN TO USE' section with four concrete scenarios (searching historical moments, finding 'moments like this one', discovering similar compositions, planning ad placements). Two detailed examples show query syntax. Lacks explicit 'when not to use' or named sibling alternatives (e.g., when to prefer 'query_observations'), hence not 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, so description carries full burden. Explicitly states 'does NOT require authentication,' which is critical safety info. Compensates for missing output_schema by detailing return structure (supported_protocols, inventory, audience_data, pricing, discovery). Does not mention rate limits or caching 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?

Excellent structure with [AdCP] tag, concise purpose statement, authentication note, and clearly delineated WHEN TO USE and RETURNS sections. Every sentence earns its place; no 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 no output schema exists, the detailed RETURNS section documenting the five top-level response fields provides essential completeness. Auth note covers security context. Missing only operational details like rate limits or cache headers, but fully adequate for a capabilities discovery tool.

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

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

Input schema has zero parameters. Per rubric, 0 params = baseline 4. Description appropriately does not invent parameter semantics where none exist.

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

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

Description clearly states the tool retrieves 'Trillboards AdCP capabilities and supported protocols' and positions it as a 'capability declaration for Trillboards as an AdCP DOOH seller agent.' This effectively distinguishes it from 50+ operational siblings (create_campaign, update_media_buy, etc.) by establishing it as a meta/discovery tool.

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?

Contains explicit 'WHEN TO USE' section with three specific scenarios: discovering protocols, understanding audience signals, and getting MCP endpoints. Lacks explicit 'when not to use' or named alternatives, though as a discovery endpoint it serves a unique prerequisite role to other AdCP tools.

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 full behavioral disclosure burden. The 'RETURNS' section effectively documents the response structure (summary, time_series, top_devices, breakdown) and data types (impressions, earnings, active_devices), compensating for the missing output schema. Does not mention rate limits or caching 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?

Excellent structure with clearly delineated sections (description, WHEN TO USE, RETURNS, EXAMPLE). Information is front-loaded with the core purpose. The examples are concrete and relevant. No wasted text despite the length.

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?

Missing crucial clarification on parameter requirements: the schema indicates 0 required parameters, but the examples imply start_date and end_date are necessary (or at least commonly used). Should specify default behavior when dates are omitted. The RETURNS section adequately compensates for the lack of output schema.

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

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

With 0% schema description coverage, the description relies on the 'EXAMPLE' section to convey parameter semantics. The examples demonstrate date formats (YYYY-MM-DD) and group_by values ('day', 'device'), but omit documentation for device_id purpose and the remaining enum values ('week', 'month'). Partial compensation for schema gaps.

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 retrieves 'analytics data for the partner account,' specifying the scope (account-level vs. entity-specific). This distinguishes it from siblings like get_campaign_performance or get_content_performance. However, it could more explicitly contrast with these specific analytic tools to prevent 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 'WHEN TO USE' section provides four specific scenarios (viewing performance metrics, analyzing devices, generating reports, comparing time periods). This gives clear activation signals. Lacks explicit 'when NOT to use' guidance or named alternatives for campaign-specific analytics.

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

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

No annotations provided, so description carries full burden. It adds substantial value by explaining FEIN technology (measurement vs estimation), providing the aCPM calculation formula, and detailing the return structure across four categories (impressions, attention, economics, emotion). Does not cover operational traits like rate limits or caching.

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?

Well-structured with clear sections: one-line summary, value proposition, WHEN TO USE bullets, RETURNS bullets, and formula. Despite length, every sentence adds distinct value (technology context, use cases, return schema, calculation methodology).

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?

Despite lacking an output schema, the description comprehensively documents all return fields (impressions, attention metrics, economics, emotion) with their types/ranges. It explains the FEIN technology context and provides the aCPM formula, making it complete for this specialized tool.

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

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

Schema has 0% description coverage for the single 'campaign_id' parameter. The description states metrics are retrieved 'for a campaign', implying the parameter purpose, but does not explicitly name or document 'campaign_id'. With only one required parameter, this is minimally adequate but does not fully compensate for the schema gap.

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 ('Get') + resource ('edge AI attention metrics') + scope ('for a campaign'), and explicitly distinguishes from sibling analytics tools by specifying 'FEIN-powered' and contrasting DOOH measurement with digital estimation.

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 an explicit 'WHEN TO USE' section listing three specific scenarios (measuring human attention, comparing aCPM, getting face/emotion data). Lacks explicit 'when-not-to-use' or named sibling alternatives (e.g., get_creative_attention), but the context makes the scope 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?

No annotations provided, but description compensates with detailed RETURNS section documenting all output fields (date, liftPct, incrementalVisits, etc.) and a complete usage EXAMPLE. Does not mention rate limits or caching behavior, but clearly establishes the read-only data retrieval pattern.

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?

Excellent structure with clear section headers (WHEN TO USE, RETURNS, EXAMPLE). Front-loaded purpose statement. No wasted words; every sentence provides actionable guidance or structural 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 no output schema exists, the description comprehensively documents return values. With 3 parameters and zero schema descriptions, the example provides minimal viable context. Does not mention pagination or date range limits, but sufficient for tool selection and basic invocation.

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

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

Schema has 0% description coverage. Description compensates partially via the EXAMPLE block showing parameter formats (e.g., '2026-03-01' for dates, 'camp_abc123' for campaign_id), but lacks explicit semantic definitions for what each parameter represents or that start_date/end_date are optional.

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?

States specific action (Get), resource (daily attribution timeseries), and scope (for a campaign). However, it does not explicitly differentiate from siblings like get_campaign_attribution or get_multi_touch_attribution, leaving the agent to infer the distinction from 'daily' and 'timeseries' keywords.

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?

Contains explicit 'WHEN TO USE' section with three concrete scenarios (tracking trends, identifying lift days, building dashboards). Lacks explicit exclusions or alternative tool recommendations for non-timeseries attribution needs.

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, description carries full burden and discloses methodology ('Uses historical audience data'), explains prediction confidence (0-1 scale based on sample count), and documents all six return fields in RETURNS section. Minor gap: no error conditions or data freshness details.

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?

Well-structured with clear headers (WHEN TO USE, RETURNS, EXAMPLE). Every sentence earns its place: purpose statement, three use cases, methodology note, six return value explanations, and concrete JSON example. Length is justified by 0% schema coverage and missing output schema.

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?

Excellent compensation for missing output schema via detailed RETURNS section. Given 0% input schema coverage and no annotations, the example provides implicit context for all four parameters, though explicit parameter descriptions would strengthen completeness further.

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 has 0% description coverage. Description compensates partially via EXAMPLE showing valid values (hour:15, day:1, lookback_days:30), but lacks explicit semantics for 'day' numbering (0=Sunday vs Monday) or 'lookback_days' purpose. Baseline viable given example coverage, but explicit parameter docs needed for full compensation.

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?

Opens with specific verb 'Predict' targeting 'audience' at a 'screen at a specific time', clearly distinguishing from sibling get_live_audience (real-time) and predict_moment_quality (quality scoring). The forecasting intent is 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?

Contains explicit 'WHEN TO USE' section listing three specific scenarios: planning campaigns, estimating before buying, and comparing times of day. This provides clear context for selection over alternatives like get_live_audience.

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 delivers substantial value: it discloses the 64-dimensional vector methodology, HNSW cosine similarity algorithm, and detailed return structure (similarity scores 0-1, metadata fields). It could improve by mentioning performance characteristics or caching 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?

Well-structured with clear sections (technical overview, when to use, returns, example). Front-loaded with the core purpose. Technical details (HNSW, pgvector) are appropriately included to inform the agent about the similarity methodology without being overly verbose.

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?

Despite no output schema and no annotations, the description adequately documents return values through the RETURNS section (array structure, field definitions, similarity ranges). The complexity of the vector search operation is sufficiently contextualized for agent usage.

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

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

Schema description coverage is 0%, requiring the description to compensate. While the EXAMPLE block demonstrates usage of screen_id, limit, and min_similarity, it fails to document the filtering semantics of 'country' and 'venue_type' parameters, leaving 40% of the parameter space unexplained.

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 ('Find') and resource ('screens with similar audience profiles'), clearly distinguishing this from siblings like discover_inventory (browsing) or get_live_audience (real-time state). The technical method (pgvector similarity) further clarifies the unique capability.

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 an explicit 'WHEN TO USE' section with three concrete scenarios (expanding campaign reach, finding inventory, building segments). This offers clear positive guidance, though it lacks explicit 'when not to use' comparisons or named alternative tools from the sibling list.

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 full burden and successfully discloses what data is retrieved (Stripe ID, credit balance, payment status). It clarifies this is a status retrieval operation. Does not mention rate limits or caching, but covers the essential behavioral scope.

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 with zero waste. First sentence front-loads the action and return value; second sentence provides usage context. No filler or redundant restatement of the tool name.

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 (no input params) and lack of output schema, the description compensates adequately by listing the four key data points returned. Sufficient for an agent to understand what information will be available after 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?

Input schema has zero parameters. Per scoring rules, 0 params establishes a baseline of 4. Description correctly does not invent parameter semantics where none exist.

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?

Uses specific verb 'Check' with clear resource 'billing status' and enumerates exact fields returned (credit balance, Stripe customer ID, payment method status). Implicitly distinguishes from sibling 'setup_billing' by describing a read-only verification action versus setup/configuration.

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 states when to use: 'before making paid API calls' and the specific decision it enables: 'determine if billing setup is needed.' This naturally implies the alternative workflow (use setup_billing if not set up) without being verbose.

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

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

No annotations provided, so description carries full burden. Extensively documents return structure across five categories (reach, footfall, cost, quality, dataFreshness) and explicitly states 'Returns null if no attribution data exists.' Missing operational details like caching behavior or latency.

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?

Excellent structure with clear section headers (WHEN TO USE, RETURNS). Front-loaded purpose statement followed by contextual details. Every sentence provides value; no repetition of schema constraints or tautology.

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?

Despite lacking structured output schema, the RETURNS section comprehensively documents all return fields (15+ metrics) including data freshness indicators (provisional vs finalized). Appropriate completeness for a read-only retrieval tool with simple input requirements.

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 has 0% description coverage for the single campaign_id parameter. While the parameter name is self-documenting and schema includes length constraints, the description doesn't compensate by explaining ID format, where to obtain it, or examples. Baseline 3 for minimal parameter count with self-evident naming.

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?

Opens with specific verb+resource: 'Get comprehensive attribution summary for a DOOH campaign.' The 'comprehensive' and 'DOOH' qualifiers distinguish it from sibling tools like get_attribution_timeseries (time-based) or get_creative_attribution (creative-level).

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?

Contains explicit 'WHEN TO USE' section with three specific scenarios (measuring effectiveness, high-level views, checking significance). However, lacks explicit alternatives or exclusions (e.g., when to use get_attribution_timeseries instead for temporal analysis).

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

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

No annotations are provided, so the description carries the full burden. It discloses important behavioral traits: data structure (lat/lng clusters), volume limits (max 500), precision (3 decimal places), and return fields (uniqueDevices, totalExposures, avgConfidence). However, it omits operational details like error handling, rate limits, or required permissions.

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?

Excellent structure with clearly demarcated sections (main description, WHEN TO USE, RETURNS). Information is front-loaded with the core purpose. Every sentence provides unique value; no repetition of structured data or filler content.

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

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

Given the absence of an output schema, the description adequately compensates by detailing the return structure, field meanings, and data limits (max 500). With only one input parameter, the tool is inherently simple, though mentioning the campaign_id parameter would have achieved completeness.

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 0% description coverage (campaign_id lacks a description field), and the tool description makes no mention of the parameter whatsoever. While the parameter name is semantically clear given the tool name, the description fails to compensate for the complete lack of schema documentation by providing context about valid campaign_id formats or sources.

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 ('Get') and clearly identifies the resource ('geographic exposure heatmap data') and scope ('for a campaign'). It distinguishes itself from siblings like get_campaign_performance and get_campaign_attribution by emphasizing geographic visualization and map-based data.

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?

Contains an explicit 'WHEN TO USE' section with three specific scenarios (visualizing coverage, identifying hotspots, analyzing foot traffic distribution). Provides clear positive guidance but lacks explicit exclusions or named alternatives for when other campaign tools might be more appropriate.

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 full burden. The 'RETURNS' section excellently discloses the response structure (campaign fields, performance metrics, screen_breakdown), compensating for the lack of output schema. However, it omits explicit statements about read-only safety or rate limits.

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?

Perfectly structured with clear headers (WHEN TO USE, RETURNS, EXAMPLE). Information is front-loaded with the core purpose in sentence one. No wasted words; every section earns its place by adding distinct value beyond the schema.

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 single-parameter tool, the description is comprehensive. The detailed RETURNS section fully compensates for the missing output schema, documenting the nested structure (performance, screen_breakdown) that the agent needs to interpret results.

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 0% description coverage (campaign_id lacks a description field). The tool description compensates partially via the EXAMPLE section showing a UUID format, but the main text lacks explicit parameter semantics (e.g., 'UUID identifier of the campaign to retrieve').

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 the specific verb 'Get' and resource 'detailed performance metrics for a campaign'. It distinguishes itself from sibling tools like get_campaign_attribution and get_campaign_heatmap by explicitly mentioning 'per-screen impression breakdowns' and specific metrics like avg_cpm and latency.

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 'WHEN TO USE' section provides three explicit scenarios (monitoring active, reviewing completed, per-screen breakdowns). While it lacks explicit 'when not to use' guidance or named alternative tools, the specific contexts provided effectively guide selection among the many sibling analytics tools.

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

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

No annotations provided, so description carries full burden. Comprehensive 'RETURNS' section discloses data structure (aggregates, distributions, top 10 screens), which substitutes for missing output schema. However, misses operational traits: no mention of data freshness/lag, rate limits, cost of query, or caching 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?

Well-structured with clear sections (header, WHEN TO USE, RETURNS, EXAMPLE). Front-loaded purpose statement. Lengthy but appropriate given zero schema coverage and lack of output schema—every section adds necessary value that structured fields omit.

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?

Highly complete for a complex analytics tool with no annotations or output schema. Use cases, return structure, and query examples provide rich context. Only gap is explicit parameter documentation, though examples partially cover this.

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 has 0% description coverage (no parameter descriptions). Description partially compensates with examples showing 'retail' as venue_type and 30/7 as days values, but fails to document constraints (1-90 range for days), valid venue_type enumerations, or video_id format requirements.

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?

Opens with specific verb ('Get'), resource ('performance metrics'), and scope ('video across the Trillboards DOOH network'). Clearly distinguishes from sibling 'get_campaign_performance' (content-level vs campaign-level) and 'search_content' (metrics retrieval vs discovery).

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?

Excellent 'WHEN TO USE' section lists four specific scenarios (checking plays/attention, analyzing venue types/dayparts, finding top screens, comparing time windows). Examples demonstrate query patterns. Lacks explicit 'when NOT to use' warnings (e.g., don't use for real-time streaming), but scope is clear from positive examples.

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 full disclosure burden. It excels by documenting the performance score formula (attention/replay/dwell weighting) and detailed return structure including metadata fields. Missing operational details like data freshness, caching behavior, or rate limits keep it from a 5.

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?

Excellent structure with clear sections: purpose statement, WHEN TO USE bullets, RETURNS schema documentation, performance formula, and EXAMPLES. Every section earns its place; the length is appropriate given the lack of output schema and schema descriptions.

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 zero schema descriptions, no annotations, and no output schema, the description is remarkably complete. It compensates with detailed return value documentation, usage examples showing different parameter combinations, and business logic explanation (scoring formula).

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

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

Schema coverage is 0%, requiring heavy description compensation. The daypart enum values are documented in the WHEN TO USE bullet. Venue_type is mentioned but valid values aren't specified. Limit appears only in examples without textual description of its purpose or constraints (1-100). Partial compensation via examples.

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 retrieves 'best-performing content recommendations' using a 'venue type' and optional 'time context', providing specific verb and resource. However, it does not explicitly distinguish from similar siblings like `get_content_performance` or `recommend_creative`.

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 'WHEN TO USE' section provides explicit scenarios including content scheduling decisions, engagement optimization, and daypart programming. While excellent for positive guidance, it lacks explicit 'when not to use' guidance or naming of alternative tools like `search_content` for browsing non-ranked content.

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

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

No annotations provided, so description carries full burden. Extensive 'RETURNS' section documents output structure (array ranking, specific fields like avgAttentionScore 0-1), which adds value. However, lacks explicit statement that this is read-only/safe, pagination behavior, or rate limits.

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?

Perfectly structured with three distinct sections (purpose, WHEN TO USE, RETURNS). No filler text; every sentence provides actionable information. Appropriate length for the complexity level (single parameter input).

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 single parameter input and no output schema, the RETURNS section adequately documents the expected response structure. Would benefit from mentioning pagination limits for large campaigns or error conditions, but covers the essential contract sufficiently.

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 has 0% description coverage with only minLength/maxLength constraints. Description mentions 'for a campaign' which implies the campaign_id parameter exists, but adds no semantics about parameter format, where to obtain campaign IDs, or example values. Fails to compensate for empty schema descriptions.

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

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

Description opens with specific verb+resource: 'Get per-creative attention breakdown for a campaign.' Clearly distinguishes from sibling get_attention_metrics (general metrics) and get_creative_attribution (attribution focus) by specifying 'per-creative attention breakdown' granularity.

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 'WHEN TO USE' section lists three specific scenarios: A/B testing creative variants, identifying engagement drivers, and comparing aCPM. Provides clear contextual triggers for tool selection without needing to infer from the name.

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 comprehensively documents the return structure in the 'RETURNS' section (ranking by store visits, attention metrics, bestContext, dateRange), compensating for the lack of output schema. However, it omits operational details like whether the operation is read-only, rate limits, or authentication requirements.

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 well-structured with clear section headers (WHEN TO USE, RETURNS) and front-loaded purpose statement. Every sentence earns its place—no filler text. The multi-line format improves readability without sacrificing density of 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 analytical complexity and the absence of an output schema, the description provides exceptional completeness by detailing the exact return structure including nested objects (bestContext, dateRange) and specific metrics (avgLiftPct, dominantEmotion). The single input parameter (campaign_id) is simple enough that its omission in the description doesn't critically impair usability.

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 0% description coverage (campaign_id lacks a description field), and the description text fails to compensate by explaining the parameter's semantics, constraints, or format. While 'campaign_id' is somewhat self-explanatory, the rubric requires the description to compensate for low schema coverage, which it 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 explicitly states the tool 'Get[s] attribution performance by individual creative variant' and distinguishes its purpose from siblings like get_campaign_attribution or get_creative_attention by specifying it links 'creative execution to attribution outcomes: which creative variant drove the most store visits?' This provides a specific verb, resource, and outcome that differentiates it from related tools.

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?

Contains an explicit 'WHEN TO USE' section listing three specific scenarios: comparing A/B/C test performance, finding optimal creative x context combinations, and identifying highest visit rates. This provides clear contextual guidance for when to select this tool over alternatives like get_campaign_attribution or get_creative_attention.

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

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

No annotations provided, so description carries full burden. It compensates partially by detailing return structure (flows array with source/target/count, channels array with touchpoints/uniqueDevices) and example channel transitions. However, it lacks disclosure on safety profile (read-only status), rate limits, or error behaviors.

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?

Excellent structure with clear sections (main description, WHEN TO USE, RETURNS). No filler text; every line provides value. Front-loaded with the core action, and efficiently compensates for missing output schema by documenting return values directly.

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 zero schema descriptions and no output schema, the description provides substantial context by documenting the return data structure and usage scenarios. Only minor gap is the lack of explicit campaign_id parameter documentation; otherwise comprehensive for a single-parameter read operation.

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 has 0% description coverage for the single required parameter (campaign_id). Description mentions 'for a campaign' which provides implicit context, but fails to explicitly document the parameter's purpose, format, or constraints, leaving significant semantic gap.

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

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

Description uses specific verb 'Get' with resource 'cross-channel customer journey data (Sankey flow)' and scope 'for a campaign'. The mention of 'Sankey flow' and specific channel examples (DOOH -> mobile -> web -> store) clearly distinguishes it from siblings like get_campaign_performance or get_analytics.

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 'WHEN TO USE' section lists three specific scenarios (visualizing journeys, understanding transitions, building Sankey diagrams). Provides clear context for invocation, though lacks explicit 'when not to use' guidance or named sibling 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?

With no annotations provided, description carries the burden well. It discloses the data source (observation_stream), filtering logic (rows with both creative ID and VAS outcome), and intended effect (picture of training data availability). It also details the return structure. Minor gap: doesn't explicitly state read-only nature or performance characteristics (e.g., query cost).

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?

Front-loaded with clear summary sentence. Structure uses headers (WHEN TO USE, RETURNS, EXAMPLE) for scannability. The RETURNS section is lengthy, but justified because no output schema exists to document the nested return structure elsewhere. No redundant tautology.

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?

Comprehensive for a zero-parameter tool without output schema. Description compensates for missing outputSchema by fully documenting return values (data, metadata, suggested_next_queries). Purpose is clear among 60+ sibling tools. The example demonstrates practical usage.

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?

Input schema has zero parameters with 100% coverage (empty object). Baseline score of 4 applies. Description adds value through the EXAMPLE section showing invocation with empty object {}, confirming no parameters are expected.

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

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

Description opens with specific verb+resource: 'Get statistics about available causal training data' and lists concrete dimensions (tuples, creatives, venue diversity). It distinguishes from generic analytics siblings like get_analytics by specifying this queries observation_stream specifically for the causal prediction engine training context.

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

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

Contains explicit 'WHEN TO USE' section with four specific scenarios (checking data sufficiency, understanding diversity, monitoring health, planning collection). This provides clear positive guidance, though it lacks explicit 'when not to use' statements or named alternatives (e.g., query_observations for raw data).

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

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

No annotations are provided, so the description carries the full burden. It extensively documents the return structure (9 fields including status, location, specs, stats) which compensates for the lack of output schema. However, it omits error behavior (e.g., device not found), permission requirements, and whether this is cached or real-time.

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?

Uses clear structural headers (WHEN TO USE, RETURNS, EXAMPLE) that make the description scannable. Despite listing 9 return fields, every sentence earns its place by compensating for missing structured schemas. The example is concrete and immediately clarifies usage patterns.

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 zero schema descriptions, no output schema, and no annotations, the description is remarkably complete. It documents all return fields (substituting for output schema), provides usage scenarios, and includes a working example. Sufficient for an agent to invoke correctly without external 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 description coverage is 0%, requiring the description to compensate. The EXAMPLE section provides crucial semantic context showing 'vending-001-nyc' as a descriptive internal ID format. The RETURNS section clarifies that device_id is 'Your internal device ID', adding meaning beyond the raw schema type (string).

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 explicitly states 'Get detailed information about a specific device' — a specific verb (get) + resource (device) + scope (specific/single). The 'specific device' qualifier effectively distinguishes this from sibling list_devices (bulk retrieval) and delete_device (mutation).

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 'WHEN TO USE' section provides explicit scenarios: checking status of a single device, getting configuration details, and debugging. While it clearly implies this is for single-device lookups versus bulk operations, it does not explicitly name sibling alternatives like list_devices or differentiate from get_device_ads.

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

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

No annotations are provided, so the description carries full disclosure burden. It compensates well by including a 'RETURNS' section documenting the response structure (ads array, default_stream, schedule) since no output schema exists. However, it lacks mention of whether data is real-time vs cached, rate limits, or permission requirements.

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?

Excellent structure with clear section headers (WHEN TO USE, RETURNS, EXAMPLE) that front-load the critical information. Every sentence earns its place; the example is concise and immediately illustrates both parameter usage and expected format without verbosity.

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 single-parameter read operation without output schema, the description is complete. It compensates for missing schema documentation via the example, documents return values via the RETURNS section, and provides sufficient usage context through the WHEN TO USE guidelines.

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

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

With 0% schema description coverage for the 'fingerprint' parameter, the description partially compensates via the EXAMPLE section showing 'P_abc123' format. However, it fails to explicitly define what a fingerprint represents (device ID, hardware hash, etc.) or its semantic meaning beyond the pattern hint in the example.

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 ('Get') and resource ('current ads scheduled for a device'), clearly distinguishing it from sibling tools like get_device (which retrieves device metadata rather than ad schedules). The parenthetical '(for testing)' effectively scopes the tool's intended 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?

Contains an explicit 'WHEN TO USE' section with three specific scenarios (testing delivery, debugging ads shown, verifying targeting). This provides clear contextual triggers for agent invocation that go beyond the basic function description.

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 full burden and discloses statistical methodology (10K Monte Carlo samples, Yates correction), return structure complexity, and empty-array behavior. Lacks operational details like rate limits, caching, or error conditions beyond the no-experiments case.

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?

Well-structured with clear sections (implied headers), logical progression from purpose to methodology to usage to returns. No redundant text; every sentence adds specific value about statistical approach or return data structure. Appropriate length for the tool's analytical complexity.

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 lack of output schema and no annotations, description comprehensively documents return structure (experimentId, DMAs, statistical fields) and methodology. Would benefit from mentioning error cases (invalid campaign_id, permission errors) or computational cost of Monte Carlo sampling.

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 has 0% description coverage for the single campaign_id parameter. Description implies the parameter through context ('for a campaign') but does not explicitly name campaign_id or describe its constraints (maxLength 128, minLength 1). Just meets minimum viable compensation for schema deficiency.

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

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

Description opens with specific verb 'Get' and precise resource 'incrementality/lift test results', immediately distinguishing it from sibling analytics tools like get_analytics or get_campaign_performance. The statistical methodology detail (Bayesian Beta-Binomial, frequentist chi-square) further clarifies the specific measurement approach.

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 'WHEN TO USE' section lists three specific scenarios (proving causal DOOH effectiveness, getting significance measures, seeing treatment vs control rates). This clearly positions the tool against alternatives by emphasizing 'causal' measurement versus standard correlation-based analytics available in sibling tools.

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 fully compensates by disclosing data refresh rate (10 seconds), source (edge AI sensors, Gemini Vision), data freshness metric (signals_age_ms), and specific AI-derived attributes (mood, purchase intent, income_level).

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?

Excellent structure with clear section headers (WHEN TO USE, RETURNS, EXAMPLE). Front-loaded purpose statement. RETURNS section efficiently documents 11 fields without prose bloat. Every sentence earns its place given lack of output schema.

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, yet description comprehensively documents all return fields (face_count, attention_score, etc.). No annotations exist, yet behavioral traits are fully disclosed. Single parameter is demonstrated in example. Complete for the tool's complexity.

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 has 0% description coverage for screen_id parameter. Description includes helpful EXAMPLE showing parameter usage with realistic ID format, but does not explicitly document what screen_id represents or how to obtain it. Baseline 3 for partial compensation via example.

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?

Opening sentence 'Get real-time audience data for a specific screen' provides specific verb (Get), resource (real-time audience data), and scope (specific screen). The real-time emphasis distinguishes it from sibling get_audience_forecast.

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 'WHEN TO USE' section lists three specific scenarios (checking before buying, monitoring live campaigns, getting detailed signals). Clear context but lacks explicit mention of alternatives like get_audience_forecast for predictive vs real-time data.

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

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

No annotations provided, so description carries full burden. It compensates by detailing the return structure (delivery metrics and breakdowns) since no output schema exists. However, it lacks operational details like caching behavior, rate limits, or permission requirements that would be essential for a data retrieval tool.

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

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

Well-structured with clear section headers (WHEN TO USE, RETURNS, EXAMPLE). Information is front-loaded with the action statement. The RETURNS section efficiently documents the data structure without verbosity, though the bullet format is slightly informal.

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 zero schema coverage, no annotations, and no output schema, the description adequately compensates by documenting return values and use cases. However, the incomplete parameter documentation leaves a significant gap for a 3-parameter tool where users need to understand the difference between 'dimensions' and 'breakdown_by'.

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

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

Schema coverage is 0%, requiring the description to fully document parameters. While it mentions available breakdown types (screen, venue, hour, audience_segment), it fails to explain the critical distinction between the 'dimensions' and 'breakdown_by' parameters (which have overlapping enums) or document the required media_buy_id format beyond the example.

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 'Get[s] delivery/performance report for a media buy' with the '[AdCP Media Buy]' prefix providing domain context. It distinguishes from siblings like get_campaign_performance by specifying the 'media buy' resource rather than general campaign analytics.

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?

Contains an explicit 'WHEN TO USE' section listing three specific scenarios (monitoring delivery, optimization breakdowns, reporting). However, it lacks 'when not to use' guidance or explicit sibling alternatives (e.g., when to use get_campaign_performance instead).

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

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

No annotations provided, so description carries full burden. Discloses supported attribution models, detailed return structure (including value ranges like 0-1 summing to 1 and cents denomination), and critical edge case ('Returns null if no multi-touch chains exist'). Lacks explicit safety/idempotency statements.

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?

Excellent structure with clear sections: one-line purpose, supported models list, WHEN TO USE bullets, and RETURNS documentation. Every sentence adds value; no redundancy. Front-loaded with the core action statement.

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 analytical complexity and lack of structured output schema, the RETURNS section comprehensively documents output fields, types, and semantics (cents, confidence scores). However, incomplete due to missing parameter documentation for the single required input.

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

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

Schema coverage is 0% (campaign_id lacks description field). Description mentions 'for a campaign' but never explicitly documents the campaign_id parameter, its format, constraints (minLength/maxLength from schema), or how to obtain a valid ID. Description fails to compensate for uncovered 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?

Opens with specific verb 'Get' and clear resource 'multi-touch attribution model results'. Distinguishes from siblings like get_campaign_attribution by specifying supported models (time_decay, position_based, attention_weighted) and emphasizing cross-channel analysis (DOOH, mobile, web, store).

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?

Contains explicit 'WHEN TO USE' section with three concrete scenarios: understanding DOOH in the funnel, credit allocation across channels, and quantifying DOOH contribution. This provides clear context for selection without requiring the agent to guess based on the tool name alone.

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

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

No annotations provided, so description carries full disclosure burden. Compensates partially by documenting return fields (total_screens, revenue_estimate_usd, etc.) but omits safety traits (read-only vs destructive), rate limits, or aggregation methodology. 'Get' implies safe read operation, but this is not explicit.

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?

Excellent structure with clear section headers (WHEN TO USE, RETURNS, EXAMPLE). Front-loaded purpose statement. Zero redundant text; every sentence serves selection or invocation guidance. Appropriate length for single-parameter tool.

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 description documents return structure comprehensively (7 fields listed). Example demonstrates valid invocation pattern. Minor gap: parameter semantics not explained textually. Otherwise complete for a simple aggregation endpoint.

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 has 0% description coverage (time_range property lacks description field). Description shows parameter usage in example ('time_range: 7d') but fails to explain parameter semantics, valid values, or defaults in prose. Relies entirely on schema enum constraints without textual explanation.

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?

Opens with specific verb 'Get' + resource 'network-wide statistics' + scope 'across all partner screens'. Effectively distinguishes from sibling analytics tools (e.g., get_campaign_performance, get_analytics) by emphasizing 'network-wide' aggregation vs. specific entity queries.

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 'WHEN TO USE' section lists three concrete scenarios (high-level overview, checking online screens, reviewing impressions/revenue). Provides clear context for selection. Lacks explicit 'when not to use' or named sibling alternatives, preventing 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, so description carries full burden. It discloses the authentication context ('authenticated partner account') and comprehensively documents the return structure (partner_id, status, earnings, etc.), compensating for the lack of output 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?

Excellent structure with clear section headers (WHEN TO USE, RETURNS, EXAMPLE). No wasted words; every sentence provides actionable guidance or data structure 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 no output schema exists, the description comprehensively documents all return fields. For a zero-parameter read operation, the description covers purpose, usage contexts, return values, and invocation example—sufficient for correct agent operation.

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?

Zero parameters present, establishing baseline of 4. The example 'get_partner_info({})' correctly signals the empty parameter requirement, reinforcing the schema structure.

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 specific verb ('Get') and resource ('information about the authenticated partner account'), distinguishing it from siblings like register_partner (creation) and get_device/get_campaign (different 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?

Provides explicit WHEN TO USE section with three concrete scenarios (checking status, verifying API key, getting details). Lacks explicit 'when not to use' or named alternatives (e.g., contrast with register_partner), but the scope 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 provided, the description carries the full burden and succeeds in disclosing auth requirements (none needed) and return structure (graduated pricing, free tiers, discounts). Could improve by mentioning caching behavior or rate limits.

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 well-structured sentences with zero waste: action statement, return value specification, and auth/usage guidance. Front-loaded with the essential verb and resource.

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?

Appropriate for a simple single-parameter tool without output schema. Describes return content (pricing tiers) adequately. Minor gap in not clarifying the optional parameter's default behavior when omitted.

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 has 0% description coverage for the 'product' parameter. The description mentions 'all Trillboards products' but fails to clarify that the parameter is optional, what specific values are accepted (enum meanings), or whether omitting it returns all products versus a default.

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?

Clear verb ('Get') and resource ('machine-readable pricing') with scope ('all Trillboards products'). Distinguishes from billing/purchase siblings by emphasizing 'evaluate costs before integrating,' though it could explicitly differentiate from get_products.

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 context ('evaluate costs before integrating') and prerequisites ('No authentication required'). Lacks explicit when-not-to-use distinctions versus related tools like get_products or setup_billing.

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. It successfully discloses key behavioral traits: real-time pricing dynamics based on demand/audience quality, and the organization structure (venue type, location, audience profile). It could improve by explicitly stating this is a read-only/safe operation, but the 'Get' verb and output documentation provide implicit clarity.

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?

Excellent structure with clearly delineated sections (description, WHEN TO USE, RETURNS, EXAMPLE). Every sentence earns its place; no redundancy. The information density is high with no filler text.

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 high complexity (6 parameters, nested objects, 0% schema coverage) and lack of output schema, the description partially compensates with the RETURNS section explaining output structure and the EXAMPLE showing input usage. However, significant gaps remain regarding input parameter semantics, particularly for the buying_mode enum and filters object structure.

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

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

With 0% schema description coverage across 6 complex parameters (including nested objects for filters and audience_profile, and an enum for buying_mode), the description fails to compensate adequately. While the EXAMPLE demonstrates market and venue_types usage, it leaves brief, buying_mode enum values, audience_profile fields, and the complex filters object completely unexplained.

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 ('Get') and resource ('DOOH advertising products and packages'), and the [AdCP Media Buy] prefix clearly scopes the domain. It distinguishes from siblings like create_campaign by emphasizing browsing/comparing inventory rather than creating or managing campaigns.

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 explicit 'WHEN TO USE' section provides three concrete scenarios: browsing before campaign creation, comparing pricing across venues, and market exploration. This clearly positions the tool relative to siblings like create_campaign (use this first) and get_pricing (use this for cross-venue comparison).

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. It effectively discloses algorithmic behavior (time-decay weighting, purchase-to-exposure matching) and edge cases ('Returns null if no transaction data exists'). It does not, however, disclose operational behaviors like rate limits, required permissions, or data freshness/latency.

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?

Well-structured with clear visual hierarchy: purpose statement, 'WHEN TO USE' section, and 'RETURNS' section. The RETURNS section extensively lists output fields, which is justified given the absence of an output schema. However, the length is substantial and could potentially be trimmed by omitting obvious field explanations (e.g., 'totalRevenueCents') while keeping the structural outline.

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 lack of output schema, the description compensates admirably with detailed return value documentation covering transactions, attribution, salesLift, and timing objects. Usage context is also well-covered. The only significant omission is the input parameter description (campaign_id), preventing 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 0% (campaign_id has no description), and the description fails to compensate by explaining the parameter. It never mentions 'campaign_id', what format it expects, or how to obtain a valid campaign ID. While the parameter name is somewhat self-evident, the complete lack of documentation for the sole required parameter is a significant gap.

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

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

Description opens with specific verb ('Get') and resource ('Return on Ad Spend with transaction attribution data'). The second paragraph distinguishes this from generic analytics siblings by specifying it 'matches purchase events to DOOH exposures with time-decay weighting' and computes 'incremental ROAS', clearly defining the tool's unique 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?

Contains explicit 'WHEN TO USE' section with three concrete scenarios (measuring DOOH-attributable revenue, getting ROAS/iROAS figures, seeing sales lift). This provides clear positive guidance. However, it lacks explicit 'when not to use' guidance or named sibling alternatives (e.g., get_campaign_attribution vs. get_incrementality) that would help the agent avoid calling the wrong attribution tool.

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

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

No annotations provided, so description carries full burden. Discloses deterministic capture methodology (cameras, microphones, ML Kit, Gemini Vision), edge AI processing location, and detailed return structure (signals array fields, metadata counts). Lacks privacy/safety disclosure for biometric capture.

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?

Excellent structure with clear headers ([AdCP Signals], WHEN TO USE, RETURNS, EXAMPLE). Information is front-loaded, no redundancy, and every sentence serves a distinct purpose (protocol compliance, methodology, usage, returns).

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; description adequately documents return structure (signals array with demographics/venue/behavior/geo, metadata fields). Explains AdCP compliance and technology stack. Complex domain (AdTech/DOOH) well-contextualized, though data freshness/latency not mentioned.

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 has 0% description coverage. Description compensates partially with concrete EXAMPLE showing signal_spec structure and valid values (demographics, behavior, venue_type: retail), but does not explicitly document all filter options (city, state, income, lifestyle) or enumerate all signal_types (geo, venue) outside the example.

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?

Opens with specific verb-resource combination ('Get real-time audience signals from DOOH screens') and distinguishes from siblings by emphasizing 'deterministic' capture vs probabilistic data, and explicitly contrasting with inventory buying tools via 'before buying inventory' context.

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

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

Contains explicit 'WHEN TO USE' section with three distinct bullet scenarios (discovering signals, evaluating composition, building segments). Clear differentiation from probabilistic data sources and purchasing workflows.

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

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

No annotations provided, so description carries full burden. It comprehensively explains the data source (AttentionGraphBuilder on CTV edge devices), the graph model (directed graph of viewer attention), detection mechanism (triggering nearby viewers), and detailed return payload structure (SAF, cascadeDepth, viralAttentionScore). Could improve by mentioning performance characteristics or error conditions.

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?

Excellent structure with clear visual hierarchy: single-sentence purpose upfront, technical context paragraph, explicit WHEN TO USE bullet list, detailed RETURNS schema, and concrete EXAMPLES. Every section earns its place; information is front-loaded and appropriately scoped for the tool's complexity.

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 high complexity (attention contagion modeling) and lack of output schema, the description provides thorough domain context and comprehensive return value documentation (down to individual payload fields). However, it should explicitly differentiate from 'get_social_contagion_summary' and document input parameters to fully compensate for the sparse input schema.

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 has 0% description coverage, requiring description to compensate. While examples demonstrate min_saf (threshold values 2.0/3.0) and venue_type ('bar'), and the RETURNS section mentions min_saf_filter, the description lacks explicit documentation for all 5 parameters (limit, screen_id, time_range structure) and their relationships. Baseline 3 appropriate given examples partially compensate but don't fully document the interface.

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

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

Description explicitly states the tool queries 'social attention contagion metrics from the observation stream' and returns 'windows where attention propagated between viewers (social amplification factor > 1)'. It uses specific verbs (Query, Returns) and domain-specific resources (observation stream, social amplification factor) that distinguish it from generic analytics siblings.

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' section with four specific scenarios (finding social proof moments, identifying high-contagion venues, understanding cascade patterns, correlating with ad effectiveness). However, it fails to distinguish from the similarly named sibling 'get_social_contagion_summary', which could cause selection confusion.

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?

Strong disclosure of internal mechanics: states it 'Queries observation_stream', specific computations performed (average SAF, cascade depth, viral score), and sorting behavior ('sorted by avg SAF descending'). With no annotations provided, this carries the full burden. Missing operational details (caching, rate limits, data latency).

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?

Well-structured with clear sections (purpose, WHEN TO USE, RETURNS, EXAMPLE). Front-loaded with the core action. No wasted words; every sentence provides net new information not duplicated in schema. Appropriate length given lack of output schema and 0% input schema coverage.

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 high complexity (multi-dimensional aggregation with computed metrics), zero schema descriptions, no output schema, and no annotations, the description compensates effectively by detailing return structure (data array fields, metadata object) and providing concrete usage examples. Minor gap: time_range string format not explicitly defined.

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

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

With 0% schema coverage, description must compensate. It successfully maps group_by enum values to semantic concepts ('dimension value', 'venue type', 'daypart'). The EXAMPLES section provides implicit documentation for time_range format (ISO date strings in object structure), though explicit parameter documentation would be stronger.

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?

Excellent specificity with 'Aggregate social attention metrics' and clear resource scope (screens/time periods). Distinguishes from sibling get_social_attention by emphasizing aggregation (computes averages) versus raw observation retrieval, and explicitly names the three grouping dimensions (venue, daypart, screen).

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 'WHEN TO USE' section lists four specific scenarios (understanding venues, comparing dayparts, identifying screens, planning campaigns). However, lacks explicit 'when not to use' guidance or reference to sibling tools like get_social_attention for non-aggregated/raw data queries.

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 successfully adds context about what data is returned (per-product breakdown, free vs paid tier details), but fails to disclose operational traits like whether this is a cached vs real-time query, rate limits, or that it is a safe read-only operation.

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 consists of two efficient sentences with zero waste. The first sentence front-loads the core action and scope ('Get your current billing period usage summary'), while the second sentence enumerates the specific cost components included, earning its place by detailing the output structure.

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 absence of an output schema, the description adequately compensates by enumerating the specific data points returned (per-product breakdown, free tier consumption, paid usage, total cost). It loses a point for not describing the return format or structure (object vs array), but is otherwise complete for a zero-parameter read operation.

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 contains zero parameters (empty properties object with additionalProperties: false). As per the rubric, zero parameters warrants a baseline score of 4, as there are no parameter semantics to clarify beyond the schema definition.

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

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

The description uses a specific verb ('Get') and resource ('billing period usage summary') and clearly distinguishes the scope with specific details ('per-product breakdown', 'free tier consumption', 'paid usage', 'total cost'). This effectively differentiates it from siblings like get_billing_status or get_pricing by emphasizing usage tracking rather than account status or rate cards.

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 data is returned but provides no explicit guidance on when to select this tool versus related billing siblings (get_billing_status, get_pricing, purchase_credits). It does not specify prerequisites, decision criteria, or exclusions that would help an agent choose the correct billing tool.

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

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

No annotations provided, so description carries full burden. Extensive RETURNS section discloses output structure (delivery records with 7 fields, total count, success rate), compensating for missing output schema. Does not explicitly state read-only/idempotent nature or rate limits, but 'Get' implies safe operation.

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?

Well-structured with clear section headers (WHEN TO USE, RETURNS, EXAMPLE). Front-loaded with one-line summary. Length is appropriate given lack of output schema - RETURNS section earns its space by documenting return values. Slightly verbose but justified by context.

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 3 simple parameters, no annotations, and no output schema, description is comprehensive. RETURNS section fully documents return structure that would normally be in output schema. Sufficient for agent to understand tool capabilities and results.

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

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

Schema coverage is 0% - no parameter descriptions in schema. Description shows parameters in EXAMPLE (webhook_id, status, limit) with sample values, but never explains what each parameter does, valid values, or constraints. Fails to compensate for zero schema coverage with explicit parameter documentation.

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?

Opens with specific verb 'Get' + resource 'delivery history for a webhook'. Clearly distinguishes from sibling tools like create_webhook, list_webhooks, or test_webhook by focusing on historical delivery records rather than webhook configuration or testing.

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 'WHEN TO USE' section lists three specific scenarios (debugging failed deliveries, auditing activity, checking success rates). Includes concrete EXAMPLE showing parameter usage with realistic values, providing clear invocation pattern.

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

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

No annotations provided, so description carries full burden. The 'RETURNS' section effectively discloses response structure (devices array, counts) compensating for missing output schema. However, it omits mention of read-only safety, pagination behavior (despite limit/offset params), or that 'all' requires iteration due to the 100-item limit.

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?

Excellent structure with clear section headers (WHEN TO USE, RETURNS, EXAMPLE). Front-loaded with precise one-line summary. No redundant text; every section adds distinct value beyond the schema and annotations.

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 4-parameter list operation with no output schema, the description is quite complete. It provides return value documentation and usage examples that compensate for missing structured metadata. Minor gap: does not explicitly document the pagination model implied by limit/offset 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?

Schema coverage is 0%, requiring description compensation. The 'WHEN TO USE' and 'EXAMPLE' sections explain 'status' and 'limit' parameters, but 'offset' (pagination cursor) and 'device_type' filter remain undocumented. Partial compensation achieved but gaps remain for half the parameter set.

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?

Clear specific verb ('List') + resource ('devices') + scope ('registered to the partner account'). Explicitly distinguishes from sibling 'get_device' (singular retrieval) by emphasizing 'all devices' and listing behavior.

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 'WHEN TO USE' section provides three concrete scenarios: getting overviews, finding devices by status, and auditing. The status filtering example and example invocation further clarify appropriate usage patterns.

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 this well by describing what the tool returns (operations array with specific fields, total count, surfaces), providing an example of usage, and explaining filtering capabilities. However, it doesn't mention potential limitations like rate limits, authentication requirements, or pagination behavior, which keeps it from a perfect score.

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 well-structured with clear sections (WHEN TO USE, RETURNS, EXAMPLE) and every sentence adds value. It's appropriately sized for a tool that needs to explain its purpose, usage, and output format. The information is front-loaded with the core purpose stated first, followed by practical guidance.

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 read-only discovery tool with 3 parameters and no output schema, the description provides excellent context about what the tool does, when to use it, and what it returns. The example adds practical guidance. The only minor gap is the lack of explicit mention that this is a read-only operation (though implied by 'list' and 'agent_safe' filtering), which prevents 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?

With 0% schema description coverage for the 3 parameters, the description fully compensates by explaining what each parameter does: 'surface' is described as filtering to specific API surfaces, 'agent_safe' filters to side-effect-free endpoints, and 'idempotent' is listed as a filter parameter. The example shows how to use the agent_safe parameter, providing practical semantic context beyond the bare 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 clearly states the tool's purpose with specific verb ('List') and resource ('every registered Trillboards API operation'). It distinguishes itself from sibling tools like 'describe_endpoint' by focusing on listing all operations rather than describing a single one. The description explicitly mentions what the tool returns, making its 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 provides explicit guidance on when to use this tool ('First call in an agent session to learn what the API offers') and how to filter results (by agent_safe, surface). It includes a concrete example showing an agent query and the corresponding tool invocation, making usage scenarios clear. The WHEN TO USE section is structured and comprehensive.

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. It discloses that the tool returns a list of error codes with specific fields (code, type, http_status, etc.) and mentions it's equivalent to a GET endpoint but executed in-process. However, it doesn't cover potential limitations like rate limits, authentication needs, or error conditions.

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 well-structured with clear sections (description, when to use, returns, note, example). Every sentence adds value—no redundancy or fluff. It's front-loaded with the core purpose.

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 (0 parameters, no annotations, no output schema), the description is nearly complete. It explains what the tool does, when to use it, and what it returns. A minor gap is the lack of explicit mention of authentication or rate limits, but for a read-only list tool, this is acceptable.

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 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and output.

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 specific action ('List every error code') and resource ('Trillboards API error catalog'), distinguishing it from sibling tools which focus on analytics, campaigns, devices, etc. It provides a complete picture of what the tool does.

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 includes an explicit 'WHEN TO USE' section with three specific scenarios (understanding API errors, building error handlers, looking up error details). It clearly defines the context for using this tool versus alternatives, though no sibling tools directly overlap.

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

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

No annotations are provided, so the description carries the full burden. It compensates effectively by detailing the complete return structure (webhooks array with webhook_id, url, events, enabled, timestamps) since no output schema exists. The verb 'List' implies read-only behavior, though it could explicitly state this is a safe, non-destructive operation.

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?

Excellent structure with clear headers (WHEN TO USE, RETURNS, EXAMPLE). Information is front-loaded with the purpose statement. Every section earns its place—the RETURNS section is particularly valuable given the absence of an output schema. No wasted words or redundant information.

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