Server Quality Checklist

Tool Scores

• hitkeep_get_ecommerceB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's 'Read' aligns well. The description adds context about what data sections are included but does not disclose potential behavioral details such as default date range behavior, pagination, or how filters interact with breakdowns. Given the strong annotations, a mid score is appropriate; no contradiction exists.

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

  Conciseness4/5

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

  The description is a single clear sentence that front-loads the action ('Read ecommerce summary...') and packs in the key data categories without waste. It earns its place by adding specificity, though it could be slightly tighter.

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

  Completeness3/5

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

  The tool has a rich output schema (not shown) and full parameter documentation, so the description doesn't need to explain return values. However, it lacks guidance on how the various breakdowns relate to parameters like item_id/item_name or how filters apply across sections, leaving some contextual gaps for an agent selecting the tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all seven parameters. The description's mention of 'summary, top products, source stats, and aggregate city, provider, and ASN breakdowns' matches several filter types (city, provider, asn) and adds domain context, but it does not add significant parameter semantics beyond what the schema describes. Baseline 3 applies.

  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 specifies the verb 'Read' and a clear resource: ecommerce analytics for one site. It enumerates the main data sections (summary, top products, source stats, city/provider/ASN breakdowns), which helps distinguish it from sibling analytics tools like hitkeep_get_site_overview or hitkeep_get_event_breakdown, though it doesn't explicitly name an alternative tool for non-ecommerce analytics.

  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 a read-only analytics use case but does not state when to use this tool versus alternatives like hitkeep_get_site_overview or hitkeep_get_event_breakdown. It provides no explicit when-to-use or when-not-to-use guidance, leaving the agent to infer applicability from the title and the content list.

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

• hitkeep_get_event_breakdownB
  3.4/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint and idempotentHint true, indicating a safe read operation. The description adds no new behavioral context—e.g., that it returns aggregated counts per property value, sorts results, or applies date filters. It merely restates the act of reading, adding no value beyond the annotations.

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

  Conciseness5/5

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

  The description is a single, concise sentence that immediately states the tool's function without any fluff or redundant phrasing. It is front-loaded and efficient, earning its place by delivering the core purpose clearly.

  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?

  With strong annotations, 100% parameter documentation, and an output schema present, the one-sentence description is adequate for a straightforward read operation. It doesn't cover every nuance, but the combination of schema and annotations fills most gaps, making the description sufficient for typical use.

  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 all parameters are already documented in the input schema. The description does not add any extra meaning about parameter usage, such as the expected format of property_key or the interpretation of from/to. Baseline 3 is appropriate given the high 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 does a read operation on a count breakdown for a single event property. The verb 'Read' is specific, and 'count breakdown for one event property' precisely identifies the resource and scope, distinguishing it from sibling tools like hitkeep_get_event_names or hitkeep_get_funnel_stats.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or scenarios where this breakdown is preferable to other hitkeep_get_* tools. The agent is left to infer usage from the name and schema.

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

• hitkeep_get_api_referenceA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the safety profile is well-covered. The description adds that it returns markdown, which is useful. However, it doesn't disclose details like pagination, caching, or rate limits. Since annotations cover the main behaviors, a 3 is appropriate.

  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 one concise sentence that clearly states the action and input. It is front-loaded and has zero waste. Perfectly concise.

  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?

  With only one parameter and full schema coverage, plus annotations indicating read-only, open-world, and idempotent behavior, the description is sufficient. The output schema exists, so return format is not needed. The only missing piece is clarification on what 'path or operation slug' means in practice, but the schema description already covers that. This is complete enough for a simple tool.

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

  Parameters3/5

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

  The schema has 100% coverage: the parameter description explains it takes an API docs path, operation slug, or official docs URL. The description adds 'by path or operation slug' which is redundant with the schema. No additional meaning beyond the schema is provided, so baseline 3 is correct.

  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 it fetches an official HitKeep REST API reference page as markdown, which is a specific verb+resource. It mentions 'by path or operation slug' but does not differentiate from siblings like 'hitkeep_get_doc' or 'hitkeep_search_docs' which might also retrieve documentation. Still, the purpose is clear and distinct 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 when to use it (to get API reference documentation) but does not explicitly state when not to use it or mention alternatives. Given siblings like 'hitkeep_search_docs' and 'hitkeep_get_doc', there is no guidance on choosing between them. This is a minor gap.

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

