Add entry IDs to Feedbin's recently read list to record which articles you've opened and keep read state in sync.
Add entry ids to recently read. Mutates Feedbin state.
| Name | Required | Description | Default |
|---|---|---|---|
| entry_ids | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. 'Mutates Feedbin state' usefully flags that this is a write operation, but it does not disclose idempotency, whether existing recently-read entries are replaced or appended, permission/auth requirements, or whether read counts are affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, mutation fact front-loaded after the action statement, with no filler. Brevity is appropriate, though the second sentence is the only place behavior is mentioned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A one-parameter mutation tool with no annotations and no output schema needs the description to cover return behavior and side effects; neither is addressed. The agent knows it writes state but not what it gets back or how errors surface.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate and it largely does not. Naming 'entry ids' matches the schema's entry_ids array of integers but adds no batch limits, validity constraints, or behavior for unknown ids.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Add entry ids to recently read,' so the agent knows exactly what changes. It does not distinguish this from close siblings like feedbin_mark_read or feedbin_list_recently_read, leaving ambiguity about how 'recently read' differs from 'read' status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus feedbin_mark_read or feedbin_list_recently_read, and no preconditions stated. The agent must infer the use case from the sibling list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.