mcp-feed-reader-crunchtools

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.3
Disambiguation5/5
Every tool targets a distinct resource and action: feed CRUD, entry listing/reading/searching, category management, OPML import/export, and stats. No two tools overlap in purpose.
Naming Consistency5/5
All tool names follow the same verb_noun_tool pattern (e.g., list_feeds_tool, create_category_tool). Consistent use of snake_case and the '_tool' suffix throughout.
Tool Count4/5
17 tools is slightly above the ideal 3-15 range but each tool serves a clear need, covering feeds, entries, categories, OPML, and stats. The count is justified for a full-featured feed reader.
Completeness4/5
The tool set provides comprehensive CRUD-like coverage for feeds, entries, and categories, plus import/export and stats. Minor gap: no explicit feed update tool (e.g., renaming a feed or changing its category), but this is not critical.
Average 3.7/5 across 17 of 17 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on March 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 only states the action without disclosing side effects, validations, or whether the operation is destructive. Since rename is a mutation, more context about overwriting behavior would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient, but it is under-specified for the tool's purpose—it conveys the basic action without earning its place through added useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no usage guidance, the description is too minimal. For a mutation tool with an output schema, it fails to explain what happens on success/failure or any constraints, leaving the agent without important context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (name and category_id) having descriptions. The tool description adds no additional parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Rename' and the resource 'category', clearly conveying the operation. It is distinct from sibling tools like create_category and delete_category, though it lacks additional scope details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. It doesn't mention prerequisites, such as whether the category must exist or how it differs from create/delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states a generic listing action. It fails to mention key behaviors such as the default 'unread_only=true' filter, pagination via limit/offset, or how multiple filters are combined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is front-loaded and easily readable, though it lacks detail that would make the extra brevity a strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a tool with 5 parameters and no annotations. It omits crucial default behavior (e.g., unread_only defaults to true) and does not explain how filters interact or what the output represents. The presence of an output schema mitigates the need for return value details, but overall context is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all five parameters well-documented including defaults and constraints. The description adds no extra parameter context, but the schema provides sufficient semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action 'list' and resource 'entries' clearly, with 'optional filters' indicating parametrization. It distinguishes from 'list_feeds_tool' by the resource type, though it does not explicitly contrast with 'search_entries_tool'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_entries_tool' or 'read_entry_tool'. There is no mention of use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without revealing side effects, irreversibility, impact on unread counts, or the caution associated with all_entries (even though the schema notes 'use with caution'). This is minimal and provides no additional behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. While it is brief, it is efficient for what it states. It is not verbose, though it could be enriched without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three mutually exclusive parameters and a potentially destructive all_entries option, yet the description does not explain usage requirements or what happens in each case. It also fails to differentiate from sibling tools. Given the lack of annotations, this is insufficient for an agent to safely and correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with textual descriptions, so the baseline is 3. The description itself does not add any parameter-specific semantics, leaving the schema to fully document the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (mark), the resource (entries), and the state change (as read). It distinguishes from the sibling mark_unread_tool by the word 'read', but doesn't explicitly mention alternatives or scopes beyond the generic resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like mark_unread_tool or read_entry_tool. There is also no mention that exactly one of feed_id, entry_id, or all_entries should be specified. The description offers no context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states the basic action and does not mention side effects, reversibility, prerequisites, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundancy. It is appropriately concise, though it could be more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description is adequate but minimal. It lacks contextual guidance given the existence of the sibling mark_read_tool and does not explain behavioral nuances beyond the literal action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full coverage for the single entry_id parameter with a description, so the baseline is 3. The description adds no additional meaning or usage details for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Mark' and the resource 'an entry as unread'. It is specific enough to distinguish from siblings in general, though it does not explicitly contrast with mark_read_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, such as mark_read_tool or read_entry_tool. No context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only indicates a mutation ('create') but does not disclose side effects, error conditions, or behavioral nuances like duplicate handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that earns its place. It contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description covers the primary purpose. However, it omits any context about constraints or result expectations, which keeps it slightly below a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter 'name' with description 'Category name', so the baseline is 3. The description adds no additional parameter semantics beyond the action itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action 'Create a new category' with a specific verb and resource. The verb 'create' distinguishes it from sibling tools like rename_category_tool and delete_category_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It merely states the action without any context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It only states that it performs full-text search across titles and content, but does not mention details like FTS5 syntax support, result ranking, or limitations. The schema notes FTS5 syntax, but the description itself adds no behavioral context beyond its one-line function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no superfluous words. It immediately states the tool's purpose, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with two parameters and an output schema, the description is fairly complete. It tells users what the tool does, and the schema covers the parameter details. It lacks advanced usage context (e.g., when to use over list_entries_tool), but the core functionality is clearly conveyed, and the output schema reduces the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter explanations, but the schema already documents the 'query' and 'limit' parameters sufficiently, including the FTS5 syntax hint and the default limit of 50.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Full-text search across entry titles and content' uses a specific verb (search), specifies the resource (entries), and denotes the scope (titles and content). This clearly distinguishes it from sibling tools like list_entries_tool or read_entry_tool, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention cases where list_entries_tool would be more appropriate, nor does it explain any exclusions or prerequisites. The helpful context is left entirely to the schema and user inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the primary action and optional category assignment. It does not mention behavior on duplicate URLs, whether the feed is fetched immediately, or side effects like category auto-creation (which is only in the schema, not in the description).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action. It has no redundant wording and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with a complete schema and an output schema, so the description does not need to explain return values. However, the lack of usage guidance relative to the sibling import_opml_tool, and the absence of behavioral details like duplicate handling, leaves the description only minimally complete for an agent to use without further information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal new meaning beyond the schema: 'by URL' aligns with the url parameter, and 'optionally assign to a category' aligns with category. It does not provide additional detail about URL formats or category creation beyond what the schema already contains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add an RSS/Atom feed by URL, optionally assign to a category.' It uses a specific verb ('Add') with a defined resource (RSS/Atom feed) and scope (by URL, optional category), which differentiates it from sibling tools like get_feed_tool, list_feeds_tool, and delete_feed_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for adding a single feed by URL, which distinguishes it from listing or getting feeds. However, it does not explicitly mention when not to use it, such as for bulk importing via import_opml_tool, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does disclose a critical side effect ('Feeds in this category become uncategorized'), which is valuable. However, it omits other behavioral aspects such as error handling for nonexistent categories, authorization requirements, or reversibility, so it is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences that are directly meaningful and front-loaded. Every word contributes to understanding the tool's purpose and a key side effect, with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and an output schema available, the description adequately covers the primary action and a crucial side effect. It does not mention potential constraints (e.g., cannot delete default categories) or detailed return behavior, but these are not essential given the tool's simplicity and the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the only parameter 'category_id' documented in the schema as 'Category ID to delete'. The description adds no additional parameter semantics beyond this, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a category') and the specific resource ('category'). It distinguishes itself from sibling tools like create_category_tool and rename_category_tool by being explicitly a delete operation, and the side effect about feeds distinguishes it from feed deletion tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you need to remove a category. It provides valuable context by noting that feeds become uncategorized, which helps an agent understand the consequences. However, it does not explicitly state when not to use it or name alternatives, though the side effect implicitly clarifies its domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. 'Get' implies a read operation, and 'details' plus 'entry counts' indicates the return content. But beyond that, there is no disclosure about side effects, permissions, or error behavior. It is minimally transparent but not richly descriptive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately communicates the core action and key output feature ('entry counts'). It wastes no words and is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, clear read intent) and the presence of an output schema (which presumably details the return structure), the description is sufficient. It doesn't explain every possible detail, but it covers the essential purpose and a distinguishing feature (entry counts), making it complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter (feed_id) has full schema coverage with a clear description ('Feed ID'). The description adds no additional meaning to the parameter, only emphasizing 'single feed,' which aligns with the schema. The baseline of 3 applies because the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get details for a single feed including entry counts.' It uses a specific verb ('Get') and resource ('single feed'), and explicitly distinguishes itself from list-oriented siblings by focusing on a single feed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the phrase 'single feed,' which suggests this is for retrieving one feed's details rather than listing all feeds. However, there is no explicit mention of when to use this tool instead of alternatives like list_feeds_tool, and no direct exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the sole source of behavior. It states the tool lists feeds with unread counts, implying a read-only operation, but it does not disclose potential side effects, authentication requirements, pagination, or ordering behavior. The information is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and information-dense. It communicates the tool's purpose without any filler or redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and has an output schema, so the description need not explain return values. The description is adequate but omits mentioning the optional category filter, which is a minor gap for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the one parameter (category_id) with clear documentation, and coverage is 100%. The description does not add any additional meaning about the parameter; in fact, saying 'all feeds' slightly contrasts with the optional filter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all feeds with unread counts' uses a specific verb ('list') and clearly identifies the resource ('feeds') and additional detail ('unread counts'). It distinguishes itself from sibling tools like get_feed_tool (specific feed) and list_categories_tool (categories).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to see all feeds) but provides no explicit guidance on when to choose this over alternatives like get_feed_tool or list_entries_tool. There are no exclusion criteria or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. The verb 'Get' clearly implies a read-only operation, and the description does not mention any side effects, permissions, or limitations. However, it does not explicitly state that the operation is safe or non-destructive, though that is strongly implied by the word 'get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, brief sentence that front-loads the core purpose and then lists the specific outputs. It contains no filler or redundant information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and an output schema exists (indicated by has output schema), the description covers all necessary context. It specifies what the dashboard stats include, and the output schema presumably details the return structure. The description is complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the instruction specifies a baseline of 4 for such cases. The description adds no parameter details because there are none to clarify; the schema is empty and fully covers the input requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('dashboard stats'), and enumerates the exact data it returns (total feeds, unread count, entries per category). This distinguishes it from sibling tools like list_feeds or list_entries, which are listing operations rather than summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description does not mention that this tool is suitable for an overview or that it should be used instead of counting entries via list_entries. Usage is only implied by the name and purpose, but no exclusions or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 disclose a behavioral trait beyond the literal import (creating categories from outline groups), which is helpful. However, it lacks details about whether the operation is additive, handles duplicates, or requires specific permissions, leaving important gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter import tool, the description is adequate, but it does not address potential edge cases like duplicate handling or invalid files. Since an output schema exists, return values are covered, but without annotations the description could be more thorough about side effects and error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single parameter 'file_path' as 'Path to the OPML file', and the description repeats this information without adding new semantics. With 100% schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Import feeds') and the resource ('from an OPML file'), and includes a distinguishing detail ('creating categories from outline groups') that sets it apart from related tools like add_feed_tool or export_opml_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the primary use case: when you have an OPML file to import feeds. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to know when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose the critical side effect that all entries are removed. However, it does not mention reversibility, permissions, or other potential cascading effects, so a slight gap remains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no redundant words. Every phrase earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description is sufficiently complete: it states the action and the important side effect. It lacks only minor usage prerequisites or error condition notes, which are not critical for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter (feed_id) with a clear definition, so the description adds no extra parameter meaning. Baseline 3 applies due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'remove' and resource 'feed', and explicitly states the side effect 'and all its entries', clearly distinguishing it from read/list/refresh siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternative mentions. The purpose is self-evident, but the description does not note that deletion is irreversible or that other feeds should not be affected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the output includes feed counts, which is a useful behavioral detail. However, it does not explicitly state that this is a read-only operation or mention any potential side effects, though for a listing tool this is largely self-evident. The description adds some transparency but not extensive context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and subject. Every word contributes value; no redundancy. It is highly appropriate for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists, and the operation is simple, the description fully covers what the agent needs to know. Additional details would be unnecessary. The description is complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is no parameter information to add; the schema is empty and fully covered. The description does not need to explain parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('all categories') with an additional detail ('with feed counts'), clearly distinguishing it from sibling tools that create, rename, or delete categories. It unambiguously states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the name and description, but there is no explicit guidance on when to use this tool versus alternatives. Given the sibling tools are all different operations (create/rename/delete), the context is clear enough, but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It discloses the output format (OPML XML string) and scope (all feeds), but does not mention potential side effects, performance considerations, or authentication requirements. For a read-only export operation, this is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and includes no extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, output schema present), the description is complete. It tells the user exactly what the tool does and what output format to expect, without needing to explain return values due to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the empty input schema confirms this. Per the rubric, a baseline of 4 is appropriate when there are no parameters, and the description correctly implies no input is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Export all feeds as OPML XML string' uses a specific verb ('Export') and resource ('all feeds') with a clear output format ('OPML XML string'). It clearly distinguishes from siblings like import_opml_tool and list_feeds_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states what the tool does, providing enough context for a parameterless export tool. However, it does not explicitly mention alternatives or when not to use it, so it lacks the explicit exclusions that would warrant a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly discloses the side effect 'auto-marks as read', which is critical for a read operation. No other behavioral traits (e.g., pagination, error cases) are mentioned, but the output schema covers return structure, and the side effect is the most important extra behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the primary action and a key side effect. Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one simple parameter and an output schema, the description fully covers what the agent needs to know: the operation (get full content) and the side effect (auto-mark as read). The presence of an output schema means return values are documented elsewhere. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (entry_id is described as 'Entry ID'). The description adds no additional meaning beyond the schema, so it meets the baseline of 3 but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('full content of an entry'), clearly distinguishing it from siblings like list_entries_tool (which likely returns summaries) and mark_read_tool (which only marks as read). The parenthetical 'auto-marks as read' adds precise scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'full content' implies the tool is for retrieving complete entry data, contrasting with list-type tools. The auto-mark behavior signals a side effect to consider, providing clear context. However, it does not explicitly state alternatives or exclusions (e.g., 'use mark_read_tool if you do not want to fetch content'), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does well by disclosing network access, slowness (30-60s), and that it refreshes feeds. It falls short of fully explaining side effects on cached data or failure behavior, but the provided context (network, slow, 'for all feeds') is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero fluff. The most critical information (purpose, performance, alternatives) is front-loaded and each sentence earns its place. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's network complexity and slow execution, the description adequately covers what it does, how long it takes, and how it relates to background timers and cached reads. The presence of an output schema covers return values, but mentioning potential side effects or failure modes would make it fully complete. Still, for a single-parameter refresh tool, this is nearly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter feed_id is already well described in the schema ('Specific feed ID to refresh (optional, refreshes all if omitted)') with 100% coverage. The description's extra note about 'all feeds' confirms the default but adds no new semantic detail, so the schema-driven baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Crawl feed sources over the network for new content.' It distinguishes itself from siblings by contrasting with list_entries for reading cached content, making it unmistakable as the refresh/update operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Prefer the systemd timer for background updates' and 'Use list_entries to read cached content.' This tells the agent when not to call this tool directly and points to the appropriate alternative, meeting the highest bar for usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-feed-reader MCP server](https://glama.ai/mcp/servers/crunchtools/mcp-feed-reader/badges/card.svg)](https://glama.ai/mcp/servers/crunchtools/mcp-feed-reader)

Score Badge

Copy to your README.md:

[![mcp-feed-reader MCP server](https://glama.ai/mcp/servers/crunchtools/mcp-feed-reader/badges/score.svg)](https://glama.ai/mcp/servers/crunchtools/mcp-feed-reader)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/crunchtools/mcp-feed-reader'

If you have feedback or need assistance with the MCP directory API, please join our Discord server