Does 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.

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

With zero annotations, the description carries the full burden, and it does disclose two real behavioral traits: no network call and full (not truncated) content. It omits important behavior such as what happens when entry_id is not present in the cache (error vs. empty), and whether output mirrors the API entry shape.

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 fragments, front-loaded with the action and immediately followed by the most decision-relevant fact (no API call). It earns its words, though the telegraphic style leaves connecting logic implicit rather than stated.

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?

For a one-parameter lookup with no output schema and no annotations, the essentials are present but gaps remain: cache-miss behavior and how to source entry_id are undocumented. Adequate to attempt a call, not adequate to call it confidently in edge cases.

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% for the single entry_id parameter, so the description must compensate and it does not. It never says what an entry_id is, where to obtain one (e.g., from feedbin_list_entries or feedbin_list_cached_entries), or that it is the Feedbin entry identifier rather than a cache row id.

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 ('Return one cached entry') and adds scope ('from SQLite only. No Feedbin API call. Full content.'), which separates it from the live-fetch sibling feedbin_get_entry. It stops short of naming that sibling explicitly, but the cached-vs-live distinction is clear.

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?

'from SQLite only. No Feedbin API call.' implies the usage condition (avoid an API round-trip / offline access), and the 'Full content' note hints at why you'd pick it over a list tool. However, there is no explicit statement of when to use this versus feedbin_get_entry, nor any prerequisite or failure-mode guidance.

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

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

No annotations are provided, so the description carries the full burden. 'Return' signals a non-mutating operation and the three disclosed fields give useful shape to the result (including the on-disk SQLite path, which hints it reads a local store), but nothing is said about auth requirements, cost, or side effects of triggering a poll-time 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?

One sentence, front-loaded with the verb and the three returned values. No preamble, no filler — every word carries information.

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?

With no output schema and no annotations, the description compensates by enumerating the three returned values, which is enough for an agent to know what it gets back. The remaining gap is the absence of any note on when to call it versus the other cache tools, which is minor for a zero-argument read.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; per the baseline, a no-param tool starts at 4. The description does not need to add parameter detail and correctly avoids inventing any.

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 ('Return') plus the exact contents returned: cached entry count, SQLite path, and last poll time. It is clearly distinguishable from the sibling cache tools (feedbin_cached_entry, feedbin_list_cached_entries) because they return entries while this returns aggregate stats. It stops short of explicitly framing itself as a diagnostic check.

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?

The mention of 'last poll time' and the cached count implies a diagnostic/health-check use case, but there is no explicit when-to-use statement and no mention of the alternative cache-inspection tools (feedbin_list_cached_entries) or when this should be preferred over them.

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

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

No annotations are provided, so the description carries the burden. It does convey via 'GET' that this is a non-mutating read, but it does not state whether the call raises an error or returns a boolean/status on invalid credentials, nor anything about side effects or rate limits. Adequate but not rich.

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?

A single front-loaded sentence with no filler. It would be hard to say less while still identifying the operation and the underlying endpoint.

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?

For a zero-parameter, read-only check with an output schema present and 100% schema coverage, the description covers what the tool does and where it maps. The only missing piece is failure behavior, which the output schema likely partially resolves.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Nothing in the description misleads about inputs.

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 ('Check Feedbin credentials') and pins it to the exact endpoint (GET /v2/authentication.json), so an agent knows precisely what is verified. It is unambiguous, though it lacks explicit contrast with sibling tools (which is mostly unnecessary since no sibling does auth checking).

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?

Usage is only implied: an agent can infer this is the credential-validation call, but the description never says when to call it (e.g., before a batch of operations, after a credential error) or what to do with an invalid result. No alternatives exist to name, so the gap is modest but real.

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

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

No annotations are provided, so the description carries the full burden. It does flag that this mutates Feedbin state, but it says nothing about permissions, whether the import runs asynchronously, whether it adds to or replaces existing subscriptions, or what the response contains.

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?

Three short, front-loaded sentences with no filler, and the mutation warning sits right after the purpose statement. It is efficient, though the terseness edges toward under-specification rather than tight completeness.

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?

For a state-mutating tool with no annotations, no output schema, and an undocumented parameter, the description is too thin. An agent still lacks the async/polling workflow and any statement of what an OPML import actually changes in the account.

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?

The single parameter opml_xml has 0% schema description coverage, so the schema offers only the name and type. 'Body is XML' confirms the string is raw OPML markup, which is a small but real addition; there is no detail on expected OPML structure, size limits, or encoding.

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 ('Create an OPML import'), which is unambiguous and clearly distinct from the read-oriented siblings list_imports and get_import. It stops short of naming those siblings as the follow-up path, so it earns a 4 rather than a 5.

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?

There is no guidance on when to use this versus list_imports or get_import, nor any note that an import is processed asynchronously and must be polled. The only implied usage comes from the verb 'Create', leaving the agent to infer the workflow.

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

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

With no annotations, the description carries the full behavioral burden. "Mutates Feedbin state" is better than nothing, but it restates what "create" already implies and reveals nothing about validation of the query, whether duplicates are allowed, whether the response returns the new ID, or error/permission behavior.

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 with zero filler and the purpose front-loaded. The size is appropriate for the dimension, though the second sentence adds little information.

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 write operation with zero annotations, no output schema, and two entirely undocumented parameters. The description should at minimum explain the query parameter's format and whether the created resource is returned; it does neither.

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% and both required parameters (name, query) are completely undocumented. The description does not explain what "name" means (a label?), nor does it give any hint about the query syntax, which is critical for a search tool.

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+resource ("Create a saved search") that an agent can distinguish from list/get/update/delete saved search siblings. It does not explicitly name the siblings or scope the operation further, but the core purpose is unambiguous.

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 create a saved search versus using a query directly, no prerequisites, and no mention of the read-oriented siblings. The agent is left to infer usage entirely from the name.

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

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

