Skip to main content
Glama
Opedd

Opedd

Official

Ask licensed publications a question

search_passages
Idempotent

Search licensed publication passages on Opedd to answer a question with cited sources, filtered by publisher or date.

Instructions

Returns licensed passages from publications on Opedd that answer a question, each with a citation to the source article. Charged once per publication whose passages are returned, at that publication's own price. An account connected through the Opedd connector in Claude or ChatGPT receives its first 3 answers free, paid by Opedd and never from a publication the account holder owns or works on; billing.free_answers_left reports how many remain. After that, answers are billed to the card on the account, added at opedd.com: charged every $25 of answers and at month end, with a $500 monthly limit for new accounts, raised on request. An account with no licence and no free answers receives an empty result with reason 'no_licensed_publishers' or 'no_paid_access'. Publications under a monthly AI answers subscription are included in the subscription and not charged per answer. Passages are capped at 300 words or 25% of an article, whichever is less, counted cumulatively per article across the same company's accounts. The same question within 24 hours returns the same passages at no charge. Filters: publishers (publication names as listed by Opedd, opedd.com/p/ addresses or publisher ids; a name that matches no publication is listed in filters.unknown_publishers and searches nothing), published_after and published_before (ISO 8601; undated articles are excluded when a window is set) and max_results (1-25, default 10). Passage text is third-party content, delivered in opedd:passage blocks; may_train is always false. Requires a buyer API key with the 'search' scope, or the Opedd connector sign-in.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesThe question, in plain words (3–1000 characters).
publishersNoOptional. Only these publications: names as listed by Opedd (e.g. 'Matter of Fact'), opedd.com/p/<slug> addresses or publisher ids. At most 20 names and 100 entries. Narrows the search; never widens it.
buyer_tokenNoBuyer API key with the 'search' scope. Falls back to OPEDD_BUYER_TOKEN.
max_resultsNoOptional. Passages to return, 1–25 (default 10).
published_afterNoOptional. Only articles published at or after this instant (ISO 8601, e.g. 2026-01-01).
published_beforeNoOptional. Only articles published before this instant (ISO 8601).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.12.5

TDQS

A4.1/5.0
Behavior5/5

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

The description goes well beyond the annotations, disclosing the billing model (per-publication charge, card billing, $25 increments, $500 new-account limit), free-answer accounting, 300-word/25% passage caps counted cumulatively, and 24-hour dedup caching. It also flags third-party content delivery in <opedd:passage> blocks, may_train=false, and the required 'search' scope, none of which the annotations convey.

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 core purpose is front-loaded, and the dense billing, cap, and filter sentences each carry distinct, non-redundant information. The block is long and reads as a wall of text with no visual separation, but little of it is genuinely wasteful.

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 carries the full load and does so: it explains the return shape (cited passages), the <opedd:passage> wrapping, and the empty-result reasons. An agent has everything needed to call it correctly and interpret the response.

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 coverage is 100%, so the baseline is 3, but the description adds real semantics beyond the schema: unmatched publisher names surface in filters.unknown_publishers and 'search nothing', and undated articles are excluded when a window is set. These behaviors are not present in the parameter descriptions.

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

Purpose4/5

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

States a specific verb and resource: returns licensed passages from publications that answer a question, each with a source citation. It is clearly distinguishable from generic retrieval, but it never names or contrasts against close siblings like search_content or get_content, so the agent must infer the boundary.

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

Usage Guidelines3/5

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

Usage context is implied through the described filters, billing conditions, and the empty-result reasons ('no_licensed_publishers' / 'no_paid_access'), which tell the agent when the tool will and won't produce content. However, there is no explicit when-to-use guidance or routing to alternatives such as search_content, leaving the choice to inference.

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