Opedd enables AI agents to discover, purchase, verify, and manage licensed content from publishers with on-chain proof and EU AI Act compliance support.
Content Discovery
lookup_content: Look up any article URL for licensing availability, license types, and pricing.
publisher_directory: Browse the publisher catalog, filterable by category, article count, or verification status.
browse_registry: Explore publicly issued licenses, filterable by publisher or article.
rsl_get: Fetch a publisher's RSL manifest including EU CDSM Article 4(3) opt-out status; optionally get a signed JSON-LD receipt.
detect_platform: Identify the platform (Substack, Ghost, etc.) behind a URL and get suggested onboarding workflows.
License Purchase
purchase_license: Buy a single-article license (human republication, AI training, or AI inference) via Stripe, receiving a license key.
purchase_enterprise_license: Purchase a bulk license covering multiple publishers with custom scopes and billing tiers.
License Verification
verify_license: Verify the authenticity of a license key, returning article details, publisher, issue date, amount paid, and blockchain proof status.
Content Retrieval & Feeds (requires auth tokens)
get_content: Retrieve the full text of a licensed article with RAG metadata (OPEDD_BUYER_TOKEN).
list_feed: List articles from your licensed catalog with delta-feed support (OPEDD_ACCESS_KEY).
stream_feed_ndjson: Bulk-export up to 1,000 articles per call in NDJSON format (OPEDD_ACCESS_KEY).
Buyer Account & Compliance (requires OPEDD_BUYER_JWT)
get_buyer_account: View your buyer profile and masked API keys.
get_audit_events: Access a per-event audit ledger with Tempo on-chain attestation proofs.
get_compliance_dossier: Generate a procurement-defense compliance dossier under CDSM and EU AI Act frameworks.
article_53_attestation: Generate a signed JWT attesting EU AI Act Article 53(1)(d) compliance for a specific license.
Publisher Tools (requires OPEDD_PUB_BEARER)
list_publisher_content: View your own articles with pricing and stats.
push_content: Upload articles (1–100 per call) to Opedd for licensing by AI buyers.
Detects Brevo content platforms and suggests onboarding workflows for AI content buyers.
Detects Ghost content platforms and suggests onboarding workflows for AI content buyers.
Detects Medium content platforms and suggests onboarding workflows for AI content buyers.
Processes license purchases via Stripe payment methods.
Detects Substack content platforms and suggests onboarding workflows for AI content buyers.
Provides buyer account, audit, and compliance tools authenticated via Supabase JWTs.
Lets AI assistants (Claude Desktop, Cursor, Windsurf, or any MCP-compatible host) discover, purchase, and verify content licenses autonomously — mid-conversation, without opening a browser. Every license is registered on-chain (Tempo blockchain) with cryptographic proof.
Unlike generic search APIs, Opedd returns content with a verifiable license key — defensible under the EU AI Act and any copyright jurisdiction.
npx opedd-mcpThen add it to your MCP host (see Claude Desktop / Cursor / Windsurf setup below). Discovery + verification tools work with no configuration; purchasing and content retrieval use optional API keys from opedd.com.
Related MCP server: PixelVault
Prefer zero-install? The same 17 tools are served hosted at https://mcp.opedd.com/mcp (Streamable HTTP). Auth is an Authorization: Bearer header with any Opedd key — public discovery tools need no auth at all.
Claude Messages API (production agents):
{
"mcp_servers": [{
"type": "url",
"url": "https://mcp.opedd.com/mcp",
"name": "opedd",
"authorization_token": "opedd_buyer_live_..."
}]
}OpenAI Responses API:
{
"tools": [{
"type": "mcp",
"server_label": "opedd",
"server_url": "https://mcp.opedd.com/mcp",
"authorization": "opedd_buyer_live_..."
}]
}claude.ai / Claude Desktop custom connector (all plans): Settings → Connectors → Add custom connector → URL https://mcp.opedd.com/mcp; add a Authorization: Bearer <your key> request header for the credentialed tools.
Cursor (.cursor/mcp.json):
{
"mcpServers": {
"opedd": {
"url": "https://mcp.opedd.com/mcp",
"headers": { "Authorization": "Bearer ${env:OPEDD_KEY}" }
}
}
}Key routing: opedd_pub_* → publisher tools · opedd_buyer_* → content retrieval · ent_* → bulk feeds · buyer-portal JWT → audit/compliance/EU-AI-Act tools. Your key is forwarded per request and never stored by the gateway.
Exposes up to 17 tools to any AI assistant (some are conditional on env vars):
Always available — discovery + per-article purchase + onboarding + rights signaling
Tool | Description |
| Look up an article by URL — returns title, publisher, pricing |
| Buy a single-article license via Stripe — returns OP-XXXX-XXXX key. Requires |
| Verify a license key — returns validity, article, publisher, blockchain proof |
| Browse the public Opedd registry — lists issued LICENSES (use |
| Browse the public Opedd publisher catalog — paginated publishers with article counts + pricing + sample articles (primary buyer-discovery surface for AI labs) |
| Buy a bulk enterprise license covering multiple publishers (Phase 10) — returns Stripe |
| Fetch a publisher's RSL Standard manifest — public discovery surface; |
| Detect the content platform behind a URL — returns suggested onboarding workflow for Substack / Beehiiv / Ghost / Medium / Brevo / custom (Phase 12 W3.1) |
Requires OPEDD_BUYER_TOKEN (opedd_buyer_live_*)
Tool | Description |
| Retrieve a licensed article — includes 7 Phase 11 M2 RAG metadata fields (author, language, word_count, content_hash, image_urls, canonical_url, tags) |
Requires OPEDD_ACCESS_KEY (ent_*) — buyer-side feed surfaces
Tool | Description |
| List articles from a buyer's licensed catalog with |
| Bulk-export up to 1000 articles per call via NDJSON wire format (Phase 11 M3). Same per-scope content contract as |
Requires OPEDD_BUYER_JWT (Supabase JWT) — buyer account + audit + compliance + EU AI Act surfaces
Tool | Description |
| Fetch buyer profile + masked API key list — buyer-dashboard mental model |
| Per-event audit ledger with Tempo on-chain attestation inclusion proofs inline (Phase 9.x + 10 M5) |
| Procurement-defense compliance dossier mapping retrievals to license terms (Phase 11 M4) |
| Signed JWT attesting EU AI Act Article 53(1)(d) compliance for a license — the artifact AI labs hand to legal/procurement (Phase 12 W1.4) |
Requires OPEDD_PUB_BEARER (opedd_pub_*) — publisher-side
Tool | Description |
| List your own articles with pricing and stats |
| Push your articles to Opedd so AI buyers can license them — 1–100 per call ( |
Per Opedd's platform invariants (W1.6 amendment):
rsl_get(publisher_id, jsonld=true) → publisher-side CDSM Article 4(3) opt-out declaration (signed JSON-LD receipt over the reservation state).
article_53_attestation(license_id) → buyer-side EU AI Act Article 53 attestation (signed HS256 JWT scoped to one license).
get_compliance_dossier(from, to) → comprehensive procurement-defense dossier covering BOTH frameworks (publisher CDSM reservation honored + buyer Article 53 evidence chain).
These serve different audit-defensibility modes and never share wire format. Tool descriptions cite the W1.6 invariant inline.
npm install -g opedd-mcpOr run directly with npx:
npx opedd-mcpSet environment variables to pre-configure the server:
Variable | Required | Description |
| Recommended | Your email — used as default for all purchases |
| Recommended | Stripe |
| Optional | Buyer API token ( |
| Optional | Enterprise access key ( |
| Optional | Supabase session JWT from the buyer portal — enables |
| Optional | Canonical Publisher API Bearer key ( |
| Deprecated | Legacy Publisher API key ( |
| Optional | Override the API base URL (default: Opedd production) |
| Optional | Set to |
Getting a Stripe payment method ID: Save a card in your Stripe account and retrieve the
pm_...ID via the Stripe API.
To understand how AI assistants use this server, opedd-mcp sends anonymous
telemetry for each tool call: only the tool name, its duration, whether it
succeeded, and the server version — plus a random per-process id. It never
sends tool parameters, responses, your email, API keys, tokens, content, or
your IP. Data goes to Opedd's PostHog (EU region).
To opt out, set either environment variable before starting the server:
OPEDD_MCP_TELEMETRY=0
# or the cross-tool standard:
DO_NOT_TRACK=1When opted out, no telemetry client is created and nothing is sent.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"opedd": {
"command": "npx",
"args": ["opedd-mcp"],
"env": {
"OPEDD_BUYER_EMAIL": "you@yourcompany.com",
"OPEDD_PAYMENT_METHOD_ID": "pm_..."
}
}
}
}Add to your MCP settings:
{
"opedd": {
"command": "npx opedd-mcp",
"env": {
"OPEDD_BUYER_EMAIL": "you@yourcompany.com",
"OPEDD_PAYMENT_METHOD_ID": "pm_..."
}
}
}Once configured, you can ask your AI assistant:
"Look up the licensing options for this article: https://theinformation.com/articles/..."
"Purchase a human republication license for that article on my behalf."
"Verify license key OP-XXXX-XXXX and tell me what it covers."
"Browse the latest licenses from The Information publisher."
"What does publisher 8268c353-ffa3-4db3-bbb2-90ddbbb43e41 license? Pull the RSL manifest." — uses
rsl_get
"Get me a CDSM Article 4(3) signed receipt for that publisher's reservation state — set
jsonld: true." — usesrsl_getwith content negotiation
"Generate an EU AI Act Article 53 attestation JWT for our license
11111111-...covering the last 90 days. I need the artifact for our procurement audit committee." — usesarticle_53_attestation(requiresOPEDD_BUYER_JWT)
"This publisher just signed up:
https://noahpinion.substack.com. Which onboarding workflow should we use?" — usesdetect_platform
"Browse the finance category in the Opedd catalog — show me publishers with at least 50 articles." — uses
publisher_directory
"What's in my buyer account? Show me my active API keys." — uses
get_buyer_account(requiresOPEDD_BUYER_JWT)
The assistant will call the appropriate Opedd tools, show you the results, and—if you've pre-configured a payment method—can complete a purchase autonomously.
Purchases use Stripe by default (via pm_... payment method IDs). USDC on Tempo is also supported by the Opedd API — pass payment: { method: 'usdc', tx_hash: '0x...' } directly to agent-purchase if building a custom integration.
git clone https://github.com/Opedd/opedd-mcp
cd opedd-mcp
npm install
npm run dev # runs with tsx (no build step)
npm run build # compiles to dist/Opedd | Generic search APIs | |
What you get | Licensed content + license key + on-chain proof — all in one API call | Scraped web content, no rights |
Content delivery | Full article text via API (JSON) — bulk on flat-fee licenses, per-call (metered) on filtered licenses; real-time feed via webhooks | Scraped snippets or full-page dumps |
Content quality | Curated publisher content (niche B2B newsletters, expert analysis) | Whatever's on the open web |
Rights | Verifiable license key per article, publisher-authorized | No rights clearance |
Proof | On-chain (Tempo blockchain) — independently verifiable | None |
EU AI Act | Compliant — full training data provenance chain | No provenance |
Pricing | Publisher sets their own price per article | Platform decides |
Delivery modes | Per-article API, bulk feed (JSON firehose), buyer webhooks (push) | Query-response only |
Protocol | REST + MCP native | REST only |
Opedd is the licensed content delivery layer for AI — not just a licensing wrapper. Publishers upload content, you retrieve it via API with a license attached. One integration gives your pipeline both the content and the legal right to use it.
Opedd for AI Agents — full documentation, code examples, endpoint reference
API Docs — OpenAPI spec with agent endpoints
Opedd Registry — browse on-chain license proofs
MIT
Browse the public Opedd license registry. Returns recently issued licenses and licensable content. Filter by publisher_id to explore all content from a specific publisher. Filter by article_id to see all licenses issued for a specific article.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return (default: 10, max: 50) | |
| article_id | No | Filter results to a specific article (UUID) | |
| publisher_id | No | Filter results to a specific publisher (UUID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates the registry is public and the action is browsing (read-only), but does not explicitly confirm no side effects, rate limits, or authentication requirements. The description adds some context but lacks completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each serving a purpose. It front-loads the main function, then provides filter usage. No redundant or vague language.
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 should describe return values. It only says 'recently issued licenses and licensable content' without details on format, fields, or ordering. For a browsing tool with three parameters, the description is adequate but lacks output granularity.
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 practical use of publisher_id and article_id filters (exploring publisher content, viewing article licenses). The limit parameter is not elaborated, but the schema covers it well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool browses the public Opedd license registry, listing recent licenses and licensable content. It uses a specific verb and resource, and the purpose is distinct from sibling tools like purchase or verify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use filters (by publisher_id or article_id) with clear examples. It does not explicitly state when not to use the tool or list alternatives, but the context is sufficient for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect the content platform behind a URL via POST /detect-platform (Phase 12 Wave 3 W3.1). Public no-auth lookup. Given a URL, identifies what platform powers it (Substack / Beehiiv / Ghost / Medium / Brevo / custom) and returns the suggested onboarding workflow. Hostname-detectable platforms (Substack subdomain, Beehiiv suffix, etc.) resolve in milliseconds; custom domains may take ~few seconds while the detector probes well-known platform endpoints in parallel. Returns: {platform, confidence, archive_method, forward_method, required_credentials, instructions}. The archive_method + forward_method fields are the two onboarding-workflow inputs Opedd's setup wizard reads (one for historical content backfill, one for new-content forward stream). instructions is human-readable operator copy explaining the inferred path.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Publisher URL to inspect (any well-formed URL works; hostname-match short-circuits the probe path). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It reveals latency differences (milliseconds for hostname-detectable, seconds for custom domains) and describes the probing mechanism. However, it omits any rate limits or usage quotas.
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 moderately long but well-structured, starting with the core purpose and then adding details. Each sentence contributes useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description details all return fields ({platform, confidence, archive_method, forward_method, required_credentials, instructions}) and explains their roles. The input is simple. The tool is fully specified.
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% for the one parameter (url). The description adds value by explaining hostname-match short-circuits probing, which is not in the schema. This extra context gives the agent a better understanding of parameter 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?
The description clearly states the tool detects the content platform behind a URL, lists specific platforms (Substack, Beehiiv, etc.), and explains return values including onboarding workflow. It is distinct from sibling tools which deal with licenses and registry.
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 indicates it is a public no-auth lookup, implying use without authentication. It does not explicitly compare to siblings, but the sibling tools are sufficiently different that no confusion arises.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a piece of content on the Opedd registry by URL. Returns the article title, publisher, available license types, and pricing (human republication price and AI training/inference price). Always call this first to check if content is licensable and what it costs.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The canonical URL of the article or content to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. It discloses return values (title, publisher, license types, pricing) and implies a read-only, non-destructive operation. However, it does not discuss authentication, error handling, or side effects.
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-loads purpose and return values, and includes a usage directive. Every sentence adds value with no redundancy or 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 one parameter and no output schema, the description adequately lists return fields. It lacks error information or handling of unknown URLs, but is otherwise complete for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds little beyond the schema's 'The canonical URL of the article or content to look up.' The only added nuance is specifying that the URL is canonical, which provides minimal extra meaning.
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: 'Look up a piece of content on the Opedd registry by URL.' It specifies the verb (look up), resource (content), and scope (by URL), and distinguishes from siblings like browse_registry and detect_platform which do different operations.
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 'Always call this first to check if content is licensable and what it costs,' providing clear when-to-use guidance. It implies this is a prerequisite before purchasing licenses but does not explicitly state when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse the public Opedd publisher catalog via GET /publisher-directory. Returns paginated publishers with article counts, pricing (per-article + annual + monthly-forward-feed), plan, and sample articles (RAG-extended metadata). The primary discovery surface for AI labs to find Opedd-licensable publishers — distinct from browse_registry (which lists issued LICENSES, not publishers). Filter by category (case-insensitive substring), min_articles, or verified status. Public no-auth — useful pre-purchase scoping before buyers commit to enterprise-license POST.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size cap. | |
| offset | No | Pagination offset. | |
| category | No | Case-insensitive substring filter on publisher category (e.g. 'finance', 'AI'). | |
| verified | No | 'true' to show only verified publishers (default), 'false' for unverified. | |
| min_articles | No | Filter to publishers with at least this many licensable articles. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. Reveals HTTP GET, public access, and return fields (pagination, counts, pricing, sample articles). Lacks mention of rate limits or caching but adequate for a browse 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?
Two concise sentences plus filter note. Front-loaded with endpoint and value proposition. Every sentence adds necessary info without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations. Description explains return content (publishers with pricing, samples), pagination, filters, and auth status. Could mention default pagination values or error handling, but sufficient for a browse tool with 5 params.
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 100% (baseline 3). Description adds context: category is case-insensitive substring, min_articles filters by licensable articles, verified defaults to 'true'. Adds value beyond 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?
Description specifies verb 'Browse' and resource 'public Opedd publisher catalog' via endpoint. Clearly distinguishes from sibling 'browse_registry' which lists licenses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states primary use: 'discovery surface for AI labs to find Opedd-licensable publishers'. Contrasts with browse_registry (licenses). Notes public no-auth for pre-purchase scoping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Purchase a bulk enterprise license covering multiple publishers (Phase 10). Returns a Stripe client_secret for payment completion + the enterprise_license_id. After payment, an ent_* access key is emailed to buyer_email. Scopes: 'custom' (pass-through publisher_ids), 'platform_wide' (auto-resolve all opted-in publishers), 'filtered' (Phase 10 filter_rules). License tiers: 'rag' (= ai_retrieval), 'training' (= ai_training, flat-fee not metered), 'inference' (= ai_retrieval), 'full_ai' (writes both retrieval + training records).
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Coverage scope (default: custom) | |
| buyer_org | Yes | Buyer organization name (for billing + audit ledger) | |
| buyer_email | Yes | Email to deliver the access key after payment | |
| billing_type | No | Billing cadence (default: annual) | |
| filter_rules | No | Required when scope='filtered'. See Phase 10 docs for shape: excluded_publisher_ids / direct_license_carveouts / categories / max_price_per_event. | |
| license_tier | No | License tier (default: rag) | |
| publisher_ids | Yes | Array of publisher UUIDs. Required for scope='custom'; ignored for platform_wide/filtered (resolved server-side). | |
| duration_months | No | License duration in months (default: 12) | |
| buyer_webhook_url | No | Optional HMAC-signed webhook for content.published events on covered publishers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description covers the flow (Stripe client secret, emailed key), scope/tier behaviors, and mapping equivalents. Could add auth or rate limit notes.
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?
Single paragraph with bullet-like lists for scopes and tiers; front-loaded purpose, but could use more structured formatting.
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 9 params and nested object, description covers return value, key delivery, scope/tier options, and references Phase 10 docs for filter_rules. Lacks output schema but mentions return contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. Description adds value by explaining scope/tier enums and clarifying when publisher_ids is required vs ignored.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly specifies it purchases a bulk enterprise license covering multiple publishers, distinct from sibling purchase_license. Mentions return values and key mapping.
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?
Implicitly distinguishes from purchase_license via 'bulk enterprise' wording and explains scopes and tiers to guide selection, but lacks explicit 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.
Purchase a content license from the Opedd protocol using a Stripe payment method. Returns a license key (format: OP-XXXX-XXXX) and a certificate URL. The buyer receives a Handshake Email with their license key. Set OPEDD_BUYER_EMAIL and OPEDD_PAYMENT_METHOD_ID env vars to avoid passing them on every call. License types: 'human' = republication rights, 'ai' = training dataset rights, 'ai_inference' = inference/RAG rights.
| Name | Required | Description | Default |
|---|---|---|---|
| article_id | No | Opedd article UUID (use this OR article_url) | |
| buyer_name | No | Full name of the buyer (for the license record and certificate) | |
| article_url | No | URL of the article to license (use this OR article_id) | |
| buyer_email | No | Email address for the license. Falls back to OPEDD_BUYER_EMAIL env var. | |
| intended_use | No | Intended use of the licensed content | |
| license_type | Yes | human = republication/editorial rights, ai = training dataset rights, ai_inference = inference/RAG rights | |
| payment_method_id | No | Stripe payment method ID (pm_...). Falls back to OPEDD_PAYMENT_METHOD_ID env var. | |
| buyer_organization | No | Organization or company name (for enterprise/editorial licenses) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return values (license key, certificate URL), side effect (Handshake Email), and license types. It does not mention payment charges or destructive nature, but overall 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?
Two sentences plus a bullet-like list. Concise and front-loaded with the main purpose. The list of license types is dense but efficient. Slight improvement could be structuring the list better.
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 8 params and no output schema, description covers key outputs, env vars, and license types. It could clarify article_id/article_url exclusivity and payment flow, but it's reasonably complete for a purchase tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by explaining env var fallbacks, license type meanings, and the license key format. This goes beyond schema 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 states the tool purchases a content license from the Opedd protocol using Stripe. It specifies the resource and action, and distinguishes from siblings like purchase_enterprise_license and verify_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 explains when to use the tool (purchasing a standard license) and mentions environment variable fallbacks for convenience. It could explicitly mention when to use purchase_enterprise_license instead, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a publisher's RSL Standard manifest via GET /rsl-manifest (Phase 12 Wave 1 W1.1). Public no-auth endpoint — discovery surface for AI agents/crawlers wanting to know what's licensable from a publisher BEFORE going through the buyer-account signup flow. Returns the 4 canonical license types (ai_retrieval, ai_training, human_per_article, human_full_archive) the publisher has opted into, plus the EU CDSM Article 4(3) opt-out posture (tdm_reservation). Set jsonld: true to request the JSON-LD shape with embedded HMAC-SHA256 signed receipt over the CDSM Article 4(3) reservation state + tdm:reservationSignedAt timestamp — regulators can post-hoc verify the reservation was the claimed value at the claimed time. Default jsonld: false returns the raw RSL Standard JSON manifest. Per INVARIANTS.md W1.6: this is the PUBLISHER-side CDSM Article 4(3) declaration surface. It is NOT an EU AI Act Article 53 attestation (which is buyer-side, JWT-auth, via article_53_attestation tool).
| Name | Required | Description | Default |
|---|---|---|---|
| jsonld | No | If true, request JSON-LD shape (Accept: application/ld+json) with embedded HMAC-SHA256 signed receipt. Default false returns raw RSL Standard JSON shape. | |
| publisher_id | Yes | UUID of the publisher whose RSL manifest to fetch. Publisher must be verified. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: public no-auth endpoint, returns 4 license types and tdm_reservation posture, explains jsonld parameter effect for signed receipt, and mentions Phase 12 and INVARIANTS.md for further 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?
Well-structured and front-loaded with main purpose, but slightly verbose with references to Phase 12 and INVARIANTS.md; every sentence adds value but could be trimmed slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description explains response contents (4 license types, tdm_reservation), jsonld variants, and external verification mechanism. Complete for a 2-param tool with no annotations.
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%, and the description adds meaning beyond schema: explains jsonld's purpose (signed receipt for verification) and notes publisher must be verified for publisher_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool fetches a publisher's RSL Standard manifest via a specific endpoint. It distinguishes from sibling tools by mentioning the EU AI Act Article 53 attestation tool, and the sibling list (browse_registry, lookup_content, etc.) further clarifies its unique 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?
Explicitly states the tool is a discovery surface for AI agents/crawlers to use before buyer-account signup, and contrasts with the buyer-side article_53_attestation tool, providing clear when-to-use and when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the authenticity of an Opedd license key. Returns license details including: article title, publisher, license type, issue date, amount paid, buyer info, and blockchain proof status. Use this to confirm a license is valid before using licensed content.
| Name | Required | Description | Default |
|---|---|---|---|
| license_key | Yes | The license key to verify (format: OP-XXXX-XXXX) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions returning license details but doesn't confirm read-only behavior or side effects. Adequate but not comprehensive.
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?
Extremely concise: two sentences plus a list. Every sentence adds value. Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single parameter, no output schema, and no annotations, the description is fairly complete. Covers purpose, usage, and return fields. Minor gaps in behavioral details.
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 covers 100% of the parameter with format hint. Description adds return fields but little additional parameter semantics. Baseline score 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?
Description clearly states the tool verifies an Opedd license key. It distinguishes from siblings like purchase_license and browse_registry by focusing on verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use 'before using licensed content'. While it doesn't mention when not to use or alternatives, the context is clear and sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: browsing registry vs. publisher directory, detecting platform, looking up content, purchasing (enterprise vs. single), fetching RSL manifest, and verifying licenses. No overlapping functionality.
All tool names follow a consistent verb_noun snake_case pattern (e.g., browse_registry, detect_platform, purchase_license). Even 'rsl_get' fits the verb_noun pattern with an abbreviation.
With 8 tools, the server is well-scoped for its purpose of license registry management, covering discovery, purchase, verification, and platform detection without being excessive or minimal.
The tool surface covers the main lifecycle: browsing, searching, purchasing (individual and enterprise), verifying, and fetching manifests. Minor gap: no tool to list or manage purchased licenses for a buyer, but core workflows are covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
100+ MCP tools for AI agents: content metadata, trade intelligence, business-expertise analysis.
Verified, sourced, real-time intelligence layer for AI agents.
15 media & data tools for AI agents: search, transcribe, subtitles, voiceover, translate & more.
Viral-content intelligence for AI agents — 7 read-only MCP tools, evidence-layer scoring.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Opedd/opedd-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