With no annotations, the description carries the behavioral burden and does disclose that the operation mutates Feedbin state and may return multiple feed choices—useful context beyond structured fields. However, it omits auth requirements, duplicate-subscription behavior, and idempotency, leaving meaningful gaps for a mutation tool.

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?

Three short sentences, front-loaded with the action, and each clause contributes a distinct fact (purpose, mutation, return quirk). Nothing is wasted.

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?

For a one-parameter mutation tool with no annotations and no output schema, the description covers purpose, side effect, and a return-value quirk. It still leaves open how to handle multiple feed choices and duplicate subscriptions, so it is minimally adequate rather than complete.

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% for the single required feed_url parameter, and the description only repeats the parameter name while implying it is a URL. It does not explain accepted formats, whether feed IDs are accepted, or any validation constraints.

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 (subscribe) and resource (feed_url / feed subscription), and 'Mutates Feedbin state' disambiguates it from read-only siblings like feedbin_list_subscriptions. It does not explicitly contrast with feedbin_update_subscription or feedbin_delete_subscription, but the action is clear enough to distinguish it.

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?

There is no guidance on when to use this versus updating an existing subscription (feedbin_update_subscription) or listing subscriptions; the agent must infer usage from the verb alone. No exclusions or alternatives are named.

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

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

With no annotations, the description carries the full disclosure burden, and "Mutates Feedbin state" only confirms a write. It says nothing about idempotency, what happens if the same tag is applied twice, whether it overwrites or adds, or what identifiers are needed to target the write.

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, front-loaded with the action, with no filler. Brevity is achieved, though the space saved is not spent on anything useful.

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 mutation tool with no annotations, no output schema, and fully undocumented parameters needs considerably more than this. Key facts an agent would need before calling it are absent.

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% and neither parameter (feed_id, name) is mentioned or explained. 'Tag a feed' weakly implies a feed identifier and a tag string, but that inference is not drawn out, so the agent gets no meaning beyond the bare JSON keys.

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?

The verb-and-resource pair "Tag a feed" identifies the operation, but with siblings like feedbin_rename_tag and feedbin_list_taggings the agent cannot tell from this text whether it creates a new Tag entity, attaches an existing tag to a feed, or replaces existing taggings. The name 'create_tagging' implies an association object, which the description never makes explicit.

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_rename_tag or feedbin_list_taggings, and no stated preconditions such as the feed or tag needing to exist. The two sentences give context for nothing beyond the operation itself.

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

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

No annotations are provided, so the description carries the full burden. "Mutates Feedbin state" does flag that this is a write, but it adds nothing about permanence/irreversibility, whether extracted content is also removed, or whether the operation fails silently on a missing id.

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, front-loaded with the action, with no filler. The second sentence is marginally redundant with the name but still conveys state mutation in a compact form.

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?

For a destructive mutation with zero annotation coverage, no output schema, and an undocumented parameter, the description is too thin. An agent cannot determine safety, prerequisites, or failure behavior from what is written.

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 coverage is 0% for the single parameter page_id, so the description must compensate and does not. It never explains what a page id is, how to obtain one, or what happens with an invalid/nonexistent id.

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?

The description names a specific verb+resource pair ("Delete a saved page") that is unambiguous and clearly distinct from siblings like feedbin_save_page or feedbin_delete_tag. It lacks an explicit sibling comparison, so it lands just short of a 5.

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?

There is no guidance on when to use this versus alternatives, no prerequisites (auth, ownership of the page), and no note on where a valid page_id comes from. The only implied usage comes from the word "saved," which the agent must infer.

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

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

With no annotations present, the description carries the full disclosure burden. "Mutates Feedbin state" does flag that this is a write, but a delete tool needs more: whether deletion is permanent, what happens to an invalid or already-deleted search_id, and whether any auth scope is required are all unstated.

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 compact sentences with the operation front-loaded; nothing is padded or buried. The second sentence is thin but does carry the one behavioral fact present.

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?

For a destructive one-parameter tool with no annotations and no output schema, the description omits the essentials: irreversibility, success/failure behavior, and the provenance of search_id. What is there is accurate but far short of what an agent needs to call this safely.

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% and the single parameter (search_id) is undocumented in both schema and description. The description never says the id comes from feedbin_list_saved_searches or that it must be an existing saved search, so nothing compensates for the coverage gap.

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 concrete verb and resource ("Delete a saved search") that unambiguously separates it from the create/update/get saved-search siblings. It stops short of naming which sibling to use if the intent was something else, but the operation itself is unmistakable.

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?

There is no guidance on when to use this versus feedbin_update_saved_search or feedbin_delete_tag, no preconditions, and no warning about irreversibility. The agent must infer all usage context from the tool name alone.

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

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

With no annotations, the description carries the full burden. "Mutates Feedbin state" correctly signals a write, but says nothing about irreversibility, whether the operation is idempotent, what happens if subscription_id does not exist, or what is returned.

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 terse sentences with no wasted clauses, which is good, but the brevity comes at the cost of substance rather than being efficiently front-loaded information.

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?

For a destructive single-parameter tool with no annotations and no output schema, the description should at minimum identify the resource being deleted and the effect on the feed/entries. Neither is covered.

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?

The single parameter subscription_id has 0% schema description coverage, and the description does not mention it at all — no statement of where to obtain the id, whether it is the Feedbin subscription id versus a feed id, or what happens with an invalid value.

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?

"Unsubscribe" is a specific verb, but the description never names the resource (a subscription) or clarifies that it removes a Feedbin subscription, leaving the tool name to carry that meaning. Against siblings like feedbin_delete_tag and feedbin_delete_page the verb alone does not disambiguate.

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?

There is no guidance on when to use this versus alternatives, no prerequisites (auth, ownership of the subscription), and no note on whether feedbin_update_subscription could achieve a similar outcome. Usage is only implied by the tool name.

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

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

