Opedd — Licensed Content for AI

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

With no annotations provided, the description carries the behavioral burden and largely meets it: it discloses the artifact type (signed HS256 JWT), what it embeds (license context, usage-count, Merkle root, canonical claims), the verification model (offline against canonical signing key), and the non-discharge of CDSM obligations. It also discloses the auth requirement and window cap. It doesn't explicitly state whether the operation is read-only or has side effects, and it doesn't describe error/failure modes, but the described behavior covers the main execution-relevant traits. A 4 is justified; a 5 would require side-effect/reversibility/error detail.

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 rich but every sentence earns its place: the artifact type, embedded content, compliance boundary, sibling distinction, parameter scoping, window cap, and auth are all decision-relevant. It is somewhat dense with parentheticals and phase/invariant references that add precision but could be trimmed; however, the structure front-loads the core behavior and then adds constraints. Not a 5 because the parenthetical citations (Phase 12 Wave 1 W1.4, INVARIANTS.md W1.6) add noise for an agent without repository 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?

The tool has four parameters, no output schema, and no annotations, so the description must cover behavior, parameters, and result expectations. It explains what the returned JWT contains and how it is verified, which substitutes for an output schema. It covers auth, window constraints, license scope, and the boundary with rsl_get. It does not explicitly describe error cases (e.g., invalid license, unauthorized buyer, window too long), and it does not state whether the call is read-only, but for a JWT-issuance attestation tool the described context is largely complete. A 5 would require explicit error conditions or side-effect disclosure.

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

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

Schema coverage is 100%, so the schema already documents all four parameters with descriptions. The description adds meaning by clarifying the optional content_id's scoping effect (default license-wide) and the 365-day window cap, which reinforces and enhances the schema's window_start/window_end descriptions. It also adds context on ownership ('Buyer must own it') that the schema mentions. This goes beyond the baseline of 3 but not to a 5 because the description does not restate all parameter formats or provide 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 states a specific verb ('Issue a signed JWT attesting...') and identifies the exact resource and endpoint (GET /eu-ai-act/article-53-attestation). It clearly differentiates this tool from the sibling rsl_get by naming what it does NOT do and which sibling handles the CDSM Article 4(3) obligation. This is unambiguous and distinguishes it from all 16 sibling 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?

The description explicitly says when to use this tool: for EU AI Act Article 53 compliance evidence for legal/procurement. It names the alternative (rsl_get with jsonld=true) for the CDSM obligation, and explicitly warns never to conflate. It also provides auth requirements (OPEDD_BUYER_TOKEN or OPEDD_BUYER_JWT), scope behavior via optional content_id, and the 365-day window cap. This is fully actionable guidance with exclusions.

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

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

With no annotations, the description carries the full burden. It discloses read-only nature via 'Browse' and 'Returns', notes the registry is public, and mentions filtering capabilities. However, it does not explain result ordering beyond 'recently issued', pagination details, or any rate limits, leaving some behavioral traits undisclosed.

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

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

The description is two sentences, front-loaded with the core purpose and followed by the two key filters. Every word contributes, with no redundancy or unrelated 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?

For a simple read-only browsing tool with three optional parameters and no output schema, the description sufficiently covers what it returns and how to filter. It could mention the limit parameter or explicitly state read-only behavior, but these are already implied or covered by the schema, making it complete enough 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 100% with descriptions for all three parameters. The description adds value by explaining the purpose of publisher_id ('explore all content from a specific publisher') and article_id ('see all licenses issued for a specific article') in natural language, going beyond the schema's bare definitions.

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

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

The description clearly identifies the tool as browsing the public Opedd license registry and specifies that it returns recently issued licenses and licensable content. It distinguishes itself from sibling tools by focusing on registry browsing and offering specific filters for publisher_id and article_id.

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

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

