Server Quality Checklist

Tool Scores

• trendingC
  2.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description bears the full burden of behavioral disclosure, yet it only states that topics are 'trending across your feeds in the last N hours.' It does not disclose whether the operation is read-only, how trending is computed, whether results are sorted, what happens with empty feeds, or what the returned topics look like beyond what the output schema provides.

  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 single sentence is efficient and front-loads the core concept with no filler words. However, it is under-specified rather than tightly specified—brevity here comes at the cost of missing behavioral and parameter information, so the sentence does not fully earn its place.

  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 an output schema present, return-value documentation is covered elsewhere, and the tool is low-complexity with two optional params. But at 0% schema parameter coverage and no annotations, the description still fails to differentiate from siblings like 'recent' and 'digest', explain 'limit', or define the trending criteria—leaving notable gaps for an agent deciding to invoke it.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It partially clarifies that 'hours' controls the look-back window via 'in the last N hours', but it says nothing about the 'limit' parameter, leaving its behavior (maximum number of topics returned) undocumented in both schema and 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?

  The description states a specific verb ('trending'), resource ('topics across your feeds'), and time window ('last N hours'). It is distinct enough from siblings like search and refresh to convey the core function, though it does not define what 'trending' means (e.g., ranked by engagement, velocity, or mentions) or how it differs from 'recent'.

  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 given on when to use this tool versus siblings such as 'recent' or 'digest'. The description implies it is for surfacing currently popular topics, but it never states exclusion criteria (e.g., 'use recent for chronological listing' or 'use digest for summaries'), leaving tool selection to inference.

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

• recentC
  2.9/5.0
  Behavior2/5

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

  No annotations exist, so the description must carry the behavioral disclosure burden. It only says 'across all feeds' and does not mention ordering, freshness window, pagination, or any limitations. The description adds little beyond what the tool name already implies.

  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 one short, front-loaded sentence with no filler or redundant statements. It is easy to scan and gets the core idea across quickly. The brevity comes at the cost of behavioral detail, but it is appropriately concise for a simple tool.

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

  Completeness2/5

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

  The tool is simple and has an output schema, but with no annotations and no sibling differentiation, the description is not fully complete. An agent has little guidance for choosing this over 'trending' or 'digest,' and no information about default sorting or response shape. The output schema helps fill some gaps, but the description remains under-specified for confident selection.

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

  Parameters2/5

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

  The schema description coverage is 0%, and the description does not explain the 'limit' parameter at all. The schema provides the type and default, and the parameter name is fairly self-explanatory, but the description itself adds no parameter-level meaning. It partially compensates by being about a simple single-parameter tool.

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

  Purpose4/5

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

  The description states that the tool returns the most recent articles and scopes it 'across all feeds,' which is clear enough to convey the basic purpose. It lacks an explicit verb like 'list' or 'get,' but the intent is unambiguous. It does not explicitly differentiate from sibling tools like search, trending, or digest.

  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?

  There is an implied use case: fetch the newest articles from all feeds. However, the description provides no explicit 'when to use this vs. other tools' guidance, and it does not mention alternatives such as trending or digest. The usage context is minimal and largely inferred.

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

• searchC
  2.9/5.0
  Behavior2/5

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

  There are no annotations, so the description must carry the behavioral disclosure burden. It reveals one useful trait, recency-boosted ranking, but says nothing about search scope limits, time-window behavior, query semantics, or whether the operation is read-only. The agent gets only a partial picture.

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

  Conciseness4/5

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

  The description is a single concise sentence with no filler, and its most distinguishing trait ('recency-boosted') is front-loaded. It is not a complete specification, but as far as length and ordering go it is well formed.

  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 tool with three parameters and no annotations, this description is thin. It leaves unclear what 'indexed feeds' means, how max_days works, and when search should be preferred over recent, trending, or digest. The output schema covers return shape, but invocation context is under-specified.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not explain query, limit, or max_days beyond what the parameter names already suggest. 'Recency-boosted' only loosely hints at max_days, and the agent must infer how limit and max_days shape results. The description does not compensate for the missing schema descriptions.

  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 identifies the tool as a search operation over indexed feeds and adds a meaningful ranking trait ('recency-boosted'). This makes its purpose distinct from sibling list tools like recent or trending, though the differentiation is implicit rather than explicit.

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

  Usage Guidelines3/5

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

  The phrasing implies use when an agent needs to search previously indexed feed content, but it never says when to choose this over recent, trending, or digest. No alternatives or exclusion conditions are named, so the guidance is only implicit.

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