• hitkeep_get_docA
  3.6/5.0
  Behavior3/5

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

  Annotations already disclose readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is clear. The description adds the 'official' constraint and the 'as markdown' output format, which are useful behavioral details, but does not explain error handling or content structure. No contradictions with annotations.

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

  Conciseness5/5

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

  The description is a single, concise sentence that directly states the action and output format with no filler. It is appropriately sized for the tool's simplicity.

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

  Completeness4/5

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

  For a one-parameter, read-only tool with full schema coverage and an output schema, the description is largely complete. It covers the core purpose and output format, though it lacks any elaboration on edge cases or when to prefer it over sibling tools.

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

  Parameters3/5

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

  Schema description coverage is 100% for the single 'path' parameter, so the schema fully documents its meaning. The description adds no extra semantic information beyond naming the resource, so it stays at the baseline score of 3.

  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 'Fetch' with a clear resource ('official HitKeep docs page') and output format ('as markdown'), making it easy to understand. It distinguishes itself from sibling tools like hitkeep_search_docs, which is for searching rather than direct retrieval.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention the existence of hitkeep_search_docs or any criteria for choosing this tool over other docs-related tools, leaving the agent to infer usage context.

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

• hitkeep_get_funnel_statsA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, and the description's 'Read' aligns with those. The description adds a useful scoping detail ('one configured funnel') and clarifies the data dimensions returned (step visitors, drop-off, conversion), but does not disclose other behavioral traits like rate limits, auth requirements, or side effects. With annotations present, this meets the baseline but does not exceed it significantly.

  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, efficiently worded sentence: 'Read aggregate step visitors, drop-off, and conversion for one configured funnel.' Every word contributes meaning, with no fluff or redundancy.

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

  Completeness4/5

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

  Given the presence of an output schema and strong annotations (readOnly, idempotent), the description is nearly complete for a simple read tool. It communicates the core purpose and the single-funnel scoping. A minor gap is that it doesn't clarify potential time range defaults, but these are covered by the schema's parameter descriptions. Overall, it's sufficient and only misses minor supplementary 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?

  Schema description coverage is 100%, so all four parameters (site_id, funnel_id, from, to) are already fully documented. The description does not add any extra meaning or context for parameters beyond what the schema 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 uses the specific verb 'Read' and identifies a precise resource: 'aggregate step visitors, drop-off, and conversion for one configured funnel.' This clearly distinguishes it from sibling tools like hitkeep_get_event_breakdown or hitkeep_get_site_overview, which focus on other metrics.

  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 alternatives. It implies usage through the resource named but does not mention exclusions, alternatives, or scenarios. There is no 'use this when...' or comparison to sibling tools.

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

• hitkeep_get_search_console_statusA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint: true and idempotentHint: true, so the safety profile is established. The description adds context by specifying exactly what is read (mapping and sync status). However, it does not go beyond that—no mention of latency, data freshness, or authorization needs. Given the annotations cover the key traits, this is adequate but not exceptional.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no fluff. It states the action and the subject efficiently. Every word contributes to clarity, making it an exemplar of conciseness.

  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 single-parameter read tool, the description is adequately complete. The presence of an output schema presumably details the return structure, and the description explains what the tool returns (status). It could elaborate on what 'sync status' entails (e.g., last synced time, errors), but given the output schema exists, this is likely covered. Overall, it meets the needs for this simple tool.

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

  Parameters3/5

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

  The schema description for site_id is complete ('HitKeep site UUID.'), achieving 100% coverage. The tool description does not add additional meaning to the parameter beyond what the schema provides. Since schema coverage is high, the baseline of 3 is appropriate; the description adds no extra parameter insight.

  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 'Read' and clearly defines the resource: 'Google Search Console mapping and sync status for one HitKeep site.' This distinguishes it from sibling tools like hitkeep_get_search_console (which likely fetches actual console data) and hitkeep_get_site_overview, focusing on the status of mapping/sync rather than data itself.

  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 gives no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or contrast with sibling tools. While the tool name is descriptive, the description lacks the 'use this when...' or 'instead of...' guidance needed for optimal selection.

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

