Server Quality Checklist

Tool Scores

• unsubscribeA
  3.5/5.0
  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 only states the action and method, offering no information on side effects, reversibility, authentication, or return values, leaving critical operational traits undisclosed.

  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 concise and front-loaded, but the two sentences partially repeat each other using synonyms ('feed' vs 'subscription'). It is still efficient and easy to parse, with no unnecessary verbosity.

  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 or annotations, the description fails to explain return values, error behavior, or the constraint that exactly one of id/route must be provided. The schema's required: [] is misleading without clarification, making the description incomplete for correct 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 coverage is 100% with both parameters already described, so the baseline is 3. The description adds minimal extra meaning beyond the schema, and it doesn't clarify the one-of requirement implied by 'by ID or route' given that the schema marks both as optional.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('unsubscribe') and resource ('RSSHub feed'/'subscription'), making the tool's purpose unambiguous. It clearly distinguishes itself from siblings like subscribe and list_subscriptions by stating the removal action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly states the action and the method ('by ID or route'), providing clear context for when to use it. It doesn't explicitly name alternative tools, but the purpose is self-evident given the sibling set, so it slightly misses the full 'when-not' guidance.

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

• get_feedA
  3.6/5.0
  Behavior2/5

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

  No annotations exist, so the description bears full responsibility for disclosing behavior. It explains the route-dependent branches and environment variable configuration, but does not describe return format, error behavior, pagination, or side effects. For an unannotated tool, this is a notable gap in transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short sentences, each earning its place: first states the core function, second explains the conditional modes, third configures the instance. Front-loaded and free of redundant filler. Excellent conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and no annotations, the description should clarify what 'feed content' looks like, how feeds are presented, and any limitations. It covers the two operational modes but omits return value structure, error handling, and rate limits. Given the tool's moderate complexity, this incomplete context leaves the agent under-informed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both 'route' and 'params' already described. The description mostly restates the route omission behavior already present in the schema and mentions the environment variable (not a parameter). It adds minimal extra meaning beyond the schema, which aligns with the baseline of 3 for full 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 primary action ('Get RSSHub feed content') and immediately distinguishes between fetching a specific feed (with route) and fetching all subscribed feeds (without route). This is a specific verb+resource pairing that sets it apart from sibling tools like search_routes or list_subscriptions.

  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?

  Provides explicit conditional guidance: 'If route is provided, fetch specific feed. If no route is provided, fetch all subscribed feeds.' This tells the agent exactly when to use each mode. It does not explicitly mention alternatives or situations to avoid, but the context is clear enough for basic selection.

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

• subscribeA
  3.7/5.0
  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 a basic mutation ('Subscribe') and the effect ('Add a route to your subscription list'), but it does not disclose potential side effects (e.g., whether an existing route is overwritten), authentication requirements, error behavior, or idempotency. This is a significant gap for a state-changing 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?

  Two short sentences that each add value: the first defines the operation, the second gives context. No redundant phrases or filler, and the key information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description adequately conveys the purpose and outcome of subscribing, but lacks information about return values, error handling, or behavior on duplicate subscriptions. Since there is no output schema and no annotations, a bit more detail would be expected for full completeness, though the tool is relatively simple.

  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 'route', 'name', and 'params'. The tool description itself adds no parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Subscribe to an RSSHub feed') and the concrete outcome ('Add a route to your subscription list'). It distinguishes the tool from siblings like get_feed and search_routes by focusing on the persistent subscription action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for easy access later' implies a use case: saving a route for future retrieval rather than immediate fetch. However, it does not explicitly contrast with alternatives such as get_feed or list_subscriptions, so it lacks full when/when-not guidance.

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

• list_subscriptionsA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It implies a read-only operation ('List', 'Shows') and states that all subscriptions are returned, but does not disclose details like return format, ordering, or whether any side effects exist. It is adequate but lacks depth beyond the basic action.

  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 two concise sentences that are front-loaded with the core action. Every word serves a purpose, and it avoids redundancy or extra fluff.

  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 zero-parameter listing tool, the description is nearly complete: it states the action and scope (all subscriptions) and notes that details are included. However, it does not specify what those details are, which could be expected given no output schema. Still, the simplicity of the tool limits the need for more.

  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 takes zero parameters, so the baseline is 4. The description does not need to add parameter meaning since there are none, and the empty schema already communicates this. The description's mention of 'all' aligns with the lack of parameters.

  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 verb 'List' with the specific resource 'all RSS feed subscriptions', and further clarifies that it shows all subscribed routes with details. It distinguishes itself from siblings like get_feed (single feed) and search_routes (filtered search) by explicitly covering the full set without filters.

  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 does not provide any explicit guidance on when to use this tool versus alternatives. It does not mention that get_feed is for a single feed or that search_routes is for filtering, so the agent is left without direction on tool selection based on use case.

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

• search_routesA
  4.2/5.0
  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 a notable behavior: 'Automatically fetches latest routes from RSSHub API and caches them,' which explains data freshness and potential cache use. It does not explicitly state read-only status, but 'search' strongly implies it.

  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 two sentences, front-loaded with the core purpose, and every sentence adds value. It is concise and well-structured without redundancies.

  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 one-parameter search tool with no output schema, the description covers the essential aspects: what it searches, how it works (fuzzy, caching), and data source. It could mention the return format, but this is a minor gap given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with a clear description of the 'query' parameter. The description adds 'fuzzy search' and enumerates searchable entities (platform names, route names, categories), going beyond the schema's examples and enriching parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Search RSSHub routes' with a specific verb and resource. It further elaborates on fuzzy search and searchable fields, distinguishing it from siblings like get_feed or subscribe, which are about feed retrieval and subscription management.

  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?

  Usage is implied: use this tool to search for routes. However, there is no explicit guidance on when not to use it or when to prefer a sibling tool. For example, it doesn't mention that get_feed is for fetching a specific feed once a route is known.

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