Sigil

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

With no annotations, the description fully covers failure semantics (independent lens failure, 200 vs 503), output structure, and the optional AIT witnessing side effect. However, it does not explicitly state if the tool is read-only or has side effects beyond witnessing, which is a minor gap.

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

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

The description is well-structured with clear sections (what it is, when to use, inputs, returns, failure semantics). It is concise yet comprehensive, with every sentence adding value and no fluff.

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

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

Given the complexity of the tool (fusing two lenses, optional AIT chaining, partial failures), the description covers all necessary aspects: input types, failure modes, return structure, and the signed token. No output schema exists, so the detailed return description is essential and provided.

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 description adds meaning beyond the schema: it explains the auto-detection of 'node', the witnessing behavior of 'ait', and provides defaults/keyword hints for 'weights' and 'thresholds'. Though schema coverage is 50%, the description compensates well, but could include more detail for object 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 clearly states it fuses two lenses into one verdict on a node, and specifies the exact use case for transaction decisions. It distinguishes itself from sibling tools which are single-lens sigil tools, establishing its unique value.

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

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

The description explicitly lists when to use (e.g., when a one-lens answer is insufficient) and implies when not to (if one lens is enough). It also suggests an alternative approach (running Scry and Sigil separately), providing clear decision 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?

The description explains the validation and signing process but lacks details on failure behavior, error responses, or side effects. Without annotations, it carries the full burden but misses some transparency.

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

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

The description is well-structured with a clear first sentence, a bullet-like list of inputs, and a return statement. No unnecessary words, every sentence adds value.

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?

All inputs are explained, the return value is mentioned, and the usage order is given. However, the description does not cover error handling, validation failure outcomes, or the enforcement of the 365-day expiry limit.

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% property descriptions, but the description compensates by listing all required parameters with explanations, examples, and constraints structure. This adds significant meaning beyond the schema.

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

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

The description clearly states the tool registers an ATAP Agent Identity Token for a media-buying agent, validates against a specific profile, and returns the signed token. It distinguishes itself from sibling verification tools by emphasizing its role as a prerequisite step.

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

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

The description explicitly instructs to use this tool once per campaign before witnessing events, providing clear usage context. It does not list alternatives, but the sibling tools are clearly distinct verification functions, making the usage guidance sufficient.

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 that Sigil validates payloads (rejecting PII), classifies evidence tiers (anchored/asserted), derives constraint violations, and signs events. This gives a clear behavioral outline for an agent, though it lacks details on authentication, rate limits, or reversibility.

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 a one-sentence summary, a bullet point for usage, and a clearly labeled inputs section. It is concise without being terse, though some redundancies could be trimmed (e.g., repeating enum values).

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

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

Given the tool's complexity (validation, classification, derivation, signing) and lack of output schema, the description covers the return values (signed witness events, tier, constraint violations) and distinguishes from sibling tool verify_supply_path. It provides enough context for an agent to decide to invoke the tool and understand the outcome.

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%, but the description adds significant meaning: it lists the three inputs (ait, event_type, payload), explicitly enumerates the event_type enum values, and specifies that payload follows the 'sigil:media_buyer:v1' profile. The description compensates well for the lack of schema docs.

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: 'Witness one agent-reported bid or budget event into an AIT's hash-chained attestation log.' It provides a specific verb (witness) and resource (events into attestation log), and distinguishes from sibling tools by noting that supply:verified events come from verify_supply_path, not this 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?

Explicit usage guidance is given: 'Use this tool when: An ATAP-enrolled media-buyer agent submits a bid, win, loss, or budget decrement and you want it on the attestation record.' It also clarifies what it does not handle. However, it does not provide alternative tools or explicit 'when not to use' beyond the one sibling mention.

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 must disclose behavior. It mentions the receipt grades events and is verifiable offline, but does not clarify if the tool is read-only or has side effects, nor does it discuss authentication or other behavioral traits.

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

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

The description is concise with a clear structure: purpose, use case, inputs, output. Every sentence adds value without redundancy.

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

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

Given no output schema, the description covers return format (JSON with receipt_id and zip_base64) and post-processing steps. It is adequate for the complexity, though it omits error handling or side effects.

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%, but the description explains both parameters: 'ait' as the AIT id and 'format' with its default and options, adding meaning beyond the schema.

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

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

