Skip to main content
Glama
Opedd

Opedd

Official
by Opedd
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List a licence order's articles

list_feed
Read-onlyIdempotent

List articles from a licensed catalog as a paginated JSON feed. Poll for new content using an ISO 8601 since timestamp or page through results with a cursor.

Instructions

List articles from a buyer's licensed catalog via GET /enterprise-license (Phase 10 + 11). Content contract: AI training orders include full content_body for the back catalogue up to the order date (content_access 'included'). Every other order is discovery-only (content_body null): AI answers monthly and client display fetch text per article via get_content (content_access 'retrieval_per_article'); pay-per-request fetches billed snippets via get_content (content_access 'metered_per_call'). Returns JSON-format response with paginated articles. Use since (ISO 8601) for delta-feed polling — only articles published after the timestamp. Use cursor for pagination across pages. Credentials: the order's enterprise access key (OPEDD_ACCESS_KEY, ent_*) OR your buyer API key (OPEDD_BUYER_TOKEN) with order_id — if your account holds exactly one active order, order_id may be omitted; with several, the error lists them. For larger bulk corpus pulls, use stream_feed_ndjson (up to 1000 articles per call vs 200 here).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax articles per response (default: 50, max: 200)
sinceNoISO 8601 timestamp — return only articles with published_at > since
cursorNoOpaque cursor from the prior response's data.pagination.next_cursor
order_idNoThe licence order to list (UUID, from list_licence_orders). Used with a buyer API key; ignored with an ent_* key.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.12.5

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. It adds real behavioral context beyond the annotations: the content contract per order type (included/discovery-only/metered), null content_body semantics, pagination, and delta-feed polling. It does not describe pagination mechanics such as next_cursor shape, but the schema covers cursor.

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

Conciseness3/5

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

Each sentence earns its place with contract and routing info, but the description is dense and front-loads implementation detail ('Phase 10 + 11') that does not help an agent select or invoke the tool. It is information-rich but could be trimmed.

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

Completeness4/5

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

For a read-only, paginated list tool with a 100%-covered schema and annotations, the description is complete enough: it covers content access modes, auth, pagination, and bulk alternatives. The only gap is inherit return-shape detail for the 'included' content contract, which is minor.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all four parameters well. The description reinforces since, cursor, and order_id semantics, but the schema is doing the heavy lifting; baseline 3 applies.

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 description opens with a specific verb and resource ('List articles from a buyer's licensed catalog') and even cites the endpoint. It explicitly distinguishes itself from stream_feed_ndjson and get_content, so an agent can tell what this tool does versus its siblings.

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 names the alternatives and the conditions that select them: get_content for per-article text, stream_feed_ndjson for bulk pulls over 200 articles. It also gives credential/order_id prerequisites and the omittable-order_id case, leaving little to inference.

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

Deploy Server

Other Tools