hackle-mcp

Official

by hackle-io

Overview Schema Related Servers Score Discussions(1)

JavaScript

Remote

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clear distinct purposes targeting specific resources like experiments, messages, remote configs, and analytics. However, there is some overlap between 'analytics-chart-detail' and 'data-report-detail' which could cause confusion as both fetch detail data for visualizations or reports, though they target different underlying data types.
Naming Consistency5/5
Tool names follow a highly consistent pattern of 'resource-action' format using kebab-case throughout, such as 'experiment-list', 'remote-config-update', and 'active-user-series'. This predictability makes it easy for agents to understand and navigate the toolset.
Tool Count4/5
With 19 tools, the count is slightly high but reasonable for an analytics and A/B testing platform covering multiple domains like experiments, messages, remote configs, and data reports. It might feel a bit heavy, but each tool appears to serve a specific function without obvious redundancy.
Completeness5/5
The toolset provides comprehensive CRUD and lifecycle coverage for its domains, including list and detail operations for experiments, messages, remote configs, and data reports, plus create and update tools for remote configs. The inclusion of time-series tools like 'active-user-series' and 'retention-series' adds analytical depth, leaving no obvious gaps for the server's purpose.
Average 2.8/5 across 19 of 19 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/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. The description only states 'fetch data report list,' which implies a read-only operation but does not specify any behavioral traits such as authentication requirements, rate limits, pagination, error handling, or what the list contains. This leaves critical operational details undefined, making it inadequate for a tool with no annotation support.
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 extremely concise with a single sentence 'fetch data report list.' It is front-loaded and wastes no words, making it efficient in terms of length. However, this conciseness comes at the cost of clarity and completeness, but as per the scoring criteria, it earns full points for being appropriately sized and structured without unnecessary elaboration.
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 lack of annotations and output schema, the description is incomplete for a tool that likely returns a list of data reports. It does not explain the return format, scope, or any behavioral aspects, leaving significant gaps in understanding. While the zero-parameter schema reduces complexity, the description fails to provide sufficient context for effective use, especially compared to more detailed sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description does not add parameter details, which is appropriate since there are no parameters to describe. This aligns with the baseline expectation for zero-parameter tools, where the description need not compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'fetch data report list' is a tautology that essentially restates the tool name 'data-report-list' with minimal additional meaning. It uses a generic verb 'fetch' without specifying what constitutes a 'data report' or the scope of the list. While it indicates a retrieval action, it lacks the specificity needed to distinguish this tool from sibling list tools like 'analytics-chart-list' or 'experiment-list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context for usage, or comparisons to sibling tools such as 'data-report-detail' for individual reports or other list tools. Without such information, an AI agent must infer usage from the name alone, which is insufficient for effective tool selection.
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?
No annotations are provided, so the description carries full burden but offers minimal behavioral insight. It doesn't disclose if this is a read-only operation, requires authentication, has rate limits, or what the output format might be (e.g., JSON structure, error handling). The description is too sparse to inform agent behavior beyond the basic 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 extremely concise with a single sentence, but this brevity borders on under-specification rather than efficiency. It's front-loaded with the core action, yet lacks necessary details, making it somewhat ineffective despite its compact form.
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 (a fetch operation with one parameter), no annotations, no output schema, and 0% schema coverage, the description is incomplete. It doesn't cover what 'detail' includes, error cases, or usage context, leaving significant gaps for an AI agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema, which has 0% description coverage. With one required parameter ('dataReportId'), the description doesn't explain what this ID is, how to obtain it (e.g., from 'data-report-list'), or its format (e.g., numeric ID as indicated by schema). This fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'fetch data report detail' states a verb ('fetch') and resource ('data report detail'), but is vague about what 'detail' entails compared to siblings like 'data-report-list'. It doesn't specify if this returns metadata, content, or analytics, leaving the purpose ambiguous despite naming the target resource.
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. With siblings like 'data-report-list' and various analytics tools, the description lacks context on prerequisites (e.g., needing a report ID from 'data-report-list') or distinctions (e.g., this fetches a single report vs. listing multiple).
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. 'fetch' implies a read operation, but the description doesn't mention authentication needs, rate limits, pagination behavior (despite pageNumber/pageSize parameters), or what the return format looks like. For a list tool with pagination parameters, this lack of behavioral 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource. However, its brevity contributes to underspecification rather than optimal clarity, as it omits necessary details for a tool with multiple parameters and sibling tools.
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 (4 parameters with 0% schema coverage, no output schema, and no annotations), the description is incomplete. It doesn't address parameter meanings, return values, behavioral constraints, or differentiation from siblings. For a list tool with filtering and pagination capabilities, this minimal description leaves too many gaps for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'chartType' enums represent, how 'searchKeyword' filters results, or the purpose of pagination parameters. With 4 parameters entirely undocumented in both schema and description, the agent lacks essential semantic context for effective tool invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'fetch data analytics chart list' states the verb ('fetch') and resource ('data analytics chart list'), making the purpose clear at a basic level. However, it doesn't distinguish this tool from similar siblings like 'analytics-chart-detail' or 'data-report-list', leaving ambiguity about scope. The description is functional but lacks specificity about what kind of chart list this retrieves.
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. With siblings like 'analytics-chart-detail' (likely for single charts) and 'data-report-list' (potentially overlapping functionality), there's no indication of context, prerequisites, or exclusions. The agent must infer usage from the name alone, which is insufficient for reliable 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?
No annotations are provided, so the description carries full burden. It mentions fetching details and visualization, but doesn't disclose critical behaviors: whether this is a read-only operation, potential errors (e.g., from mismatched chartType), rate limits, authentication needs, or what the result format looks like. The visualization hint is useful but insufficient for a tool with no annotation coverage.
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 concise with two sentences that are front-loaded: the first states the core action, and the second adds a usage hint. There's no unnecessary repetition or fluff, though it could be more informative. It earns its place but leaves gaps in completeness.
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, no output schema, and a tool that fetches details (likely involving data retrieval), the description is incomplete. It doesn't explain the return value format, error conditions, or how the visualization hint translates to practical use. For a 2-parameter tool with siblings, more context is needed to guide the agent 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?
Schema description coverage is 100%, so the schema already documents both parameters (chartId and chartType) with descriptions and enum values. The description adds no additional meaning beyond what's in the schema, such as explaining how chartId is obtained or the implications of chartType matching. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'fetch analytics chart detail' which provides a basic verb+resource combination, but it's vague about what 'detail' includes (e.g., configuration, data, metadata). It doesn't clearly distinguish from siblings like 'analytics-chart-list' (which presumably lists charts) or 'data-report-detail' (which might have overlapping functionality). The second sentence about visualization adds some context but doesn't clarify the core purpose.
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 explicit guidance on when to use this tool versus alternatives is provided. The description mentions visualization, which might imply use for rendering charts, but it doesn't specify prerequisites (e.g., needing a valid chartId) or exclusions (e.g., not for creating charts). Without comparison to siblings like 'analytics-chart-list' or 'data-report-detail', the agent lacks clear direction.
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 burden but only states the basic action. It doesn't disclose behavioral traits like whether this is a read-only operation, pagination behavior (implied by parameters but not explained), rate limits, authentication needs, or what happens on errors. 'Fetch' implies reading, but no safety or performance context is given.
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 extremely concise with a single sentence 'Fetch Remote Config list.', which is front-loaded and wastes no words. Every part earns its place by stating 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?
Given 4 parameters with 0% schema coverage, no annotations, no output schema, and sibling tools like 'remote-config-detail', the description is incomplete. It doesn't explain the tool's behavior, parameter usage, or output, leaving significant gaps for an AI agent to understand how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'pageNumber', 'pageSize', 'searchKeyword', or 'status' do, their formats, or how they affect the fetch. The description fails to provide meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch Remote Config list' clearly states the action (fetch) and resource (Remote Config list), but it's vague about scope and doesn't distinguish from siblings like 'remote-config-detail' or 'remote-config-create'. It lacks specificity about what kind of list this returns.
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 like 'remote-config-detail' for specific configs or 'remote-config-create' for creation. The description doesn't mention prerequisites, context, or exclusions for usage.
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 full burden. It states 'Updates', implying a mutation, but doesn't disclose behavioral traits such as permissions required, whether changes are reversible, rate limits, or what the response looks like. This is inadequate for a mutation tool with complex parameters.
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 sentence with zero waste, making it appropriately sized and front-loaded. However, it's overly concise to the point of under-specification, slightly reducing effectiveness.
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 (2 parameters with nested objects), no annotations, and no output schema, the description is incomplete. It fails to provide necessary context for safe and effective use, such as error handling or return values, making it insufficient for this tool's requirements.
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 50%, with detailed descriptions for nested parameters but not for top-level ones. The description adds no meaning beyond the schema, as it doesn't explain parameters like 'remoteConfigId' or 'body'. However, the schema provides some context, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Updates remote config's content' states the action (updates) and resource (remote config's content), but it's vague about what 'content' specifically means. It doesn't distinguish this tool from sibling tools like 'remote-config-update-description' or 'remote-config-update-user-identifier-criteria', leaving ambiguity about scope.
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. With siblings like 'remote-config-create' and 'remote-config-update-description', the description lacks any indication of prerequisites, context, or exclusions for usage.
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 mentions that 'the total number of RC is limited,' which is useful context about resource constraints, but doesn't describe what 'creates' entails (e.g., permissions needed, whether it's idempotent, response format, or error conditions). This leaves significant gaps 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 two sentences and reasonably concise, but the second sentence about updating existing RCs feels somewhat tangential to the core purpose. It could be more front-loaded with essential information, though it avoids excessive verbosity.
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 creation tool with no annotations, no output schema, and poor parameter documentation (0% schema coverage with no description compensation), the description is incomplete. It mentions a limitation but lacks details on behavior, parameters, or expected outcomes, making it inadequate for informed tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about parameters, while the input schema has 0% description coverage (only enum values for dataType are described). With 1 required parameter (body) containing nested properties, the description fails to add any meaning beyond what the bare schema provides, resulting in poor parameter documentation.
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 action ('creates an empty remote config') and identifies the resource ('remote config'), which provides a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'remote-config-update' beyond mentioning an alternative action.
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 provides some usage guidance by recommending to 'update an existing RC first if there is an associated RC' due to total number limitations, which implies context for when to consider alternatives. However, it doesn't explicitly state when to use this tool versus other remote-config tools or provide clear 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 of behavioral disclosure. It states 'Fetch' which implies a read-only operation, but doesn't clarify permissions, rate limits, error handling, or what 'detail' includes (e.g., full configuration, metadata). This leaves significant gaps for a tool that likely returns structured data.
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 extremely concise at three words, front-loaded with the core action ('Fetch'), and wastes no space. Every word earns its place, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a detail-fetching tool with no output schema and no annotations), the description is incomplete. It doesn't explain what 'detail' entails, potential response formats, or error cases, which are crucial for an agent to use the tool effectively in context with siblings like list and update tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'remoteConfigId' well-documented in the schema (including type, constraints, and a note to get it from 'remote-config-list'). The description adds no additional parameter information beyond the schema, so it meets the baseline for high coverage without compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch remote config detail' clearly states the action (fetch) and resource (remote config detail), but it's vague about what 'detail' encompasses compared to siblings like 'remote-config-list' or 'remote-config-update'. It distinguishes the basic operation but lacks specificity about the scope of information returned.
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 explicit guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a remoteConfigId from 'remote-config-list'), exclusions, or contextual cues, leaving the agent to infer usage from the parameter description 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 carries the full burden. It states this is a retrieval operation, implying read-only behavior, but does not disclose other traits like error handling, authentication needs, rate limits, or response format. This leaves significant gaps for a tool with no annotation coverage.
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 directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand 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?
Given the lack of annotations and output schema, the description is incomplete. It does not cover behavioral aspects, parameter details, or return values, leaving the agent with insufficient information to use the tool effectively beyond its basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'specific push message' but does not explain the 'pushMessageId' parameter's meaning, format, or how to obtain it. This adds minimal value beyond the schema's structural definition.
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 ('Retrieves') and resource ('detailed information for a specific push message'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'push-message-list', which likely lists multiple messages rather than retrieving details for one.
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 prerequisites, such as needing a specific pushMessageId, or compare it to siblings like 'push-message-list' for broader queries.
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 states the tool retrieves information (implying a read-only operation) but doesn't cover critical aspects like authentication requirements, rate limits, error handling, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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, clear sentence with zero waste. It's front-loaded with the core purpose and efficiently conveys the essential information without unnecessary elaboration, 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?
Given the tool's complexity (a read operation with one parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral traits, response details, or usage context, leaving the agent with insufficient information to invoke the tool effectively beyond its basic purpose.
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 0%, but the description adds minimal semantic context by implying the parameter is an 'experimentId' for a 'specific A/B test experiment'. However, it doesn't explain the parameter's format (e.g., numeric ID), constraints, or examples. With one parameter and low schema coverage, the description provides some value but doesn't fully compensate for the lack of schema details.
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 ('retrieves') and resource ('detailed information for a specific A/B test experiment'), making the purpose unambiguous. It distinguishes from sibling tools like 'experiment-list' by specifying retrieval of details for a single experiment rather than listing multiple. However, it doesn't explicitly contrast with other detail tools (e.g., 'analytics-chart-detail'), so it's not a perfect 5.
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 doesn't mention prerequisites (e.g., needing an experiment ID), exclusions, or comparisons to sibling tools like 'experiment-list' for listing experiments or other detail tools. Usage is implied by the name and purpose but not explicitly stated.
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 mentions pagination and search functionality, which is helpful, but fails to address critical aspects like authentication needs, rate limits, error handling, or the format of returned data. This leaves significant gaps for an agent to understand how to interact with the tool effectively.
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 front-loads key information (fetches, paginated list, search) without any wasted words. It's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no output schema, no annotations), the description is incomplete. It lacks details on return values, error cases, and full parameter documentation, making it insufficient for an agent to use the tool confidently without additional 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 low at 33%, with only 'searchKeyword' documented. The description adds value by implying pagination and search, but it doesn't detail parameter semantics beyond what's in the schema, such as default behaviors or constraints. This meets the baseline for partial coverage but doesn't fully compensate for the gaps.
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 action ('fetches'), resource ('paginated list of A/B test experiments'), and functionality ('with search functionality'), making the purpose evident. However, it doesn't explicitly distinguish this tool from sibling tools like 'experiment-detail' or other list tools, which prevents a perfect score.
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 'experiment-detail' for single experiments or other list tools for different resources. It lacks context on prerequisites or exclusions, leaving usage unclear.
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 states this is a retrieval operation, implying it's read-only and non-destructive, but doesn't cover aspects like authentication requirements, rate limits, error conditions, or the format/scope of the returned details. This leaves significant gaps for a tool that presumably fetches sensitive message data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action ('retrieves detailed information'), making it easy to scan and understand 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?
Given the complexity of retrieving message details (likely involving permissions or data structures), no annotations, and no output schema, the description is insufficient. It doesn't explain what 'detailed information' includes, potential side effects, or error handling, leaving the agent under-informed for safe and effective 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?
The description implies the tool requires an 'inAppMessageId' to identify a specific message, which aligns with the single required parameter in the schema. However, with 0% schema description coverage, the description doesn't add meaningful details beyond this basic inference—it doesn't explain what an inAppMessageId is, its format, or where to obtain it. The baseline is 3 due to the single parameter being straightforward.
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 ('retrieves') and resource ('detailed information for a specific in-app message'), making the purpose unambiguous. However, it doesn't explicitly differentiate from its sibling 'in-app-message-list', which likely lists multiple messages rather than retrieving details for a specific one.
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 doesn't mention prerequisites (e.g., needing an inAppMessageId), exclusions, or comparisons to siblings like 'in-app-message-list' for listing messages or other *-detail tools for different resources.
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 full burden. It mentions pagination and search, which are helpful behavioral traits, but lacks critical details like authentication requirements, rate limits, error handling, or what the response format looks like. For a list tool with no annotations, this leaves significant 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, efficient sentence that front-loads key information ('fetches a paginated list of in-app messages with search functionality'). Every word earns its place, with no redundancy or unnecessary elaboration.
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, no output schema, and low schema description coverage (33%), the description is incomplete. It covers basic purpose but lacks details on behavior, response format, error cases, or usage context, which are essential for a tool with 3 parameters and search functionality.
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 33% (only 'searchKeyword' has a description). The description adds value by implying pagination ('paginated list') and search functionality, which aligns with the parameters, but doesn't explain semantics beyond what's minimally inferred. With low schema coverage, it partially compensates but not fully, warranting a baseline score.
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 ('fetches') and resource ('paginated list of in-app messages'), and specifies 'with search functionality' which adds useful detail. However, it doesn't explicitly differentiate from sibling tools like 'in-app-message-detail' or 'push-message-list', which would require a 5.
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. There are multiple sibling list tools (e.g., 'analytics-chart-list', 'data-report-list', 'push-message-list') and detail tools, but no indication of context, prerequisites, or exclusions for this specific 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 carries the full burden. It mentions pagination and search, but lacks details on permissions, rate limits, error handling, or response format. For a read operation with no annotation coverage, this is insufficient to inform safe and effective use.
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 front-loads the core purpose. Every word earns its place, with no redundancy or unnecessary elaboration, making it 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?
Given the tool's complexity (3 parameters, no output schema, no annotations), the description is incomplete. It doesn't cover behavioral aspects like pagination mechanics, search limitations, or return values, leaving gaps that could hinder correct 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?
Schema description coverage is low (33%), with only 'searchKeyword' documented. The description adds value by clarifying that search applies to 'name, description, or campaignKey', but doesn't explain 'pageNumber' or 'pageSize' beyond defaults. It partially compensates for the coverage gap but leaves key parameters under-specified.
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 action ('fetches') and resource ('paginated list of push messages'), and specifies the functionality ('with search functionality'). It distinguishes from siblings like 'push-message-detail' by indicating it's a list operation, though it doesn't explicitly contrast with other list tools (e.g., 'in-app-message-list').
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 doesn't mention when to choose it over 'push-message-detail' for individual messages or other list tools, nor does it specify prerequisites or exclusions. Usage is implied only 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.
Behavior2/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 mentions the change applies to 'both production and development environment', which adds some context about scope, but lacks details on permissions, side effects, error handling, or response format. For a mutation tool with zero annotation coverage, this is insufficient.
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 front-loaded and concise with two sentences that directly state the action and scope. There's no wasted text, making it efficient and easy to parse.
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 (mutation with 2 parameters, no output schema, and no annotations), the description is incomplete. It lacks details on behavioral traits, parameter usage, and output expectations, making it inadequate for safe and effective tool 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 50% (only 'remoteConfigId' has a description), and the description doesn't add meaning beyond the schema. It implies parameters for updating a description but doesn't explain 'body' or 'description' fields. With low coverage, the description fails to compensate, resulting in a baseline score.
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 action ('Updates') and resource ('remote config's description'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'remote-config-update' or 'remote-config-update-user-identifier-criteria', which would require more specificity about what exactly this tool updates versus those.
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 doesn't mention prerequisites, compare with siblings like 'remote-config-update' or 'remote-config-create', or specify scenarios where this tool is appropriate, leaving usage unclear.
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 full burden. It discloses that the update applies to both production and development environments, which is useful behavioral context. However, it lacks critical details like permission requirements, whether the change is reversible, rate limits, or error handling 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, efficient sentence that directly states the action and scope. It's appropriately sized without unnecessary elaboration, though it could be slightly more structured by separating purpose from behavioral 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?
For a mutation tool with no annotations, no output schema, and incomplete parameter documentation (50% coverage), the description is insufficient. It lacks details on return values, error conditions, side effects, and doesn't fully compensate for the missing structured information, leaving significant gaps for an AI agent.
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 50% (one of two parameters has a description). The description adds no additional parameter semantics beyond what's in the schema. It doesn't explain the structure of 'body' or provide examples for 'userIdentifierCriteria', leaving gaps in understanding the two required parameters.
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 ('Updates') and resource ('remote config's user identifier criteria'), making the purpose understandable. It distinguishes from siblings like 'remote-config-update' by specifying the exact aspect being updated, though it doesn't explicitly contrast with 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 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 like 'remote-config-update' or 'remote-config-update-description'. The description mentions the change applies to both environments but doesn't specify prerequisites, constraints, or appropriate contexts for usage.
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 states the tool 'retrieves' data, implying a read-only operation, but doesn't address critical aspects like authentication requirements, rate limits, data freshness, or response format. For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 appropriately concise with two sentences that directly state the tool's purpose and parameter options. It's front-loaded with the core functionality. There's no wasted language, though it could be slightly more structured by explicitly listing parameters.
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 (retrieving analytics data), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral traits, response format, error handling, or usage context relative to siblings. For a tool with two parameters and significant operational implications, this minimal description fails to provide adequate context 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 description coverage is 50% (one of two parameters has a description). The description adds value by explaining the 'unit' parameter options ('daily, weekly, and monthly units'), which aligns with the enum in the schema. However, it doesn't clarify the 'date' parameter beyond what the schema provides ('End date in YYYY-MM-DD format'), nor does it explain the interaction between parameters (e.g., if 'date' is optional, what default is used). The baseline is 3 due to moderate schema coverage and some added meaning.
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: 'Retrieves time-series data of user retention.' It specifies the verb ('retrieves'), resource ('time-series data of user retention'), and available granularities ('daily, weekly, and monthly units'). However, it doesn't explicitly differentiate from sibling tools like 'active-user-series' or 'stickiness-series' that might also retrieve time-series data, which prevents a perfect score.
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 mentions available units but doesn't specify use cases, prerequisites, or exclusions. With sibling tools like 'analytics-chart-list' and 'data-report-list' that might offer similar data, the lack of comparative context 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.
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 states the tool retrieves data, implying a read-only operation, but doesn't disclose behavioral traits such as authentication requirements, rate limits, data format, pagination, or error handling. For a data retrieval tool with no annotation coverage, this is a significant gap 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 front-loaded and concise with two sentences that efficiently convey the tool's purpose and key parameter information. Every sentence earns its place by stating what the tool does and the available units, with no redundant or unnecessary 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?
Given the complexity of a time-series data tool with no annotations, no output schema, and incomplete parameter documentation (50% coverage), the description is insufficient. It lacks details on return values, data structure, error conditions, and usage context, making it incomplete for effective agent 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 description coverage is 50% (one parameter described, one not). The description adds value by explaining that the data is available in weekly and monthly units, which clarifies the 'unit' parameter's enum values. However, it doesn't address the 'date' parameter's semantics or provide additional context beyond what the schema partially covers, resulting in a baseline score.
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 retrieves time-series data of user stickiness (return visit frequency) with available weekly and monthly units. It specifies the verb 'retrieves' and resource 'time-series data of user stickiness', distinguishing it from siblings like active-user-series or retention-series by focusing on return visit frequency rather than active users or retention metrics. However, it doesn't explicitly contrast with all siblings, keeping it at 4 instead of 5.
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 mentions available units but doesn't specify use cases, prerequisites, or comparisons with sibling tools like retention-series or analytics-chart-detail. This leaves the agent without contextual direction for tool 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool retrieves data (read operation) but doesn't mention permissions, rate limits, pagination, or response format. For a data retrieval tool with no annotation coverage, this leaves significant behavioral gaps. The description adds minimal value beyond the basic 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 extremely concise with two sentences that directly state the tool's purpose and available units. Every word earns its place with zero waste. It's front-loaded with the core functionality. This is an excellent example of efficient communication.
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 a 2-parameter tool with no annotations and no output schema, the description provides basic purpose and parameter context but lacks details about response format, data structure, error conditions, or behavioral constraints. For a data retrieval tool, this leaves the agent with incomplete information about what to expect from the 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 description coverage is 50% (only 'date' parameter has description). The description mentions 'daily, weekly, and monthly units' which maps to the 'unit' parameter's enum values, adding some semantic context beyond the schema. However, it doesn't explain the 'date' parameter's purpose or format beyond what's in the schema. With partial schema coverage, the description provides moderate compensation.
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: 'Retrieves time-series data of active users' with specific resource (active users data) and verb (retrieves). It distinguishes from some siblings like 'retention-series' and 'stickiness-series' by specifying the metric type, but doesn't explicitly differentiate from all analytics tools. The purpose is clear but sibling differentiation could be more explicit.
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 provides some usage context by mentioning 'Available in daily, weekly, and monthly units,' which implies when to use different parameter values. However, it doesn't explicitly state when to choose this tool versus alternatives like 'retention-series' or 'stickiness-series,' nor does it mention prerequisites or exclusions. Usage is implied rather than explicitly guided.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hackle-io/hackle-mcp'

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