HitKeep is a privacy-first web analytics platform. This read-only MCP server allows AI assistants to query analytics, AI visibility, ecommerce, and documentation data. Key capabilities include:
Site Traffic Overview: Aggregate KPIs (pageviews, sessions, bounce rate, session duration), top pages, referrers, devices, countries, UTM attribution, goals, and chart data with optional date comparison.
AI Visibility Analytics: Track AI crawler fetches, top assistants/paths, error rates, response times, and fetch-to-visit correlation.
Ecommerce Analytics: Revenue KPIs, order counts, average order value, checkout conversion rates, top products, and revenue by source/UTM/referrer.
Web Vitals: Core Web Vitals (LCP, INP, CLS, FCP, TTFB) scores with page or visitor-context breakdowns.
Custom Events: List event names and read breakdowns for specific event properties.
Google Search Console: Clicks, impressions, CTR, and average position by queries, pages, country, and device.
Opportunities: AI-generated, localized analytics recommendations with impact scores and confidence levels.
Documentation & API Reference: Search docs, retrieve documentation pages, API references, and MCP usage guides as markdown.
Site Management: List all accessible sites and retrieve live visitor counts.
Import Google Search Console aggregate data for query, page, country, and device reporting.
Integration for adding HitKeep analytics tracking to WordPress sites.
100% open source. The complete product is MIT-licensed. Custom tracking domains and team SSO live in the same public codebase—not in a separate proprietary edition.
Full data sovereignty. Self-host one Go binary with embedded DuckDB and NSQ, or export your data in open formats. Complete takeout, APIs, webhooks, share links, and permissions keep the data useful outside HitKeep.
AI-native analytics. HitKeep treats AI as a first-class traffic channel: crawler fetches, AI-referred visits, and chatbot outcomes remain distinct. Ask AI uses cited aggregate evidence, while read-only MCP gives approved assistants governed analytics access.
Privacy by default. The browser tracker sets no analytics cookies, respects Do Not Track, and collects focused website analytics without building a cross-site identity.
Reporting that reaches the outcome. Follow acquisition through pages, automatic and custom events, goals, funnels, ecommerce revenue, UTM and QR campaigns, Search Console, and Web Vitals.
Self-host the complete open-source product, or use HitKeep Cloud in a managed EU or US region when you do not want to operate it yourself.
HitKeep is web-focused. It favors aggregate traffic and conversion evidence over visitor profiles, session replay, mobile SDKs, or built-in experimentation. The result is a smaller collection boundary and operating surface without stopping at a basic pageview counter.
Related MCP server: Google Search Console Audit MCP
On Apple silicon macOS or x86_64 Linux, install HitKeep with Homebrew:
brew install PascaleBeier/hitkeep/hitkeep
hitkeep --versionFollow the Homebrew installation guide to configure and start HitKeep. On Linux ARM64, use the published ARM64 binary or Docker instead.
For a production-oriented self-hosted setup, download the Docker Compose file and environment template:
mkdir hitkeep && cd hitkeep
curl -fsSLo compose.yml https://raw.githubusercontent.com/PascaleBeier/hitkeep/main/examples/compose.yml
curl -fsSLo .env https://raw.githubusercontent.com/PascaleBeier/hitkeep/main/examples/.env.exampleOpen .env and replace paste-the-generated-value-here with a long random value from your password manager. Then start HitKeep:
docker compose up -dOpen http://localhost:8080 and create the first account. Keep .env private and retain the same secret across restarts.
Before exposing an instance publicly, follow the Docker Compose guide for HTTPS and trusted proxies, then review backups and the configuration reference. For a native Linux service, download an AMD64 or ARM64 binary from GitHub Releases and follow the binary installation guide.
Create a site in the dashboard, then add the tracker to your pages:
<script async src="https://analytics.example.com/hk.js"></script>Pageviews and supported automatic interaction events—outbound clicks, file downloads, and form submissions—start flowing immediately. Use the custom events guide for product-specific actions such as signups, purchases, or qualified leads.
Find answers in the documentation, report reproducible bugs through GitHub Issues, and disclose vulnerabilities privately through the security policy.
Run ./hk setup, then start seeded development with ./hk dev --seed or use ./hk dev --detach. Capture product proof with ./hk screenshot; inspect ./hk catalog commands --output json and ./hk catalog configuration --output json instead of copying mutable workflow facts. Validate with ./hk qa pr. The Compose stack and complete workflow live in CONTRIBUTING.md.
Operate: Installation · Configuration · REST API · Goals · Funnels
Evaluate: Comparison library · Compliance · Releases · Changelog
Contribute: Contributor guide · Security policy · Issues
Support open source: Fund HitKeep on GitHub Sponsors or make a one-time contribution.
HitKeep is distributed under the MIT License.
Read AI crawler fetch overview, timeseries, and optional fetch-to-visit correlation for one site.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional RFC3339 end timestamp. Defaults to now. | |
| from | No | Optional RFC3339 start timestamp. Defaults to 30 days before to. | |
| path | No | Optional normalized page path filter. | |
| site_id | Yes | HitKeep site UUID. | |
| window_days | No | Correlation window in days. Defaults to 30 and is capped at 90. | |
| resource_type | No | Optional fetched resource type filter. | |
| assistant_name | No | Optional AI assistant name filter. | |
| assistant_family | No | Optional AI assistant family filter. | |
| include_timeseries | No | Whether to include AI fetch timeseries. Defaults to true. | |
| include_correlation | No | Whether to include fetch-to-visit correlation details. |
| Name | Required | Description |
|---|---|---|
| to | Yes | |
| from | Yes | |
| site_id | Yes | |
| overview | Yes | |
| timeseries | No | |
| correlation | No |
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.
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.
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.
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.
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.
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.
Fetch an official HitKeep REST API reference page as markdown by path or operation slug.
| Name | Required | Description | Default |
|---|---|---|---|
| path_or_operation | Yes | API docs path, operation slug, or official docs URL. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| path | Yes | |
| markdown | Yes |
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.
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.
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.
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.
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.
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.
Fetch an official HitKeep docs page as markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Official HitKeep docs path or URL. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| path | Yes | |
| markdown | Yes |
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.
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.
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.
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.
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.
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.
Read ecommerce summary, top products, source stats, and aggregate city, provider, and ASN breakdowns for one site.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional RFC3339 end timestamp. Defaults to now. | |
| from | No | Optional RFC3339 start timestamp. Defaults to 30 days before to. | |
| limit | No | Maximum rows to return. Defaults to 10 and is capped at 50. | |
| filters | No | Optional analytics filters. | |
| item_id | No | Optional ecommerce item id filter. | |
| site_id | Yes | HitKeep site UUID. | |
| item_name | No | Optional ecommerce item name filter. |
| Name | Required | Description |
|---|---|---|
| to | Yes | |
| from | Yes | |
| site_id | Yes | |
| sources | Yes | |
| summary | Yes | |
| products | Yes |
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.
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.
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.
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.
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.
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.
Read a count breakdown for one event property.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional RFC3339 end timestamp. Defaults to now. | |
| from | No | Optional RFC3339 start timestamp. Defaults to 30 days before to. | |
| limit | No | Maximum rows to return. Defaults to 10 and is capped at 50. | |
| site_id | Yes | HitKeep site UUID. | |
| event_name | Yes | Event name to inspect. | |
| property_key | Yes | Event property key to break down. |
| Name | Required | Description |
|---|---|---|
| to | Yes | |
| from | Yes | |
| site_id | Yes | |
| breakdown | Yes |
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.
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.
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.
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.
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.
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.
List event names tracked for one site in a date range.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional RFC3339 end timestamp. Defaults to now. | |
| from | No | Optional RFC3339 start timestamp. Defaults to 30 days before to. | |
| site_id | Yes | HitKeep site UUID. |
| Name | Required | Description |
|---|---|---|
| to | Yes | |
| from | Yes | |
| names | Yes | |
| site_id | Yes |
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.
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.
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.
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.
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.
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.
Read aggregate step visitors, drop-off, and conversion for one configured funnel.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional RFC3339 end timestamp. Defaults to now. | |
| from | No | Optional RFC3339 start timestamp. Defaults to 30 days before to. | |
| site_id | Yes | HitKeep site UUID. | |
| funnel_id | Yes | Configured funnel UUID. |
| Name | Required | Description |
|---|---|---|
| to | Yes | |
| from | Yes | |
| stats | Yes | |
| site_id | Yes |
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.
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.
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.
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.
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.
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.
Return local MCP usage guidance, token setup, privacy boundaries, date ranges, and filter syntax.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| path | Yes | |
| markdown | Yes |
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.
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.
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.
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.
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.
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.
Read saved localized Opportunities recommendations for one site without raw prompts or provider payloads.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum rows to return. Defaults to 10 and is capped at 50. | |
| status | No | Optional opportunity status filter: new, saved, done, dismissed, or all. Defaults to all statuses. | |
| site_id | Yes | HitKeep site UUID. |
| Name | Required | Description |
|---|---|---|
| site_id | Yes | |
| opportunities | Yes |
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.
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.
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.
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.
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.
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.
Read aggregate QR campaign opens, pageviews, visitors, and optional open timeseries without redirect tokens or raw hit data.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional RFC3339 end timestamp. Defaults to now. | |
| from | No | Optional RFC3339 start timestamp. Defaults to 30 days before to. | |
| limit | No | Maximum campaigns to return. Defaults to 10 and is capped at 50. | |
| site_id | Yes | HitKeep site UUID. | |
| include_series | No | Whether to include QR open timeseries for each campaign. |
| Name | Required | Description |
|---|---|---|
| to | Yes | |
| from | Yes | |
| site_id | Yes | |
| campaigns | Yes |
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.
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.
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.
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.
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.
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.
Read imported Google Search Console overview, series, and optional dimension reports for one site.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional RFC3339 end timestamp. Defaults to now. | |
| from | No | Optional RFC3339 start timestamp. Defaults to 30 days before to. | |
| page | No | Optional exact Google Search Console page URL filter. | |
| path | No | Optional normalized page path filter. | |
| limit | No | Maximum rows to return. Defaults to 10 and is capped at 50. | |
| device | No | Optional Google Search Console device filter. | |
| country | No | Optional country filter. Accepts alpha-2 or alpha-3 country code. | |
| site_id | Yes | HitKeep site UUID. | |
| sections | No | Optional sections: overview, series, queries, pages, country, or device. Defaults to overview and series. |
| Name | Required | Description |
|---|---|---|
| to | Yes | |
| from | Yes | |
| pages | No | |
| device | No | |
| series | No | |
| country | No | |
| queries | No | |
| site_id | Yes | |
| overview | No | |
| warnings | Yes | |
| sync_status | No | |
| property_uri | No |
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.
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.
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.
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.
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.
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.
Read Google Search Console mapping and sync status for one HitKeep site.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes | HitKeep site UUID. |
| Name | Required | Description |
|---|---|---|
| mapped | Yes | |
| reason | Yes | |
| site_id | Yes | |
| team_id | No | |
| sync_status | No | |
| available_to | No | |
| property_uri | No | |
| available_from | No | |
| data_available | Yes | |
| needs_attention | Yes | |
| property_permission_level | No |
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.
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.
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.
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.
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.
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.
Read aggregate traffic KPIs, top dimensions, goals, chart data, and optional comparison for one site.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional RFC3339 end timestamp. Defaults to now. | |
| from | No | Optional RFC3339 start timestamp. Defaults to 30 days before to. | |
| filters | No | Optional analytics filters. | |
| site_id | Yes | HitKeep site UUID. | |
| compare_to | No | Optional RFC3339 comparison end timestamp. | |
| compare_from | No | Optional RFC3339 comparison start timestamp. |
| Name | Required | Description |
|---|---|---|
| to | Yes | |
| from | Yes | |
| stats | Yes | |
| site_id | Yes |
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.
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.
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.
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.
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.
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.
Read aggregate Web Vitals p75, sample counts, rating counts, and optional page or visitor-context breakdowns for one site.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional RFC3339 end timestamp. Defaults to now. | |
| from | No | Optional RFC3339 start timestamp. Defaults to 30 days before to. | |
| path | No | Optional normalized page path filter. | |
| limit | No | Maximum page or breakdown rows to return. Defaults to 10 and is capped at 50. | |
| metric | No | Optional Web Vital metric filter: LCP, INP, CLS, FCP, or TTFB. Defaults to all metrics for summary and LCP for page or dimension breakdowns. | |
| rating | No | Optional rating filter: good, needs_improvement, or poor. | |
| site_id | Yes | HitKeep site UUID. | |
| include_pages | No | Whether to include aggregate page breakdown rows. | |
| include_timeseries | No | Whether to include metric timeseries when metric is set. | |
| breakdown_dimension | No | Optional aggregate visitor context breakdown: browser, country, language, device, city, provider, or asn. |
| Name | Required | Description |
|---|---|---|
| to | Yes | |
| from | Yes | |
| pages | No | |
| metric | No | |
| site_id | Yes | |
| summary | Yes | |
| breakdown | No | |
| timeseries | No | |
| breakdown_dimension | No |
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.
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.
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.
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.
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.
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.
List HitKeep sites visible to the bearer API client.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| sites | Yes |
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.
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.
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.
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.
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.
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.
Search official HitKeep documentation using the LLM catalog and cached markdown pages.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum rows to return. Defaults to 10 and is capped at 50. | |
| query | Yes | Search query for official HitKeep docs. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.13.10hitkeep_get_ai_visibility5 fields changedInput schema / properties / include_timeseriesAdded value: +{
+ "description": "Whether to include AI fetch timeseries. Defaults to true.",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / pathAdded value: +{
+ "description": "Optional normalized page path filter.",
+ "type": "string"
+}Output schema / properties / correlation / properties / citation_pathsAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "ai_referred_visits": {
+ "type": "integer"
+ },
+ "fetch_count": {
+ "type": "integer"
+ },
+ "path": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "path",
+ "fetch_count",
+ "ai_referred_visits"
+ ],
+ "type": "object"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}Output schema / properties / correlation / requiredPrevious value: -[
- "summary",
- "citation_yield",
- "opportunity_pages",
- "failure_hotspots"
-]New value: +[
+ "summary",
+ "citation_yield",
+ "citation_paths",
+ "opportunity_pages",
+ "failure_hotspots"
+]Output schema / requiredPrevious value: -[
- "site_id",
- "from",
- "to",
- "overview",
- "timeseries"
-]New value: +[
+ "site_id",
+ "from",
+ "to",
+ "overview"
+]hitkeep_get_ecommerce1 field changedInput schema / properties / filters / items / properties / type / descriptionPrevious value: -"Filter type: path, hostname, referrer, referrer_host, device, country, city, provider, asn, browser, language, utm_campaign, utm_content, utm_medium, utm_source, or utm_term."New value: +"Filter type: path, ai_bot, ai_bot_category, ai_source, hostname, referrer, referrer_host, device, country, city, provider, asn, browser, language, utm_campaign, utm_content, utm_medium, utm_source, or utm_term."hitkeep_get_funnel_statshitkeep_get_qr_campaignshitkeep_get_site_overview8 fields changedInput schema / properties / filters / items / properties / type / descriptionPrevious value: -"Filter type: path, hostname, referrer, referrer_host, device, country, city, provider, asn, browser, language, utm_campaign, utm_content, utm_medium, utm_source, or utm_term."New value: +"Filter type: path, ai_bot, ai_bot_category, ai_source, hostname, referrer, referrer_host, device, country, city, provider, asn, browser, language, utm_campaign, utm_content, utm_medium, utm_source, or utm_term."Output schema / properties / stats / properties / comparison / properties / ai_bot_hitsAdded value: +{
+ "type": "integer"
+}Output schema / properties / stats / properties / comparison / properties / ai_source_visitsAdded value: +{
+ "type": "integer"
+}Output schema / properties / stats / properties / comparison / requiredPrevious value: -[
- "total_pageviews",
- "unique_sessions",
- "bounce_rate",
- "avg_session_duration",
- "pages_per_session",
- "chart_data",
- "utm_campaign_hits",
- "utm_content_hits",
- "utm_medium_hits",
- "utm_source_hits",
- "utm_term_hits",
- "goals",
- "total_conversions"
-]New value: +[
+ "total_pageviews",
+ "unique_sessions",
+ "bounce_rate",
+ "avg_session_duration",
+ "pages_per_session",
+ "chart_data",
+ "ai_bot_hits",
+ "ai_source_visits",
+ "utm_campaign_hits",
+ "utm_content_hits",
+ "utm_medium_hits",
+ "utm_source_hits",
+ "utm_term_hits",
+ "goals",
+ "total_conversions"
+]Output schema / properties / stats / properties / funnelsAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "created_at": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "site_id": {
+ "type": "string"
+ },
+ "steps": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "type": {
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "site_id",
+ "name",
+ "steps",
+ "created_at"
+ ],
+ "type": "object"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}Output schema / properties / stats / properties / top_ai_bot_categoriesAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "value": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "name",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}Output schema / properties / stats / properties / top_ai_bots_by_categoryAdded value: +{
+ "additionalProperties": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "value": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "name",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+ },
+ "type": "object"
+}Output schema / properties / stats / requiredPrevious value: -[
- "live_visitors",
- "total_pageviews",
- "unique_sessions",
- "bounce_rate",
- "avg_session_duration",
- "pages_per_session",
- "chart_data",
- "top_pages",
- "top_landing_pages",
- "top_exit_pages",
- "top_referrers",
- "top_devices",
- "top_countries",
- "top_cities",
- "top_providers",
- "top_asns",
- "top_browsers",
- "top_ai_bots",
- "top_ai_sources",
- "top_languages",
- "top_utm_campaigns",
- "top_utm_contents",
- "top_utm_mediums",
- "top_utm_sources",
- "top_utm_terms",
- "ai_bot_hits",
- "ai_source_visits",
- "utm_campaign_hits",
- "utm_content_hits",
- "utm_medium_hits",
- "utm_source_hits",
- "utm_term_hits",
- "goals"
-]New value: +[
+ "live_visitors",
+ "total_pageviews",
+ "unique_sessions",
+ "bounce_rate",
+ "avg_session_duration",
+ "pages_per_session",
+ "chart_data",
+ "top_pages",
+ "top_landing_pages",
+ "top_exit_pages",
+ "top_referrers",
+ "top_devices",
+ "top_countries",
+ "top_cities",
+ "top_providers",
+ "top_asns",
+ "top_browsers",
+ "top_ai_bots",
+ "top_ai_bot_categories",
+ "top_ai_sources",
+ "top_languages",
+ "top_utm_campaigns",
+ "top_utm_contents",
+ "top_utm_mediums",
+ "top_utm_sources",
+ "top_utm_terms",
+ "ai_bot_hits",
+ "ai_source_visits",
+ "utm_campaign_hits",
+ "utm_content_hits",
+ "utm_medium_hits",
+ "utm_source_hits",
+ "utm_term_hits",
+ "goals",
+ "funnels"
+]hitkeep_get_web_vitals2 fields changedInput schema / properties / include_timeseriesAdded value: +{
+ "description": "Whether to include metric timeseries when metric is set.",
+ "type": "boolean"
+}Output schema / properties / timeseriesAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "good": {
+ "type": "integer"
+ },
+ "needs_improvement": {
+ "type": "integer"
+ },
+ "p75": {
+ "type": "number"
+ },
+ "poor": {
+ "type": "integer"
+ },
+ "samples": {
+ "type": "integer"
+ },
+ "time": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "time",
+ "p75",
+ "samples",
+ "good",
+ "needs_improvement",
+ "poor"
+ ],
+ "type": "object"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}v2.8.1hitkeep_get_ai_visibilityhitkeep_get_api_referencehitkeep_get_dochitkeep_get_ecommercehitkeep_get_event_breakdownhitkeep_get_event_nameshitkeep_get_mcp_helphitkeep_get_opportunitieshitkeep_get_search_consolehitkeep_get_search_console_statushitkeep_get_site_overviewhitkeep_get_web_vitalshitkeep_list_siteshitkeep_search_docsAll 16 tools have clearly distinct purposes. Analytics tools target specific data types (overview, ecommerce, web vitals, funnels, events, QR, search console, opportunities), while docs tools are separated into reference, doc, and search functions. No two tools appear to compute or return the same information.
Every tool follows the 'hitkeep_<verb>_<noun>' pattern, using either 'get', 'list', or 'search' as verbs. The resource nouns are descriptive and match the output type. This is a perfectly consistent and predictable naming scheme.
With 16 tools, the server is slightly above the typical 3-15 threshold, but each tool represents a distinct analytics report or documentation feature. The breadth is justified by the wide domain coverage, though a few tools could be consolidated without loss of clarity.
The tool set covers the major analytics aspects a user would expect from HitKeep (overview, ecommerce, web vitals, funnels, events, search console, QR, opportunities). The only missing pieces are write operations, but for a read-only analytics server that is appropriate. The documentation tools (get_doc, get_api_reference, search_docs) are a nice addition for self-navigation.
Read-only website analytics, AI referrals, crawlers, goals, revenue, and funnels.
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
Clamp Analytics MCP server: traffic, revenue, funnels, cohorts, errors, and search, for AI agents.
Read-only MCP server for Flamel.ai's public content: company overview, blog, case studies, FAQs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/PascaleBeier/hitkeep'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