• digestB
  3.1/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 behavioral burden. It indicates the tool generates a digest and nothing else, but it does not disclose potential side effects, dependencies on feeds, rate limits, or how content is selected. Some behavior is clear, but much is left unspecified.

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

  Conciseness5/5

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

  A single sentence that leads with the action and output format. Every word earns its place, and there is no redundant or filler content.

  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?

  With an output schema present and only two optional parameters with defaults, an agent can invoke this tool with no arguments reasonably safely. However, the description omits how hours and limit interact, what 'trending topics' means, and whether the digest depends on configured feeds, leaving room for misinterpretation.

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

  Parameters2/5

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

  Schema description coverage is 0% and the description does not explain 'hours' or 'limit'. The parameter names and defaults are somewhat self-explanatory, and 'recent articles' hints at hours, but the description adds no explicit parameter semantics to compensate for the schema's lack of descriptions.

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

  Purpose4/5

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

  The description states a clear verb ('Generate') and resource ('markdown digest grouping recent articles and trending topics'), making the tool's core function obvious. It does not explicitly compare itself with siblings like recent or trending, but the grouping and digest format distinguish it enough.

  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: call this when you want a consolidated markdown digest of recent articles and trending topics. It does not provide explicit when-to-use versus alternatives or mention exclusions, so guidance is only implied.

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

• add_feedA
  3.8/5.0
  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 explaining behavior. It discloses that the operation adds a feed and fetches its articles, indicating a state-changing action. It does not detail edge-case behaviors such as duplicate feeds, validation failures, or what happens if the fetch fails, but it is transparent about the core 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 a single, direct sentence that front-loads the primary verb and object. Every word contributes meaningful information, with no filler or redundant restatement of the tool name.

  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 tool with an output schema, the description is mostly complete: it states the operation, the target resource, and the immediate fetch behavior. It could additionally mention that the feed becomes part of the user's feed list or that fetching may be synchronous, but the existing description covers the essential 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?

  The input schema only defines 'url' with no description, and schema description coverage is 0%. The description adds that the URL should point to an RSS/Atom feed, which is helpful context beyond the bare parameter name, but it does not elaborate on URL format, protocol expectations, or validation rules.

  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 and resource: 'Add an RSS/Atom feed and fetch its current articles.' It clearly distinguishes from siblings like remove_feed, list_feeds, and refresh by indicating this tool creates a new feed subscription and performs an initial fetch.

  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 the tool should be used when a user wants to add a new feed, and it contrasts implicitly with remove_feed and refresh. However, it does not explicitly state when not to use it, mention alternatives, or clarify that refresh is the appropriate tool for updating an existing feed.

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

• remove_feedA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden and it explicitly discloses that the feed and all its indexed articles are removed, which is the key destructive side effect. It stops short of stating irreversibility or permission requirements, but the main behavioral risk is clearly surfaced.

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

  Conciseness5/5

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

  A single, front-loaded sentence with no filler: the subject, action, and destructive scope are all in few words. Every element earns its place.

  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 one-parameter destructive tool with an output schema present, the description is nearly sufficient: it defines the action and the critical cascade. It could add a note about irreversibility or URL semantics, but output formatting is already covered by the output schema and the tool complexity is low.

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

  Parameters2/5

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

  Schema description coverage is 0% and the description does not compensate: it never explains that the feed is identified by URL, what URL formats are accepted, or that the parameter is required. The schema only provides the parameter name and type, so the description adds no parameter meaning.

  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 the specific verb 'Remove' with the resource 'feed' and adds the cascading effect on indexed articles, so an agent can unambiguously tell this from siblings like add_feed or list_feeds. It states a clear action and scope.

  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 operation itself is self-evident: use it when a feed should no linger be present. However, the description gives no explicit when-to-use/when-not-to-use guidance, no alternatives, and no prerequisites or warnings beyond the action, so usage is implied rather than stated.

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