• hitkeep_get_site_overviewA
  3.8/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true and idempotentHint=true, and the description's 'Read' aligns with these. The description adds a bit of context regarding the tool's configuration by mentioning 'optional comparison' and 'for one site'. No contradictions exist, and the description is consistent with the safety profile.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that uses specific terminology ('aggregate traffic KPIs') and avoids fluff. Every word earns its place, providing maximum information in a minimal format.

  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 an output schema available and all parameters documented, the description is adequate. It clearly defines the tool's scope ('one site') and breadth (KPIs, dimensions, goals, charts). It could add a bit more color on what 'top dimensions' means but is largely complete for the agent to make an informed selection.

  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 parameters are well-documented there. The description does weave in the concept of 'optional comparison,' which loosely connects to the compare_from/compare_to parameters, but it does not add significant new detail beyond what the schema provides; therefore, the baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description has a clear verb ('Read') with specific resources ('aggregate traffic KPIs, top dimensions, goals, chart data') and a scope ('for one site'). It clearly communicates the tool's purpose. However, it does not explicitly distinguish itself from sibling tools by naming any alternatives, though the enumerated data types and 'one site' scope provide decent differentiation.

  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 guidance is only implied through the data types listed ('KPIs, dimensions, goals'), suggesting this is the go-to overview tool. There are no explicit when-to-use vs. alternatives, nor any exclusions, despite a long list of sibling tools where such guidance would be beneficial. The agent has to infer the tool's role is the broad overview.

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

• hitkeep_get_web_vitalsA
  3.8/5.0
  Behavior4/5

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

  The description adds context beyond the readOnlyHint annotation by specifying the exact data returned (p75, sample counts, rating counts) and the availability of page or visitor-context breakdowns. It accurately reflects a read-only, idempotent operation without contradicting annotations.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and scope. Every word adds value, with no redundant content.

  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?

  With an output schema available and fully described parameters, the description sufficiently covers the main functionality. It outlines the key data types (p75, counts) and optional breakdowns, and while it could mention timing defaults, these are in the schema. The description is adequate for the tool's complexity.

  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 already provides complete descriptions for all 10 parameters (coverage 100%). The tool description mentions 'page or visitor-context breakdowns' but does not add substantial semantic detail beyond what the schema offers. Baseline of 3 is appropriate given 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 reads aggregate Web Vitals (p75, sample counts, rating counts) for one site, with optional breakdowns. The verb 'read' and specific resource distinguish it from sibling tools like site_overview or event_breakdown.

  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 such as hitkeep_get_site_overview or hitkeep_get_event_breakdown. The description does not mention exclusions or scenarios where other tools would be more appropriate.

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

• hitkeep_search_docsA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, side-effect-free operation. The description adds some value by mentioning 'the LLM catalog and cached markdown pages', which hints that results may come from a cached source rather than live documentation. However, it does not disclose return behavior or potential staleness in detail.

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

  Conciseness5/5

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

  The description is a single, well-formed sentence that front-loads the action ('Search official HitKeep documentation') and then adds a brief qualifier. It is concise, with no filler or repetition of schema details.

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

  Completeness4/5

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

  For a simple search tool with two well-documented parameters, an output schema, and safety annotations, the description is largely complete. It explains the search source (LLM catalog and cached markdown pages), which provides useful context. The main missing element is guidance on when to use this tool relative to documentation retrieval siblings, but that is already partially addressed in the usage dimension.

  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 provides 100% coverage: both 'query' and 'limit' have clear descriptions, including default and cap for limit. The description adds no additional parameter context beyond what the schema already provides, so a 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 tool's function: searching official HitKeep documentation. It uses a specific verb ('Search') and identifies the resource ('official HitKeep documentation'). It also distinguishes itself from sibling tools like 'hitkeep_get_doc' by indicating this is a search operation rather than a retrieval operation.

  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 that this tool is used to search documentation, but it does not explicitly state when to prefer it over alternatives like 'hitkeep_get_doc' or 'hitkeep_get_api_reference'. There is no mention of exclusions or comparisons with sibling tools, so usage guidance is only implied rather than explicit.

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