With no annotations, the description does carry the key burden of disclosing the cascade ('and its taggings') and labels the operation as mutating Feedbin state. It does not say whether the deletion is reversible, what happens if the tag is absent, or what a successful response looks like — meaningful gaps for an irreversible destructive operation.

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, front-loaded with the action and the cascade behavior; nothing is wasted.

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?

For a trivial one-parameter tool this is close to sufficient, but with no annotations and no output schema, the description leaves the destructive semantics and the meaning of `name` under-specified.

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?

The single `name` parameter has 0% schema description coverage, and the description never explains it — whether it is the tag's literal name versus an identifier, case sensitivity, or matching rules. With only one parameter this is a small but real gap the description should have closed.

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 (delete a tag) and adds the important scope detail that its taggings are deleted too, which separates it from feedbin_delete_tagging. It does not explicitly point at that sibling, but the resource distinction is legible.

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 statement of when to use this versus feedbin_delete_tagging or feedbin_rename_tag, and no prerequisites such as whether the tag must already exist. The agent must infer the choice from the tool name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that this mutates Feedbin state, but it does not say what is removed, whether the operation is idempotent, what permissions are required, or what happens to the underlying tag.

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?

The description is two short sentences and front-loads the operation. It is efficient, though the second sentence is sparse and the whole definition is arguably under-specified rather than richly concise.

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?

For a mutation tool with no annotations, no output schema, and 0% parameter description coverage, the description is too thin. It leaves key agent-relevant context unstated: parameter meaning, deletion scope, and side effects.

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 should compensate but does not mention tagging_id at all. The parameter name is fairly self-explanatory, which prevents a 1, but the description adds no semantic information such as whether this is a tagging record ID versus a tag ID.

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?

The description states a specific verb and resource: 'Delete a tagging.' It is clear what the tool does, but it does not distinguish itself from nearby siblings such as feedbin_delete_tag or explain how a tagging differs from a tag.

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?

There is no guidance on when to use this tool versus feedbin_delete_tag or when deletion is appropriate. The only extra sentence is a mutation warning, not usage guidance or exclusions.

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

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

With no annotations, the description carries the full burden. It does correctly flag that the call mutates Feedbin state, which is the most important disclosure, but it says nothing about permissions, whether the operation is irreversible, what 'clearing' actually destroys versus merely acknowledges, or what happens to ids that don't exist.

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 terse sentences with nothing wasted and the operation front-loaded. The length is appropriate, though the terseness borders on under-specification rather than efficiency.

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?

For a mutation tool with no annotations and no output schema, the description leaves key questions open: whether the call returns anything, whether the clear is idempotent, and what the practical effect on the user's Feedbin account is. It is too thin for an unannotated write operation.

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% for the single entry_ids parameter, so the description must compensate. 'Clear updated-entry ids' does hint that the values are entry ids drawn from the updated-entries listing, but it gives no format, cardinality, or bounds beyond the array-of-integers schema itself.

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?

The verb 'clear' plus resource 'updated-entry ids' identifies the operation, and the second sentence confirms it is a mutation. But alongside a sibling named feedbin_list_updated_entries, the description never states the relationship (e.g. that it clears ids consumed from that list), and 'clear' is ambiguous between deleting entries and clearing a tracking marker.

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?

There is no when-to-use or when-not-to-use guidance, no mention of the list_updated_entries sibling, and no precondition stated. The agent must infer that this is the follow-up step after reading the updated entries list.

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

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

No annotations are provided, so the description carries the full burden, yet it discloses nothing about return format (HTML vs plain text), failure behavior when extraction is unavailable, auth requirements, or whether the call is a read-only fetch. For a network-backed extraction endpoint this is a meaningful gap.

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?

A single tight sentence with no padding, front-loaded on the action. It is efficient, though brevity comes at the cost of the clarity issues noted elsewhere.

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?

With no annotations and no output schema, the description is the only source of truth, and it leaves out what the extracted content looks like, how errors surface, and how this differs from sibling content-retrieval tools. Inadequate for the role it must play here.

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 coverage is 0% for the single required entry_id parameter, so the description should explain it. Instead it refers to 'extracted_content_url', a field that is not the parameter at all, which risks confusing the agent about what to pass.

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: fetching extracted full content for an entry. It distinguishes itself from plain entry retrieval (feedbin_get_entry) by emphasizing 'extracted full content', though it never names a sibling explicitly. The phrase 'via its extracted_content_url' is slightly off since the tool actually takes an entry_id.

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 statement of when to use this instead of feedbin_get_entry or feedbin_cached_entry, which are the obvious alternatives in this large sibling set. The agent must infer that this is for full-text extraction rather than raw entry metadata.

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

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

With no annotations, the description carries the full burden; it does disclose one real behavioral trait — reads come from a local cache unless force_refresh is true — which is the kind of context annotations would not have covered. It says nothing about staleness guarantees, what 'full content' expands to, or auth/prerequisite requirements.

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 sentences, zero waste, with the core action and the cache-override caveat front-loaded. Nothing is repeated from the schema or title.

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?

For a 6-parameter tool with no annotations and no output schema, the description is thin: it accounts for one optional flag and leaves the other four unexplained. An agent cannot tell whether include_content_diff or mode meaningfully changes the payload or the cost of the call.

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% across 6 parameters, so the description must compensate, and it only explains entry_id implicitly and force_refresh explicitly. Four parameters — mode, include_original, include_enclosure, include_content_diff — are left completely undefined in both schema and description, and 'mode' in particular is opaque.

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: 'Get one entry by id with full content', plus a scope hint (full content vs summary). It does not name the nearby alternatives (feedbin_list_entries, feedbin_cached_entry, feedbin_extract_content), so the agent must infer when a single-entry fetch beats a list or cache read.

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?

