rybbit-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.9/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives 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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. 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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![rybbit-mcp MCP server](https://glama.ai/mcp/servers/neverhunt/rybbit-mcp/badges/card.svg)](https://glama.ai/mcp/servers/neverhunt/rybbit-mcp)

Score Badge

Copy to your README.md:

[![rybbit-mcp MCP server](https://glama.ai/mcp/servers/neverhunt/rybbit-mcp/badges/score.svg)](https://glama.ai/mcp/servers/neverhunt/rybbit-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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