Opedd — Licensed Content for AI

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

With no annotations, the description carries the full transparency burden. It discloses the return type (freshly-signed HS256 JWT), the embedded contents (license context, usage-count, Merkle root, canonical claims), the authentication requirement (OPEDD_BUYER_JWT), and hard constraints (window cap 365 days). This is comprehensive behavioral disclosure.

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

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

The description is lengthy but information-dense; each clause adds needed context (endpoint, artifact use, legal scope, exclusions, defaults, auth). It is front-loaded with the core action, though the sentence count could be trimmed without losing meaning.

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

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

For a complex legal/security tool with no output schema, the description fully explains the return value, the artifact's purpose, the legal boundaries, parameter semantics, and required auth. It is contextually complete for an 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?

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the optional content_id scoping behavior and default license-wide, plus the window cap. It also clarifies that the license must be owned by the buyer, which is not 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 clearly states the tool's purpose: issue a signed JWT attesting to EU AI Act Article 53 compliance for a specific license, via a named endpoint. It also distinguishes itself from the sibling rsl_get tool with an explicit exclusion, making the tool's unique scope obvious.

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 explicit when-to-use guidance: it is the artifact for legal/procurement for EU AI Act Article 53(1)(d) evidence. It also explicitly says when NOT to use it (does not discharge CDSM Article 4(3) obligation) and names the alternative tool (rsl_get jsonld=true variant).

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, the description carries the full burden. It discloses the row contents (license_terms, on-chain attestation), the default inclusion of proof, and the authentication requirement. It omits some details like pagination behavior, but still provides substantial behavioral context.

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

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

The description is structured with the core action first, followed by supporting details. It is concise despite containing several pieces of specific information, though the rationale about tool consolidation adds marginal noise.

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 row content, auth requirement, and window cap, while providing a sibling comparison. It lacks explicit pagination guidance, but the schema covers cursor and limit, making it sufficiently complete for the intended use.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds the 30-day window constraint and clarifies event_type is optional, but it does not add deeper parameter syntax beyond what the schema already provides.

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 a specific verb+resource: 'Browse per-event audit rows for the authenticated buyer via GET /buyer-audit'. It also distinguishes itself from sibling get_compliance_dossier by noting the 30-day window cap vs 90-day, making the tool's scope 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 clear context for when to use the tool by comparing its 30-day cap with get_compliance_dossier's 90-day cap, and states the required OPEDD_BUYER_JWT. However, it does not explicitly say when not to use this tool or name alternatives beyond the one comparison.

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

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

With no annotations provided, the description takes on the full burden and discloses critical behavior: returns the enterprise_buyers row, the masked key list with the no-plaintext policy, and the requirement for OPEDD_BUYER_JWT. This goes beyond minimal by surfacing a security constraint and output details.

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

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

The description is front-loaded with the primary purpose, then adds tightly packed, non-redundant details on return value, security, use cases, and alternatives. Every sentence earns its place, and the structure (purpose, details, use cases, exclusion, auth) is logical and digestible.

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 zero-parameter read operation with no output schema, the description fully covers what the tool does, what it returns, its security stance, when to use it, and where to go for more detailed license info. It leaves no critical gaps for an 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?