The second sentence implies a caching workflow and when to override it with force_refresh=true, which is genuine usage guidance. There is no explicit when-not-to-use or routing to sibling tools such as feedbin_cached_entry or feedbin_list_entries.

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

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

No annotations are provided, so the description carries the full burden. 'Get' implies a read, but nothing is said about error behavior for unknown ids, whether the call is cached/rate-limited, or what 'metadata' comprises.

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?

A single front-loaded sentence with no filler. Brevity is appropriate, though the terse phrasing is under-specification rather than deliberate economy.

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?

For a tool with no annotations, no output schema, and an undocumented parameter, the description should at minimum explain how to obtain a feed id and roughly what metadata is returned. Neither is covered.

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% and agnostic — feed_id has only a title. The description repeats that a feed id is required but doesn't explain where to source it (e.g., from feedbin_list_subscriptions) or whether it matches the subscription's feed_id.

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 ('Get feed metadata') scoped to an id, which is clearly distinct from siblings like feedbin_get_entry or feedbin_get_subscription. It doesn't explicitly name those alternatives, so it falls short of a 5.

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 call this versus feedbin_get_subscription or feedbin_list_subscriptions, nor any prerequisite such as needing a feed id obtained elsewhere. Usage is only inferable from the name.

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

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

No annotations exist, so the description carries the full behavioral burden, yet it discloses almost nothing: it does not say the call is a safe read, whether a pending import requires repeated polling, how item statuses are represented, or what happens for an unknown import_id. Only the phrase 'import and its item statuses' hints at the response shape.

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?

One short, front-loaded sentence with no padding. It is arguably too terse rather than verbose, but nothing in it is wasted.

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?

With no annotations and no output schema, the description is the only source of truth about behavior and return values, and 'item statuses' is unexplained. For a single-parameter read tool this leaves a meaningful gap an agent must guess around.

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% for the single required parameter import_id, which has no type-descriptive title beyond 'Import Id'. The description implies the id selects one import but adds no format, source, or example of where such an id comes from (presumably from create_import or list_imports).

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 concrete verb+resource: retrieve a single OPML import plus the per-item statuses belonging to it. That distinguishes it adequately from feedbin_list_imports and feedbin_create_import, though it never names those siblings explicitly.

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?

There is no when-to-use guidance, no mention of when to prefer feedbin_list_imports, and no prerequisites (e.g. auth, whether the import must already be in progress). An agent must infer the usage pattern entirely from the word 'one'.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the default result is entry IDs and that include_entries=true returns full entries, but it omits pagination behavior via the page parameter, authentication requirements, and error behavior for invalid search IDs.

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?

The description is a single front-loaded sentence with no filler. The parenthetical efficiently conveys the conditional output behavior, though the structure is minimal.

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?

For a three-parameter getter with no annotations and no output schema, the description covers the core return variation but leaves pagination and error/auth context undocumented. It is minimally viable but incomplete for an agent needing to invoke it correctly in all cases.

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 document all three parameters. It explains the effect of include_entries and implies the role of search_id, but never mentions the page parameter or its pagination semantics, leaving a clear gap.

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?

The description states a specific verb ('Get') and resource ('saved search matches'), and clarifies the output variation via include_entries. It does not explicitly distinguish itself from sibling tools such as feedbin_list_saved_searches or feedbin_list_entries, but the resource is distinct enough for an agent to identify the operation.

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?

There is no guidance on when to use this tool versus alternatives like feedbin_list_saved_searches (to list saved searches) or feedbin_list_entries (to browse entries). The only conditional mentioned concerns output shape, not tool selection or context.

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

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

With no annotations, the description carries the full behavioral burden and does not meet it. 'Get' weakly implies a non-mutating read, but nothing states whether authentication is required, what happens for an unknown id, or what the returned subscription contains.

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?

A single short sentence with the resource and qualifier front-loaded and no filler. It is efficient, though the terseness borders on under-specification rather than genuinely tight writing.

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?

The tool is simple (one integer parameter, no output schema, no nested objects), so a minimal description is defensible. Still, for an unannotated tool it leaves the agent guessing about return shape and failure behavior.

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 coverage is 0%, so the description must compensate, yet 'by id' merely restates the parameter name 'subscription_id'. It confirms the id identifies a subscription but adds no format, source (e.g. from list_subscriptions), or validity semantics.

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 ('Get') and resource ('one subscription') with a scoping qualifier ('by id'), which implicitly distinguishes it from the sibling feedbin_list_subscriptions. It does not explicitly name that sibling, but the singular/plural contrast is unambiguous.

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?

There is no when-to-use guidance, no mention of when to prefer feedbin_list_subscriptions instead, and no prerequisites or error conditions. The agent must infer usage purely from the name contrast.

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

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

With no annotations, the description carries the full behavioral burden. 'Get' implies a safe read, which is helpful, but there is no mention of what happens for a nonexistent id, what the returned tagging contains, or any auth requirements for a 1-param lookup tool.

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?

One short, front-loaded sentence with no filler. It is efficient, though its brevity edges toward under-specification rather than true conciseness.

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?

For a simple single-parameter read tool this is minimally viable, but with no annotations, no output schema, and 0% parameter coverage, the description leaves the return value and id provenance entirely unspecified.

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 coverage is 0%, so the description must compensate. 'By id' does confirm that tagging_id is an identifier, but it doesn't explain where to source that id (e.g., from list_taggings) or its expected format beyond the integer type in the schema.

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?

The description states a specific verb and resource with scope: 'Get one tagging by id.' That clearly separates it from the feedbin_list_taggings sibling, though it never names or contrasts against any sibling explicitly.

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?

There is no guidance on when to use this versus list_taggings or how to obtain a valid tagging_id in the first place. The single sentence implies 'fetch a single tagging' but offers no alternatives, prerequisites, or exclusions.

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