The description clearly states the tool generates an ATAP v0.1 compliance Receipt for an AIT, distinguishing it from sibling tools focused on verification or registration.

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

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

Explicitly says 'Use this tool when: A reporting period closes and you need a compliance export', providing clear context. Does not mention when not to use or alternatives, but the directive is sufficient.

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. Mentions pre-computed scores, inline error handling for invalid IDs, but lacks auth needs, rate limits, or mutation disclosure (though likely read-only). Adequate but not exhaustive.

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 brief purpose, usage context, and parameter descriptions. Concise but not overly terse. Could be slightly more structured with bullet points.

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, so description covers return fields (count, scored_count, results array with inline error handling). Lacks details on result sub-fields, but sufficient for a batch 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 coverage is 0% (no descriptions in schema). Description explains entity_ids format as '{type}:{domain}' and weights as custom component options, adding significant value beyond bare schema types.

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?

Clearly states it computes trust scores for up to 200 entities in one call for campaign setup. Distinguishes from sibling sigil_score_entity by being batch-oriented.

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

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

Explicitly says when to use: 'when you have a list of publishers/SSPs to grade at once.' Does not explicitly state when not to use, but context is clear.

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

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

With no annotations, the description carries full burden. It discloses determinism (no ML black box), what factors are used (ads.txt health, supply-chain directness, reach, stability), and that scores are recomputed daily. It does not mention permissions or rate limits, but for a read-only tool this is acceptable.

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

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

The description is concise and well-structured with bullet points for inputs and returns. Every sentence adds value, and it is appropriately 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?

No output schema is provided, but the description lists all return fields: trust_score (0-1), score_components, trend (14-day), and warnings. For a single-parameter tool, this is complete and sufficient.

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

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

The input schema has 0% description coverage, so the description fully compensates. It explains the required entity_id format as '{type}:{domain}' with examples, adding meaning beyond the schema.

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

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

The description clearly states the tool retrieves a pre-computed trust score for a supply-chain entity (publisher or SSP). The verb 'get' and resource 'trust score' are specific, and the mention of 'one' entity distinguishes it from siblings like sigil_score_batch.

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

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

The description explicitly says 'Use this tool when: you want a fast standing trust signal for an entity without running checks.' This gives clear context, though it does not explicitly exclude alternatives or mention when not to use it.

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

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