The description implies usage context (browse the registry, explore a publisher or article's licenses) but does not explicitly mention alternatives or when not to use this tool compared to siblings like lookup_content or list_feed. It provides useful context but lacks explicit exclusions or alternative 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, the description carries the full burden. It discloses auth requirements ('Public no-auth lookup'), latency expectations (milliseconds vs ~few seconds for custom domains), and the fact that it probes well-known platform endpoints in parallel. This is substantial behavioral context, though it does not cover failure modes 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?

The description is front-loaded with the primary action and auth status, then provides return format and field semantics. It includes the unnecessary phase label 'Phase 12 Wave 3 W3.1' which adds noise, but otherwise every sentence contributes 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?

Despite having no output schema, the description enumerates all return fields (platform, confidence, archive_method, forward_method, required_credentials, instructions) and explains how the key workflow fields are consumed. It also covers performance and auth, making it complete for a single-parameter 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?

The schema already documents the url parameter with 100% coverage, including the hostname-match short-circuit behavior. The description adds no additional parameter-specific semantics; it only reiterates behavior already in the schema. Baseline 3 is appropriate.

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

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

The description opens with a specific verb+resource: 'Detect the content platform behind a URL' and enumerates output platforms (Substack, Beehiiv, Ghost, Medium, Brevo, custom). It clearly distinguishes from sibling tools by focusing on platform identification and onboarding workflow rather than content retrieval or licensing.

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

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

The description states 'Public no-auth lookup' and 'Given a URL, identifies what platform powers it,' which implies the use case. It also explains that the returned archive_method and forward_method are read by Opedd's setup wizard, giving strong context for when to use it. However, it does not explicitly contrast with sibling tools or state 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 provided, the description carries the full behavioral burden and does so thoroughly: it discloses auth requirements (OPEDD_BUYER_TOKEN or OPEDD_BUYER_JWT), row shape, when inclusion_proof appears, the default inclusion behavior, and the 30-day window cap. It also explains that no separate flag is needed, preventing a likely misinvocation.

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 main purpose, filters, window cap, row contents, and auth are front-loaded and dense with useful info. Minor noise exists in internal references like 'Phase 9.x' and 'M6.4 consolidation per founder ratification' — these add historical context but do not help an agent select or invoke the tool correctly.

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

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

For a tool with no output schema and no annotations, the description explains the endpoint, auth, filtering, window limitation, row contents, attestation semantics, and default inclusion behavior. An agent has enough contextual information to call this tool correctly and interpret its response; nothing critical is missing.

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 already describes all five parameters at 100% coverage, so the baseline is 3. The description adds meaningful beyond-schema semantics by specifying the 30-day window cap that constrains from/to, and by enumerating the event_type options. This is useful context that the schema alone does not provide.

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

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

The description states a specific verb and resource ('Browse per-event audit rows for the authenticated buyer via GET /buyer-audit'), names the row contents, and distinguishes itself from get_compliance_dossier by the 30-day vs 90-day window cap. An agent can immediately tell what this tool does and how it differs from its closest sibling.

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

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

The description gives clear context: optional event_type filtering, the 30-day window cap, and a direct comparison to the 90-day cap on get_compliance_dossier. It implies when to choose this tool over the sibling, though it stops short of an explicit 'use this when X, otherwise use Y' rule or a list of exclusions.

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

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

With no annotations, the description carries the full burden and rises to it: it discloses the masking behavior (only 12-char key_prefix, never plaintext post-issuance), the JWT-only authentication design and its rationale, and the exact endpoint. This is substantive behavioral context, not just a restatement of the tool's name.

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 front-loaded with the action and resource, followed by return details, use cases, alternative guidance, and auth requirements in a logical order. Every sentence adds distinct value; there is no redundant filler.

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

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

Given no output schema, the description compensates by naming the returned enterprise_buyers fields and the masked key list format, plus the auth requirement and boundary conditions. This is complete enough for an agent to invoke the tool correctly without additional structured metadata.

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

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

The tool has zero parameters, so the schema trivially provides 100% coverage and the baseline of 4 applies. The description adds the implicit auth requirement OPEDD_BUYER_JWT, but there are no parameter semantics to explain beyond that.

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 a specific verb and resource: 'Fetch the authenticated buyer's account profile + masked API key list'. This clearly distinguishes it from sibling tools like get_audit_events or verify_license by focusing on the buyer account and API key inventory.

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 lists concrete use cases (post-signup verification, buyer dashboard mental model, audit prep) and names an alternative channel ('buyer portal at opedd.com/buyer') for mid-lifecycle license details, effectively telling the agent when not to use this 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?

With no annotations, the description carries the full disclosure burden. It reveals a non-obvious side effect: every successful call writes one license_events row with event_type='compliance_report_generated' BEFORE returning. It also covers authentication requirements, window caps, pagination behavior, and output shape, which goes well beyond what the schema exposes.

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

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

The description is dense but every sentence conveys a distinct, high-value fact: purpose, output shape, fan-out behavior, side effect, window cap, pagination strategy, legal framework mapping, and authentication. It is front-loaded with the core purpose. The only minor weakness is the jargon-heavy phrasing like 'Phase 11 M4' and 'procurement-defense', which adds little operational clarity.

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

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

For a tool with no annotations and no output schema, the description is unusually complete. It explains the response shape, row fan-out, compliance framework anchors, side effects, pagination pattern, and required credentials. An agent has enough context to select the tool, provide valid inputs, and interpret the 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 100%, so baseline is 3. The description adds value by explaining how the cursor should be used (_meta.next_cursor), how the window cap affects calling strategy, and how annual audits should be broken into quarterly windows. These details enhance the parameter semantics beyond the schema entries.

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

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

The description states a specific verb and resource: 'Generate a procurement-defense compliance dossier via GET /buyer-compliance-report'. It also differentiates from the closest sibling by explicitly contrasting the 90-day window cap with get_audit_events' 30-day cap, so an agent can tell which tool is intended.

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 gives clear operational guidance: it states the 90-day per-call window, contrasts it with the sibling's 30-day cap, and instructs agents to paginate via _meta.next_cursor across four quarterly windows for annual audits. It does not explicitly list exclusions or say 'use X instead', but the usage context is strongly implied and actionable.

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

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

With no annotations, the description carries the full burden, and it excels: it discloses token environments, env var requirements, license-specific response behavior, 403 ARTICLE_EXCLUDED, publisher content-delivery prerequisites, RAG metadata fields, and nuanced NULL semantics. This is far beyond a generic 'get' phrase.

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 long but every sentence carries operational weight, from error handling to NULL interpretation. It could be lightly reorganized for scanning, but details are not padded or redundant.

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 there is no output schema, the description compensates thoroughly: it explains response shape via RAG metadata fields, snippet truncation rules, error semantics, and historical NULL behavior. An agent can correctly interpret and filter results without needing additional documentation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value: canonical live/test token formats, env var fallback, and license scoping for tokens. It improves the agent's ability to supply the right token without merely restating schema text.

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

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

The description opens with a specific verb and resource: 'Retrieve the full body of a licensed article' using a buyer API token. It clearly articulates scope and even distinguishes full-text vs. snippet behavior by license type, which separates it from search or lookup 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 clear context on when full text is returned (per-article Human republication, AI monthly, client display) and when a snippet is returned (AI answers pay-per-request), plus the 403 error case. It does not explicitly name sibling tools as alternatives, so it stops short of full when/when-not routing.

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 discloses the JSON paginated response, the content_body inclusion rules per order type, the two access modes (retrieval_per_article vs metered_per_call), and the auth requirement (OPEDD_ACCESS_KEY). This is substantially more than a generic list description.

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 information-dense with no filler. It opens with purpose, then content contract, then parameter usage, auth, and the sibling alternative. Every sentence earns its place, and the structure makes it easy for an agent to extract key decision 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?

Given no annotations and no output schema, the description is remarkably complete: it covers what the tool returns, auth requirements, pagination, content-access rules, and the appropriate alternative for bulk use. The only omitted detail is exact response field names, but the schema already references data.pagination.next_cursor, so no critical gap remains.

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

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

The schema already covers all three parameters (100% coverage), so the baseline is 3. The description adds useful usage semantics for `since` (delta-feed polling) and `cursor` (pagination across pages), and implicitly clarifies `limit` by contrasting with stream_feed_ndjson's 1000-article cap.

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

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

The description states a specific action ('List articles'), a specific resource ('a buyer's licensed catalog'), and the endpoint ('GET /enterprise-license'). It also distinguishes the content-access modes, making it clear this is the feed-level listing tool versus get_content or stream_feed_ndjson.

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 explains when to use `since` for delta-feed polling, when to use `cursor` for pagination, and tells the agent to use stream_feed_ndjson instead for larger bulk pulls ('up to 1000 articles per call vs 200 here'). This is textbook when/when-not guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the operation is read-only, requires specific credentials, and that the single-order mode includes Schedule document text and SHA-256 fingerprint. It also implies pagination via cursor. It doesn't mention rate limits or error behavior, but for a read-only list tool, the disclosed traits are substantial.

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

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

Three sentences, each earning its place: the first defines the list behavior and fields, the second explains the single-order mode and its extra payload, the third covers auth and read-only status. Information is front-loaded and there is no filler.

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

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

For a read-only list tool with no output schema, the description covers the main fields returned, the ordering, the pagination cursor, the single-order variant, and the auth requirement. It doesn't describe error cases or rate limits, but those are minor for this tool's complexity. The description is complete enough for an agent to call 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?

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds context for order_id (what it returns: Schedule document text and SHA-256) and implies pagination via cursor, but it doesn't add syntax or format details beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb ('List'), a resource ('buyer's licence orders'), and a clear ordering ('newest first'). It also distinguishes the single-order read mode via order_id, which separates it from sibling tools like place_licence_order and purchase_license. The scope 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?

The description explicitly says when to use the list mode vs. the single-order mode ('Pass order_id to read one order'), and it names the required authentication context (buyer API key with 'audit' scope or buyer session). It also states the read-only nature, which helps an agent avoid using it for mutations. It doesn't explicitly name alternatives, but the mode distinction and auth requirements provide clear usage guidance.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly: it discloses authentication requirements, the exact stored-body readback semantics, 8,000-character truncation, page size 20, cursor pagination, and the push_content verification workflow. This goes well beyond the structured 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?

Four dense sentences, each earning its place: scope/auth, returned fields, include_body semantics with truncation and pagination, and the downstream license-purchase workflow. The long parenthetical sentence is information-dense rather than filler, though it is slightly heavy.

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 annotations and output schema, the description is quite complete: it covers auth, return fields, pagination, truncation, and a practical verification workflow. It does not detail error behavior or the exact response envelope beyond article fields, but the combination of description and schema is sufficient for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context to include_body (stored text exactly as buyers receive it, truncation, verification of push_content) and pagination via cursor. It does not substantially enrich id/type/limit/offset, but those are already well documented in 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 opens with a specific verb, resource, and scope: 'List all licensable articles for the authenticated publisher.' It further differentiates the tool by naming its downstream role ('Use article IDs from this list to purchase licenses via purchase_license'), which distinguishes it from generic content get/search/lookup 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?

The description provides clear context for when to use this tool: listing the publisher's licensable articles, verifying what push_content stored via include_body=true, and obtaining IDs for purchase_license. It does not explicitly state when not to use it or name alternative listing tools, so it stops short of a 5.

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

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

With no annotations provided, the description carries full burden. It discloses output fields and implies a read-only lookup, but it does not mention error handling, required permissions, or any edge cases (e.g., unavailable content). However, for a simple lookup tool, the disclosed behavior is 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?

Two sentences, front-loaded with the action and resource, then returns/usage instruction. Every sentence earns its place—no fluff, no repetition of schema 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?

For a simple single-parameter tool with no output schema, the description covers the input (URL), the output (title, publisher, licenses, pricing), and the appropriate context ('Always call this first'). This is fully sufficient for an agent to select 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?

Schema coverage is 100% (url described as 'canonical URL'), so the baseline is 3. The description reiterates that lookup is 'by URL' but adds no extra semantic information beyond the schema, such as format expectations or non-canonical URL handling.

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 'Look up' with a clear resource ('content on the Opedd registry by URL'), and further clarifies the lookup scope by listing returned data (title, publisher, license types, pricing). This clearly differentiates it from siblings like 'get_content' or 'browse_registry' by emphasizing licensing/cost information.

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

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

The phrase 'Always call this first to check if content is licensable and what it costs' gives explicit guidance on when to use the tool. It does not explicitly mention alternatives or when not to use it, but the directive is clear and contextually 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 of behavioral disclosure, and it excels. It details that unavailable publishers are returned in `unavailable` and never charged, that monthly AI answers subscriptions cover only articles from the start date, that include_archive adds the full catalogue, and that the returned access key works only once paid via hosted_invoice_url. It also states the requirement for terms acceptance. This is comprehensive 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 long but every sentence carries essential information. It front-loads the core purpose, then systematically covers licence options, billing modes, edge cases, return values, and prerequisites. There is no redundancy or fluff; the density is appropriate for the complexity of the operation.

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

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

The description is fully self-contained: it explains the return payload (order, lines, access key, hosted_invoice_url), the prerequisites (buyer session, terms_accepted), and the edge cases (unavailable publishers, include_archive behavior). Without an output schema, it provides all necessary context for an agent to call the tool correctly and 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?

Schema coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema. It explains the semantic differences between licences (enterprise vs archive vs training vs display), the allowed billing modes per licence, the quantity constraint for display, the publisher limit of 18 for metered, the include_archive behavior, and the terms_accepted requirement. This transforms the parameter documentation from structural to behavioral.

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 verb and resource: 'Place a licence order with Opedd for one or more publishers.' It then precisely defines the one-order-one-licence model, enumerates the four licence types with their billing modes, and explains the per-publisher Schedule pricing. This level of specificity fully distinguishes the tool's purpose from any sibling without ambiguity.

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

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

The description provides clear operational context: it states the prerequisite of a buyer session (OPEDD_BUYER_JWT) and the mandatory terms_accepted flag, and it explains the behavior for unavailable publishers. However, it does not explicitly mention alternatives or exclusions (e.g., when to prefer purchase_license). The context is sufficient for an agent to infer appropriate use, but lacks explicit routing to 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 are provided, so the description must disclose behavioral traits. It reveals the HTTP method (GET), public no-auth access, pagination behavior, and the fact that sample articles contain RAG-extended metadata. It lacks rate limit or error details, but for a public read-only browse tool the disclosure is strong.

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

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

The description is compact and front-loaded with the primary purpose. Four sentences cover the function, return data, differentiation from a sibling, and use case. The bolded phrase highlights the tool's role without wasting words.

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 compensates by naming the returned fields (article counts, pricing, plan, sample articles). It also covers auth, pagination, filters, and the intended usage context. This is complete for a public GET tool with five 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 description coverage is 100%, so the baseline is 3. The description recaps filters (category, min_articles, verified status) but does not add information beyond the schema. The schema already provides details like case-insensitivity and default behavior for verified.

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

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

The description clearly states the action (browse), the resource (Opedd publisher catalog), and what it returns (publishers with article counts, pricing, plan, sample articles). It explicitly distinguishes itself from the sibling tool browse_registry by noting the latter lists licenses, not publishers.

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

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

It names browse_registry as the alternative and explains the difference, and further contextualizes when to use it: 'useful pre-purchase scoping before buyers commit to enterprise-license POST.' This is explicit when/why 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, the description carries the behavioral disclosure burden and does a good job: it discloses the returned license key and certificate URL, the Handshake Email sent to the buyer, env var fallbacks, and the human-only restriction. It does not explicitly warn that the Stripe payment method will be charged or that the purchase is binding, but 'Purchase... using a Stripe payment method' strongly implies a financial transaction.

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?

Four sentences, each contributing useful information: purpose and return values, email notification, env var shortcuts, and licensing restrictions. The most important distinction is front-loaded, and there is no filler.

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

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

For a 9-parameter purchase tool with no output schema, the description covers the essential return value, side effects, fallbacks, and the key alternative tool. It is not exhaustive about failure modes or irreversible charges, but the schema already documents every parameter and the description gives enough behavioral context for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful context beyond the schema: env var fallbacks for buyer_email and payment_method_id, the license key format, and the relationship between license_type and the alternative place_licence_order. This improves the agent's ability to populate parameters correctly.

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

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

The description states a specific action ('Purchase a content license'), the protocol (Opedd), and the payment method (Stripe), and clearly distinguishes this tool from its sibling place_licence_order by explaining that AI licenses are handled elsewhere. The license key format and certificate URL add concrete outcome detail.

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 routes AI license purchases to place_licence_order and states that single-article purchases are limited to the 'human' license type. This gives the agent clear criteria for choosing purchase_license over the closest 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 are provided, so the description carries the burden of behavioral disclosure. It reveals the authentication requirement (OPEDD_PUB_BEARER), the 1–100 article call limit, the required fields, and that published_at defaults to now. This gives the agent substantial operational knowledge beyond the schema, though it stops short of describing responses, error behavior, or idempotency.

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?

Every sentence earns its place: one for purpose and auth, one for batching limits, one for required fields/defaults, and one for sibling differentiation. The most important operational information is front-loaded, with no filler or repetition.

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

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

For a tool with a complex nested article object and no annotations or output schema, the description covers the essential invocation context: auth, batch size, required fields, defaults, and when to use it. A brief note on response/result behavior would make it fully complete, but nothing critical is missing for correctly calling the 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 description coverage is 100%, and the schema already documents each field and its constraints. The description adds value by emphasizing that only title, url, and html_body are required and that published_at defaults to now, but it does not need to compensate for missing schema documentation. Baseline 3 is appropriate.

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

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

The description names a specific verb and resource ('Push your published articles to Opedd') and clearly states the purpose: licensing them to AI buyers. It explicitly positions itself against a sibling tool ('supply-side companion to list_publisher_content'), making the tool's identity 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 gives concrete usage context: use it to onboard an archive or push new content, and it names the sibling alternative (list_publisher_content). It also provides batching guidance for larger back-catalogues. It does not explicitly state when not to use the tool, but the guidance is clear enough for an agent to select it correctly.

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 present, so the description carries the full burden. It discloses that the endpoint is public and no-auth, explains the two response shapes (raw JSON vs JSON-LD with HMAC-SHA256 signed receipt), and notes the publisher-side CDSM context. This is rich behavioral detail beyond basic read 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 is informative and front-loaded with the core purpose, but includes some internal project references like 'Phase 12 Wave 1 W1.1' and 'Per INVARIANTS.md W1.6' that add noise. Overall, each sentence earns its place despite the 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 and annotations, the description provides comprehensive context: what the manifest contains, why an agent would use it, how the jsonld flag changes the response, and how this tool differs from the sibling attestation tool. It is complete for a simple GET 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?

The input schema covers both parameters with detailed descriptions (e.g., jsonld includes the signed receipt behavior). The tool description largely repeats this information without adding new parameter-level semantics. With 100% schema coverage, a baseline of 3 is appropriate.

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

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

The description clearly states 'Fetch a publisher's RSL Standard manifest via GET /rsl-manifest', which is a specific verb+resource. It also distinguishes this tool from the sibling 'article_53_attestation' by explicitly noting it is NOT the EU AI Act Article 53 attestation.

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: it is a 'discovery surface for AI agents/crawlers wanting to know what's licensable from a publisher BEFORE going through the buyer-account signup flow' and explicitly contrasts it with the buyer-side `article_53_attestation` tool. This gives clear when-to-use and when-not-to-use guidance.

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

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

With no annotations, the description carries the full burden and succeeds: it discloses auth requirements ('public, no key needed'), search syntax (quotes, -word), output fields (publisher, prices, word count, snippet), and an explicit limitation ('never the body'). This is above-average transparency for a read-only search 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?

Three sentences with zero waste. Purpose, syntax, return contents, and usage guidance are each given their own focused sentence, front-loaded with the most critical 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 search tool with no output schema, the description fully covers what the agent needs to know: scope, auth, syntax, return fields, limitations, and follow-up tools. Nothing essential is missing.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful value beyond the schema by explaining the query parameter's supported syntax ('quotes for phrases and -word to exclude') and natural-language prompting, which the schema's 'Search words' does not convey.

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

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

The description states a specific verb and resource: 'Full-text search across everything licensable on Opedd.' It also differentiates from sibling tools by explicitly directing users to lookup_content or get_content for specific articles, making the search tool's role distinct.

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

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

It explicitly states when to use the tool ('does Opedd have coverage on X') and routes to named alternatives ('then lookup_content or get_content for a specific article'). This gives clear context and exclusion 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?

No annotations are provided, so the description carries the full burden, and it does so thoroughly. It discloses charging behavior, per-publisher pricing, cumulative 300-word/25% caps, may_train=false, the 24-hour free re-ask, and the explicit warning that passage text is data, not instructions—an important safety behavior.

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

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

The description is longer than average, but every sentence earns its place by covering a distinct operational or safety requirement. It front-loads the core purpose and the paid-vs-free distinction, then layers licensing, caps, safety, and typical flow in a logical order.

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 complexityately, no annotations, and no output schema, the description is exceptionally complete. It explains empty-result behavior with the 'no_licensed_publishers' reason, licensing flow, passage caps, citation obligations, injection safety, and the typical end-to-end workflow.

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

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

Schema coverage is 100%, but the description adds meaningful context beyond the schema by explaining query as a plain-words question, clarifying buyer_token's scope requirement and OPEDD_BUYER_TOKEN fallback, and linking token/licence semantics to tool behavior.

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 a specific verb and resource: ask a question and get back short, licensed passages with citations. It explicitly contrasts with search_content by naming the paid vs free distinction, making sibling differentiation immediate and accurate.

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 and when-not-to-use guidance: search_content for discovery, place_licence_order for licensing, then search_passages for actual reading. It also states prerequisites like buyer API key, active per-question licence, and the limitation to licensed publishers only.

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 behavioral burden and does so thoroughly. It discloses the 1000-article cap, the line-delimited JSON wire format, the metadata-only behavior for non-AI-training orders, the analytics-only usage_records sentinel, the backend's 5000-article capability, and the access key requirement. This goes well beyond what the schema alone could convey.

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

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

The description is dense but mostly purposeful, front-loading the endpoint and core behavior before parameter guidance and SDK alternatives. Minor noise like 'Phase 11 M3' and the jargon-heavy 'revenue-model bifurcation invariant' slightly reduce conciseness, but nearly every sentence contributes operational 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?

For a tool with no annotations and no output schema, this description is remarkably complete: it covers the endpoint, response format, content contract, billing implications, pagination, delta behavior, authentication, and when to prefer the SDK. An agent has enough context to select and invoke the tool correctly without needing additional external information.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining `since` as the delta-feed mechanism, `cursor` as the pagination mechanism beyond 1000, and the MCP cap of 1000 versus the backend's 5000. This enriches the parameter semantics rather than merely repeating schema text.

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

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

The description opens with a specific verb and resource: 'Bulk-export a buyer's licensed catalog via GET /enterprise-license?format=ndjson'. It clearly distinguishes itself from siblings by naming list_feed as the same content contract and get_content for article text, so an agent can tell exactly what this tool does and how it differs.

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

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

Usage guidance is explicit: use `since` for delta feeds, use `cursor` to paginate beyond 1000, and use get_content when article text is needed. It also explicitly warns that real bulk-ingest pipelines should use the Python SDK directly, not MCP, and states the access key requirement. This is strong when-to-use and when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the full burden. It states the tool 'verify[ies]' and 'returns license details,' implying a read-only, non-destructive operation, and it mentions 'blockchain proof status' as part of the response. While it doesn't explicitly state there are no side effects or prerequisites, the verification context is sufficiently transparent.

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

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

The description is two sentences long. The first sentence states the core purpose; the second lists return fields and gives a usage statement. Every sentence adds value, and the structure is front-loaded with the most important information.

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

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

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is complete. It explains what the tool does, what it returns (listing specific fields), and when to use it. This is sufficient for an agent to 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 100% coverage for the single parameter, including its format ('OP-XXXX-XXXX'). The description does not add additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Verify the authenticity of an Opedd license key.' It uses specific verb+resource phrasing and lists various returned details (article title, publisher, license type, etc.), which distinguishes it from sibling tools like purchase_license or get_buyer_account.

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 usage context: 'Use this to confirm a license is valid before using licensed content.' It does not mention alternatives or exclusions, but the intended scenario is clear enough for an agent to select this tool over others.

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