Does 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.

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

No annotations are provided, so the description carries the full burden. It usefully discloses that HTML content/summary is truncated to 500 chars and gives the ids format, but says nothing about pagination behavior with page/per_page, how mode/since filters behave, or the defaults applied when the null-valued params are omitted.

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?

Three short sentences with no filler and the truncation caveat front-loaded, but the brevity reflects under-specification rather than economy given a 10-parameter tool.

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 10-param listing endpoint with no annotations, no output schema, and no schema descriptions needs far more than one line about ids. Key behaviors (pagination, filter interactions, include_* effects, default page size) are missing entirely.

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% and there are 10 parameters, so the description must compensate and instead covers only one (ids). The critical filters (mode, since, read, starred, per_page) and the include_* toggles are entirely undocumented, leaving their semantics and defaults opaque.

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?

"List entries" restates the tool name with no scope, no object detail, and no differentiation from the many sibling list tools (feedbin_list_feed_entries, feedbin_list_unread, feedbin_list_starred, feedbin_list_recently_read). Only the truncation note adds any information about what comes back.

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?

There is no statement of when to use this over feedbin_list_feed_entries, feedbin_list_unread, feedbin_list_starred, or feedbin_list_updated_entries. The agent must guess which listing endpoint fits its case.

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

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

With no annotations at all, the description carries the full burden. It does disclose one genuinely useful behavioral trait: HTML content and summary are truncated to 500 chars, which affects how the agent should consume results. But it says nothing about pagination behavior (page/per_page), default read-state filtering, or the fact that this is a non-mutating list call.

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 tight sentences with the resource statement front-loaded and the truncation caveat immediately after. No wasted words, though the brevity is partly a symptom of under-specification rather than discipline.

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 10-parameter listing tool with no annotations and no output schema needs far more than two sentences. The truncation note is the only behavioral detail; nothing explains filtering, pagination, or return shape for a tool whose surface area is this large.

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?

Ten parameters with 0% schema description coverage, and the description explains none of them. Filters like read, starred, since, mode, include_original, include_enclosure, and include_content_diff are entirely undocumented anywhere, leaving the agent to guess at semantics and formats.

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 entries for a feed'), and the 'for a feed' qualifier implicitly separates it from the sibling feedbin_list_entries. It stops short of explicitly naming that sibling or any other alternative, so it is clear but not fully differentiated.

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?

There is no guidance on when to use this versus feedbin_list_entries, feedbin_list_unread, feedbin_list_starred, or feedbin_list_recently_read, all of which overlap heavily. No prerequisites, no exclusions, no mention of how filtering options affect the choice.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only listing operation via 'List', but does not state whether it requires authentication, whether results are paginated, or what the response shape looks like (e.g., URLs vs binary data).

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?

The description is a single, front-loaded sentence with no wasted words. It immediately conveys the resource and scope.

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?

For a simple zero-parameter listing tool, the description is minimally adequate. However, because there is no output schema, the description should ideally explain what an icon record contains (e.g., host and favicon URL) or how results are returned.

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?

The tool has zero parameters, so there are no parameter semantics to document. Per the baseline rule for zero-parameter tools, a score of 4 is appropriate.

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?

The description uses a clear verb ('List') and resource ('feed favicons for subscribed hosts'), making the tool's purpose immediately identifiable. It is distinct from sibling tools like feedbin_list_subscriptions or feedbin_list_entries, though the phrase 'subscribed hosts' could be slightly more precise.

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?

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites or authentication, and no exclusions. The zero-parameter nature makes usage somewhat implied, but the description does not explicitly help an agent decide when this tool is appropriate.

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

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

With no annotations, the description carries the full disclosure burden, yet 'List' is the only behavioral signal (implying a read). It says nothing about whether imports are paginated, how many are returned, whether completed imports are included, or any auth requirement.

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 words, front-loaded with the verb and resource, with no filler. It is under-specified rather than verbose, which is a completeness problem, not a conciseness one.

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?

Although the tool is structurally simple and has no output schema, the agent still learns nothing about what an import record contains (status, timestamps, counts) or how many are returned. For a list endpoint with no annotations and no output schema, those omissions matter.

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?

The tool takes zero parameters, so there is nothing for the description to clarify; the schema is trivially complete. Baseline 4 applies for a no-parameter tool.

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 (List) and resource (OPML imports), which is enough to distinguish it from feedbin_create_import and feedbin_get_import by name alone. It stops short of saying anything about scope or contents, but the purpose itself is unambiguous.

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?

There is no indication of when to call this rather than feedbin_get_import (single import by id) or the other list tools, and no prerequisites or follow-up guidance. The agent must infer usage entirely from the name.

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

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

With no annotations, the description carries the burden, and it does disclose two useful traits: the result is a list of ids (not full entries) and items come back in 'display order'. It says nothing about result caps, pagination, or the time window that counts as 'recently'.

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?

A single tight sentence with no filler, and the key qualifier ('in display order') is placed where it is read first.

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?

For a zero-param, read-only listing tool with no output schema, the description states the resource and result shape adequately. The only real gap is the absence of any cap or window information, which keeps it below a 5.

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?

Zero parameters, so there is nothing to disambiguate and no schema burden to compensate for; the baseline of 4 applies.

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?

Specific verb ('List') and specific resource ('recently read entry ids'), plus the return shape ('entry ids') and ordering. It is distinguishable from feedbin_add_recently_read by the verb, though it never names a sibling or says how it differs from feedbin_list_unread.

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 statement of when to use this versus feedbin_list_unread, feedbin_list_entries, or feedbin_add_recently_read. The agent must infer usage entirely from the name; there are no exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, yet it only implies a read-only enumeration via the word "List." It says nothing about authentication requirements, whether results are paginated, what a saved search object contains, or the ordering of results.

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?