With no annotations, the description carries full burden. It discloses caching behavior ('Fast cached lookup against Sigil's daily crawl of the top ~10k publisher domains') and describes the optional `resolve_chain` behavior. However, it does not mention error conditions, rate limits, or what happens if the domain is not in the crawl.

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 sections and bullet-like lines, but it is slightly verbose. Every sentence adds value, though some phrasing could be tightened without loss.

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 4 parameters, no output schema, and no annotations, the description covers inputs, behavior, and output fields. It lacks edge-case details like null handling or error responses, but overall provides sufficient context 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 description coverage is 0%, so description fully compensates. It explains each required parameter (publisher_domain, exchange_domain, seller_id) and the optional `resolve_chain` boolean, adding meaning beyond the schema's type/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 checks whether an exchange/SSP is authorized to sell a publisher's inventory via ads.txt, using a specific verb 'Check' and distinct resource context. It also differentiates from sibling tools by noting it is 'not a full supply-path score'.

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

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

The description explicitly provides usage conditions under 'Use this tool when:', specifying it is for a single, narrow authorization check and for validating a specific triple. It implicitly excludes broader supply-path analysis via 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, so description carries the burden. It discloses that the tool returns verified, store listing, and developer_match, but does not mention error handling, rate limits, or network calls. Adequate but not thorough.

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?

Description is concise and well-structured: start verb, then bullet-like list of inputs and returns. Every sentence provides value, no fluff.

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

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

Given no output schema, the description includes return fields. Covers purpose, inputs, outputs, and use case. Could mention error conditions or limitations, but is largely 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 coverage is 0%, but the description fully explains each parameter: bundle_id (required), platform (required with values 'ios | android | ctv_* | web'), claimed_developer (optional developer name to match). Adds meaning beyond schema names.

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 it verifies app bundle existence in its store and optionally checks developer match, detecting spoofing. This is a specific verb+resource and distinguishes from sibling sigil_verify 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?

Explicitly says 'Use this tool when: a bid request names an app bundle and you must confirm the app is real.' While no 'when not to use' or alternatives are given, the guidance is clear and contextual.

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 must disclose behavior. It does so by stating 'Stateless — the IP is never logged or stored,' which is a key behavioral trait. It also explains the output structure. It could be more explicit about being read-only, but the information provided is sufficient.

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

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

The description is concise and well-structured. It front-loads the primary purpose, then adds critical details (stateless, privacy note), usage guidelines, input format, and output. Every sentence earns its place without redundancy.

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

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

Given the simple tool (one parameter, no output schema), the description is complete. It explains what the tool does, when to use it, what it returns, and a privacy guarantee. No gaps are apparent for an AI agent to select and invoke it correctly.

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

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

The input schema has only one parameter (ip) with an example. The description adds meaning by specifying it is required and expects an IPv4 address, which aligns with the schema. It also provides context about bid-request traffic, enhancing understanding beyond the schema. With 0% schema description coverage, the description compensates well.

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: classify an IPv4 address as datacenter, residential, mobile, or unknown. The verb 'classify' is specific and the resource (IPv4 address) is explicit. It distinguishes from sibling tools like sigil_verify_ads_txt by focusing on IP type classification.

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 guidance: 'Use this tool when: - You need to know whether bid-request traffic originates from a datacenter.' This specifies a clear use case. However, it does not mention when not to use it or suggest alternatives, which would make it 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 details per-node checks against sellers.json and ads.txt, and returns per-node and aggregate verdict with signed token. Does not mention side effects or auth, but still informative.

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?

Concise, well-structured with bullet points. Every sentence adds value without redundancy.

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

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

Describes inputs and outputs (per-node results, verdict, recommendations, sigil_token) despite lacking output schema. Covers essential aspects 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?

Description adds significant meaning beyond schema: explains schain structure (ver, complete, nodes with asi, sid, hp) and optional inputs site_domain/app_bundle used for ads.txt check. Schema coverage is low (33%), so description compensates well.

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?

Clearly states the tool verifies a full OpenRTB SupplyChain object, with per-node checks. This distinguishes it from siblings like sigil_verify_ads_txt.

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

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

Explicitly says 'Use this tool when: - A bid request carries an OpenRTB `schain` and you want it verified verbatim.' Provides clear context but does not explicitly mention when not to use or list 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 are provided, so the description carries the full burden. It discloses return values (trust_score, verdict, per-check results, recommendations, sigil_token), explains the optional `ait` parameter's effect (records as witnessed attestation), and includes a privacy statement for IP ('never stored'). It does not mention authentication, rate limits, or potential side effects, but these are reasonable omissions for a read-only verification 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?

The description is well-structured with a clear opening statement, a 'Use this tool when:' section, and bullet-pointed inputs and returns. It is front-loaded with the core purpose and every sentence adds value without redundancy. The format aids quick comprehension.

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

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

Given the tool's moderate complexity (2 parameters, nested objects, no output schema), the description adequately covers inputs, behavior, and return values. It explains the composite nature of the verification and the signed token's purpose. However, it could mention potential error conditions or required preconditions (e.g., network access) for 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?

Schema description coverage is 50%, and the description adds value by explaining the `ait` parameter's binding behavior and the IP address's non-storage policy. It also outlines the structure of `supply_path` with its optional fields. While the schema already documents these, the description provides contextual meaning beyond the basic field descriptions.

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

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

The description clearly states the tool's purpose: 'Verify the trustworthiness of one programmatic ad supply path and get back a composite trust verdict plus a signed proof token.' It lists specific components (ads.txt, IP classification, fraud lookup, app-bundle checks) and distinguishes it from sibling tools that perform individual checks, as stated: 'instead of running ads.txt / IP / bundle checks separately.'

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 a dedicated 'Use this tool when:' section with two clear scenarios: when an ad-buying agent is about to bid and when a single call is preferred over separate checks. It implicitly distinguishes from siblings but does not explicitly state when not to use this tool or provide alternative tool names.

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