FeedKeeper RSS/Atom reader and remote MCP Server

Publish curated newspaper edition

publish_edition

Publishes an ordered selection of 1 to 24 article IDs as the user's official curated edition, optionally with title, summary, layout, and expiry.

Instructions

Publishes an ordered selection of 1 to 24 article IDs as the user's official curated edition ('Deine Zeitung'). The published edition remains available until the next edition is published or expires. Pass the revision from get_edition as expectedRevision for optimistic concurrency, and a UUID requestId for idempotent retries. Does NOT alter underlying articles. Requires write scope.

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": {
      "itemIds": "<itemIds>"
    },
    "name": "publish_edition"
  }
}

Input Schema

Name	Required	Description
`title`	No	Optional editorial headline for this edition (e.g. 'Monday Morning Briefing')
`layout`	No	Optional visual layout specification (character and editorial blocks)
`itemIds`	Yes	Ordered list of 1 to 24 article IDs to include in this edition
`summary`	No	Optional editorial summary or introduction text for the edition
`overview`	No	Optional structured briefing sections grouping items with editorial commentary
`expiresAt`	No	ISO datetime when this edition expires and a new issue is due (max 7 days)
`requestId`	No	Idempotency key (UUID v4) to safely retry publication without duplicate processing
`durationHours`	No	Duration in hours until this edition expires (1 to 168 hours, default: 24)
`expectedRevision`	No	The revision from get_edition to ensure optimistic concurrency and avoid conflicts

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.36.4Nov 9, 2026

addedInput schema / properties / durationHours / description

Added value: +"Duration in hours until this edition expires (1 to 168 hours, default: 24)"

addedInput schema / properties / expectedRevision / description

Added value: +"The revision from get_edition to ensure optimistic concurrency and avoid conflicts"

addedInput schema / properties / expiresAt / description

Added value: +"ISO datetime when this edition expires and a new issue is due (max 7 days)"

addedInput schema / properties / itemIds / description

Added value: +"Ordered list of 1 to 24 article IDs to include in this edition"

addedInput schema / properties / layout / description

Added value: +"Optional visual layout specification (character and editorial blocks)"

addedInput schema / properties / overview / description

Added value: +"Optional structured briefing sections grouping items with editorial commentary"

addedInput schema / properties / requestId / description

Added value: +"Idempotency key (UUID v4) to safely retry publication without duplicate processing"

addedInput schema / properties / summary / description

Added value: +"Optional editorial summary or introduction text for the edition"

addedInput schema / properties / title / description

Added value: +"Optional editorial headline for this edition (e.g. 'Monday Morning Briefing')"

First observedv0.36.3Nov 9, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses lifecycle behavior (edition persists until the next publication or expiry), non-destructiveness ('Does NOT alter underlying articles'), the write-scope requirement, and optimistic-concurrency/idempotency semantics. It omits what happens on a revision conflict or what the call returns, which keeps it below a 5.

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 dense sentences, front-loaded with the core action and followed by lifecycle, concurrency, and scope constraints in a sensible order. No filler, though the concurrency/idempotency sentence packs two distinct concepts together.

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 9-parameter tool with nested layout/overview objects and no annotations, the description covers purpose, lifecycle, auth, and concurrency adequately. The remaining gap is response/error behavior — notably what a stale-revision conflict yields — which an agent would need to recover gracefully, and no output schema exists to fill that in.

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 baseline is 3; itemIds, expectedRevision, and requestId are all already documented in the schema with essentially the same meaning. The description adds workflow context (revision comes from get_edition) but says nothing about layout, overview, summary, expiresAt, or durationHours beyond what the schema provides.

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 (publishes) and resource (an ordered selection of 1 to 24 article IDs as the user's official curated edition), plus the named edition concept 'Deine Zeitung'. This clearly separates it from siblings like get_edition, get_edition_candidates, and dismiss_edition.

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 tells the agent to obtain the revision from get_edition and pass it as expectedRevision, and to supply a UUID requestId for idempotent retries — concrete workflow guidance. It stops short of saying when to publish versus when to inspect candidates or dismiss an edition, so it is strong context without full alternative routing.

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