Opedd

Official

by Opedd

Overview Schema Related Servers Score Discussions

JavaScript

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.6.7
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.3/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 32 commits in the last 12 weeks
- Last stable release on May 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![opedd-mcp MCP server](https://glama.ai/mcp/servers/Opedd/opedd-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Opedd/opedd-mcp)

Score Badge

Copy to your README.md:

[![opedd-mcp MCP server](https://glama.ai/mcp/servers/Opedd/opedd-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Opedd/opedd-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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