FreshRSS MCP Server

Server Quality Checklist

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

Latest release: v1.0.0-beta.4
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific resources and actions in the FreshRSS domain. For example, list_articles vs. mark_as_read vs. subscribe are unambiguous, and even similar tools like add_labels and remove_labels are clearly differentiated by their opposing actions.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern throughout, such as list_articles, edit_feed, delete_folder, and mark_as_read. There are no deviations in style or convention, making the tool set highly predictable and readable.
Tool Count3/5
With 27 tools, the count is on the high side for an RSS server, bordering on heavy. While it covers many operations, it may feel overwhelming compared to a more streamlined set of 3-15 tools, though it is not extreme like 50+ tools.
Completeness5/5
The tool set provides comprehensive CRUD and lifecycle coverage for RSS feed management, including subscription handling, article reading/starring, labeling, folder management, and import/export. No obvious gaps exist; agents can perform all core workflows without dead ends.
Average 3/5 across 27 of 27 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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 of behavioral disclosure. While 'Delete' implies destruction, the description doesn't specify what happens to articles tagged with this label, whether the operation is permanent, or if there are prerequisites.
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 three-word fragment. While not verbose, it is under-substantive rather than efficiently concise—every sentence (here, fragment) does not earn its place given the ambiguity around folders vs. labels and delete vs. remove operations.
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 the complexity suggested by sibling tools (distinctions between labels and folders, deletion versus removal), the description is incomplete. It fails to clarify whether this deletes the label category entirely or removes it from articles, and doesn't address the folder/label relationship noted in the 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 description coverage is 100% (the 'name' parameter is fully described in the schema as 'Name of the folder/label to delete'). The description adds no parameter semantics beyond the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a label' is a tautology that restates the tool name. It fails to distinguish from siblings like 'remove_labels' (which likely removes labels from articles rather than deleting the label definition) and 'delete_folder' (given the schema mentions 'folder/label').
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 provided on when to use this versus 'remove_labels' or 'delete_folder'. Given the schema description conflates 'folder/label', the description should clarify the specific use case but does not.
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 the full burden of behavioral disclosure. While 'Rename' implies a mutation, the description fails to specify what happens if oldName doesn't exist, whether the operation is atomic, if it affects articles currently tagged with the label, or any permission requirements.
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 extremely brief at only three words. While it wastes no words, it is arguably too minimal to provide necessary context for a mutation operation with no annotations. However, it meets the criteria of being appropriately sized for conciseness (not verbose).
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 this is a mutation tool with no annotations and no output schema, the description is insufficient. It lacks differentiation from similar sibling tools, error handling context, and behavioral constraints needed for safe invocation, falling below minimum viable completeness for this complexity level.
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 input schema has 100% description coverage for both parameters (oldName and newName). The description 'Rename a label' adds no additional semantic context beyond what the schema already provides, warranting the baseline score for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Rename a label' is tautological, merely restating the tool name 'rename_label'. It fails to distinguish this tool from its sibling 'rename_folder', which is critical given the parameter descriptions reference 'folder/label' and both tools exist on the same server.
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 provided on when to use this tool versus alternatives (e.g., rename_folder), prerequisites (such as label existence), or error conditions. The description offers no 'when-to-use' or 'when-not-to-use' context.
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, and the description carries the full burden of behavioral disclosure. It fails to indicate whether the operation is idempotent, what happens if 'newName' already exists, or whether this is a destructive operation that affects nested feeds/articles.
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 extremely brief (four words), which borders on under-specification rather than efficient conciseness. While it contains no wasted words, it lacks the necessary detail to be genuinely useful for tool selection.
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?
For a mutation tool with no annotations and no output schema, the description is inadequate. It lacks behavioral constraints, error conditions, and critical differentiation from the 'rename_label' sibling tool that would be necessary for correct agent invocation.
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 clear descriptions for 'oldName' and 'newName'. The description adds no additional semantic context about the parameters, but the schema is sufficient for understanding the inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action (rename) and target resource (folder/category), but creates ambiguity by using 'folder/category' interchangeably without clarifying the relationship to the sibling 'rename_label' tool. It does not distinguish when to use this versus the label-specific variant.
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 provided on when to use this tool versus 'rename_label' or other folder manipulation tools like 'delete_folder'. No mention of prerequisites (e.g., whether the folder must exist) or constraints on naming.
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 behavioral burden. While 'Get' implies a read-only operation, the description fails to disclose idempotency, caching behavior, computational cost, or the structure of the returned statistics.
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 extremely brief (four words) with no wasted content, but it borders on underspecification. It is front-loaded but lacks the necessary detail to be truly helpful without additional context.
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?
Given the absence of an output schema, the description partially compensates by mentioning 'unread counts and statistics' as return categories. However, it omits the structure, format, or specific statistical metrics (total feeds, per-feed counts, etc.) that would make it complete for a zero-parameter 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 input schema has zero parameters and 100% coverage trivially. According to scoring rules, this establishes a baseline of 4. No parameter semantics are needed or provided in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic action ('Get') and target data ('unread counts and statistics'), but 'statistics' remains vague about what specific metrics are returned. While 'unread counts' provides some specificity in the context of the feed-reader sibling tools, it lacks the granular resource scoping seen in top-tier definitions.
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 provided on when to use this versus siblings like 'list_unread_article_ids' (which returns IDs rather than counts) or 'get_user_info'. No prerequisites or conditions are mentioned.
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 of behavioral disclosure but fails to mention pagination, caching behavior, whether results are user-scoped, or the return format. 'List all' implies no filtering but doesn't clarify if this includes system labels or only user-created ones.
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 extremely concise at only four words with no wasted sentences. However, given the complete absence of annotations and output schema, the 'appropriate size' standard might require additional context about return values, preventing a perfect score.
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?
With no output schema and no annotations, the description should compensate by describing the return structure (e.g., whether it returns IDs, names, colors, or counts). The current description provides none of this necessary context for a list operation.
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 input schema has zero parameters with 100% description coverage (vacuously). Per the baseline rules for zero-parameter tools, this scores a 4 as there are no parameters requiring semantic clarification beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic operation ('List all labels/tags') with a clear verb and resource, but it is minimal and does not differentiate from sibling tools like add_labels or delete_label beyond the obvious verb difference. It clarifies that labels and tags may be synonymous in this system.
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 provided on when to use this tool versus alternatives like list_folders, or prerequisites for invocation. The agent is given no context about whether this should be called before add_labels or when labels need refreshing.
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 burden of behavioral disclosure. It fails to mention idempotency (what happens if labels already exist), side effects, or success/failure behavior for this state-modifying operation.
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?
Extremely concise at three words with no wasted text. However, for a mutation tool, this brevity may be insufficient rather than optimally structured, as it front-loads nothing about risks or constraints.
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?
As a mutation tool with no output schema and no annotations, the description should disclose behavioral traits and return value expectations. It provides neither, leaving significant gaps for safe agent operation.
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?
With 100% schema description coverage ('Article IDs to modify', 'Label names to add/remove'), the schema fully documents parameters. The description adds no additional semantic context beyond what the schema provides, warranting the baseline score.
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 verb (add) and resource (labels to articles), providing specific purpose. However, it lacks explicit differentiation from sibling tool 'remove_labels' regarding when to use each.
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 provided on when to use this tool versus alternatives like 'remove_labels', nor any prerequisites (e.g., whether labels must exist first) or conditions for use.
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 of behavioral disclosure but fails to specify whether the import is additive or destructive (replaces existing subscriptions), how it handles duplicate feeds, or what the return value indicates.
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 four-word description is maximally concise and front-loaded with the verb and resource. While efficient, it arguably sacrifices necessary behavioral context in favor of brevity given the lack of annotations or output schema.
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 data-import tool with no annotations and no output schema, the description provides minimal viable context by identifying the operation type and data format, but leaves significant gaps regarding conflict resolution, idempotency, and success/failure indicators.
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 input schema has 100% description coverage ('OPML XML content to import'), clearly indicating the parameter expects raw XML content rather than a file path. The tool description adds no additional parameter semantics, meeting the baseline expectation when the schema is self-documenting.
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 uses a specific verb ('Import') and identifies both the resource ('subscriptions') and format ('OPML'), distinguishing it from single-feed siblings like 'subscribe' or 'quickadd_feed'. However, it stops short of explicitly clarifying that this is a bulk operation for multiple feeds.
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 states what the tool does but provides no guidance on when to use this versus single-feed alternatives like 'subscribe' or 'quickadd_feed', nor does it mention prerequisites such as XML format requirements or size limitations.
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 mentions 'optional filtering' but fails to explain the override behavior where 'state' overrides other selectors and 'streamId' overrides all selectors, nor does it mention pagination capabilities.
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 single sentence is efficient with zero fluff—every word earns its place. However, given the tool's complexity (10 parameters, override rules, pagination), it is arguably undersized rather than perfectly concise.
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?
While the schema has excellent coverage of individual parameters, the description lacks synthesis of the behavioral model (override hierarchy, pagination). It is minimally viable given the rich schema, but an agent would benefit from explicit mention of the override rules and continuation token usage.
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 10 parameters well-documented in the schema itself. The description mentions 'optional filtering' which loosely references the parameters but adds no additional semantic meaning, syntax guidance, or examples beyond what the schema provides. Baseline 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?
States a clear verb (List) and resource (articles from FreshRSS) and mentions the filtering capability. However, it fails to distinguish from siblings like list_starred_article_ids or list_unread_article_ids, which return specific subsets of article IDs versus full articles.
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?
Provides no guidance on when to use this tool versus alternatives (e.g., list_starred_article_ids for just IDs). Does not mention pagination with continuation tokens or the parameter override hierarchy (state/streamId overrides) that is critical for correct invocation.
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 fails to indicate whether the operation is atomic (partial failure handling), idempotent (removing non-existent labels), or what constitutes success. No mention of side effects or permissions required.
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 extremely concise at four words with zero redundancy. Every word earns its place. However, given the lack of annotations and output schema, the description could benefit from additional sentences without violating conciseness principles.
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?
As a mutation tool with no annotations and no output schema, the description is insufficient. It does not describe the return value, success indicators, or error scenarios. The agent must know what happens when invalid article IDs or non-existent labels are provided.
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?
With 100% schema description coverage, the schema already documents both parameters ('Article IDs to modify' and 'Label names to add/remove'). The description adds no additional semantic information about parameter formats, validation rules, or constraints beyond the schema.
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 provides a clear verb (Remove), resource (labels), and scope (from articles). The phrase 'from articles' effectively distinguishes this tool from the sibling 'delete_label' tool, clarifying that labels are being unassigned rather than permanently deleted from the system.
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 like 'add_labels'. It does not mention prerequisites (e.g., that articles and labels must exist) or whether the operation is idempotent.
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 burden for behavioral disclosure. While 'star' implies a mutation, the description fails to disclose idempotency (can you star an already-starred article?), error handling for invalid IDs, or what constitutes success/failure.
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?
Extremely concise at only 4 words. No redundancy or filler, though given the lack of annotations and behavioral context, this brevity may be excessive rather than efficient.
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?
For a mutation operation with no annotations and no output schema, the description is inadequate. It lacks critical context about side effects, the relationship to 'list_starred_article_ids', and whether the operation is idempotent or destructive.
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% ('Article IDs to star/unstar'), so the parameter is already well-documented. The tool description adds no additional semantic context about the parameter format or constraints beyond the schema.
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?
Clearly states the action (star/favorite) and resource (articles), but does not explicitly distinguish from the sibling 'unstar_articles' tool or clarify that this specifically adds stars rather than toggles them.
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?
Provides no guidance on when to use this tool versus 'unstar_articles' or other article management tools like 'mark_as_read'. No mention of prerequisites or preconditions for starring.
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 of behavioral disclosure but offers minimal information. It implies state mutation (creating a subscription) but does not clarify side effects like immediate article fetching, duplicate handling, or failure modes.
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 single sentence is efficiently structured with the action front-loaded. However, at only five words, it is arguably too terse given the tool's mutative nature and the presence of similar sibling tools, leaving room for one clarifying sentence.
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?
For a state-mutating tool with no annotations and no output schema, the description is insufficient. It lacks critical context such as confirmation of what the operation returns, error conditions, or whether the subscription persists immediately.
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 input schema has 100% description coverage for all three parameters (url, title, category). Since the schema fully documents the parameters, the baseline score applies even though the description adds no additional semantic context beyond the schema.
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 provides a clear verb ('Subscribe') and resource ('RSS feed'), making the basic purpose understandable. However, it fails to differentiate from the sibling tool 'quickadd_feed', which likely performs a similar function.
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 'quickadd_feed', nor are prerequisites mentioned (e.g., verifying the feed URL is accessible). The description offers no selection criteria.
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 provided, so description carries full burden. Fails to disclose whether this permanently deletes the feed and its articles, merely stops updates, or is reversible. Doesn't mention authentication requirements or rate limits.
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?
Extremely concise at 4 words with no filler. Front-loaded with the action verb. However, 'appropriately sized' is debatable given the lack of behavioral transparency, though that's penalized in other dimensions.
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?
Inadequate for a state-modifying tool with no annotations. Missing crucial context: what happens to existing articles, whether the operation is destructive, success/failure indicators, and relationship to the subscribe sibling 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?
Schema has 100% description coverage ('ID of the feed to unsubscribe from'), so baseline is 3. Description adds no additional semantic context about the parameter format, validation rules, or how to obtain valid feed IDs.
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?
States a specific verb (unsubscribe) and resource (RSS feed). Clear enough to distinguish from sibling 'subscribe' by virtue of being the inverse operation, though it doesn't explicitly contrast with other feed management tools like delete_folder or edit_feed.
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?
Provides no guidance on when to use versus alternatives, prerequisites (e.g., verifying feed exists), or side effects. Doesn't mention that feedId should likely come from list_feeds or that subscribe is the reverse operation.
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 the full burden of behavioral disclosure. It fails to indicate whether this is a cached operation, what format the user information takes, privacy sensitivity of returned data, or whether it requires specific permissions. The phrase 'Get' implies read-only, but this isn't explicit.
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 appropriately terse for a zero-parameter tool. It front-loads the action and subject without filler words, making it scannable. Given the simplicity of the operation, the brevity is justified.
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?
While the tool concept is simple, the lack of an output schema means the description should ideally hint at the return structure (e.g., 'returns user profile including username and email'). As written, it meets minimum viability but leaves the agent uncertain about what data fields to expect in the response.
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 input schema has zero parameters, which per guidelines establishes a baseline of 4. The description doesn't need to compensate for missing parameter documentation, though it doesn't add any context about why no parameters are needed (e.g., 'uses current authenticated session').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic action ('Get') and resource ('current user information'), but 'information' is vague—it doesn't specify whether this returns profile data, preferences, account settings, or authentication status. While it implicitly distinguishes from feed/folder management siblings, the lack of specificity on what user data is returned limits its utility.
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 provided on when to use this versus other tools, prerequisites (e.g., authentication requirements), or when not to use it. The description stands alone without contextual usage hints.
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 of behavioral disclosure but fails to specify the return format (URLs, base64 data, binary blobs), pagination behavior, or authentication requirements. While 'List' implies read-only, the description does not confirm idempotency or side effects.
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 consists of a single, front-loaded sentence with no redundant words or filler. It immediately communicates the core operation. However, given the lack of output schema and annotations, the extreme brevity borders on under-specification rather than optimal 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?
While adequate for a zero-parameter tool, the description fails to compensate for the missing output schema by describing the returned data structure. It also omits the relationship to `get_feed_favicon`, which is critical context given the sibling tool names suggest overlapping functionality.
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 input schema contains zero parameters, establishing a baseline score of 4. The description does not need to elaborate on parameter semantics, though it correctly implies no filtering arguments are accepted (listing all subscribed feeds).
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 uses the specific verb 'List' with resource 'favicons' and scope 'subscribed feeds', clearly stating the tool's function. The 'Fever API' parenthetical adds protocol context. However, it lacks explicit differentiation from the sibling tool `get_feed_favicon`, which appears to perform a similar operation for individual feeds.
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 bulk listing tool versus the singular `get_feed_favicon`, nor does it mention prerequisites, rate limits, or caching behavior. The agent receives no signals about optimal invocation patterns.
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 provided, so description carries full burden. While 'List' implies read-only behavior, the description lacks critical details: return format (IDs, names, objects?), pagination behavior, hierarchical structure, or whether empty folders are included.
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?
Extremely brief at 4 words, but appropriately sized for a simple parameterless operation. Front-loaded with verb first. No redundant filler, though bordering on under-specification.
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?
Given zero parameters and simple list semantics, description is minimally viable. However, lacks explanation of return values (critical since no output schema exists) and folder semantics within this feed management system.
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?
Tool accepts zero parameters. Per scoring guidelines, baseline is 4 for parameterless tools. Schema coverage is vacuously 100% with empty properties object.
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?
Uses specific verb 'List' and identifies target resource 'folders/categories'. Distinguishes from siblings like list_labels and list_feeds by resource name, though could clarify what folders contain (feeds vs articles) to strengthen differentiation.
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?
Provides no guidance on when to use this versus list_labels, nor does it explain the relationship between folders and categories (synonyms or distinct?). No prerequisites or contextual conditions mentioned.
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 provided, so description carries full burden. While 'Fever API' hints at the protocol, the description lacks critical behavioral details: pagination behavior, rate limiting, whether the operation is read-only (implied but not stated), or what the return format looks like (array of integers, strings?).
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?
Extremely concise at 6 words. Appropriately sized for a zero-parameter tool with no complex options. Front-loaded with the action verb. However, brevity borders on under-specification given the lack of output schema or annotations.
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?
Minimal but adequate for low complexity (zero params, simple list operation). However, with no output schema provided, the description should ideally specify the return structure (e.g., 'returns array of integer IDs'). Mentioning 'IDs' in the description partially addresses this but lacks format specificity.
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?
Input schema has zero parameters with 100% coverage (empty object). Per evaluation rules, zero-parameter tools baseline at 4. The description doesn't need to compensate for missing schema documentation, though it could have clarified if filters were available via other means.
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?
Clear verb 'List' and specific resource 'unread article IDs'. The 'Fever API' parenthetical adds context. However, it doesn't explicitly distinguish from sibling 'list_articles' (which likely returns full article objects vs. just IDs) or clarify the difference between 'unread' and 'starred' states relative to 'list_starred_article_ids'.
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 on when to use this versus 'list_articles' or 'list_starred_article_ids'. Doesn't mention prerequisites like authentication or that unread status is typically managed via 'mark_as_read'/'mark_as_unread' siblings. Zero guidance on selection criteria.
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 the full burden. It states the action (marking as read) but fails to disclose behavioral traits such as whether the operation is reversible (via 'mark_as_unread'), potential performance implications for large streams, or that it modifies article state.
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, efficient sentence with no wasted words. It is appropriately front-loaded with the action and scope.
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?
Given the simple two-parameter structure with complete schema coverage, the description is minimally viable. However, it lacks mention of return values or success/failure behavior, which would be helpful given the absence 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 description coverage is 100%, establishing a baseline of 3. The description implies the streamId parameter by mentioning 'in a stream' but adds no semantic details beyond what the schema already provides for 'streamId' or 'olderThan'.
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 uses a specific verb ('Mark') and resource ('articles in a stream'), and distinguishes itself from sibling tool 'mark_as_read' by specifying 'all'. However, it does not explicitly clarify the distinction between bulk vs. individual marking 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 explicit guidance on when to use this tool versus 'mark_as_read' or other alternatives. While the word 'all' implies bulk usage, there are no explicit when/when-not conditions or prerequisites (e.g., warnings about large streams).
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 of behavioral disclosure. While 'Mark' implies a mutation, the description fails to disclose whether the operation is reversible (via 'mark_as_unread'), what the return value or success indicators are, or whether there are any side effects like triggering sync operations.
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, efficient sentence with six words. It is appropriately front-loaded with the action and target, containing zero redundant or wasted language.
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?
Given the tool's simplicity (single parameter, no output schema), the description adequately covers the core functionality but leaves gaps. It could be improved by mentioning that this affects specific articles (differentiating from the 'all' variant) or noting that 'mark_as_unread' reverses this operation.
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 input schema has 100% description coverage ('Article IDs to mark'), establishing a baseline score of 3. The description adds minimal semantic value beyond the schema, though it reinforces the cardinality constraint ('one or more') which aligns with minItems: 1 in the schema.
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 uses a specific verb ('Mark') and resource ('articles') with a clear state change ('as read'). It implicitly distinguishes from siblings like 'mark_all_as_read' (via 'one or more' vs. implied 'all') and 'mark_as_unread' (opposite state), though it doesn't explicitly name these alternatives.
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 like 'mark_all_as_read' (for bulk operations) or 'mark_as_unread' (for the reverse action). It also doesn't indicate that article IDs should typically be sourced from 'list_articles' or similar tools.
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. While 'mark' implies a state mutation, the description does not clarify whether this is a destructive operation, if it is idempotent, or what happens when article IDs do not exist. It fails to disclose write-specific behaviors like authentication requirements or rate limiting.
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 a single, efficient sentence that leads with the action verb and specifies scope without filler words. Every word serves to clarify the operation's intent and cardinality. No restructuring or compression is needed.
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 single-parameter state-change operation with complete schema documentation, the description covers the essential functional contract. However, given the absence of annotations and output schema, the lack of behavioral context (side effects, error conditions) and differentiation from similar tools leaves minor gaps in contextual completeness.
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 input schema has 100% description coverage with 'Article IDs to mark', establishing a baseline understanding. The description adds the constraint 'one or more' which reinforces the schema's `minItems: 1` requirement, but does not elaborate on ID format, source, or validation rules. Since the schema fully documents the parameter, additional semantic detail is minimal.
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 'Mark one or more articles as unread' provides a specific verb (mark), resource (articles), and target state (unread). It implicitly distinguishes from the sibling tool `mark_all_as_read` by specifying 'one or more' rather than 'all'. However, it does not explicitly contrast with `mark_as_read` to clarify when to mark as unread versus read.
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 its siblings like `mark_as_read` or `mark_all_as_read`. It does not specify prerequisites such as needing valid article IDs from `list_articles` or whether this operation is reversible. Without explicit when-to-use context, the agent must infer from the name alone.
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 provided, so description carries full disclosure burden. While 'Remove' implies a write operation, the description omits mutation semantics, side effects, failure modes (invalid IDs, non-existent articles), or whether the operation is idempotent.
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?
Extremely concise single sentence with zero redundancy. Information is front-loaded and every word serves a purpose.
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?
Adequate for a low-complexity single-parameter tool with complete schema documentation. However, given the absence of annotations and output schema, the description should ideally disclose behavioral traits (destructive nature, error handling) to be fully complete.
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%, establishing baseline 3. The description mentions 'one or more' (aligning with minItems: 1), but the schema already documents the array structure and constraints. Minimal semantic value added beyond the schema's 'Article IDs to star/unstar' description.
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?
Clear verb ('Remove star') and resource ('articles') immediately convey the tool's function. However, it lacks explicit differentiation from sibling tool 'star_articles' (e.g., no contrasting language like 'use this instead of star_articles to remove stars').
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?
Provides no guidance on when to use this tool versus alternatives, nor prerequisites such as obtaining valid article IDs from list_articles or list_starred_article_ids. No mention of idempotency or error conditions (e.g., unstarring already unstarred articles).
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 provided, so description carries full burden. Specifies output format (OPML) but fails to disclose return type (file content, download URL, or file path), idempotency, or whether operation is read-only.
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?
Extremely concise at 6 words. No redundant text; every word conveys essential information (action, scope, format).
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?
Adequate for a simple export tool but lacks output specification due to missing output schema. Without annotations or return value description, agent cannot predict response structure.
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?
Zero parameters present. Per scoring rules, 0 params baseline is 4. Description correctly implies no filtering is possible via 'all subscriptions'.
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?
Clear verb (Export) and resource (all subscriptions) with specified format (OPML). Scope ('all') is explicit and matches the parameterless schema. Distinguishes directionally from sibling import_opml, though doesn't explicitly mention RSS/Atom context.
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 when-to-use guidance or comparison to alternatives like import_opml or list_feeds. Doesn't indicate typical use cases (backup, migration, etc.).
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 clarifies the return format (MCP resource) and references the Fever API context, but omits error handling (e.g., missing favicons), caching behavior, or whether this is a read-only operation.
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 single-sentence description is efficiently structured and front-loaded with the core action. However, the parenthetical '(Fever API)' adds domain context that may be opaque without external knowledge, slightly reducing clarity-per-word efficiency.
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?
Given the tool's simplicity (single parameter) and lack of output schema, the description adequately covers the basic operation but lacks completeness regarding error states, return value structure, or Fever API specific behaviors.
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 input schema has 100% description coverage for the feedId parameter. The description does not add additional semantic meaning, syntax examples, or validation rules beyond what the schema already provides, warranting the baseline score.
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 uses a specific verb ('Get') and resource ('feed favicon') and clarifies the output format ('as an MCP resource'). While it implies singularity (distinguishing from list_favicons), it does not explicitly differentiate when to use this versus the sibling list_favicons 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 like list_favicons, nor does it mention prerequisites such as needing a valid feedId from list_feeds first.
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 the full burden of behavioral disclosure. It states 'List' implying a read-only operation, but fails to describe the return format, pagination behavior, or what properties are included for each feed (titles, URLs, IDs).
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 a single, efficient sentence with zero redundant words. It is appropriately front-loaded with the action and scope immediately clear.
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?
Given the tool's simplicity (zero parameters) and lack of output schema, the description adequately covers the basic operation but leaves significant gaps regarding the structure and content of the returned feed data. For an unannotated tool without output schema, more detail on return values would be expected for a higher score.
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 input schema contains zero parameters, which establishes a baseline score of 4 per the evaluation rules. The description correctly implies no filtering is possible by stating 'all' feeds will be returned.
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 uses a specific verb ('List') and resource ('subscribed RSS feeds') that clearly distinguishes this from sibling tools like list_articles, list_folders, or list_labels. However, it stops short of being fully comprehensive by not clarifying what constitutes a 'feed' in this context (e.g., URLs, metadata, etc.).
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. While the tool name is descriptive, there is no explicit mention of prerequisites, ordering constraints (e.g., check existence first), or exclusion criteria.
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 successfully explains the auto-detection mechanism ('detect the actual feed'), but omits whether the operation is idempotent, what happens if the feed already exists, or what the tool returns upon success.
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, efficient sentence of 12 words with zero redundancy. It front-loads the action and immediately follows with the mechanism, demonstrating optimal information density.
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?
Given the single-parameter, simple operation with no output schema, the description covers the core mechanism adequately. However, it lacks guidance on the relationship to 'subscribe' and does not indicate whether the tool returns the newly created feed ID or confirmation status.
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% ('Website or feed URL to quick-add'), so the schema fully documents the parameter. The description reinforces that the URL can be either a website or direct feed, but adds no additional semantic detail beyond what the schema 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 uses a specific verb ('Quick-add') and resource ('feed URL'), and distinguishes itself from siblings via the 'FreshRSS will detect the actual feed' clause, implying auto-discovery functionality that differs from manual subscription methods.
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 when-to-use or when-not-to-use guidance is provided. The sibling tool 'subscribe' likely offers an alternative subscription method, but the description fails to clarify which tool to use for manual vs. automatic feed addition.
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 full burden but lacks disclosure of error behavior (invalid feedId), whether both title and category can be updated atomically in one call, or side effects like URL preservation. Only states the two possible operations without behavioral 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?
Single sentence of 8 words with zero redundancy. Main clause states the action, parenthetical efficiently specifies the two modification modes. Every element earns its place.
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?
Adequate for a simple metadata-update tool with complete schema coverage, but gaps remain regarding partial update semantics, error scenarios, and confirmation of whether both parameters can be provided simultaneously given no output schema or annotations.
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%, establishing baseline 3. The description maps conceptual operations ('rename'→title, 'move'→category) but adds no syntax details, format constraints, or examples beyond what the schema already provides.
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 specific verb 'Edit' with resource 'feed subscription' and parenthetically clarifies the two supported operations (rename/move), clearly distinguishing it from siblings like 'subscribe' (create), 'unsubscribe' (delete), and 'rename_folder' (different resource).
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?
Implies usage for existing feeds through the word 'Edit', but provides no explicit when-to-use guidance contrasting with 'subscribe' for new feeds or 'unsubscribe' for removal, nor mentions that feedId must reference an existing subscription.
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 provided, so description carries full burden. While 'List' implies read-only, it does not confirm safety, disclose pagination behavior, rate limits, or return format (e.g., array of integers). 'Fever API' hint is the only behavioral clue.
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?
Single efficient sentence of 6 words. Front-loaded with action and resource. No redundant or filler text; every word earns its place for this simple retrieval tool.
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?
Given zero parameters and simple purpose, description adequately identifies the return concept ('IDs'). However, with no output schema and no annotations, it omits return type structure (array format) and behavioral constraints that would help invocation.
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?
Input schema has zero parameters, establishing baseline 4. Description appropriately does not invent parameter semantics where none exist.
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?
Specific verb 'List' plus exact resource 'starred/saved article IDs' clearly distinguishes from sibling 'list_articles' (full objects) and 'list_unread_article_ids' (different filter). The 'Fever API' parenthetical adds useful protocol context.
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 on when to use this versus 'list_articles' (which likely returns full article metadata) or how it relates to mutation siblings 'star_articles'/'unstar_articles'. Lacks explicit when-to-use criteria.
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 provided, so description carries full burden. It discloses the critical side effect that feeds are moved to default rather than deleted, but omits other behavioral traits like reversibility, idempotency, permission requirements, or error conditions.
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?
Single sentence with action front-loaded ('Delete a folder/category') and critical side effect in efficient parenthetical. Zero waste; every word earns its place for a simple 1-parameter tool.
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?
Appropriate for a simple destructive operation with 100% schema coverage. The description addresses the essential user concern (what happens to feeds?) but could strengthen completeness by noting irreversibility or error cases given the lack of annotations.
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 has 100% description coverage ('Name of the folder/label to delete'), establishing baseline 3. The description doesn't add syntax details, format constraints, or examples beyond what the schema 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?
Clear verb 'Delete' and resource 'folder/category'. The parenthetical '(feeds will be moved to default)' clarifies scope and side effects. Distinguishes from label operations via 'folder/category' terminology but doesn't explicitly contrast with sibling 'delete_label'.
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 vs alternatives (e.g., rename_folder), but the side effect disclosure '(feeds will be moved to default)' implicitly guides usage by clarifying data preservation behavior. Lacks explicit exclusions or prerequisites.
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:

[![freshrss-mcp MCP server](https://glama.ai/mcp/servers/alysson-souza/freshrss-mcp/badges/card.svg)](https://glama.ai/mcp/servers/alysson-souza/freshrss-mcp)

Score Badge

Copy to your README.md:

[![freshrss-mcp MCP server](https://glama.ai/mcp/servers/alysson-souza/freshrss-mcp/badges/score.svg)](https://glama.ai/mcp/servers/alysson-souza/freshrss-mcp)

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/alysson-souza/freshrss-mcp'

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