A single three-word sentence, front-loaded and free of padding, which is appropriately sized for a zero-argument list operation. The terseness is under-specification rather than verbosity, so it isn't penalized here.

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?

For a trivial zero-parameter, read-only list tool with no output schema, the description is minimally sufficient to call it correctly. However, with no output schema the agent has no idea what fields a saved search record returns (query string? name? id?), which would matter for any follow-up call.

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?

The tool takes zero parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies; the absence of parameters is itself the relevant semantic fact and the description is consistent with it.

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?

"List saved searches" is a verbatim restatement of the tool name feedbin_list_saved_searches and adds no information an agent doesn't already have. It does not distinguish this from siblings like feedbin_get_saved_search or feedbin_create_saved_search, so the agent must infer the boundary from naming conventions alone.

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?

There is no guidance on when to use this versus feedbin_get_saved_search (single lookup) or the create/update/delete saved-search siblings. The agent is left to infer that "list" means enumeration, with no stated preconditions or exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only listing and specifies that entry ids are returned, but does not mention authentication requirements, pagination behavior, rate limits, or ordering. For a list endpoint, this is a notable gap.

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?

The description is a single, front-loaded sentence with no wasted words. It conveys the operation and the return scope efficiently.

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?

Given the low complexity, zero parameters, and absence of an output schema, the description is minimally adequate because it states the return value ('entry ids'). However, it omits useful context such as pagination, ordering, and whether authentication is needed, which an agent might reasonably want to know before calling.

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?

The tool takes zero parameters, so there are no parameter semantics to document. The baseline for zero-parameter tools is 4, and the description does not create confusion.

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?

The description states a specific verb ('List') and resource ('starred entry ids'), making the operation clear. It does not explicitly distinguish itself from siblings like feedbin_list_entries or feedbin_star_entries, but the 'starred' qualifier and 'ids' output scope imply differentiation.

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?

The description provides no guidance on when to use this tool versus alternatives such as feedbin_list_entries, feedbin_list_unread, or feedbin_star_entries. It merely states what the tool does, leaving selection entirely to inference.

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

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

No annotations are provided, so the description carries the full burden. It does not state that this is a read-only operation, whether results are paginated, whether all subscriptions are returned or truncated, or what the response looks like. Only the parameter hints are disclosed.

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, front-loaded with the action and followed by parameter notes; nothing is padded. It is under-specified rather than bloated, which is a separate concern from structure.

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?

With no annotations, no output schema, and 0% schema description coverage, the definition leaves an agent unable to determine pagination, sort order, or what extended mode returns. For a listing tool in a family of 40+ siblings, this is thin.

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 partially does: it reveals the ISO 8601 format for `since` and that `mode` accepts the value "extended" — neither of which appears in the schema, which types both only as nullable strings. However, it never explains what filtering `since` performs or what "extended" changes in the output.

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?

Names a specific verb and resource ("List subscriptions"), which is clearly distinct from siblings like feedbin_get_subscription or feedbin_create_subscription. It stops short of explicitly naming when to prefer it over get_subscription, but the list-vs-get distinction is inferable from the verb.

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?

There is no guidance on when to use this versus the many alternative listing tools (feedbin_list_taggings, feedbin_list_entries) or the single-subscription getter. The word "Optional" hints that params may be omitted, but that is schema restatement rather than usage guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden and mostly fails to. It doesn't state that this is a read-only operation, whether results are paginated, whether auth is required, or how the data is ordered. The only real disclosure is the shape of a tagging record.

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?

A single short sentence with no filler, front-loaded with the verb and resource. Nothing is wasted and the clarifying parenthetical is well placed.

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?

For a zero-argument list tool with no output schema, the description is only barely sufficient. It doesn't say whether results are paginated or what distinguishes a tagging from a tag (feedbin_rename_tag / feedbin_delete_tag operate on the tag itself), which is the one ambiguity an agent is likely to hit.

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?

Zero parameters, so there is no schema semantics to compensate for; baseline is 4. The parenthetical "feed_id + tag name" adds genuine value by characterizing the returned record, not just repeating the name.

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 taggings") and defines what a tagging is ("feed_id + tag name"), which disambiguates it from feedbin_get_tagging and the create/delete/rename siblings. It stops short of explicitly saying it returns all taggings in the account, but the intent is unambiguous.

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 when-to-use guidance, no prerequisites, and no mention of any alternative or sibling tool. An agent must infer from the name alone that this is the enumeration counterpart to feedbin_get_tagging.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only listing and reveals the return is ids only, but says nothing about auth requirements, result caps, pagination, ordering, or unread-count semantics — significant gaps for a zero-annotation tool.

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 words, front-loaded, zero waste. It is on the terse side, but no sentence is filler.

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?

For a simple zero-param listing tool with no output schema, 'entry ids' covers the essential return shape. Still missing are pagination/limits and what to do with the ids, which are the main questions an agent would have.

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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to clarify or compensate for.

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+resource ('List') and a precise scope ('unread entry ids'), making clear it returns identifiers rather than full entries. It doesn't distinguish itself from siblings like feedbin_list_entries or feedbin_list_starred beyond the 'unread' qualifier.

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 when-to-use guidance, no mention of the alternative feeds (list_entries, list_recently_read), and no hint that the returned ids are typically fed into feedbin_get_entry. The agent must infer the workflow from the sibling list.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that only entry ids are returned and that results are filtered by an updated-after date, but omits auth requirements, pagination behavior, whether deleted or read/star changes are included, and explicit read-only safety context.

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?

A single front-loaded sentence with no redundant or filler text. Every element contributes directly to understanding the operation.

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?

For a simple one-parameter tool this is adequate, and it partially covers return values by saying 'entry ids'. Still, with no output schema or annotations, it leaves default/omitted-since behavior and pagination unclear, so it is not fully complete.

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?