• list_feedsA
  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 burden. The verb 'List' clearly signals a read-only operation, and the phrase 'with article counts' discloses key behavior about the returned data. It does not mention auth, caching, or ordering, but these are minor for a zero-parameter listing 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 a single short sentence with no filler. The verb and resource are front-loaded, and every word contributes meaning ('configured feeds', 'article counts').

  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 tool with an output schema, the description is sufficient: it names the resource and the key expected output field. It could add ordering or live-vs-cached count details, but these are not required for correct 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?

  The tool has zero parameters, so the input schema is already fully complete. The description adds no parameter detail, and none is needed; this matches the baseline for no-parameter tools.

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

  Purpose5/5

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

  The description states an explicit verb ('List') and resource ('configured feeds') and adds a useful output detail ('with article counts'). This clearly distinguishes it from siblings that operate on article content (search, recent, trending, digest) or mutate feeds (add_feed, remove_feed).

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

  Usage Guidelines3/5

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

  The description implies when to use this tool: when the agent needs to see configured feeds and their article counts. However, it does not explicitly discuss when not to use it or point to alternatives such as source_health for feed status or refresh for live counts, leaving some routing to inference.

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

• refreshA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full transparency burden. It discloses that the refresh is forced and immediate, not a scheduled or passive update. It does not detail side-effects like network load or rate limiting, but for a zero-parameter command this level of disclosure is generally sufficient.

  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, tight sentence that leads with the action and immediately states scope. No filler or redundant phrasing.

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

  Completeness5/5

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

  With no parameters, an existing output schema, and no overlapping siblings, this description supplies all the context an agent needs to select and invoke the tool correctly. Anything more would be unnecessary for such a simple command.

  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 confirms zero parameters, so there is nothing to document. The description adds no parameter-level detail, but none is needed; baseline 4 applies.

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

  Purpose5/5

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

  The description states a specific verb ('Force-refresh') and resource ('all feeds'), clearly identifying a manual refresh action. It is distinct from all sibling tools, which handle feed management, search, and digests, so an agent can easily understand what this tool does.

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

  Usage Guidelines4/5

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

  The intended context is clear: use this when you want to force an immediate refresh of all feeds. No sibling tool overlaps with this action, and no exclusion is necessary. It stops short of explicitly stating when not to use it or citing alternatives, but the context is unambiguous.

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

• source_healthA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full behavioral burden. The read-only verb 'Check' and the enumerated status categories communicate expected behavior and outcome shape. It does not elaborate on underlying mechanics (e.g., network requests), but for a zero-parameter status query this is not a critical omission.

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

  Conciseness5/5

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

  A single front-loaded sentence with no filler. Every phrase adds semantic value, and no redundant details are included.

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

  Completeness5/5

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

  The tool is maximally simple: no params, no required inputs, and an output schema exists. The description is sufficient for an agent to correctly select and invoke the tool without missing context.

  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?

  There are zero parameters, so the schema already fully covers invocation inputs. Baseline 4 applies because there is no parameter information for the description to add.

  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 ('Check') with a clear resource ('feeds') and defines the exact health outcomes ('healthy, late, or producing errors'). This distinguishes it from siblings like list_feeds (plain listing) and refresh (manual trigger) without ambiguity.

  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 context is clear: call this when the agent needs feed health status rather than feed content or management. It does not explicitly name when not to use it or alternative tools, but the single-purpose phrasing leaves little ambiguity.

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