inoreader-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources or actions, such as get_articles for fetching content and manage_subscription for feed management. However, some overlap exists between get_articles and get_article_ids, where the latter is a lightweight version, which could cause minor confusion if not carefully described.
Naming Consistency5/5
Tool names consistently follow a verb_noun pattern throughout, such as get_articles, list_subscriptions, and manage_tags. There are no deviations in naming conventions, making the set predictable and easy to understand.
Tool Count5/5
With 12 tools, the server is well-scoped for RSS feed management, covering authentication, subscription handling, article retrieval, and user interactions. Each tool serves a clear purpose without redundancy, fitting typical tool count ranges for such a domain.
Completeness4/5
The tool surface provides comprehensive coverage for RSS feed operations, including CRUD-like actions for subscriptions and tags, article management, and user info. A minor gap is the lack of a tool for directly editing or deleting individual articles, but agents can work around this using batch operations in manage_tags.
Average 4.1/5 across 12 of 12 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

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. It discloses a cost ('Costs 1 Zone 1 request'), which is useful behavioral context (e.g., rate limit implications). However, it doesn't cover other traits like pagination, error handling, or authentication needs, leaving gaps for a mutation-free tool.
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 front-loaded with the core purpose in the first sentence and adds a cost note in the second. Both sentences earn their place by providing essential information without redundancy, making it efficiently structured and appropriately sized.
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 low complexity (1 optional parameter, no output schema, no annotations), the description is minimally complete. It covers the purpose and cost but lacks details on output format (e.g., what 'metadata' includes) and usage context, which could help an agent invoke it 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?
Schema description coverage is 100%, so the schema fully documents the single parameter ('folder'). The description doesn't add any parameter-specific information beyond what's in the schema, resulting in the baseline score of 3 for adequate coverage without extra value.
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 ('List') and resource ('all RSS feed subscriptions') with specific attributes ('folders, URLs, and metadata'), making the purpose explicit. However, it doesn't differentiate from sibling tools like 'list_folders_and_tags' or 'analyze_feeds', which prevents a perfect score.
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_folders_and_tags' or 'analyze_feeds'. It mentions a cost ('Costs 1 Zone 1 request'), which hints at usage considerations, but lacks explicit when/when-not instructions or named alternatives.
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 of behavioral disclosure. It adds value by mentioning the cost ('Costs 1 Zone 1 request'), which informs about rate limits or resource usage. However, it lacks details on permissions, response format, pagination, or error handling, leaving gaps in behavioral context for a list operation.
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 highly concise and front-loaded: it states the purpose in the first part and adds cost information in a second, efficient sentence. Every sentence earns its place by providing essential information without waste, making it easy for an agent to parse quickly.
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 complexity (simple list operation with 0 parameters) and lack of annotations and output schema, the description is somewhat complete but has gaps. It covers the purpose and cost, but doesn't explain what the output looks like (e.g., format, structure) or any behavioral nuances, which could hinder correct invocation by an agent.
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 0 parameters with 100% coverage, meaning no parameters are documented. The description doesn't add parameter details, which is appropriate since there are none. It compensates by not introducing confusion, but it doesn't provide extra semantic context beyond the schema, which is minimal here.
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 tool's purpose: 'List all folders, tags, and labels.' It specifies the verb ('List') and the resources ('folders, tags, and labels'), making the action and target explicit. However, it does not differentiate from sibling tools like 'list_subscriptions' or 'manage_tags', which could have overlapping functionality, so it doesn't fully distinguish from 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. It mentions a cost ('Costs 1 Zone 1 request'), which hints at resource usage but doesn't specify contexts, prerequisites, or exclusions. Without explicit when/when-not instructions or named alternatives, the agent lacks clear usage direction.
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 full burden of behavioral disclosure. It successfully reveals the cost implication ('Costs 1 Zone 2 request'), which is a critical behavioral trait not evident from the schema. It doesn't cover other aspects like error conditions, response format, or permission requirements, but the cost disclosure adds significant value beyond the basic action 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 perfectly concise with two sentences: the first states the core purpose, and the second adds critical behavioral information (cost). Every word earns its place, and the structure is front-loaded with the most important information about what the tool does.
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 mutation tool with 6 parameters, no annotations, and no output schema, the description provides adequate but incomplete context. It covers the purpose and cost implications well, but doesn't address response format, error handling, or permission requirements. The schema handles parameter documentation, but behavioral aspects beyond cost are missing.
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 schema already documents all 6 parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't explain parameter interactions or provide examples). This meets the baseline expectation when schema coverage is complete.
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 specific verbs ('Add, edit, or remove') and resource ('an RSS feed subscription'), distinguishing it from sibling tools like list_subscriptions (which only reads) and manage_tags (which handles tags rather than subscriptions). It provides a complete action-oriented summary in the first sentence.
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 context through the cost statement ('Costs 1 Zone 2 request'), suggesting this is for subscription management operations. However, it doesn't explicitly state when to use this tool versus alternatives like list_subscriptions (for viewing) or setup_auth (for authentication), nor does it provide prerequisites or exclusions for different actions.
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 full burden of behavioral disclosure. It effectively describes key behavioral traits: the cost ('Costs 1 Zone 1 request per page'), pagination details ('max 100 articles per page'), and filtering capabilities. However, it does not cover aspects like error handling or response format, leaving some 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 front-loaded with the core purpose, followed by key features and behavioral details in two concise sentences. Every sentence adds value (e.g., filtering options and cost information) with zero waste, making it efficient 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?
Given the complexity (6 parameters, no output schema, no annotations), the description is largely complete: it covers purpose, filtering, pagination, and cost. However, it lacks details on the return format (e.g., article structure) and error cases, which would be beneficial for an agent invoking the tool without 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?
The schema description coverage is 100%, so the input schema already documents all parameters thoroughly. The description adds marginal value by mentioning filtering and pagination context, but does not provide additional semantics beyond what the schema specifies. This meets the baseline for high 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 clearly states the action ('Fetch articles') and the resources ('from a feed, folder, tag, or all items'), distinguishing it from siblings like get_article_ids (which returns IDs only) or get_unread_counts (which returns counts). It specifies the scope of retrieval, making the purpose explicit and differentiated.
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 by mentioning filtering capabilities and pagination, but does not explicitly state when to use this tool versus alternatives like get_article_ids or analyze_feeds. It provides some context (e.g., filtering by status) but lacks explicit guidance on tool selection among siblings.
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 full burden. It discloses the mutation behavior ('Mark as read'), the cost implication ('Costs 1 Zone 2 request'), and the scope ('all articles'). However, it doesn't mention permissions, side effects, or response format, leaving some behavioral 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?
Two sentences with zero waste: the first states the purpose and scope, the second adds critical cost information. It's front-loaded with the core action and appropriately sized for the tool's complexity.
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 mutation tool with no annotations and no output schema, the description covers the core action, scope, and cost, but lacks details on permissions, response format, or error handling. Given the 2-parameter schema with full coverage, it's mostly complete but could benefit from more behavioral 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%, so the schema already fully documents both parameters. The description doesn't add any parameter-specific details beyond what's in the schema, such as explaining 'stream_id' formats or 'before' date handling. Baseline 3 is appropriate when schema does the heavy lifting.
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 specific action ('Mark all articles as read'), the target resource ('in a feed or folder'), and distinguishes it from siblings like 'get_unread_counts' (which only reads) or 'manage_tags' (which modifies tags). It provides a complete verb+resource+scope statement.
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 context by specifying it applies to feeds or folders, but doesn't explicitly state when to use it versus alternatives like 'manage_tags' for tagging or 'get_unread_counts' for checking status. No explicit exclusions or prerequisites 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?
No annotations are provided, so the description carries the full burden. It describes the conditional behavior based on the 'code' parameter and mentions OAuth 2.0 flow, but doesn't disclose important behavioral traits like error handling, token expiration, required permissions/scopes, or whether this creates persistent authentication state. The description adds basic context but lacks comprehensive behavioral disclosure.
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 perfectly concise with two sentences that each earn their place: the first establishes the core purpose, the second explains the conditional behavior. It's front-loaded with the main action and wastes no words while covering essential information.
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 this is an authentication tool with no annotations and no output schema, the description should do more to explain what 'returns the authorization URL' and 'exchanges it for access tokens' actually means in practice. While it covers the basic conditional flow, it lacks details about return formats, error conditions, and the overall authentication lifecycle that would be important for an agent to use this tool effectively.
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 schema already fully documents the single 'code' parameter. The description adds marginal value by explaining the conditional logic ('If no code is provided... If a code is provided...'), but doesn't provide additional semantic context beyond what the schema already states about the parameter's purpose and format.
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 specific action ('Authenticate with Inoreader via OAuth 2.0') and resource (authentication system), distinguishing it from all sibling tools which focus on feed analysis, article retrieval, subscription management, and other operational functions rather than authentication.
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?
The description explicitly provides when-to-use guidance: 'If no code is provided, returns the authorization URL to visit. If a code is provided, exchanges it for access tokens.' This clearly outlines the two distinct usage scenarios based on parameter presence, with no misleading or missing guidance.
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 full burden and adds valuable behavioral context: it specifies that this retrieves 'current authenticated' user info (implying authentication is required) and discloses the cost ('Costs 1 Zone 1 request'), which is useful for rate limit awareness. However, it doesn't describe response format or error 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?
The description is perfectly concise with two sentences that each earn their place: the first states the core purpose, and the second adds critical behavioral context (cost). There is zero waste or redundancy, and information is front-loaded appropriately.
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 read operation with 0 parameters and no output schema, the description is reasonably complete: it covers purpose, authentication context, and cost. However, without annotations or output schema, it could benefit from mentioning what user information is returned (e.g., profile, settings) to fully guide the agent.
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 0 parameters with 100% coverage, so the schema fully documents the absence of inputs. The description appropriately doesn't add parameter details, maintaining a baseline of 4 since no parameters need explanation beyond what the schema 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 clearly states the specific action ('Get') and resource ('current authenticated user information'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'get_articles' or 'get_rate_limit_status' by focusing on user data rather than content or system status.
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 for retrieving authenticated user data, but provides no explicit guidance on when to use this tool versus alternatives like 'get_rate_limit_status' for system info or 'setup_auth' for authentication management. It lacks clear when/when-not statements or named alternatives.
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 full burden of behavioral disclosure. It effectively describes the tool's actions (marking, applying/removing tags), supports batch operations, lists specific tag options, and mentions the cost ('Costs 1 Zone 2 request'), which adds valuable context beyond basic functionality. However, it doesn't detail error handling or response formats, leaving some behavioral aspects unclear.
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 sized and front-loaded, with the core purpose stated first ('Mark articles as read/unread/starred, or apply/remove custom tags'), followed by supporting details (batch operations, friendly names, cost). Every sentence adds value without redundancy, making it efficient 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?
Given the tool's moderate complexity (batch operations with multiple tag types), no annotations, and no output schema, the description does a good job covering key aspects like actions, parameters, and cost. However, it lacks details on error cases, response format, or prerequisites (e.g., authentication needs), which would enhance completeness for a mutation 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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by repeating tag options (e.g., 'read', 'starred') and mentioning batch operations, but doesn't provide additional syntax, constraints, or usage examples beyond what the schema specifies. This meets the baseline for high 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 clearly states the tool's purpose with specific verbs ('mark', 'apply/remove') and resources ('articles', 'tags'), distinguishing it from siblings like 'mark_all_read' (batch vs all) and 'list_folders_and_tags' (modify vs list). It explicitly mentions batch operations, which further differentiates its functionality.
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 for usage by listing supported actions (read/unread/starred, custom tags) and friendly names, and implies batch operations as a key feature. However, it lacks explicit guidance on when to use this tool versus alternatives like 'mark_all_read' (for all articles) or 'list_folders_and_tags' (for viewing only), which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 thoroughly describes key behavioral traits: the statistical methodology (Beta-Binomial Bayesian model with empirical Bayes prior), caching behavior (1-hour cache, cost differences between first and subsequent calls), cost implications (Zone 1 requests based on parameters), and the effect of parameter choices (e.g., 'shrinks small-sample feeds toward the global mean'). This goes well beyond basic functionality.
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 appropriately sized and front-loaded, starting with the core purpose and methodology. Each sentence adds valuable information about the model, ranking options, caching, and costs. While dense with technical details, there is minimal redundancy, and the structure logically progresses from what the tool does to how it behaves.
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 complexity of the tool (statistical modeling, 7 parameters, cost implications) and the absence of both annotations and an output schema, the description does an excellent job covering behavioral aspects, methodology, and usage considerations. The main gap is the lack of information about return values (format, structure), which would be helpful since there's no output schema, but the description compensates well with other contextual details.
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, providing detailed documentation for all 7 parameters. The description adds some semantic context by explaining how 'prior_strength' affects shrinkage and how 'starred_pages' impacts data quality and cost, but most parameter meaning is already covered in the schema. This meets the baseline of 3 for high 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 explicitly states the tool's purpose: 'Analyze feed health and engagement using a Beta-Binomial Bayesian model.' It specifies the exact statistical method, the metrics computed (engagement_rate, credible_lower), and distinguishes it from siblings by focusing on analytical modeling rather than data retrieval or management operations like 'get_articles' or 'manage_subscription'.
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 for when to use this tool: for analyzing feed engagement with Bayesian modeling, including caching behavior and cost implications. It mentions using 'credible_lower for conservative ranking' as an alternative sorting method, but does not explicitly state when not to use it or compare it directly to sibling tools like 'get_unread_counts' for simpler metrics.
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 full burden of behavioral disclosure. It effectively describes the lightweight nature of the operation, the cost implications, and the purpose (counting/batch operations). However, it doesn't mention pagination behavior (implied by continuation parameter) 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?
The description is extremely efficient - three sentences with zero waste. Each sentence adds distinct value: purpose, use cases, and cost information. It's perfectly front-loaded with the core functionality.
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 read-only tool with no output schema, the description provides good context about what the tool returns (IDs only, not full content) and its use cases. It could be more complete by mentioning the return format (e.g., list of IDs) or pagination details, but the cost information and lightweight nature are valuable additions.
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 schema already documents all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for high 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 clearly states the specific action ('Lightweight fetch'), resource ('article IDs from a stream'), and scope ('without full content'). It distinguishes from siblings like 'get_articles' (which presumably fetches full content) by emphasizing lightweight ID-only retrieval.
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?
The description explicitly states when to use this tool ('Useful for counting or batch operations') and provides cost information ('Costs 1 Zone 1 request'), which helps the agent decide when this tool is appropriate versus alternatives. It clearly differentiates from content-heavy operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so effectively. It discloses key behavioral traits: it 'Costs 0 requests (uses cached response headers)', which is crucial information about resource usage and performance that isn't obvious from the tool name alone.
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 perfectly concise and front-loaded: the first sentence states the core purpose, and the second adds critical behavioral context. Every sentence earns its place with no wasted 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?
For a 0-parameter tool with no output schema, the description is nearly complete. It explains what the tool does and key behavioral aspects. A minor gap is that it doesn't specify the format of the returned rate limit data (e.g., whether it includes reset times), but this is acceptable given the tool's simplicity.
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 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information.
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 specific verbs ('Check current API rate limit usage and remaining budget') and distinguishes it from sibling tools like 'get_articles' or 'get_user_info' by focusing on API usage metrics rather than content or user data.
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 for when to use this tool ('Check current API rate limit usage'), but it does not explicitly state when not to use it or name alternatives. The sibling tools are all content-related, so the distinction is implied but not explicit.
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?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the tool returns sorted data (by count descending) and has a cost implication ('Costs 1 Zone 1 request'), which is critical for rate limit awareness. However, it doesn't mention potential errors, response format, or whether it's idempotent, leaving some 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 front-loaded with the core purpose in the first sentence, followed by usage guidance and cost information. Every sentence earns its place: the first defines the tool, the second guides usage, and the third discloses cost. It's efficient with zero wasted 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 (0 parameters, no output schema, no annotations), the description is largely complete. It covers purpose, usage, sorting, and cost. However, without an output schema, it doesn't describe the return format (e.g., whether it's a list of objects with feed names and counts), which could help the agent interpret results. This minor gap prevents a perfect 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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by clarifying the scope ('for all feeds and folders') and sorting behavior, which goes beyond the empty schema. A baseline of 4 is appropriate since no parameters exist, and the description provides useful context.
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 specific action ('Get unread article counts'), resource ('for all feeds and folders'), and scope ('sorted by count descending'). It distinguishes this tool from siblings like 'get_articles' (which retrieves article content) or 'mark_all_read' (which modifies read status), making the purpose unambiguous.
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?
The description explicitly provides usage guidance: 'Use this first to understand what needs attention.' This tells the agent when to invoke this tool (as an initial diagnostic step) and implies it should be used before tools like 'get_articles' or 'mark_all_read' that act on specific articles. It effectively positions this tool in the workflow.
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:

[![inoreader-mcp MCP server](https://glama.ai/mcp/servers/justmytwospence/inoreader-mcp/badges/card.svg)](https://glama.ai/mcp/servers/justmytwospence/inoreader-mcp)

Score Badge

Copy to your README.md:

[![inoreader-mcp MCP server](https://glama.ai/mcp/servers/justmytwospence/inoreader-mcp/badges/score.svg)](https://glama.ai/mcp/servers/justmytwospence/inoreader-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/justmytwospence/inoreader-mcp'

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