Skip to main content
Glama
Opedd

Opedd

Official

Publish or update your articles

push_content
DestructiveIdempotent

Send published articles to Opedd for licensing to AI buyers: submit 1–100 per call with title, URL, and HTML body to onboard archives or add new content from an AI assistant.

Instructions

Push your published articles to Opedd so they can be licensed to AI buyers (requires OPEDD_PUB_BEARER — your opedd_sk_ publisher key). Send 1–100 articles per call; batch larger back-catalogues into multiple calls. Each article needs title, url, and html_body — everything else is optional (published_at defaults to now). This is the supply-side companion to list_publisher_content: use it to onboard your archive or push new content with no code, straight from your AI assistant.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
articlesYes1–100 articles to push in this call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.12.5

TDQS

A4/5.0
Behavior4/5

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

Adds real context beyond the annotations: the required bearer credential (OPEDD_PUB_BEARER / opedd_sk_ publisher key), the 1–100 batch ceiling, and the minimal required fields with published_at defaulting to now. It does not, however, explain the update-on-conflict behavior implied by the title 'Publish or update' and by destructiveHint=true / idempotentHint=true, so the consequence of re-pushing an existing article remains unstated.

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?

Four compact sentences, front-loaded with the action and destination, then credentials, then batching limits. Every sentence carries operational information; only the closing 'no code, straight from your AI assistant' clause is marketing filler.

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?

There is no output schema, so the description should cover the return contract for a batch operation — e.g. whether results are per-article, how partial failures are reported, and whether re-pushing overwrites. Those are unaddressed, leaving a real gap for a destructive, batch, non-idempotent-looking write even though auth and limits are well covered.

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% and the schema already documents the array bounds, required fields, published_at default, and every optional field. The description restates the required trio and the default rather than adding format or constraint detail, so the baseline 3 is 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?

States a specific verb and resource ('Push your published articles to Opedd') plus the downstream purpose ('licensed to AI buyers'). It explicitly positions itself against the sibling list_publisher_content, so an agent can separate supply-side push from read-side listing 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 Guidelines4/5

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

Gives concrete conditions: onboard an archive, push new content, batch back-catalogues into multiple calls when over 100 articles. Names the companion tool list_publisher_content. It stops short of stating when not to use it or what to do if an article already exists.

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