There are zero parameters, so the input schema is trivially 100% covered. The description adds no parameter-specific detail because none exist; it correctly focuses on the request's outcome. A baseline of 4 is appropriate for a parameterless tool.

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 ('Fetch the authenticated buyer's account profile + masked API key list via GET /buyer-account'), clearly distinguishing it from sibling tools by focusing on the buyer account and key list. It also notes the endpoint and scope, leaving no ambiguity about the tool's function.

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 is explicitly guided with concrete use cases (post-signup verification, dashboard mental model, audit prep) and an explicit alternative for full license details ('buyers consult the buyer portal at opedd.com/buyer'). The prerequisite auth requirement is also stated, providing clear when-to-use and when-not-to-use context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals a critical side effect: every successful call writes a license_events row before returning. It also discloses authentication requirements (OPEDD_BUYER_JWT), window caps, and pagination behavior. This is exceptional transparency for a tool that has a write side-effect despite being a 'get' 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 a single dense paragraph but efficiently packs essential information: purpose, endpoint, data shape, side effects, window caps, pagination strategy, compliance anchors, and authentication. While longer than ideal, every sentence contributes new information and the purpose is front-loaded. It is structured well with semicolons to separate concepts, avoiding unnecessary 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 tool's complexity—no output schema, no annotations, multiple behavioral nuances—the description is remarkably complete. It covers the dossier shape, side-effect write, authentication, window caps, pagination for multi-year ranges, and compliance framework anchors. There is enough context for an agent to understand when and how to invoke the tool, and what to expect from its behavior.

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 documents all three parameters (from, to, cursor) with 100% coverage. The description adds meaningful context beyond the schema by specifying the 90-day window cap for from/to ranges and explaining that cursor is used for pagination via _meta.next_cursor. It does not provide additional format details, but the cap and pagination semantics are valuable enhancements over the bare schema.

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

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

The description clearly identifies the tool's function: generating a procurement-defense compliance dossier via a specific endpoint. It distinguishes itself from siblings like get_audit_events by noting its 90-day window cap versus the 30-day cap, giving a unique scope. The verb 'generate' and resource 'compliance dossier' are specific and non-tautological.

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 mentions when to use this tool (for compliance dossiers) and contrasts it with get_audit_events, noting the 90-day vs 30-day window cap. It also provides guidance on pagination for annual audits using _meta.next_cursor across four quarterly windows, which tells the agent how to handle larger date ranges. This is clear usage context with an alternative explicitly named.

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 thoroughly discloses authentication requirements, token fallback, license scope, publisher conditions, response shape with 7 metadata fields, and extensive NULL semantics with a caution not to interpret NULL as anti-match. This is exceptionally 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 longer than average, but every sentence serves a purpose: action, prerequisites, license types, conditions, response details, and NULL semantics. It is front-loaded with the main purpose and structured logically.

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 tool with no output schema, the description is remarkably complete. It lists the 7 RAG-essential metadata fields, explains nullability on historical articles, clarifies data-missing semantics, and states all needed conditions. No significant gaps remain.

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 goes beyond schema by explaining token pattern (buyer_live_*/buyer_test_*), fallback to env var, and the meaning of NULL in historical articles, adding significant value.

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 the full body of a licensed article, with specific verb+resource. It implies content retrieval rather than metadata lookup, but does not explicitly distinguish from the sibling tool lookup_content, which could overlap in purpose.

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

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

The description provides clear context on when to use the tool: requires OPEDD_BUYER_TOKEN, supports per-article and archive licenses, and requires publisher content delivery. It gives prerequisites and conditions but does not explicitly mention alternatives or 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 fully discloses key behaviors: metered keys get discovery-only feed with null content_body and 'metered_per_call' access, retrieval via get_content is billed, requires OPEDD_ACCESS_KEY, and returns paginated JSON. This is rich, non-obvious context beyond what any schema 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?

Dense but efficient; each sentence carries distinct info (endpoint, content contract, params, auth, alternative). Slightly long, but every clause adds value and the structure is logical.

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?

Covers purpose, response format, authentication, pagination, delta polling, metered behavior, and alternative. Given no output schema and no annotations, this description provides sufficient context for an agent to use the tool correctly without further clarification.

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 important semantic context: `since` is for delta-feed polling, `cursor` is an opaque token from the response's data.pagination.next_cursor, and `limit` has a max of 200. This goes beyond the schema descriptions, which are already good.

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 'List articles from a buyer's licensed catalog via GET /enterprise-license' — a specific verb, resource, and endpoint. It also differentiates from sibling tools like get_content and stream_feed_ndjson by describing the distinct behavior for metered keys and bulk pulls.

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 usage context: `since` for delta-feed polling, `cursor` for pagination, and a direct alternative for bulk pulls ('use stream_feed_ndjson'). This gives clear guidance on when to use this tool versus alternatives.

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

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

With no annotations provided, the description carries the full burden. It discloses the authentication requirement, the returned data fields (titles, descriptions, pricing, sales statistics), and the relationship to purchase_license. While it doesn't discuss rate limits or error cases, it provides solid behavioral context for a read-oriented 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 dense sentences deliver purpose, auth, return contents, and downstream usage without any waste. The structure is front-loaded with the core action, followed by necessary specifics.

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 no output schema, so the description must explain return values, and it does ('titles, descriptions, pricing, and sales statistics'). It also covers authentication and a practical use case. It could mention pagination explicitly, but limit/offset are already in the schema, so completeness is high.

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%, with each parameter (type, limit, offset) already described in the schema. The description adds no new parameter-level meaning, so the baseline of 3 applies as the schema handles parameter semantics.

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 ('List') with a clear resource ('licensable articles for the authenticated publisher') and a well-defined scope. It distinguishes from siblings by explicitly connecting its output to a concrete downstream action ('Use article IDs from this list to purchase licenses via purchase_license'), making its role unique.

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 the required authentication context ('requires OPEDD_PUB_BEARER, or legacy OPEDD_API_KEY') and indicates the typical use case (before purchasing licenses with purchase_license). It does not explicitly exclude alternative tools like list_feed, but the context is clear enough for appropriate invocation.

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?

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 provided, the description carries the full burden, and it delivers rich behavioral detail: returns a Stripe client_secret and enterprise_license_id, emails the access key after payment, defines scope behaviors (custom pass-through, platform_wide auto-resolve, filtered rules), maps license tiers to internal types, and requires terms_accepted with HTTP 400 rejection. This is exemplary transparency for a purchase workflow.

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?

Despite its length, every sentence adds critical information: purpose, return values, scopes, tiers, terms, and edge cases. It is front-loaded with the main action and returns, then systematically expands on options. No fluff or redundancy—it is dense but well-structured for a complex tool.

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

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

The tool has 10 parameters, no output schema, and a complex domain (licensing, scopes, tiers, MSA acceptance). The description covers the return format (client_secret + ID), email delivery, scope-specific behavior, tier mappings, and legal requirement. It also mentions filter_rules documentation and optional webhook. Given the complexity, this description is remarkably complete.

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

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

Although schema coverage is 100%, the description goes far beyond the property descriptions. It clarifies the meaning of scope values (e.g., 'custom' pass-through vs 'platform_wide' auto-resolve), maps license_tier values to internal record types, explains that publisher_ids is ignored for non-custom scopes, and details the terms_accepted requirement. This adds significant semantic value that is not present in the schema alone.

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

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

The description starts with a specific verb and resource: 'Purchase a bulk enterprise license covering multiple publishers (Phase 10).' It clearly states what the tool does and differentiates from sibling tools like purchase_license by focusing on bulk enterprise coverage. The return values are also explicitly mentioned, making the purpose unmistakable.

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

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

The description clearly implies when to use this tool: for bulk enterprise licenses covering multiple publishers, with scope and tier options. However, it does not explicitly contrast it with the sibling purchase_license tool or state when NOT to use it, so it stops short of fully explicit when/when-not guidance.

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

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

With no annotations, the description carries full burden for behavioral disclosure. It mentions the return of a license key and certificate URL, and that a Handshake Email is sent. However, it omits critical behavioral details such as the mandatory 'terms_accepted' requirement, the possibility of rejection, and that a Stripe charge will occur (though 'purchase' implies it). This is a meaningful gap for a financial transaction 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 three concise sentences with no fluff. The first sentence states the core action, the second gives the return format, and the third provides env var tips and license type definitions. Each sentence earns its place, and the key information is front-loaded.

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

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

Given the tool's complexity (9 params, no annotations, no output schema), the description covers the basic purpose, return values, and env var usage, but omits the critical 'terms_accepted' requirement and the distinction from enterprise licensing. It also does not explain the relationship between article_id and article_url, leaving some gaps for correct 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?

The input schema has 100% coverage for all 9 parameters, including descriptions for each. The description adds some context (license type meanings, env var fallbacks) but largely repeats what is already in the schema, neither compensating for nor materially enhancing the parameter semantics.

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: 'Purchase a content license from the Opedd protocol using a Stripe payment method.' It specifies the resource (content license), the action (purchase), and the payment method, distinguishing it from sibling tools like purchase_enterprise_license.

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 on usage, including license types (human, ai, ai_inference) and env var fallbacks, implying when to use this tool for individual licenses. It does not explicitly mention exclusions or alternatives, but the license type breakdown and mention of enterprise licenses as a sibling suggest differentiation.

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 (OPEDD_PUB_BEARER), batch size limits, required fields, and the default for published_at. However, it does not describe the return value, whether pushes are idempotent or overwrite existing content, or any error/rate-limit behavior. This is adequate but not rich.

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 dense sentences, each earning its place: purpose + auth, batching + required fields, and use-case + sibling context. No fluff or repetition; the key information is front-loaded.

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

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

For a single-parameter tool with a nested schema and no output schema, the description covers purpose, auth, batching, required fields, defaults, and relationship to a sibling. It lacks details on what happens after a successful push (e.g., result format, overwrite behavior), but given the rich schema and clear use case, it is largely complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by grouping required fields ('title, url, and html_body — everything else is optional') and clarifying the default behavior for published_at ('defaults to now'), going beyond the raw schema descriptions.

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

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

The description uses the specific verb 'Push' with a clear resource ('your published articles to Opedd') and explicitly positions it as the 'supply-side companion to list_publisher_content', which distinguishes it from sibling tools. It states exactly what the tool does and its role in the ecosystem.

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 when-to-use guidance: 'use it to onboard your archive or push new content with no code'. It also advises batching larger back-catalogues into multiple calls (1–100 per call). It names the sibling tool list_publisher_content as the complementary read-side tool, but does not explicitly mention exclusions or alternative tools for other scenarios.

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 provided, the description fully discloses critical behavior: MCP cap of 1000 vs backend 5000, line-delimited JSON wire format, the non-billable sentinel 'bulk-export:<request_id>:<article_id>', the revenue-model bifurcation invariant, and required OPEDD_ACCESS_KEY. This goes far beyond a typical tool 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 dense but every sentence carries essential information, front-loaded with the primary purpose. It covers purpose, limits, comparison to siblings, usage patterns, exclusions, billing nuances, and auth in a compact, well-structured block. No fluff or redundancy.

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

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

For a tool with no annotations and no output schema, this description is remarkably complete. It addresses behavior, constraints, alternatives, billing impact, and prerequisites, enabling an agent to select and invoke the tool correctly even without additional 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?

Schema coverage is 100%, so baseline is 3. The description adds operational context beyond the schema: `since` is explicitly tied to delta-feed, `cursor` to paginating beyond 1000, and `limit`'s cap is explained by the MCP-vs-backend transport reasonability. This gives the agent deeper practical understanding of how to use the 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 the tool's function: 'Bulk-export a buyer's licensed catalog via GET /enterprise-license?format=ndjson'. It uses a specific verb and resource, and distinguishes itself from siblings by referencing list_feed's contract and directing article-text retrieval to get_content, and real bulk-ingest to the Python SDK.

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 guidance is provided: use `since` for delta-feed, `cursor` for pagination beyond 1000, and a direct exclusion — 'Real bulk-ingest pipelines should use the Python SDK ... not via MCP'. It also clarifies when not to use this tool (for article text → use get_content).

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

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

No annotations 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.