Lists locally cached Feedbin entries from SQLite with optional feed, title search, and result limits, returning truncated HTML without making an API call.
List cached entries from SQLite. Optional feed_id, title search, limit. HTML truncated to 500 chars. No API call.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| search | No | ||
| feed_id | No |
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 does carry useful behavioral detail: results come from a local SQLite cache, no network request occurs, and HTML bodies are truncated to 500 chars. It omits cache-freshness semantics (whether stale data is returned, how the cache is populated/refreshed) and default/bound behavior, which matter for a cache-backed read.
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?
Four short sentences, front-loaded with the resource and source of truth, then parameters, then the truncation caveat. Nothing is padding; every clause contributes.
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?
No output schema and no annotations means the description bears full disclosure burden, and it stops short: nothing about returned entry fields, ordering, or what an empty/stale cache result looks like. For a three-parameter list tool this is adequate but incomplete.
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 only partly does: it names all three parameters and hints that feed_id and search are optional filters and that search matches titles. It does not specify the default limit of 50, any maximum, or whether search is substring vs. case-insensitive, so a quarter of the semantics remain undocumented.
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 ("List cached entries from SQLite") and implicitly distinguishes itself from the live-API siblings via "No API call." An agent can tell this reads from a local cache rather than Feedbin's API, though the sibling it contrasts with (feedbin_list_entries) is never named.
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 API call" implies this is the cheap/offline option, but the description never states when to prefer it over feedbin_list_entries, feedbin_list_feed_entries, or the single-entry feedbin_cached_entry. Usage is inferable rather than declared, and no exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.