Rybbit MCP Server

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation4/5
Most tools target distinct resources and actions, but the analytics cluster (overview, overview_timeseries, metric, site_summary, compare_periods) has overlapping purposes that require careful reading of descriptions. The rest are clearly separated by resource type.
Naming Consistency5/5
All tools follow a consistent rybbit_<verb>_<noun> snake_case pattern, with clear verbs like get, create, update, delete, track, analyze. This makes the tool set predictable and easy to navigate.
Tool Count2/5
At 57 tools, this is far beyond the typical well-scoped MCP server. While each tool has a defined role, the sheer number creates cognitive overhead and increases the likelihood of misselection.
Completeness4/5
The tool set covers the full analytics lifecycle: data ingestion (track), querying (run_query), dashboards (overview, funnels, retention), user management, and site/team administration. Minor gaps exist (e.g., no remove_organization_member), but the surface is largely comprehensive.
Average 3.5/5 across 57 of 57 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 23 commits in the last 12 weeks
- Last stable release on July 18, 2026
- 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of disclosing behavioral traits. It only states 'Get members' with no mention of required permissions, return format, pagination, rate limits, or any side effects. The description is entirely non-transparent about behavior beyond the minimal action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the key action and resource. It avoids verbosity or irrelevant details. While it is minimal, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description should compensate by explaining expected return values or any special behavior. It does not, leaving the agent uncertain about the response structure or potential limitations. For a simple fetch tool, this is a notable gap.
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 one parameter (organizationId) with 100% description coverage, so the schema already documents its meaning as 'Organization identifier'. The description adds no additional semantic context about the parameter, which is acceptable given the high schema coverage but does not enhance the agent's understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Get') and resource ('members of a specific organization'). It distinguishes this from sibling tools like rybbit_get_organizations (which lists organizations) and rybbit_add_organization_member (which adds members). The wording does not explicitly name alternatives but the purpose is unambiguous.
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, nor does it mention any context such as prerequisites or typical use cases. Sibling tools like rybbit_add_organization_member imply a related action, but the description does not state when to use this instead.
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?
With no annotations provided, the description must fully disclose behavioral traits. It only states the action without mentioning potential side effects, required authorization, or behavior when the member already exists. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence, but it adds little value beyond the tool name. It lacks structure or detail, and while not overly verbose, it under-specifies rather than being efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description does not explain success/failure behavior, restrictions, or role semantics beyond the enum. For a mutation tool, this minimal text leaves the agent without essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully covers all three parameters (organizationId, email, role) with descriptions and an enum for role. The description adds no additional parameter meaning, which aligns with the baseline of 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Add') and resource ('member to an organization'). However, it does not explicitly differentiate it from sibling tools like rybbit_get_organization_members or rybbit_update_member_site_access, so it misses the top score for sibling distinction.
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, prerequisites, or alternatives. There is no mention of exclusions (e.g., cannot add existing members) or contrast with other member-management tools.
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 carry full behavioral disclosure. It only states 'get error occurrence trends over time' with no detail on aggregation, time-bucket behavior, default ranges, or output shape. This is insufficient for an agent to understand side effects or response semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, but it is also under-specified—'trends over time' conveys little more than the tool name. It is appropriately short but lacks the detail that would make it truly useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no annotations, and no output schema, this description is far too thin. It doesn't explain return values, how date ranges or pastMinutes interact, what 'filters' are for, or how this differs from sibling tools. The complexity demands more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the schema does the heavy lifting. The description itself adds no parameter-specific meaning beyond the tool's general purpose, which aligns with a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('error occurrence trends over time'), clearly indicating it returns time-series error data. It doesn't explicitly contrast with sibling timeseries tools like rybbit_get_overview_timeseries, but the error-specific naming and phrasing provide adequate 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 such as rybbit_get_error_events or rybbit_get_error_names. There are no stated use cases, prerequisites, or exclusion criteria.
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?
With no annotations, the description must disclose behavior, but it only implies a mutation. It doesn't state whether the update is partial or replaces the whole configuration, whether it requires special permissions, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, but it is underspecified for a tool with 10 parameters. It's concise in length but not appropriately sized to convey necessary usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 10 parameters, no annotations, and no output schema, the description provides almost no context. The schema covers parameter meanings, but the description fails to explain the update semantics, required siteId, or return behavior, leaving the agent to guess.
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 structured schema already explains all 10 parameters. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Update') on a clear resource ('site configuration'). It is not a bare tautology, but it lacks detail about what configuration aspects are affected and doesn't explicitly differentiate it from other site-related tools like rybbit_get_site or rybbit_delete_site.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There's no mention of prerequisites, partial vs. full updates, or that it's the mutation counterpart to rybbit_get_site.
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 carries the full burden. It does not disclose whether the operation is read-only, how it handles date ranges, potential rate limits, or any side effects. The behavioral profile is largely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the action and expected outcome. There is no wasted wording, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and no output schema, this is a moderately complex tool, but the description is too terse. It does not explain how parameters interact, what the return structure looks like, or how to choose between date-based and past-minutes time ranges. The lack of behavioral context makes it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all parameters. The description adds minimal semantic value beyond hinting at 'step-by-step conversion data,' which aligns with the steps parameter. Since the schema does the heavy lifting, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes a funnel and returns step-by-step conversion data, providing a specific verb and resource. However, it does not distinguish itself from sibling tools like rybbit_get_funnels or rybbit_get_funnel_step_sessions, so it lacks explicit 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?
There is no guidance on when to use this tool versus alternatives. The description gives no context about prerequisites, exclusions, or appropriate scenarios, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses no behavioral traits beyond the schema's mode enum: no mention of read-only nature, pagination, parameter interactions, or required date ranges. The description adds essentially no operational 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, direct sentence. It is front-loaded with the action and object, contains no filler, and is highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, no output schema), the description provides almost no operational context. It omits how the steps array should be structured, date range requirements, pagination behavior, and the nature of the return value. This is inadequate for correct invocation.
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 baseline is 3. The description does not add meaningful parameter semantics; it paraphrases what mode and stepNumber already specify in 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 uses a specific verb 'Get' and clearly identifies the resource: sessions filtered by funnel step outcome (reached or dropped off). This distinguishes it from generic session tools like rybbit_get_sessions and funnel analysis tools like rybbit_analyze_funnel.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as the need for a funnel definition or when to prefer this over related funnel/session tools.
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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It fails to explain how journeys are computed, what counts as a 'page navigation path,' whether results are paginated, or the meaning of 'most common' (e.g., frequency threshold). Only a high-level function is stated, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy or filler. Every word contributes to the core purpose, making it highly concise and well-structured for quick parsing.
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 tool has 10 parameters, no output schema, and no annotations, the one-sentence description is insufficient. It does not clarify the relationship between parameters (e.g., how 'filters' and 'stepFilters' interact), expected return shape, or business context (e.g., does 'journeys' imply a sequence of page views within a session?). The agent would need to guess at important usage details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 100% of the 10 parameters, so the baseline is 3. The tool description adds minimal parameter context beyond the schema, such as implying that 'limit' and 'steps' control journey characteristics, but it doesn't provide additional semantic value beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving the most common page navigation paths (user journeys) within sessions. It uses a specific verb ('Get') and identifies the resource ('journeys'). It distinguishes itself from sibling tools like 'rybbit_get_sessions' or 'rybbit_get_funnels' by focusing on navigation paths, though it doesn't explicitly contrast those alternatives.
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 the many sibling analytics tools, nor does it mention any prerequisites or exclusions. Usage context is only implied by the tool name and description, offering no explicit decision criteria for an AI agent.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to explain what 'currently active' means (e.g., the time window defined by the 'minutes' parameter) and does not mention the return format or any edge cases. The behavior is underspecified beyond the basic read operation.
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 of 10 words, efficiently front-loaded with the main purpose. It contains no fluff or redundant information, but it is slightly terse given that it omits useful context that could be included without bloating.
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?
For a simple read tool with no output schema, the description covers the core function but lacks details about the return value (e.g., whether it's just a number or includes a timestamp). The existing schema documents parameters, so the main gap is the absence of output/response expectations, which is moderate for a tool this simple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters, including descriptions for siteId and minutes. The description adds no extra meaning about the parameters, so it meets the baseline of 3 given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: getting the count of currently active visitors. It is specific about the resource (visitors) and the state (currently active), which distinguishes it from other get_* tools. However, it does not explicitly differentiate itself from similar tools like get_overview or get_sessions, so it misses the full 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. It neither mentions prerequisites, exclusions, nor alternative tools. The only implied usage is for live visitor counts, but there is no explicit context or when-not-to-use information.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the tool's basic function. It does not explain data aggregation, permissions, timezone handling, filter behavior, or what the response contains.
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, front-loaded sentence with no filler words. It is concise, but it could be slightly expanded with usage context without becoming bloated.
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 8 parameters, no output schema, and many sibling timeseries tools, this description is too sparse. It does not clarify how this tool relates to other performance/timeseries tools, what metrics are included, or what the response structure looks like.
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 every parameter already has a meaningful description. The tool description adds no additional parameter semantics, which is acceptable given the schema's thoroughness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('performance metrics over time'), which clearly separates it from non-timeseries performance tools like rybbit_get_performance_overview and rybbit_get_performance_by_dimension. However, it does not distinguish it from other timeseries tools like rybbit_get_overview_timeseries or rybbit_get_error_timeseries.
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 phrase 'for trend analysis' implies the tool is for temporal analysis, but there is no explicit guidance on when to use this tool versus alternatives. It does not mention sibling tools, prerequisites, or scenarios where another getter 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only says 'Get,' implying a read operation, but does not explain what the returned analysis data looks like, whether it is aggregated, any data delays, or limitations. This lack of detail leaves the agent guessing about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. Every word earns its place by stating the action and resource clearly. It is appropriately sized for such a tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must explain what the tool returns. It merely says 'analysis data' without specifying the format, cohort definition, or any constraints. This is insufficient for an agent to fully understand the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all three parameters (mode, range, siteId) with 100% coverage, so the baseline is 3. The description adds no extra meaning about parameter interactions or usage context, but since the schema is thorough, no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('cohort-based retention analysis data'), making the purpose unambiguous. However, it does not explicitly differentiate this tool from sibling analytics tools such as rybbit_get_overview or rybbit_get_metric, although the 'retention' focus provides some implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention use cases, prerequisites, or conditions for selection, leaving the agent to infer from the name alone. No exclusions or alternative tool references are provided.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions pagination and analytics data, without covering read-only nature, default pagination sizes, sorting behavior, or the structure of the response. This is minimal and leaves the agent uncertain about important behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and resource. It contains no filler, though it could be more informative while still remaining concise.
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 tool's complexity (11 parameters, no output schema, no annotations) and the large number of sibling tools, the description is too minimal to provide complete context. It doesn't explain how pagination parameters interact, what 'analytics data' includes, or which filters are commonly used.
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%, with all 11 parameters having individual descriptions. The tool description adds no additional meaning to the parameters, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a paginated list of sessions with analytics data, using a specific verb and resource. It is distinguishable from sibling tools like rybbit_get_session_details by mentioning pagination and a list, but it doesn't explicitly call out the distinction from related list tools such as rybbit_get_user_sessions.
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 alternative list tools like rybbit_get_user_sessions or rybbit_get_goal_sessions. It lacks any context about appropriate use cases, prerequisites, or exclusions.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that the result is paginated, which is already implied by schema parameters. It doesn't disclose the return format, default sorting/pagination, or whether this is a read-only operation (though 'Get' hints at it). No mention of required siteId context or filtering behavior.
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, front-loaded with the action verb 'Get', and contains no filler. Every word earns its place and it is easy to parse quickly.
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 having 12 parameters and no output schema, the description is minimal and doesn't explain the return structure, default pagination behavior, or the meaning of 'analytics data'. It lacks usage context and fails to compensate for the complexity, making it insufficient for an agent to fully understand the tool's behavior without additional inference.
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 baseline is 3. The description adds no parameter-specific meaning beyond what the schema provides; 'analytics data' hints at the output fields, but doesn't clarify parameter semantics. The schema itself already documents all 12 parameters, including formats, enums, and alternatives (e.g., date-based vs pastMinutes).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Get'), the resource ('a paginated list of users'), and a qualifier ('with analytics data'). It distinguishes from sibling tools like get_user_info (single user) and get_user_sessions (user sessions), though it could be more explicit about which analytics metrics are included.
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 over alternatives. Sibling tools like get_user_info, get_user_sessions, and get_user_session_count exist, but the description doesn't differentiate use cases or mention any exclusions. The only hint is 'list of users with analytics data', which implies usage for bulk user listing.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'update', but does not explain whether updates are partial or full, what happens to omitted optional fields, required permissions, or error behavior. This is vague for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded, clear sentence with no redundant wording. It is appropriately concise for the action it describes.
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?
This is a mutation tool with 8 parameters, no output schema, and no annotations. The description does not mention the need for siteId and goalId identifiers, how it relates to goal creation/deletion, or what a successful update returns. The context is insufficient for an agent to use this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all parameters, so the baseline is 3. The description adds no additional parameter-level meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (update) and resource (existing goal configuration), which is specific. However, it does not explicitly distinguish from sibling tools like rybbit_create_goal or rybbit_delete_goal beyond the word 'existing'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. There are no preconditions (e.g., the goal must already exist) or exclusions. This gap is significant given the sibling tools for creating/deleting goals.
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?
With no annotations, the description carries the full burden but only restates that it retrieves completed-goal sessions. It does not mention pagination, ordering, time ranges, or potential side effects, adding marginal value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, but it is under-specified for a tool with multiple parameters. It is not as minimal as 'Process', but it lacks necessary elaboration for a non-trivial operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks context about how sessions relate to goals, how to obtain siteId/goalId, or what the response contains. With no output schema and no annotations, this is insufficient for an agent to confidently invoke the tool in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description does not add parameter details, but the schema is sufficient for parameter 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 uses a specific verb ('Get') with a clear object ('sessions') and a qualifying condition ('that completed a specific goal'), distinguishing it from generic session tools like rybbit_get_sessions and funnel-specific tools like rybbit_get_funnel_step_sessions.
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 over siblings such as rybbit_get_funnel_step_sessions or rybbit_get_sessions. It only states the basic action, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of disclosing behavior. It only says 'Create or update' without explaining side effects, the role of reportId, conflict handling, or return values. This is insufficient for a mutation tool.
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, front-loaded sentence with no wasted words. While efficient, it is slightly undersized for a dual create/update operation that would benefit from a bit more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a minimal description, the tool lacks essential context. It does not explain when update occurs, what the steps JSON should include, or what the API returns, making it incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all four parameters (100% coverage), so the baseline is 3. The description adds no additional meaning beyond the schema, such as how steps should be structured or when reportId triggers an update.
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 'Create or update a saved funnel' with a specific verb and resource. It distinguishes this tool from read-only funnel tools like rybbit_get_funnels and rybbit_analyze_funnel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. The description does not mention the distinction between creating a new funnel and updating an existing one, nor does it reference sibling tools for lifecycle management.
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?
With no annotations, the description carries the full burden of disclosing behavior. It implies a read-only operation via 'Get', but does not mention output format, pagination, authorization requirements, or any potential side effects. The minimal phrase adds little beyond the tool name.
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 concise sentence that immediately states the action and scope. There is no wasted wording and the key information is front-loaded.
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?
For a simple one-parameter list tool with no output schema, the description is adequate but sparse. It does not describe the structure of returned funnels or any error/edge-case behavior, leaving the agent to infer too much for a tool with no annotations.
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 siteId described as 'Site ID or identifier'. The description echoes this with 'for a site' but adds no additional parameter meaning. Baseline of 3 is appropriate when the schema already documents the only parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('all saved funnels') scoped to a site, clearly indicating a list operation. It distinguishes from siblings like rybbit_analyze_funnel and rybbit_create_funnel, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as rybbit_analyze_funnel or rybbit_get_funnel_step_sessions. The description simply states what it does without context for selection.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states a read operation ('Get') but does not mention any potential side effects, required permissions, return format, or edge cases. It is functionally transparent for a simple read but lacks valuable 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, concise sentence that directly states the tool's function without any redundant or extraneous words. It is perfectly sized for the information it conveys.
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's simplicity (one parameter, no output schema), the description is adequate but not complete. It does not specify what details and configuration include, nor does it differentiate from similar tools like rybbit_get_site_summary or rybbit_get_overview. More context would help an agent decide when to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter 'siteId' with its description 'Site ID or identifier'. The tool description adds no additional meaning beyond implying site identity, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get site details and configuration' clearly states the verb (Get) and resource (site details and configuration), distinguishing it from sibling tools that fetch other types of data (e.g., overview, visitors, retention). It is specific enough to identify the tool's primary purpose, though 'details and configuration' is somewhat generic.
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 the many sibling get_* tools. There are no exclusions or alternative recommendations, leaving the agent to infer usage solely from the tool name.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get' which implies read-only, but does not disclose required permissions, error behavior, return format, or any constraints. The mention of 'profile traits and linked devices' gives some clue about the response but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is concise and free of fluff. It efficiently communicates the core purpose in a well-structured manner.
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?
For a simple two-parameter read tool with no output schema, the description is minimally viable but leaves gaps. It does not describe the full return value shape beyond 'profile traits and linked devices', nor does it provide usage context or prerequisites. However, the tool's simplicity lessens the need for extensive detail.
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 parameter descriptions ('Site ID or identifier', 'User identifier') are minimal and add little beyond the parameter names. The tool description does not elaborate on how these parameters affect the query, so it fails to add meaningful semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get'), resource ('detailed user information'), and adds scope ('including profile traits and linked devices'). It distinguishes from sibling tools by its focus on profile traits and devices, though it does not explicitly say 'single user' to differentiate from rybbit_get_users.
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_users or rybbit_get_user_sessions. It only describes what the tool does, leaving the agent to infer usage from the name and parameters.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only mentions pagination, which is already implied by the page/pageSize parameters in the schema. It does not disclose date range behavior, sorting, response structure, rate limits, or any side effects. The event type clarification adds scope but not behavioral depth.
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, focused sentence that front-loads the primary action and resource. It contains no redundant text and earns its place by specifying the event types, which adds useful scope clarification.
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 tool has 11 parameters, no output schema, and no annotations, the description is far too minimal. It does not explain how the pieces fit together (e.g., pagination flow, date filtering, filter syntax), leaving the agent to infer critical usage context from the parameter descriptions alone.
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 all parameters already have descriptions. The tool description adds no extra meaning beyond the schema, so a baseline of 3 is appropriate. It does not explain relationships between parameters like startDate vs pastMinutesStart, but the schema descriptions are sufficient.
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 a paginated list of events, enumerating the specific event types (pageviews, custom events, outbound clicks). This distinguishes it from sibling tools like get_sessions, get_event_names, and get_outbound_links, which target different data shapes or aggregations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are no explicit conditions, exclusions, or references to sibling tools that could help the agent decide between, for example, get_events and get_sessions or get_event_names.
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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says the tool 'gets' a breakdown, which is a read operation, but it does not disclose pagination (page/limit), date filtering (startDate/endDate), filtering (filters), or timezone handling. These are significant behavioral aspects that the agent would not know about from the description alone.
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, 13 words, and front-loaded with the primary action. It contains no filler or redundant information. Every word earns its place, making it exceptionally concise and well-structured.
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?
This tool has 10 parameters, no annotations, and no output schema. The description is too brief to fully orient the agent: it does not explain what 'metrics' are included, how the date-range parameters work together, how filters are structured, or what the response looks like. Given the complexity, the description is incomplete and leaves the agent to guess important operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all 10 parameters, so the baseline is 3. The description adds a small semantic layer by explaining that 'parameter' is the dimension to break down by and lists example values, but it does not elaborate on the other 9 parameters. No additional value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get dimensional breakdown of metrics by a specific parameter' – a specific verb ('get') and resource ('metrics' broken down by a dimension). It lists concrete examples (browser, country, pathname), which helps distinguish it from sibling tools like overview or live visitors. However, it does not explicitly differentiate itself from similar breakout tools like get_sessions or get_events, so it loses a point.
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 usage context is implied: the user chooses a 'parameter' to break down metrics by. But there is no explicit guidance on when to use this tool versus alternatives, no 'use when' or 'instead of' language, and no mention of prerequisites like date range or site selection. The description relies on the reader to infer that this tool is for dimensional analysis.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the core function. It does not disclose how the list is ordered, whether counts are aggregated per link, how date parameters interact, or any rate limits. This could mislead an agent about the tool's behavior.
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 with no filler words, efficiently conveying the primary purpose. It is appropriately front-loaded with the action and resource.
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 complexity of 7 parameters including alternative date ranges (pastMinutesStart/End) and filters, the description is too sparse. It does not explain the structure of the returned list, how occurrence counts are computed, or the relationship between the date parameters. This is insufficient for reliable tool invocation without additional schema reads.
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 descriptions cover all 7 parameters (100% coverage), including formats and purpose (e.g., startDate, endDate, pastMinutes). The tool description adds no additional parameter-level meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a list of outbound link clicks') and the resource ('outbound link clicks') with their occurrence counts, distinguishing it from sibling tools that focus on other entities (e.g., events, goals, sessions). The verb is specific and the outcome is understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites (e.g., siteId), time period selection, or any exclusions, leaving the agent to infer usage from the name alone.
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 carry the full burden of disclosing behavior. It only states what the tool does ('Get time-series analytics data') without explaining return formats, defaults, required auth, or limitations. This is minimal for a read operation, but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds meaning, and it avoids repeating schema details.
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 having 8 parameters and no output schema, the description provides only a high-level purpose. It doesn't describe what data is returned, how time ranges interact, or what filters do, leaving the agent with incomplete information for tool selection and invocation.
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% descriptive coverage for all 8 parameters, so the baseline is 3. The description's reference to 'configurable time buckets' adds context to the bucket parameter but doesn't enrich the other parameters. This is adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' with a specific resource ('time-series analytics data') and adds the differentiator 'broken into configurable time buckets for trend analysis.' It clearly separates this from non-timeseries tools like rybbit_get_overview, though it doesn't explicitly differentiate from other timeseries siblings such as rybbit_get_performance_timeseries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case ('for trend analysis') but provides no explicit when-to-use or alternative guidance. With many sibling tools like rybbit_get_performance_timeseries and rybbit_get_error_timeseries, the agent gets no help choosing among them.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action and metrics, but does not disclose what the response structure looks like, whether date ranges are required, how data is aggregated, or any potential side effects. This is a significant gap for a tool with 7 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose and the specific metrics. There is no wasted wording or repetition, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters and no output schema, so the description should explain the return values and default behavior. It falls short by only naming the metrics, without explaining what the overview output contains, how percentiles are presented, or how date/filter parameters affect the result. This leaves significant contextual gaps.
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%, meaning all 7 parameters have descriptions in the input schema. The tool description itself adds no extra meaning to the parameters; it only lists output metrics. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('Core Web Vitals and performance metrics overview') plus specific metrics (LCP, CLS, INP, FCP, TTFB percentiles). This clearly states what the tool does and differentiates it from sibling tools like rybbit_get_performance_timeseries and rybbit_get_performance_by_dimension by emphasizing 'overview'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or scenarios where one of the sibling performance tools would be more appropriate. The word 'overview' implies a summary use case, but explicit guidance is absent.
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 carry the full burden of behavioral disclosure. The description only states the action and does not mention side effects, return format, timezone handling, or whether it is a safe read operation. This is a significant gap.
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, direct sentence that clearly front-loads the action and resource. No filler or redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema, the description should explain the return value structure. It only says 'number of sessions per day' without specifying the format (e.g., array of dates and counts) or how timeZone affects the daily aggregation. This leaves the agent without enough context for a complete invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters (siteId, userId, timeZone). The description adds no extra meaning beyond the schema; it merely repeats the 'specific user' concept. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('get'), resource ('number of sessions per day'), and scope ('specific user'). It distinguishes from siblings like rybbit_get_user_sessions by focusing on a daily count rather than session details, but it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied from the purpose: use when needing a daily session count for a user. However, there is no explicit guidance on when to use this tool versus siblings like rybbit_get_user_sessions, nor any conditions or exclusions.
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?
With no annotations provided, the description carries the full burden. It only states 'Get session data for a specific user' and does not disclose what data is returned, whether it returns a list, pagination, filtering behavior, or any access requirements. This is minimal and leaves much behavior unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly-worded sentence with no redundancy. It front-loads the verb and object and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain what 'session data' means and what is returned. The one-liner is too sparse to fully inform an agent about the return shape or scope, especially given the many sibling session tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (siteId, userId) have schema descriptions, providing 100% coverage. The description does not add additional semantics beyond the schema, such as formats or relationships. Baseline 3 is appropriate as the schema handles the meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('session data') with a specific scope ('for a specific user'), differentiating it from broader session tools like rybbit_get_sessions. The verb and object are unambiguous, though the exact nature of 'session data' is not elaborated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as rybbit_get_sessions or rybbit_get_session_details. There are no prerequisites, exclusions, or examples to help select this tool.
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 bear the burden of behavioral disclosure. It only says 'send' but does not describe side effects (e.g., event persistence), required permissions, or the expected response. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and efficiently lists the event type variants in parentheses. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 14 parameters, no output schema, and no annotations, the description is far too minimal. It does not hint at return values, error behavior, or the overall workflow, leaving the agent with limited context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema; it lists event types that are already in the enum. It does not explain relationships between parameters (e.g., `eventName` required for `custom_event`).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Send) and resource (tracking event), and enumerates the supported event types. It is easily distinguishable from the sibling `rybbit_track_events` by being singular, though the description does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not mention that this is for a single event while `rybbit_track_events` might handle multiple, nor does it state any prerequisites or exclusions.
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?
With no annotations, the description must carry full weight. It mentions 'permanently', indicating irreversibility, but does not disclose what gets destroyed (site data, associated analytics, user access), any auth requirements, or whether the operation cascades to related resources. This is inadequate for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. Every word adds value: 'Delete site' identifies the action/object, and 'permanently' conveys a key behavioral trait.
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?
For a simple one-parameter delete, the description is minimally viable: it states the action and irreversibility. However, it omits crucial context such as what happens to dependent data, whether confirmation is needed, and any return value. Given the absence of annotations and output schema, more detail would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for siteId with 'Site ID or identifier'. The description adds no additional meaning about how to obtain the siteId or any format expectations. Baseline 3 applies because schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('site'), clearly distinguishing it from the many read-only sibling tools like rybbit_get_site and also from other delete tools like rybbit_delete_user. It states exactly what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, such as rybbit_update_site for modifications or archiving. It also fails to mention prerequisites like ownership/permissions or that deletion is irreversible beyond the word 'permanently', which is only hinted.
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 of disclosing behavior. The verb 'Get' clearly implies a read-only operation with no side effects, which is a positive signal. However, it does not disclose any additional behavioral traits such as date-range defaults, response format, pagination, or data aggregation caveats, leaving some ambiguity for agents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the core purpose and lists key metrics. There is no redundancy, filler, or irrelevant detail, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderate number of parameters (7) and no output schema. The description covers the basic purpose, and the schema explains parameters well. However, it lacks usage context relative to sibling tools and provides no information about the return structure or any specific behaviors like default date ranges. For a simple read-only tool, the description is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description itself adds no extra meaning about the parameters; it only lists the metrics returned. The schema already provides clear descriptions for all seven parameters, including date formats and alternative time windows, so the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Get high-level analytics metrics for a site' and lists the specific metrics (sessions, pageviews, users, bounce rate, session duration). This specifies both the action and the resource, and distinguishes it from sibling tools like 'rybbit_get_overview_timeseries' or 'rybbit_get_metric' by emphasizing 'high-level' aggregate metrics. However, it does not explicitly contrast itself with 'rybbit_get_site_summary', which could overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool vs. alternatives. It does not mention that this is a summary endpoint, when to choose it over get_overview_timeseries, get_metric, or get_site_summary, or when not to use it. There is no mention of prerequisites or contextual recommendations.
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 carries the full burden of behavioral disclosure. It states that the output includes stack traces and full context, which gives some idea of the return type, but it omits behavior around pagination, date-range filtering, rate limits, or any potential side effects. The transparency is adequate but minimal for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, immediately front-loaded with the core purpose. Every word contributes value, and there is no redundancy or fluff. It is an excellent example of concise writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no output schema, and no annotations, the description is sparse. It doesn't differentiate this tool from rybbit_get_events or other error-related tools, and it doesn't explain the full response structure beyond 'full context'. The schema covers parameters well, but the description leaves the agent without enough context for confident tool selection and invocation.
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?
All 10 parameters have individual schema descriptions, giving 100% coverage. The description adds no new parameter semantics beyond the schema; it only reinforces that errorMessage is a filter. Baseline 3 is appropriate when the schema is comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource as 'individual error occurrences'. The mention of 'full context including stack traces' distinguishes it from sibling tools like rybbit_get_error_names (which likely returns only names) and rybbit_get_error_timeseries (which returns timeseries data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or scenarios where another error-related tool (e.g., rybbit_get_error_names, rybbit_get_error_timeseries) would be more appropriate. This leaves the agent without clear selection criteria.
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 carries the full burden. It implies a read-only operation via 'Get' and discloses the aggregate nature (unique messages, counts). However, it does not mention pagination behavior, filter application, or any operational details that might affect usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's purpose. It is concise and free of any wasted words, earning full marks for efficiency.
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?
Despite having 9 parameters and no output schema, the description focuses on the core return value but omits usage context and alternative selection criteria. The schema covers parameter details, but the description does not provide enough context for an agent to fully assess when this tool is the best choice compared to error_events and error_timeseries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all 9 parameters, so the baseline is 3. The description adds no extra parameter meaning beyond the schema, which is acceptable but not enhancing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and a detailed resource: 'unique error messages with occurrence and session counts'. It distinguishes itself from sibling tools like rybbit_get_error_events and rybbit_get_error_timeseries by emphasizing the aggregated, unique-message nature of the result.
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?
There is no guidance on when to use this tool versus alternatives. No mention of exclusions, prerequisites, or contrasting sibling tools, leaving the agent without direction for selection among error-related tools.
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 carries the full burden of disclosing behavioral traits. The description merely restates the creation action and the purpose (tracking conversions) but does not disclose any side effects, required inputs beyond the schema, potential errors, or what the response will look like. For a create operation, this lack of additional context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource. Every word is informative, with no filler or repetition of information already present in the tool name or schema.
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?
This is a create tool with 7 parameters, 3 required, and no output schema or annotations. The description is too minimal to provide contextual completeness; it does not clarify conditional parameter usage (e.g., eventName for event-based goals) or explain what the tool returns upon success. While the schema documents all fields, the description fails to tie things together or offer behavioral context, making it insufficient for an agent to fully understand how to invoke the tool effectively.
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 covers 100% of the parameters with descriptions, so the baseline is 3. The description adds no extra meaning beyond the schema; the mention of 'path-based or event-based' is already captured in the goalType enum. Thus, the description neither enhances nor detracts from the schema's clarity.
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 creates a new goal for tracking conversions, specifying path-based or event-based types. This distinguishes it from sibling tools like rybbit_get_goals, rybbit_update_goal, and rybbit_delete_goal, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for creating new goals, which is obvious from the name and the 'Create a new goal' phrasing. It doesn't explicitly exclude alternatives or name alternatives, but the context is clear, and the sibling tool names (update_goal, delete_goal) imply the distinction without needing explicit guidance.
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?
With no annotations provided, the description carries the full burden for behavioral disclosure. The word 'create' indicates a mutation, but there is no information about side effects (e.g., whether the site goes live immediately, default settings applied), permissions required, or what happens on duplicate domain. No behavioral traits beyond the basic action 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It follows a clear subject-verb-object structure and is appropriately sized for the tool's function. It wastes no tokens and delivers the core meaning efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters (3 required), no annotations, and no output schema. With such complexity, the description should provide additional context about what happens on creation, required inputs, or prerequisites. It only states the basic action, leaving significant gaps. Since there is no output schema, the description also does not clarify what the response will contain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 9 parameters. The description adds no parameter-specific meaning beyond what the schema provides; it merely states the overall purpose. Baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create), the resource (site), and the context (in an organization). It differentiates from siblings like rybbit_get_site, rybbit_update_site, and rybbit_delete_site by specifying the creation verb, and from other create tools (goal, funnel, team) by naming the resource. This is a specific and unambiguous purpose statement.
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 implies usage: use this tool when you need to create a new site within an organization. The verb and resource make the context clear. However, it does not explicitly mention alternatives or when-not-to-use, but the distinct resource and action provide adequate context without needing exclusions. This is above baseline clarity.
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 the burden of disclosing behavior. It does reveal that the tool returns aggregated counts and unique names, which is useful. However, it does not mention date-range applicability, permission requirements, or output structure beyond counts, leaving some behavioral ambiguity.
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, efficient sentence that conveys the core function without any filler. Every word contributes value.
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 tool with 7 parameters and no output schema, the description sufficiently explains the main return value (unique event names with counts). Combined with 100% schema parameter coverage, this is nearly complete. Minor gaps like sorting or pagination behavior are not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has a descriptive definition. The tool description does not add parameter-specific context, but given full schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Get a list of unique custom event names') and adds the distinguishing detail of 'occurrence counts'. This clearly separates it from sibling tools like rybbit_get_events or rybbit_get_event_properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or recommend this over rybbit_get_events for summary purposes. Usage context is only implied by the tool name and description.
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 carries full burden. It discloses that the result is paginated and includes conversion metrics, but does not mention response structure, default sorting, or any side effects. For a simple read operation, this is a minimum viable disclosure but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clear sentence that is front-loaded with the key action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain return shape. It mentions 'conversion metrics' but not the structure of a goal object or pagination metadata. For a tool with 11 parameters including filters and date ranges, the description is too thin to fully guide usage.
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?
All 11 parameters have detailed schema descriptions (100% coverage), so baseline is 3. The description adds no additional parameter-level semantics beyond confirming pagination (page/limit) and metrics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), names the resource ('goals'), and adds key details ('paginated list', 'conversion metrics'). This clearly distinguishes it from sibling tools like rybbit_create_goal, rybbit_update_goal, and rybbit_get_goal_sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching goals and their metrics but gives no explicit guidance on when to prefer this over alternatives like rybbit_get_goal_sessions or when not to use it. No alternatives or exclusions are mentioned.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic purpose and does not mention pagination, filters, return format, permissions, or rate limits, adding no extra insight beyond the name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, efficiently front-loading the core action and resource.
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 the schema having 100% parameter coverage, the tool has 12 parameters and no output schema. The description does not explain return structure, pagination/filter usage, or operational context, making it incomplete 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 repeats the dimension examples already present in the schema and adds no additional meaning to any 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 uses the specific verb 'Get' with resource 'performance metrics' and specifies the breakdown by dimension with examples. It clearly distinguishes from siblings like performance_overview and performance_timeseries by focusing on dimension breakdown.
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 implies its usage when a dimension breakdown is needed, providing clear context for when to use the tool. However, it does not explicitly name alternatives or exclusions, so it stops short of a 5.
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 carries the full burden of behavioral disclosure. It only states content scope and fails to mention pagination, filtering via minutes, or response structure. The phrase 'all events' conflicts with the schema's page/limit/offset parameters, potentially misleading agents into thinking pagination is unnecessary—a notable transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (13 words) that is front-loaded with the core action and resource. Every word contributes to the purpose, and there is no redundancy or filler.
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?
Without an output schema, the description should compensate by explaining return format, pagination behavior, and how optional parameters shape results. It only states 'detailed information' and 'all events and pageviews,' leaving the agent to guess about pagination, event ordering, and response fields. Given the tool's complexity (6 params, no output schema), this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters already have descriptions. The tool description adds little beyond that—it vaguely relates to 'events and pageviews' but does not explain how each parameter behaves or affects results. This meets the baseline for good schema coverage without adding extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource as 'detailed information about a specific session, clearly distinguishing it from list-oriented siblings like rybbit_get_sessions or rybbit_get_session_locations. It also mentions content scope ('including all events and pageviews'), making the purpose unambiguous.
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 phrase 'specific session' implies when to use this tool versus list or location-focused tools, providing clear context for the intended use case. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a full 5.
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 the full burden. It does disclose the key behavioral trait of permanence (irreversibility), which is a critical safety warning. However, it does not mention required permissions, effects on associated data, or error conditions.
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, efficient sentence with no unnecessary words. It is front-loaded with the core action and resource, and the word 'permanently' adds critical context without bloating the length.
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?
For a simple two-parameter delete tool with no output schema, the description is enough to convey purpose and irreversibility. However, it lacks guidance on usage context, potential side effects beyond deletion, and does not differentiate from other delete tools except by resource type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage for both parameters with basic descriptions. The tool description adds no additional meaning about the parameters beyond what is in the schema, so it earns the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a goal'), making it immediately obvious what the tool does. It also includes 'permanently' to emphasize the scope, which distinguishes it from potentially soft-delete operations.
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 intended use is implied by the verb and resource, but the description does not explicitly state when to use this tool versus alternatives like rybbit_update_goal or rybbit_get_goals, nor does it mention any prerequisites or 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?
With no annotations provided, the description carries the full burden. It discloses that results are 'aggregated' and include 'coordinates', which helps set expectations. However, it does not mention the role of date filters, whether data is returned in a specific format, or any other behavioral details that would aid an agent.
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, compact sentence that front-loads the key action and resource. It avoids unnecessary detail and is easy to scan.
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 absence of an output schema and the presence of 7 parameters, the description is minimal. It conveys the core output (locations with coordinates) but does not explain how the parameters shape the result, such as time aggregation or filtering. It is adequate for a straightforward read operation but lacks depth for an agent to fully anticipate tool behavior.
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 the parameter descriptions already document each field. The description adds the context of 'aggregated' and 'map visualization', but does not elaborate on how parameters like startDate, endDate, or pastMinutes affect the aggregation. It meets the baseline for fully documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies a distinct resource ('aggregated session locations with coordinates') with an explicit use case ('for map visualization'). This clearly differentiates it from sibling tools like rybbit_get_sessions and rybbit_get_live_visitors.
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 phrase 'for map visualization' implies the intended use case, but there is no explicit guidance on when to use this tool versus alternatives (e.g., rybbit_get_live_visitors for current locations). No exclusions or alternative references are 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, the description carries the burden of disclosing behavior. It states the deletion is 'permanently', which is a key behavioral trait (irreversible). However, it does not mention potential side effects, required permissions, or what happens to associated data, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the primary action. It contains no filler or redundant information, earning full marks for conciseness and structure.
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?
This is a simple delete operation with a clear action and permanent nature, which is adequately described. There is no output schema, but for a delete tool the return format is often trivial; the description is sufficient for the tool's complexity, though it could mention return values or confirmation.
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%, with both siteId and funnelId having basic descriptions. The tool description adds no additional meaning beyond the schema, so it matches the baseline for adequate but unenhanced parameter semantics.
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 'Delete a saved funnel permanently' uses a specific verb (Delete), identifies the resource (saved funnel), and adds the critical qualifier 'permanently', distinguishing it from other funnel-related tools like create/update/analyze. There is no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, but the name and action make it clear that it is for deleting funnels. No exclusions or preconditions are mentioned, so guidance is 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses this is a read operation ('List') and the required auth scope ('org:read'), which is useful. However, it does not mention pagination, error behavior, or return format beyond the content types included, leaving some transparency gaps.
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, front-loaded with the action verb 'List,' and provides the key content scope and auth requirement without any unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description adequately covers what it does and the content returned ('including their members and site assignments'). It lacks details such as potential pagination or error handling, but is largely complete for a straightforward list operation.
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 the parameter 'organizationId' described as 'Organization identifier.' The tool description does not add meaning beyond the schema; it only reinforces the concept of an organization. Baseline 3 is appropriate since the schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List teams in an organization, including their members and site assignments.' This clearly distinguishes it from sibling tools like rybbit_get_organizations (lists orgs) and rybbit_get_organization_members (lists members), as well as team mutation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the resource and content (teams, members, site assignments), but it does not explicitly mention when to use this tool over alternatives or provide exclusions. It also states the org:read scope requirement, which is a prerequisite but not a comparative guideline.
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 present, so the description carries the full burden. It discloses the required users:write scope, which is useful, but it does not explain side effects such as whether existing traits are overwritten, whether the operation is reversible, or what happens if the userId already exists. For a mutation tool, this is a moderate gap.
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 two concise sentences with the primary action front-loaded. Every word adds value, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with complete parameter schema coverage. The description provides the core purpose and scope requirement, which is sufficient for basic invocation. However, the absence of an output schema means the return value or success/failure behavior is unstated, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% description coverage for all four parameters, so the description adds no additional parameter-level meaning. The phrase 'optionally merge profile traits' echoes the existing traits parameter description, offering no new insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Link an anonymous visitor to a known user ID') and identifies the distinct resource and purpose. It also mentions optional trait merging, which helps distinguish it from sibling tools like update_user_traits and the many read-only get_* tools.
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 gives a clear implied usage (identifying anonymous visitors) and mentions the required scope, but it does not explicitly state when to use this tool versus alternatives like update_user_traits or delete_user. No when-not guidance is provided.
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?
With no annotations, the description carries the full burden and discloses key behaviors: events are sent sequentially, the result reports per-event success/failure, and the meaning of siteId and API key scopes. This goes beyond minimal but could add more about partial failures or error handling.
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 three sentences long, with the main purpose front-loaded and additional notes (siteId, API key scope) appended concisely. It earns its place without redundancy, though it could be slightly more succinct.
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 batch tool with nested object schemas and no output schema, the description covers the essential behavior (sequential processing, per-event results) and important context (siteId source, auth scope). It is not exhaustive but sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the 'events' parameter, so the schema already documents all fields. The description adds overall context about batch behavior and that each event matches rybbit_track_event, but does not add per-parameter meaning beyond what the schema provides.
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 it sends a batch of 1-50 tracking events in one call, using a specific verb ('send') and resource ('tracking events'). It explicitly distinguishes itself from the singular sibling 'rybbit_track_event' by describing the batch nature and event count range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for multiple events (batch size 1-50) but does not explicitly state when to prefer this over the singular 'rybbit_track_event' or when not to use it. It provides contextual guidance about siteId and API key scope, but no clear alternative or exclusion guidance.
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 the burden of behavioral disclosure. It adds useful context about required roles/scopes and the meaning of memberId. However, it does not disclose return values, error behavior, or the conditional dependency between hasRestrictedSiteAccess and siteIds, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and no wasted words. Every clause adds value: the action, the memberId clarification, and the required permissions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, prerequisites, and a key ID nuance. However, it misses important contextual details: the logical relationship between hasRestrictedSiteAccess and siteIds (siteIds should be provided when restricting), and what the tool returns or does on success. Without annotations or output schema, this could leave an agent uncertain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameter meanings. The description reinforces the memberId nuance (from rybbit_get_organization_members, not user ID), which is helpful, but does not add material semantics 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 starts with a specific verb and resource: 'Restrict or unrestrict which sites an organization member can access.' It clearly distinguishes the tool from siblings like rybbit_add_organization_member (adding members) and rybbit_update_user_traits (updating user traits) by focusing on site access for existing members.
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?
Provides explicit context by stating 'Requires org admin/owner role and the org:write scope' and clarifying that memberId is the membership record ID from rybbit_get_organization_members, not the user ID. This helps the agent know when to use it and what prerequisites must be met, though it does not explicitly mention alternative tools.
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 carries the full behavioral disclosure burden. It implies a read-only operation and indicates the output includes property pairs and counts. However, it does not describe behavior around date ranges, filters, or how occurrence counts are computed, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that immediately conveys the tool's purpose. No wasted words or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 8 parameters and no output schema, the description provides a reasonable high-level overview of what is returned. The schema covers parameter details. Missing some behavioral specifics like default time range or filter handling, but the core purpose is adequately captured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds little beyond the schema, though it does highlight the 'specific event name' emphasis. Baseline 3 applies because the description does not need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get), the resource (property key-value pairs), and the scope (for a specific event name), and mentions the occurrence counts. This distinguishes it from sibling tools like rybbit_get_events or rybbit_get_event_names, which likely list events/names rather than property details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for retrieving property key-value pairs for a specific event. The sibling tool names suggest alternatives, and the description implicitly indicates when to use this tool. However, it does not explicitly state when not to use it or name alternatives.
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 carries the full burden. It discloses the auth requirement (sites:read scope), which is valuable. It does not detail response format, pagination, or filtering behavior, but for a simple list retrieval, the scope note provides adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action and the resource, with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, and the description covers its purpose and auth requirement. It lacks an output schema, so a note about the returned list format could enhance completeness, but overall it is sufficient for a straightforward read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents siteId with a description, achieving 100% schema coverage. The description's phrase 'for a site' reaffirms the parameter's purpose but adds no new semantic detail beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly specifies the resource ('list of IP addresses excluded from tracking for a site'), distinguishing it from sibling tools like rybbit_get_excluded_countries.
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 states the required scope (sites:read) and clarifies the tool is for a specific site, providing clear context for when to use it. However, it does not explicitly mention alternatives or exclusionary cases, though the tool's name and purpose make those implicit.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It reveals that the operation is admin-gated and requires the sites:write scope, which is critical context for authorization. The verb 'Get' implies read-only, and no contradictions exist.
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 two sentences: the first states the action, the second states requirements. No fluff, well-structured, and front-loaded with the key verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, and the schema covers it fully. However, there is no output schema, so the description should ideally describe what the returned configuration contains; it only mentions 'configuration' generically, leaving a minor gap for an agent expecting return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single required parameter siteId is fully documented in the schema with description 'Site ID or identifier,' achieving 100% coverage. The description adds no additional parameter-level detail beyond connecting the parameter to the site context, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Get the private-link sharing configuration for a site,' a specific verb-resource pair. This clearly distinguishes it from all sibling tools, none of which mention private-link config.
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 implies use when retrieving a site's private-link sharing configuration, which is unique among siblings. It also provides explicit permission requirements (org admin/owner, sites:write scope), helping an agent assess feasibility. However, it does not explicitly state exclusions or alternatives, though none exist.
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 carries the burden. It discloses the required role and OAuth scope, which is critical behavioral context for safe invocation. It also mentions the optional assignment of members and sites. It does not describe return values or side effects, but for a create operation this is acceptable.
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 two concise sentences. The first sentence front-loads the purpose and optional behavior, while the second sentence states the required permissions. Every word earns its place, and there is no redundancy or filler.
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 4-parameter create tool with no annotations and no output schema, the description covers the essential context: purpose, prerequisites, and optional assignments. It does not explain the response format, but the agent can reasonably infer a success indication. It is adequate but not exhaustive, earning a 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all 4 parameters (100% coverage). The description adds only minor clarification by noting that members and sites are optional assignments, which is already implied by the schema's required fields. Thus, the description adds little beyond the schema, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Create a team in an organization.' It clearly distinguishes from sibling tools like get_teams, update_team, and delete_team, and also notes optional member/site assignment, making the tool's purpose unambiguous.
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 clearly states a prerequisite: 'Requires org admin/owner role and the org:write scope,' which tells the agent when the tool can be used. It does not explicitly name alternatives, but the create/update/delete naming convention among siblings makes the context clear.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly notes that deletion is 'permanently' (irreversibility) and states the required admin role and scope, which are critical behavioral constraints. It does not mention potential side effects like cascading deletions, but for a simple delete tool this is adequate.
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 crisp two-sentence structure: one sentence for the action and one for the prerequisites. It wastes no words, front-loads the primary purpose, and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple destructive tool with only two well-documented parameters and no output schema. The description covers the core aspects: what it does, that it is permanent, and the access requirements. It is sufficiently complete for an agent to understand the operation and its prerequisites.
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?
Both parameters (teamId and organizationId) have schema descriptions ('Team identifier' and 'Organization identifier'), giving 100% schema coverage. The tool description adds no additional parameter-level meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Delete a team permanently,' which clearly specifies the action (delete), the resource (team), and an important nuance (permanently). This distinguishes it from sibling tools that delete users, goals, funnels, or sites, and from get/create/update team tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Requires org admin/owner role and the org:write scope,' providing clear prerequisites that help an agent decide whether it can use this tool. However, it does not explicitly mention alternatives or when not to use it, which would push it to a 5.
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?
With no annotations, the description carries the behavioral transparency burden. It reveals that the tool 'fans out to ~7 API requests internally,' which is a significant performance/cost behavior, and mentions 'current live visitor count' indicating real-time data. This goes beyond the schema and annotations, offering useful context about how the tool operates.
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, front-loaded with the core purpose, followed by a list of included data and a behavioral note about internal fan-out. Every sentence earns its place; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description effectively communicates the return contents by listing the metrics and breakdowns. It does not describe error cases or how date ranges interact with the live visitor count, but given the full schema coverage and rich parameter descriptions, the description is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter-specific semantics beyond what the schema already documents (e.g., limit, date ranges, filters). It does not clarify how parameters interact with the digest components, but the schema is fully self-descriptive.
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 a specific verb+resource ('Get a one-call analytics digest') and enumerates the exact components (overview metrics, top pages, referrers, countries, etc.), which distinguishes it from sibling tools like rybbit_get_overview or rybbit_get_live_visitors. The purpose is unambiguous.
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 says 'prefer this over calling each tool separately,' giving clear when-to-use guidance. It implies that if you need a comprehensive aggregate in one call, this is the right choice, while individual sibling tools are for specific slices. However, it doesn't explicitly state when NOT to use it (e.g., when only a single metric is needed), which would make it fully explicit.
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?
With no annotations, the description carries the burden. It explicitly discloses wholesale replacement behavior, a serialized size limit of 2KB, and the required OAuth scope. This is strong transparency for a mutation tool, though it doesn't detail failure modes or return values.
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 filler. The first sentence states the action; the second packs the critical warnings. Perfectly sized.
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 replace operation, the description covers the essential context: operation type, replacement semantics, size limit, and auth. It lacks explicit handling of invalid JSON or user-not-found, but given the availability of sibling tools and the lack of an output schema, this is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents each parameter (100% coverage). The description reinforces that 'traits' is a complete replacement and adds the 2KB serialization limit, which is relevant to the traits parameter. This is a modest addition beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Replace the profile traits of an identified user' – a specific verb and resource that clearly distinguishes it from sibling tools like get_user_info or delete_user. The added warning about wholesale replacement reinforces the precise purpose.
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 states it replaces all traits and warns to include every trait to keep, which implies when this tool is appropriate (full overwrite). It also notes the users:write scope prerequisite. However, it doesn't explicitly name alternative tools for partial updates or merges, so it's not fully explicit about 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the read-only nature via 'Get' and the auth requirement ('Requires the sites:read scope'). It doesn't elaborate on return format or error behavior, but for a simple getter the core traits are covered.
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 two concise sentences, front-loaded with the main action and followed by the scope requirement. Every word earns its place with no unnecessary information.
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 having no output schema or annotations, the description is complete for a simple one-parameter getter. It specifies what the tool returns (list of country codes) and the required scope, which is sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the siteId parameter described as 'Site ID or identifier'. The description adds no additional parameter detail, so the baseline of 3 applies; the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('the list of country codes excluded from tracking for a site'), clearly identifying what the tool returns. It distinguishes from siblings like rybbit_get_excluded_ips by specifically mentioning country codes.
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 clearly implies when to use this tool (when needing excluded country codes for a site) and explicitly states the required scope (sites:read), which is a prerequisite. It does not mention alternatives or exclusions, so it lacks the explicit differentiation seen in top-tier examples.
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 carries the safety/behavior disclosure burden. It discloses key behavior: the tool returns current/previous values, computes absolute and percent changes, and explicitly explains the percentChange null edge case. It does not explicitly mention permissions or read-only nature, but 'Compare... Returns...' strongly implies a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences deliver the core purpose, operation, return values, and an edge case without wasted words. It is front-loaded with the main action and easily scanned.
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 comparative analytics tool with no output schema, the description sufficiently explains the return shape and the period calculation logic. It could name the exact metrics returned, but 'site overview metrics' is adequate context given sibling tool naming and the parameter schema.
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 the baseline is 3, but the description adds meaningful context by clarifying that the provided startDate/endDate define the current period and the preceding period is automatically equal-length. This is not present in the schema and is central to correctly using the tool.
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 uses specific verb 'Compare' and identifies exact resource ('site overview metrics') plus core operation (date range vs equal-length preceding period). This clearly distinguishes it from sibling get-only tools like rybbit_get_overview and rybbit_get_overview_timeseries.
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 makes the intended use case clear: comparing the current period to the immediately preceding equal-length period. It does not explicitly name alternatives or give when-not-to-use guidance, but the use case is strongly implied and distinct from the available siblings.
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?
With no annotations provided, the description carries the full burden and adequately discloses a read-only operation ('Get') and its scope. It does not describe return format or pagination, but for a simple list tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It states the verb and object immediately, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter, the description fully conveys the purpose and scope. It lacks return structure details, but given the simplicity and lack of output schema, this is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100% (empty schema). Baseline 4 applies since there are no parameters to document; the description adds no parameter-specific information because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('organizations') and defines scope ('the authenticated user is a member of'). This distinguishes it from sibling tools like rybbit_get_organization_members, which focus on members within an organization.
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 clearly implies when to use the tool: to retrieve all organizations for the current authenticated user. It does not explicitly mention exclusions or alternatives, but the context is self-evident within the sibling toolset.
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?
With no annotations provided, the description carries the transparency burden. It discloses the key behavioral trait that memberUserIds and siteIds are replaced wholesale, which is essential for safe use. The authorization requirement is also clearly stated. It could mention return value or side effects of partial updates, but the critical behavior is well covered.
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 that front-load the purpose, immediately add a critical warning, and state permissions. Every word earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5-parameter mutation tool with no annotations or output schema, the description covers the essential context: purpose, key side effects, and authorization. It does not describe return values or error behavior, but these are not expected to be in the description for a simple update tool. Overall, the context is sufficient for an agent to select and invoke the tool 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%, so each parameter has a description. The description adds value by emphasizing the wholesale replacement behavior and advising to include full desired lists, which reinforces and clarifies the schema's 'replaces existing' notes. This helps the agent understand the consequences of providing these 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 'Update a team' with a specific verb and resource, distinguishing it from sibling create/delete team tools. The purpose is unambiguous and directly tied to the tool name.
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?
Provides clear guidance on when to use (updating existing teams) and includes critical usage warnings about wholesale list replacement. The note about requiring org admin/owner role and org:write scope gives explicit context for use vs. non-use. Does not explicitly name alternatives, but sibling names make differentiation obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job: it discloses that the operation is DESTRUCTIVE and IRREVERSIBLE, runs asynchronously, and requires specific permissions. No contradictions with annotations (none exist).
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 two sentences, front-loaded with the core purpose, and every sentence adds valuable context (scope, destructiveness, permissions). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, asynchronous operation, the description covers all essential context: what is deleted, irreversibility, async behavior, and required role/scope. No output schema is needed; the description is complete for an agent to safely invoke this 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% for both parameters (siteId and userId). The description reinforces the scope of deletion but adds no additional parameter-level meaning beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Permanently delete a user and all their data' with a specific verb, resource, and scope (events, session replays, profile, aliases), and explicitly labels it as GDPR erasure. This clearly distinguishes it from sibling tools like rybbit_identify_user or rybbit_update_user_traits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage (GDPR erasure, permanent deletion) and prerequisites (org admin/owner role, users:write scope), but it does not explicitly mention when not to use the tool or name alternatives. This is clear context without exclusions, fitting a 4.
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?
With no annotations, the description carries the full transparency burden. It explicitly states 'No API request is made' and lists what it returns (column names, types, usage notes), providing useful insight into the tool's behavior and safety. It does not mention side effects or caveats, but given it's a read-only schema lookup, this is adequate.
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 two sentences, front-loaded with the primary action, and every clause adds value: the resource, the purpose, the return values, and the no-API call. There is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter schema retrieval tool, the description is complete. It states the input (none), the object (scoped_events table), the output (column names, types, usage notes), and the relationship to rybbit_run_query. There is no output schema, but the description sufficiently covers what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds context about the table and purpose, but param-specific semantics are not needed since there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the specific resource ('ClickHouse column schema of the scoped_events table'), and its intended use ('for use with rybbit_run_query'). This distinguishes it from sibling tools which retrieve data rather than schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by mentioning it is meant to be used with rybbit_run_query, implying it should be called before constructing a query. However, it does not explicitly state when not to use it or name alternatives, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It goes above and beyond by detailing server-enforced limits: SELECT/WITH-SELECT only, max 1,000 rows, 10-second cap, 20,000-char length, no semicolons, no quoted identifiers, blocked DDL/DML and remote table functions. It also states the required scope (sql:read) and read-only nature. This is exceptional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, table scope, limits, required scope, prerequisite call, cross-site behavior. It is well-structured, moving from purpose to operational constraints to usage tips, without redundancy. Length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should cover return behavior; it mentions a 1,000-row limit but not the result format. However, given the extensive operational details (limits, restrictions, scope, prerequisite), all other critical context is covered. A brief note on result format would make it a 5, but it's already strong.
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 baseline is 3. The description adds meaningful semantic nuance beyond the schema: omitting siteId queries across all accessible sites, and references to helper tools for organizationId. This justifies a 4, though much of the parameter meaning still comes from 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 opens with a specific verb+resource: 'Run a read-only ClickHouse SQL query against your analytics events.' It names the exact table (scoped_events) and clearly differentiates itself from the many sibling get_* tools by being the generic SQL query interface. This is unambiguous and distinguishes the tool from all alternatives.
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?
Provides explicit usage guidance: 'Call rybbit_get_query_schema first to see available columns' and 'Omit siteId to query across all accessible sites.' It also clarifies scoping to accessible sites. However, it does not explicitly contrast with specific siblings or state when not to use it (e.g., prefer specialized get_* tools for predefined analytics). This is a minor gap, so not a 5.
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-server MCP server](https://glama.ai/mcp/servers/daikazu/rybbit-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/daikazu/rybbit-mcp-server)

Score Badge

Copy to your README.md:

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

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/daikazu/rybbit-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server