Opedd — Licensed Content for AI

Read a licensed article

get_content

Read-onlyIdempotent

Retrieve the full body of a licensed article using a buyer API token (opedd_buyer_live_* canonical; opedd_buyer_test_* for sandbox). Requires OPEDD_BUYER_TOKEN env var (create one at opedd.com/licenses after purchasing). Works for licence orders (and for Human republication licences bought before it was retired on 2026-10-26): AI answers monthly and client display return full text. Your self-serve buyer API key reads articles under every order your account holds — no separate order token is needed. AI answers pay-per-request (including the self-serve licence) does NOT retrieve articles: it answers 403 SEARCH_ONLY_LICENCE — ask a question with search_passages instead. Articles the publisher stopped licensing answer 403 ARTICLE_EXCLUDED. The publisher must have content delivery enabled and must have pushed content for the article. The response includes author, language, word_count, content_hash, image_urls, canonical_url and tags. On pre-2026-05-14 historical articles, optional fields (author/language/image_urls/canonical_url/tags) may be NULL. NULL means the data is unavailable for this article, not that it is empty.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "article_id": "<article_id>"
    },
    "name": "get_content"
  }
}

Input Schema

Name	Required	Description	Default
`article_id`	Yes	The Opedd article UUID to retrieve content for
`buyer_token`	No	Buyer API token (opedd_buyer_live_* or opedd_buyer_test_*). Falls back to OPEDD_BUYER_TOKEN env var.

Schema Changelog

Changes observed during successful MCP inspections.

First observedJul 11, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and nothing in the description contradicts that. The description still adds real value beyond them: token prefixes for live vs sandbox, the OPEDD_BUYER_TOKEN env fallback, the fact that one account-level key covers every order without a per-order token, and the specific 403 codes with their meanings. That is strong supplemental behaviour disclosure despite the annotation coverage.

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

Conciseness4/5

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

The capability statement and entitlement rule are front-loaded and the failure modes are grouped logically at the end. It is dense rather than padded, though the Human-republication parenthetical on the retired 2026-10-26 cut-off is a niche detail that lengthens the read for the common case.

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

Completeness5/5

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

With no output schema, the description enumerates the returned fields (author, language, word_count, content_hash, image_urls, canonical_url, tags) and pre-empts the most likely misinterpretation by explaining that NULL on pre-2026-05-14 articles means unavailable, not empty. Auth setup, entitlement scope, and error paths are all covered for a two-parameter read tool.

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

Parameters4/5

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, but the description earns above it: it explains the token prefix convention (opedd_buyer_live_* canonical, opedd_buyer_test_* sandbox), the env-var fallback chain, and crucially that the self-serve key is not order-scoped — semantics an agent could not infer from the schema. It adds little for article_id beyond the schema's UUID note.

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

Purpose5/5

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

The first sentence states a specific verb and resource ('Retrieve the full body of a licensed article') and immediately scopes it to buyer-token entitlements. It also distinguishes itself from the nearest sibling by naming search_passages as the tool to use when a licence is search-only, so an agent can route correctly without opening either schema.

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

Usage Guidelines5/5

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

It gives explicit when-to-use conditions (licence orders, AI answers monthly, client display), explicit when-not conditions with the exact failure signal (403 SEARCH_ONLY_LICENCE → use search_passages instead), plus an exclusion for retired Human republication licences and a 403 ARTICLE_EXCLUDED case. Prerequisites (publisher content delivery enabled, content pushed) are stated rather than left implicit.

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

All Opedd — Licensed Content for AI tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.