• hitkeep_get_opportunitiesA
  3.9/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint and idempotentHint, so the description doesn't need to re-state safe read behavior. It adds context: 'without raw prompts or provider payloads' indicates data privacy/abstraction. But it doesn't mention whether the output is paginated or limited by default, which is useful but arguably already in parameter descriptions.

  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, front-loaded with purpose, no filler. Every word earns its place. Extremely concise and structured.

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

  Completeness5/5

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

  Given the presence of a detailed output schema (indicated by has_output_schema: true) and 100% parameter schema coverage, the description is sufficient. It captures the essential nuance (localized, no raw prompts) that the schema cannot. The tool is simple; no additional context needed.

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

  Parameters3/5

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

  Schema description coverage is 100% for all three parameters—limit, status, site_id have clear descriptions. The description adds no additional parameter semantics beyond the schema. Baseline is 3 because the schema does the heavy lifting, and the description adds no 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 tool reads saved localized Opportunity recommendations for one site, using specific verb 'Read'. It distinguishes from siblings that deal with other hitkeep features (e.g., analytics, QR campaigns). However, it doesn't contrast directly with a similar tool; among 15 siblings, none appear to fetch opportunities.

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

  Usage Guidelines3/5

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

  The description implies usage: when you need saved opportunity recommendations for a site. It does not explicitly state when not to use or suggest alternatives. Since there are no sibling tools with overlapping focus, the lack of explicit exclusions is acceptable but still a gap.

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

• hitkeep_get_ai_visibilityA
  4/5.0
  Behavior4/5

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

  Annotations already specify readOnlyHint=true and openWorldHint=false. The description adds what data is returned (overview, timeseries, correlation) but no side-effect or requirement details. It doesn't contradict annotations, and the added behavioral detail is useful but modest.

  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, front-loaded with the action ('Read') and immediately states the resource and scope. No wasted words or 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?

  The tool has many optional filters, but the schema covers all parameters (100% coverage). The output schema exists for return data. The description adequately conveys the core function (overview, timeseries, correlation) without needing to enumerate filters. It's complete for a read operation with rich schema documentation.

  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 detailed parameter descriptions spancho each parameter. The description adds minimal value beyond saying 'for one site' and mentioning correlation, which maps to a parameter. Baseline 3 applies since schema already covers all 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 tool reads AI crawler fetch overview, timeseries, and optional correlation for a single site. 'Read' is a specific verb, and the resource is the site's AI visibility data. It also distinguishes itself from siblings like get_site_overview and get_search_console by specifying 'AI crawler'.

  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 use when you need AI crawler visibility data for a site, but it does not explicitly mention when not to use it or alternative tools. However, the tool name and sibling context make the purpose clear, so it's adequate but lacking explicit exclusions.

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

• hitkeep_get_event_namesA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe read operation. The description adds the one-site and date-range scoping constraints but does not disclose additional behavioral details such as uniqueness, ordering, or pagination. With annotations carrying the safety profile, this level of added context is acceptable but not rich.

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

  Conciseness5/5

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

  The description is a single front-loaded sentence with no filler words. Every word earns its place, directly stating action, scope, and temporal boundary.

  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 simple, has a fully documented input schema, and an output schema exists. The description sufficiently explains what the tool returns and under what constraints, requiring no additional behavioral or return-value explanation.

  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 input schema fully documents site_id, from, and to. The description adds no parameter-level detail beyond what the schema already provides, which meets the baseline expectation but does not elevate it.

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

  Purpose5/5

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

  The description uses a specific verb-resource pairing: 'List event names tracked for one site in a date range.' It clearly identifies the tool's output (event names), scope (one site), and temporal constraint, distinguishing it from sibling tools like hitkeep_get_event_breakdown and hitkeep_get_site_overview.

  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 the tool: to list event names for one site within a date range. It does not explicitly name alternatives or exclusion conditions, but the scope is concrete enough that an agent can infer its purpose relative to siblings.

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