The sole parameter has 0% schema description coverage, so the description meaningfully compensates by stating it is optional and expects an ISO 8601 value. It does not specify timezone or inclusive/exclusive boundary semantics, but the core meaning is supplied.

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 ('List') and resource ('entry ids updated') with the relevant filter. It is clear on its own, but does not explicitly distinguish itself from siblings such as feedbin_list_entries or feedbin_delete_updated_entries.

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?

The mention of an optional 'since' parameter implies incremental/update polling usage. However, it gives no explicit guidance on when to use this versus feedbin_list_entries or feedbin_poll_entries, and no exclusions are stated.

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

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

With no annotations, the description carries the full burden, and it does disclose two useful traits: this mutates Feedbin state and caps input at 1000 ids. It omits idempotency, error behavior for unknown ids, and whether the change is reversible, so it only partially compensates for the missing annotations.

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?

Three terse sentences, zero waste, with the core action stated first and the mutation warning and limit following. Every sentence earns its place.

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?

For a single-parameter mutation with no output schema, the description covers the action, the mutation risk, and the input cap—enough to call it correctly. Missing idempotency and unknown-id handling, a minor gap given the tool's simplicity.

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 coverage is 0% and the only parameter is undocumented in the schema, so the description must compensate. It correctly identifies the parameter as entry ids and adds the 1000-id limit, but says nothing about id format, validity, 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 ('Mark entry ids as read'), which an agent can distinguish from feedbin_mark_unread by polarity of the name and description. It does not explicitly name the sibling, so differentiation relies on inference.

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?

Usage is implied by the operation name; the description never says when to prefer this over feedbin_mark_unread or feedbin_add_recently_read, nor any preconditions such as ids needing to exist. Adequate but with clear gaps.

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

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

With no annotations provided, the description carries the full burden, and it does disclose two useful traits: it mutates Feedbin state and accepts a maximum of 1000 ids. It does not say whether the operation is idempotent for already-unread entries, whether it requires auth, or what the response contains, leaving meaningful gaps for a mutation tool.

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?

Three short clauses, front-loaded with the action and followed by the mutation warning and the batch limit. No wasted words, though the fragmentary style omits connectives that would make the limit read as a hard constraint.

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?

For a mutation tool with no annotations, no output schema, and an undocumented parameter, the description covers the essentials (what changes, the size limit) but omits idempotency, return behavior, and error conditions such as invalid ids.

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% for the single required parameter, so the description must compensate. It confirms entry_ids are entry identifiers and adds a batch cap of 1000 ids, but it does not say where ids come from (e.g., feedbin_list_entries) or that they are integers.

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 ('Mark entry ids as unread'), so the agent knows exactly what it does. It is clearly the inverse of the sibling feedbin_mark_read, but it never names that sibling or any other, so it earns a 4 rather than a 5.

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 instead of feedbin_mark_read or the recently-read tools, and no prerequisites or exclusions. The agent must infer the use case entirely from the tool name.

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

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

With no annotations, the description carries the full burden and does address the two riskiest behaviors: it will not change remote read state, and it returns a summary rather than HTML bodies. It omits how many entries are fetched per run, whether the cache is replaced or appended, and rate-limit behavior.

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?

Three short sentences, zero waste, with the core action and the non-destructive guarantee front-loaded. Nothing in it repeats the tool name or schema.

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?

For a zero-param tool with no annotations and no output schema, the description covers action, side effects, and return shape in miniature. The one gap is that 'a summary' is left undefined and cache replacement semantics are unstated, which matters for a tool whose whole job is populating a local store.

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?

Zero parameters, so there is nothing to disambiguate; baseline 4 applies. The description correctly implies a no-argument, whole-scope operation ('unread entry bodies') rather than a filtered one.

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 (fetch) plus the precise resource (unread entry bodies) and its destination (local SQLite cache), which separates it from the remote-only list/unread tools in the sibling set. It stops short of naming the sibling it replaces (e.g. feedbin_list_unread), so the differentiation is inferred rather than explicit.

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?

'Does not mark entries read' hints at when-not semantics relative to feedbin_mark_read, but the description never states the scenario that selects this tool over feedbin_list_unread, feedbin_list_entries, or feedbin_list_cached_entries. Usage is implied only.

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

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

With no annotations, the description carries the entire burden, and it does declare the mutation ('Mutates Feedbin state'), which is useful. However it omits key behavioral facts: whether a missing old_name creates a new tag, whether all taggings are rewritten atomically, whether the operation is reversible, and whether it requires auth scopes.

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 flag front-loaded right after the action, zero filler. It is arguably over-terse rather than padded, but structure-wise it is clean and front-loaded.

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?

For an unannotated mutation tool with no output schema and 0% schema coverage, the description should cover side effects and failure modes; it covers neither. An agent cannot tell what happens on a nonexistent tag or whether existing taggings survive the rename.

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 both parameters (old_name, new_name) are undocumented except by their titles. The description only implies the old→new mapping by wording; it does not state case sensitivity, format constraints, or whether new_name is validated against existing tags.

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 ('Rename a tag') plus the scope affected ('across taggings'), so the agent knows exactly what changes. It stops short of distinguishing itself from nearby siblings like feedbin_create_tagging or feedbin_delete_tag, which a reader would have to infer.

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 rename versus delete-and-recreate, or when to prefer the tagging-level siblings (create_tagging/delete_tagging). No prerequisites or error conditions are mentioned.

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

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

With no annotations provided, the description carries the full disclosure burden. It does usefully state 'Mutates Feedbin state,' making the write semantics explicit — a meaningful addition since readOnlyHint is absent. However, it says nothing about how duplicate URLs are handled (idempotency), authentication requirements, or what the response contains.

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, zero filler, with the core action front-loaded ahead of the mutation caveat. Every word earns its place.

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?

