Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@rybbit-mcp What are the top pages this week?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that exposes Rybbit Analytics as tools for Claude (or any MCP-compatible client). Ask Claude things like:
"What's the traffic overview for my site this week?"
"What are the top 10 pages by visits this month?"
"How many people are on the site right now?"
"Where is my traffic coming from, by country?"
"Show me the most recent sessions from mobile users."
It works against both Rybbit Cloud (app.rybbit.io) and self-hosted Rybbit instances.
Tool | Description |
| List organizations and sites (with their site IDs) |
| Get config/details for one site |
| Sessions, pageviews, users, bounce rate, duration for a time range |
| Same metrics bucketed over time (for trend charts) |
| Top pages, referrers, countries, browsers, devices, UTM params, etc. |
| Current active visitor count |
| Paginated list of visitor sessions |
| Full detail + event list for one session |
| Aggregated session geolocation, for mapping |
This covers Rybbit's Overview and Sessions API families. The same client/tool pattern can be extended to Events, Users, Goals, Funnels, Performance, and Errors — see Extending below.
Related MCP server: GA4 MCP Server
In your Rybbit dashboard: Settings → Account → API Keys → Create.
Self-hosted instances have no rate limits. Rybbit Cloud rate-limits API keys per your plan (Standard: 20 req/min, Pro: 200 req/min); Free/Basic plans don't get API key access.
git clone https://github.com/<your-username>/rybbit-mcp.git
cd rybbit-mcp
npm install
npm run buildThis produces build/index.js.
Claude Desktop / Claude Code — add to your MCP config (claude_desktop_config.json or .claude/settings.json):
{
"mcpServers": {
"rybbit": {
"command": "node",
"args": ["/absolute/path/to/rybbit-mcp/build/index.js"],
"env": {
"RYBBIT_URL": "https://app.rybbit.io",
"RYBBIT_API_KEY": "your-api-key-here"
}
}
}
}If you self-host Rybbit, set RYBBIT_URL to your instance's base URL instead (e.g. https://analytics.yourdomain.com).
Restart Claude Desktop / reload Claude Code, and the rybbit_* tools should appear.
This MCP server supports Server-Sent Events (SSE) for remote clients over HTTP. This is perfect for deploying to a platform like CapRover so that a remote AI agent can access the tools.
Create a new App in your CapRover dashboard (e.g., rybbit-mcp).
Set the Environment Variables in CapRover:
RYBBIT_URL
RYBBIT_API_KEY
PORT=3000 (Optional, defaults to 3000)
Under the Deployment tab, deploy using the Captain Definition or simply push this repository via the CapRover CLI. This repository contains a Dockerfile that CapRover will automatically detect and build.
Once deployed, the SSE endpoint will be available at:
https://rybbit-mcp.your-caprover-domain.com/sse
Your remote AI agents can connect to this URL via SSEServerTransport instead of stdio.
"Use rybbit to show me an overview of site 123 for the last 7 days" "What are the top pages on my site this month?" "How many live visitors do I have right now?"
npm run watch # recompile on change
npm run inspector # open the MCP Inspector against this serverRybbit's API has more endpoint families than this v1 covers (Events, Users, Goals, Funnels, Performance metrics, Errors — see the Rybbit API docs). To add one:
Add a method to src/rybbit-client.ts calling the endpoint.
Register a corresponding tool in src/index.ts with server.registerTool(...), using zod for the input schema.
npm run build and reload your MCP client.
MIT
Get analytics broken down by a single dimension, ranked by traffic. Use this for questions like 'what are the top pages', 'where is traffic coming from', 'what countries/browsers/devices do visitors use', 'what are the top UTM campaigns', etc. Set parameter to the dimension to break down by, e.g.: pathname, page_title, hostname, referrer, channel, entry_page, exit_page, country, region, city, browser, browser_version, operating_system, device_type, language, utm_source, utm_medium, utm_campaign, utm_term, utm_content, event_name. Results include visit count, percentage of total, pageviews, and bounce rate per value.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | The Rybbit site ID (numeric ID from your Rybbit dashboard or the rybbit_list_sites tool). | |
| parameter | Yes | Dimension to break down by, e.g. pathname, referrer, country, browser, device_type, utm_source, channel. | |
| limit | No | Max number of rows to return (default applies if omitted). | |
| page | No | Page number for pagination (1-indexed). | |
| start_date | No | Start date, e.g. 2024-01-01. Use with end_date and time_zone. | |
| end_date | No | End date, e.g. 2024-01-31. Use with start_date and time_zone. | |
| time_zone | No | IANA time zone, e.g. America/New_York. Required when using start_date/end_date or start_datetime/end_datetime. | |
| start_datetime | No | Exact start datetime, e.g. '2024-01-15 13:00:00' (UTC). Alternative to start_date. | |
| end_datetime | No | Exact end datetime, e.g. '2024-01-15 15:00:00' (UTC). Alternative to end_date. | |
| past_minutes_start | No | Relative range start in minutes ago, e.g. 60. Use with past_minutes_end instead of dates. | |
| past_minutes_end | No | Relative range end in minutes ago, e.g. 0 for 'now'. Use with past_minutes_start. | |
| filters | No | Optional list of filters to narrow the data (AND logic across different filters). Example: [{"parameter":"country","type":"equals","value":["US"]}] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description covers the behavioral aspects: it returns results with visit count, percentage, pageviews, bounce rate. It lists valid dimension values and filter options. No mention of side effects, but tool is read-only by nature.
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?
Four sentences, front-loaded with purpose and examples. Every sentence adds necessary context 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?
Despite 12 parameters and no output schema, the description explains the output fields, covers all parameter categories, and provides usage examples. It is sufficiently complete for an AI agent to invoke 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 coverage is 100% with descriptions for each parameter. The description adds value by listing example dimension values and explaining the filter structure in detail, which goes beyond the schema.
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 it 'Get analytics broken down by a single dimension, ranked by traffic' and provides concrete example questions. It distinguishes itself from sibling tools like overview or session tools by focusing on breakdowns.
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 includes example usage scenarios like 'what are the top pages', making it clear when to use. It does not explicitly exclude alternative tools, but the use cases are well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the count of currently active sessions on a site within a recent time window (real-time visitor count).
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | The Rybbit site ID (numeric ID from your Rybbit dashboard or the rybbit_list_sites tool). | |
| minutes | No | Look-back window in minutes for 'active'. 1 = very active right now, 5 = standard live count (default), 15 = recently active, 30 = short-term engagement. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It explains the minutes parameter and its effect on 'active' definition, but does not disclose output format, uniqueness of visitors, or any limitations.
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, clear sentence that directly communicates the tool's purpose without extraneous words. It is front-loaded and efficient.
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 no output schema, the description should specify what the tool returns (e.g., a single number). It does not, leaving ambiguity. The description is adequate for simple usage but lacks completeness for an agent to fully understand the response.
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. The tool description adds context to the minutes parameter with example values, but does not significantly enhance understanding beyond the schema.
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 explicitly states it retrieves the count of active sessions on a site within a time window, using clear verbs 'Get' and 'count'. It differentiates from sibling tools like 'get_overview' or 'get_breakdown' which focus on different 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 implies the tool is for real-time visitor counts, but lacks explicit guidance on when to use this versus other related tools (e.g., for historical data or breakdowns). No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get high-level analytics metrics for a site over a time range: sessions, pageviews, unique users, pages per session, bounce rate, and average session duration.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | The Rybbit site ID (numeric ID from your Rybbit dashboard or the rybbit_list_sites tool). | |
| start_date | No | Start date, e.g. 2024-01-01. Use with end_date and time_zone. | |
| end_date | No | End date, e.g. 2024-01-31. Use with start_date and time_zone. | |
| time_zone | No | IANA time zone, e.g. America/New_York. Required when using start_date/end_date or start_datetime/end_datetime. | |
| start_datetime | No | Exact start datetime, e.g. '2024-01-15 13:00:00' (UTC). Alternative to start_date. | |
| end_datetime | No | Exact end datetime, e.g. '2024-01-15 15:00:00' (UTC). Alternative to end_date. | |
| past_minutes_start | No | Relative range start in minutes ago, e.g. 60. Use with past_minutes_end instead of dates. | |
| past_minutes_end | No | Relative range end in minutes ago, e.g. 0 for 'now'. Use with past_minutes_start. | |
| filters | No | Optional list of filters to narrow the data (AND logic across different filters). Example: [{"parameter":"country","type":"equals","value":["US"]}] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. The verb 'Get' and the list of metrics imply a read-only operation, but the description does not explicitly state behavioral traits such as idempotency, side effects, or authorization requirements. It adds some value by indicating the scope (high-level overview) but lacks rich behavioral context.
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 sentence that front-loads the main action and lists the metrics concisely. Every part is relevant, and there is no wasted text. It is appropriately sized for a tool with well-documented parameters.
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 tool has 9 parameters and no output schema, the description is minimal. It tells what metrics are retrieved but does not explain the output format, constraints, or usage notes for the many parameters. While the schema handles parameter details, the description could be more complete for a complex 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 baseline is 3. The description only lists the metrics returned and does not add meaning to the parameters beyond what the schema provides. No parameter-specific explanations are added, so the description does not compensate further.
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 retrieves high-level analytics metrics for a site, listing specific metrics (sessions, pageviews, etc.). It uses a specific verb 'Get' and resource 'analytics overview', making the purpose unambiguous even without explicit sibling 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?
The description provides no guidance on when to use this tool versus alternatives like rybbit_get_breakdown or rybbit_get_overview_timeseries. There are no prerequisites, exclusions, or context for use, leaving the agent to infer from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the same metrics as rybbit_get_overview (sessions, pageviews, users, bounce rate, etc.) broken down into time buckets, for charting trends. Choose a bucket size appropriate to the range: 'minute' or 'five_minutes' for the last hour or so, 'hour' for a single day, 'day' for weeks/months, 'week' or 'month' for longer ranges.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | The Rybbit site ID (numeric ID from your Rybbit dashboard or the rybbit_list_sites tool). | |
| bucket | Yes | Time bucket size for the series. | |
| start_date | No | Start date, e.g. 2024-01-01. Use with end_date and time_zone. | |
| end_date | No | End date, e.g. 2024-01-31. Use with start_date and time_zone. | |
| time_zone | No | IANA time zone, e.g. America/New_York. Required when using start_date/end_date or start_datetime/end_datetime. | |
| start_datetime | No | Exact start datetime, e.g. '2024-01-15 13:00:00' (UTC). Alternative to start_date. | |
| end_datetime | No | Exact end datetime, e.g. '2024-01-15 15:00:00' (UTC). Alternative to end_date. | |
| past_minutes_start | No | Relative range start in minutes ago, e.g. 60. Use with past_minutes_end instead of dates. | |
| past_minutes_end | No | Relative range end in minutes ago, e.g. 0 for 'now'. Use with past_minutes_start. | |
| filters | No | Optional list of filters to narrow the data (AND logic across different filters). Example: [{"parameter":"country","type":"equals","value":["US"]}] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions the metrics (sessions, pageviews, etc.) and bucket breakdown, but does not state that the operation is read-only, discuss rate limits, or describe the output format. The safety profile is implied but not explicit.
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?
Two sentences, no redundant words. The first sentence states purpose and relation to sibling, the second gives practical usage advice. Information is front-loaded and efficient.
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 explains the tool's output conceptually (same metrics as overview in time buckets) and provides bucket size recommendations. However, it lacks details on the output structure (e.g., fields per bucket, pagination). Given no output schema, this is a minor gap but not critical for correct invocation.
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 parameters are already documented. The description adds value by recommending bucket size for different ranges, which is not in the schema enum description. This guidance helps the agent choose appropriately.
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 it retrieves the same metrics as rybbit_get_overview but broken into time buckets for charting trends. It differentiates from siblings by specifying the time-series aspect, and the sibling list includes rybbit_get_overview as the non-time-series version.
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 explicit guidance on choosing bucket size based on time range (e.g., 'minute' for last hour, 'day' for weeks/months). It implies use cases for trends but does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full detail for a single session by ID: session metadata plus the ordered list of pageview/custom events within it.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | The Rybbit site ID (numeric ID from your Rybbit dashboard or the rybbit_list_sites tool). | |
| session_id | Yes | The session_id, as returned by rybbit_list_sessions. | |
| limit | No | Max number of events to return. | |
| offset | No | Offset into the events list, for pagination. | |
| minutes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes output (session metadata plus ordered events) but lacks annotation support. No mention of side effects, auth requirements, or rate limits. With no annotations, description provides basic behavioral context but not comprehensive.
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 and scope. No redundant words. Highly efficient.
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 no output schema, description adequately outlines return structure (session metadata + ordered events). Missing details on pagination implications or event types, but sufficient for a single-session fetch.
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 80% (4 of 5 parameters described). Description adds no parameter meaning beyond schema, so baseline 3 applies. No enrichment.
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?
Clearly states 'Get full detail for a single session by ID' with specific resources (session metadata, ordered list of events). Distinguishes from siblings like rybbit_list_sessions and rybbit_get_overview by specifying the full detail for one session.
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?
Implies use case (retrieving full session detail) but does not explicitly state when to use vs alternatives or provide exclusions. No guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregated session counts by geographic coordinates (lat/lon, city, country) for a site, suitable for plotting on a map.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | The Rybbit site ID (numeric ID from your Rybbit dashboard or the rybbit_list_sites tool). | |
| start_date | No | Start date, e.g. 2024-01-01. Use with end_date and time_zone. | |
| end_date | No | End date, e.g. 2024-01-31. Use with start_date and time_zone. | |
| time_zone | No | IANA time zone, e.g. America/New_York. Required when using start_date/end_date or start_datetime/end_datetime. | |
| start_datetime | No | Exact start datetime, e.g. '2024-01-15 13:00:00' (UTC). Alternative to start_date. | |
| end_datetime | No | Exact end datetime, e.g. '2024-01-15 15:00:00' (UTC). Alternative to end_date. | |
| past_minutes_start | No | Relative range start in minutes ago, e.g. 60. Use with past_minutes_end instead of dates. | |
| past_minutes_end | No | Relative range end in minutes ago, e.g. 0 for 'now'. Use with past_minutes_start. | |
| filters | No | Optional list of filters to narrow the data (AND logic across different filters). Example: [{"parameter":"country","type":"equals","value":["US"]}] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It correctly implies a read-only operation but lacks details on authentication, rate limits, pagination, or data format. The aggregation behavior is stated, but no edge cases or constraints are disclosed.
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 wastes no words. It front-loads the primary purpose. However, it could be considered slightly under-specified given the tool's complexity.
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 absence of an output schema and 9 parameters, the description should explain the return format (e.g., structure of geographic data) and possible limitations. It only vaguely mentions 'aggregated counts' without describing the actual response shape or error conditions.
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 has 100% description coverage, so the description adds little extra beyond clarifying the output context. The description does not deepen understanding of parameter interactions, such as the relationship between date ranges and relative time 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 retrieves aggregated session counts by geographic coordinates (lat/lon, city, country) for a site, with the specific use case of plotting on a map. This verb+resource combination distinguishes it from sibling tools like rybbit_get_overview or rybbit_get_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?
The description hints at usage for map plotting but does not provide explicit guidance on when to use this tool versus alternatives, nor does it give any 'when not to use' advice or mention sibling tools by name for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get configuration and details for a single site by ID (name, domain, tracking feature flags, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | The Rybbit site ID (numeric ID from your Rybbit dashboard or the rybbit_list_sites tool). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only describes what the tool returns (configuration and details) but does not disclose whether it is read-only, requires authentication, rate limits, error behavior, or side effects. This is a significant gap for a tool with no 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, well-structured sentence that front-loads the verb and resource, then provides examples. There is no unnecessary information, and every word adds value. 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 simple read tool with one parameter and no output schema, the description covers the return fields (name, domain, tracking feature flags) and parameter source. However, it lacks information on error handling, authentication requirements, or whether the tool is destructive. Given the low complexity, it is mostly complete but could be slightly more thorough.
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 single parameter 'site' is described in the schema as 'The Rybbit site ID (numeric ID from your Rybbit dashboard or the rybbit_list_sites tool).' The description adds value by providing context on where to obtain the ID, going beyond the schema's type information. Schema coverage is 100%, so the description enhances understanding.
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 'Get configuration and details for a single site by ID' with specific examples of returned fields (name, domain, tracking feature flags). This distinguishes it from sibling tools like rybbit_list_sites (for listing) and other get tools for different resources.
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 indicates usage 'by ID', implying it should be used when the site ID is known. While it doesn't explicitly state when not to use it or mention alternatives, the context signal of sibling tools (e.g., rybbit_list_sites) provides implicit differentiation. A score of 4 reflects clear usage context but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a paginated list of visitor sessions with details: location, browser/OS/device, referrer, entry/exit pages, pageview and event counts, duration, and UTM params.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | The Rybbit site ID (numeric ID from your Rybbit dashboard or the rybbit_list_sites tool). | |
| page | No | Page number, 1-indexed. | |
| limit | No | Number of sessions per page. | |
| user_id | No | Filter to sessions for a specific Rybbit user_id. | |
| identified_only | No | Set to restrict to sessions with an identified user (per Rybbit's identify() API). | |
| start_date | No | Start date, e.g. 2024-01-01. Use with end_date and time_zone. | |
| end_date | No | End date, e.g. 2024-01-31. Use with start_date and time_zone. | |
| time_zone | No | IANA time zone, e.g. America/New_York. Required when using start_date/end_date or start_datetime/end_datetime. | |
| start_datetime | No | Exact start datetime, e.g. '2024-01-15 13:00:00' (UTC). Alternative to start_date. | |
| end_datetime | No | Exact end datetime, e.g. '2024-01-15 15:00:00' (UTC). Alternative to end_date. | |
| past_minutes_start | No | Relative range start in minutes ago, e.g. 60. Use with past_minutes_end instead of dates. | |
| past_minutes_end | No | Relative range end in minutes ago, e.g. 0 for 'now'. Use with past_minutes_start. | |
| filters | No | Optional list of filters to narrow the data (AND logic across different filters). Example: [{"parameter":"country","type":"equals","value":["US"]}] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It mentions pagination and returned fields but omits important aspects like rate limits, authentication requirements, or any side effects. For a read-only listing tool, more context is expected.
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, well-structured sentence that front-loads the main action and includes key details without extraneous information.
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?
Despite 13 parameters and no output schema, description only outlines output fields. It lacks guidance on filtering, ordering, or default pagination sizes, leaving significant gaps for a complex 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 coverage is 100%, so description adds no extra meaning beyond parameter names. The description focuses on output, not input parameters, meeting baseline but not exceeding.
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?
Description clearly states 'Get a paginated list of visitor sessions' with specific details like location, browser, etc. It differentiates from sibling tools (e.g., get_session for single session, get_breakdown for different aggregation).
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?
Description implies use for listing sessions but does not explicitly guide when to choose this over siblings. No 'when to use' or 'when not to use' information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all organizations the authenticated user belongs to, and every site (with its numeric site ID) under each. Call this first if you don't already know a site ID.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses that authentication is required and that the output includes organizations and sites with IDs. It could be more explicit about permissions and whether the list is exhaustive.
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?
Two concise sentences: first describes the action and result, second provides usage guidance. No extraneous 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?
For a simple list tool with no parameters or output schema, the description covers the purpose and output structure adequately. It lacks mention of limitations or exact return 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?
The input schema has zero parameters, so baseline applies. Description adds no parameter info because none exist.
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 it lists organizations and sites with numeric site IDs. The phrase 'Call this first if you don't already know a site ID' distinguishes it from siblings like rybbit_get_site, which retrieves a specific site.
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 explicitly advises to call this tool first when site ID is unknown, providing clear context for use. However, it does not mention when not to use it or directly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool serves a distinct analytics purpose: breakdown, live visitors, overview, timeseries, session detail, location map, site config, session list, site list. No overlap in functionality.
All tools follow the consistent pattern 'rybbit_{verb}_{noun}' with verbs 'get' for single/aggregate results and 'list' for collections, and nouns clearly indicating the resource.
9 tools cover the core analytics operations—overview, breakdown, sessions, live visitors, site listing—without being excessive. Each tool earns its place for typical analytics queries.
The set provides comprehensive querying capabilities for analytics metrics, breakdowns, sessions, and sites. Missing are explicit date-range parameters noted in descriptions, and custom event detail retrieval beyond breakdowns, but the core is well-covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Analytics your AI agent can actually use. Track, experiment, and optimize via MCP.
Read-only analytics for Convex apps, queryable via MCP from Claude, Cursor, and other clients.
Read and edit GA4, Search Console and Google Tag Manager from any MCP client. 29 tools.
Analytics and debugging for your MCP server — explore usage and sessions, then root-cause errors.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/neverhunt/rybbit-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
