FeedKeeper RSS/Atom reader and remote MCP Server

Get single article content and metadata

get_item

Read a single subscribed article's metadata and stored HTML or plain text by numeric itemId; paginate large content with offset and revision, and call fetch_full_text when only an RSS teaser exists.

Instructions

Returns full metadata and stored content (HTML or plain text) for a single subscribed article by its numeric itemId. Content is chunked at 40,000 characters; use offset and content.revision to paginate large articles. If an article only has an RSS teaser/summary and full web text is desired, call fetch_full_text.

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": {
      "itemId": "<itemId>"
    },
    "name": "get_item"
  }
}

Input Schema

Name	Required	Description
`format`	No	Format of content: 'html' for sanitized HTML, 'text' for plain text extraction
`itemId`	Yes	The numeric ID of the article to retrieve
`offset`	No	Character offset for reading subsequent chunks of large articles
`maxChars`	No	Maximum character length of content to return (up to 40,000)
`revision`	No	Revision token returned in previous chunk to ensure pagination consistency

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.36.4Nov 9, 2026

changedInput schema / properties / format / description

Previous value: -"Use text to read plain publisher text without HTML markup"New value: +"Format of content: 'html' for sanitized HTML, 'text' for plain text extraction"

addedInput schema / properties / itemId / description

Added value: +"The numeric ID of the article to retrieve"

changedInput schema / properties / maxChars / description

Previous value: -"Shorten the content to this many characters"New value: +"Maximum character length of content to return (up to 40,000)"

addedInput schema / properties / offset / description

Added value: +"Character offset for reading subsequent chunks of large articles"

changedInput schema / properties / revision / description

Previous value: -"Keep pagination on the same content revision"New value: +"Revision token returned in previous chunk to ensure pagination consistency"

First observedv0.36.3Nov 9, 2026

TDQS

A4.6/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 that content is chunked at 40,000 characters, that pagination requires offset plus a revision token for consistency, and that stored content may be only a teaser. It does not cover failure behavior (invalid or unsubscribed itemId) or whether reads have side effects such as marking read, which leaves a real gap for a mutation-free but state-touching 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?

Three sentences, front-loaded with what is returned, then pagination, then the alternative-tool escape hatch. No redundant restatement of the name or schema fields; every sentence adds information an agent would otherwise have to infer.

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 exists, and the description compensates by describing the return payload (full metadata plus HTML or plain-text content) and its chunked shape. What remains thin is error and edge-case behavior, but for a single-record read tool with fully documented parameters this is close to sufficient.

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 meaning beyond the schema by explaining the relationship between offset, revision, and the 40,000-character chunk size as a coherent pagination protocol rather than three isolated integers. It also frames itemId as belonging to a subscribed article, which the schema does not say.

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 ('Returns full metadata and stored content ... for a single subscribed article') plus the identifier type (numeric itemId) and the content formats. It is clearly distinguishable from list-oriented siblings such as list_items and search_items, and it names fetch_full_text as the different tool for a different need.

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?

Gives an explicit routing rule to an alternative: if the article only has an RSS teaser and full web text is wanted, call fetch_full_text. It also states the internal pagination procedure (use offset and content.revision for large articles), so an agent knows both when to pick this tool and how to iterate with it.

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