For a simple two-parameter tool with no output schema and no annotations, the essential facts (what it saves, that it writes) are present. But duplicate handling, return value, and the role of the optional title parameter are unaddressed, leaving real gaps for a mutation tool.

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 both parameters (url, title) are undocumented. The description only implies that a URL identifies the page and says nothing about the optional title argument or whether unknown URLs are fetched server-side, so it fails to compensate for the coverage gap.

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: 'Save a webpage as a Feedbin page/entry.' An agent can distinguish it from siblings like feedbin_extract_content or feedbin_cache_entry, though the description doesn't explicitly name the closest alternative.

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?

There is no when-to-use guidance, no prerequisites, and no mention of when to prefer feedbin_extract_content (which also takes a URL) or feedbin_delete_page for the reverse operation. The agent must infer the selection criteria from the description alone.

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

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

With no annotations, the description carries the full burden, and it does disclose the two things that matter most: this mutates Feedbin state and caps at 1000 ids. It stops short of idempotency (does re-starring an already-starred entry error or no-op?), auth requirements, or what the call returns, which leaves real gaps for a mutation tool.

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?

Three short sentences, mutation warning and size cap front-loaded, zero filler. Nothing could be removed without losing information.

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?

For a simple one-parameter tool with no output schema, the description covers the essentials of what it does and its limit. It omits the return value (starred ids? confirmation?) and idempotency/side-effect semantics that an agent batching 1000 ids would want.

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 coverage is 0%, so the description must compensate. 'Max 1000 ids' usefully constrains the entry_ids array size and 'Star entry ids' clarifies the element meaning, but it does not say where valid ids come from (e.g. feedbin_list_entries) or that they are Feedbin entry identifiers rather than feed 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 ('Star entry ids') and names the payload type, which is enough to distinguish it from feedbin_unstar_entries and feedbin_list_starred. It does not explicitly name those siblings, so differentiation is inferential rather than stated.

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?

There is no guidance on when to use this versus feedbin_list_starred, feedbin_unstar_entries, or the read/unread equivalents. The agent must infer usage from the verb alone, and nothing is said about preconditions such as the ids needing to exist.

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

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

With no annotations, the description carries the full burden. It usefully discloses that this mutates Feedbin state and enforces a 1000-id cap, which is valuable behavioral context. However, it does not state auth requirements, whether non-starred ids cause errors, idempotency, or return behavior, leaving notable gaps for a mutation tool.

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?

Three short, front-loaded sentences with no filler. The mutation warning and batch limit each add distinct value, and nothing is redundant.

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?

For a single-parameter mutation tool with no annotations and no output schema, the description covers the core action and a safety-adjacent limit. It remains incomplete regarding error behavior, response shape, and idempotency, which an agent needs to invoke it confidently.

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. It identifies the parameter domain as entry ids and adds a batch-size limit (1000), which is meaningful beyond the raw schema. It still does not clarify array semantics, invalid-id handling, or required ordering, so compensation is partial.

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 ('Unstar entry ids'), which unambiguously distinguishes it from the sibling feedbin_star_entries. It does not explicitly name the sibling or define scope beyond the operation, but the purpose is clear.

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?

There is no explicit guidance on when to use this tool versus feedbin_star_entries or other entry-state tools, nor any stated preconditions or exclusions. The operation is implied by the name and description, but the agent is left to infer usage context.

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

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

No annotations are provided, so the description carries the full burden. 'Mutates Feedbin state' only restates that it is a write; it does not disclose permission requirements, partial-update/field-omission behavior, reversibility, or what happens when search_id does not exist.

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, front-loaded with the action and fields, with zero padding. The brevity is efficient, though it edges toward under-specification given the tool's complexity.

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?

For a simple 3-parameter mutation with a fixed shape and no output schema, the description covers the basics, but the absence of annotations and 0% parameter coverage leaves meaningful gaps (required id meaning, field omission behavior) unaddressed.

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 for all three parameters. It gives meaning to 'name' and 'query' but never explains search_id (the sole required parameter) or the null/optional semantics that the anyOf schema leaves ambiguous.

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?

Names a specific verb (update) and resource (saved search) plus the fields it can change (name or query), which distinguishes it from the sibling create/get/delete/list saved-search tools by operation. It stops short of naming a sibling or stating scope conditions explicitly, so it is clear but not maximally differentiated.

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?

The description gives no when-to-use guidance: it does not say whether at least one of name/query must be supplied, whether omitted fields stay unchanged, or when to prefer delete+create over updating. An agent must infer partial-update semantics from the schema's nullable defaults alone.

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

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

With no annotations, the description must cover the behavioral burden, and all it offers is 'Mutates Feedbin state.' That flags a write operation, but it does not say whether this requires authentication, whether the change is reversible, whether the original feed title is lost, or what happens on an invalid subscription_id. This is a real gap for a mutation tool with zero annotation coverage.

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, front-loaded with the action, with no filler. The terseness comes at the cost of the omissions noted above, but the framing itself is efficient and readable.

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?

For a two-required-parameter mutation with no annotations and no output schema, the description is under-specified. It says nothing about the return value, idempotency, or how subscription_id should be sourced, all of which an agent needs before calling it confidently.

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 coverage is 0%, so the description must explain both parameters, but it only implies 'title' through the word 'custom title.' The required subscription_id is never mentioned, and nothing indicates that the title is a display override rather than the feed's canonical name, which is the one piece of semantics that would matter here.

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?

The description names a specific verb and resource: set a custom title on a subscription. That is clearer than the name alone, but it does not explicitly distinguish this operation from siblings like rename_tag or update_saved_search, leaving the agent to infer that titles and tags are different things.

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?

There is no guidance on when to use this tool instead of alternatives, no prerequisites, and no exclusions. An agent gets no signal about how this relates to update_saved_search (a similar update operation on another resource) or about when a subscription title should be set at all.

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