• hitkeep_get_mcp_helpA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the description need not restate safety. It adds only the scope of returned content ('local MCP usage guidance...'), which is useful but not deeply behavioral; it does not contradict the annotations.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that enumerates the key topics without filler. Every phrase earns its place, and it is 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.

  Completeness5/5

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

  For a no-input help tool with a rich output schema and safety annotations, the description sufficiently covers the tool's purpose and content domains. No additional behavioral or return-value explanation is necessary given the output schema and simple nature.

  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?

  This tool takes zero parameters, so the schema carries full coverage and there is no parameter ambiguity. The description appropriately skips parameter details; the baseline for zero-parameter tools is 4, and the description does not add unnecessary noise.

  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 'Return' and a clear resource: 'local MCP usage guidance, token setup, privacy boundaries, date ranges, and filter syntax.' This distinguishes it from sibling data-retrieval tools like hitkeep_get_event_names or hitkeep_get_site_overview, making its purpose immediately obvious.

  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 obtaining MCP-related help by listing concrete topics like token setup and filter syntax, but it does not explicitly state when to prefer this tool over siblings such as hitkeep_get_api_reference, hitkeep_get_doc, or hitkeep_search_docs. No exclusions or alternative recommendations are provided.

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

• hitkeep_get_qr_campaignsA
  4.1/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds useful scope ('aggregate', 'without redirect tokens or raw hit data'), but it does not disclose additional behaviors such as pagination, rate limits, or response shape beyond what the output schema already conveys.

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

  Conciseness5/5

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

  A single, front-loaded sentence conveys the tool's purpose, scope, and key limitation without any filler or redundancy. Every part earns its place.

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

  Completeness5/5

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

  For a read-only list/analytics tool with full schema coverage, an output schema, and strong annotations, the description is sufficiently complete. It clarifies the metric categories and what is intentionally excluded, which is all the agent needs to select and 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%, and each parameter already has a descriptive schema entry. The description does not add meaningful parameter-level meaning beyond what the input schema provides, so the baseline 3 applies.

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

  Purpose5/5

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

  The description uses a specific action ('Read aggregate') with a clear resource ('QR campaign opens, pageviews, visitors') and explicitly states what it excludes ('without redirect tokens or raw hit data'). This clearly distinguishes it from the sibling analytics tools.

  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?

  It clearly implies when to use this tool: when you need aggregate QR campaign metrics rather than raw hit data or redirect tokens. It does not explicitly name alternative sibling tools, but the scope is clear enough for selection.

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

• hitkeep_get_search_consoleA
  4.3/5.0
  Behavior4/5

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

  The description aligns with the readOnlyHint and idempotentHint annotations ('Read' indicates no side effects). Since annotations already declare safety, the description does not need extra detail. It adds context about the type of data but doesn't contradict annotations. Adequate 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?

  The description is a single, clear sentence with no redundant words. It follows a logical structure: action, resource, optional modifications, and scope. Highly concise and well-structured.

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

  Completeness4/5

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

  The description covers the essential context: what data is read, the optional sections, and that it's per site. Given the rich schema and annotations, it is complete enough. It does not mention return format, but no output schema is provided, so this is acceptable.

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

  Parameters5/5

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

  The schema provides detailed descriptions for all 9 parameters, including defaults, allowed values, and formats (e.g., 'RFC3339 end timestamp', 'alpha-2 or alpha-3 country code'). The tool description doesn't need to add more because the schema fully explains each parameter's 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 clearly states the action ('Read'), the resource ('imported Google Search Console'), and the scope ('overview, series, and optional dimension reports for one site'). It distinguishes this tool from siblings like 'hitkeep_get_ai_visibility' by specifying the Search Console data source.

  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 does not explicitly state when to use this tool over alternatives. It implies usage for Search Console data but lacks direct comparison or conditions such as 'Use this when you need Search Console performance metrics.' No when-not or alternative guidance is provided.

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

• hitkeep_list_sitesA
  4.5/5.0
  Behavior4/5

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

  The readOnlyHint and idempotentHint annotations already cover safety, and the description adds the scoping detail about 'bearer API client' visibility, which is transparent and non-contradictory.

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

  Conciseness5/5

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

  The description is a single, concise, and well-structured sentence that conveys all necessary information without verbosity.

  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 simplicity of the tool (no parameters, straightforward output), the description is complete enough for an agent to understand its purpose and likely return behavior, though it does not detail the output format.

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

  Parameters5/5

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

  No parameters exist, so this dimension is trivially satisfied and the description adds no ambiguity.

  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 ('List') and resource ('HitKeep sites'), and the phrase 'visible to the bearer API client' differentiates it from sibling tools that focus on specific metrics or 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 implicitly indicates when to use this tool (to enumerate accessible sites) and does not conflict with sibling tools, though it does not explicitly mention alternatives or exclusion criteria. The context is clear enough.

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