aptabase-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct query or resource: app metadata, metrics, time series, top lists, live sessions, and session details. Even similar tools like get_top_countries and get_top_regions differ in granularity and purpose.
Naming Consistency5/5
All tools follow the get_<noun> pattern, with lowercase snake_case and no style mixing. The naming is uniform and predictable, making it easy to infer each tool's purpose.
Tool Count4/5
At 17 tools, the server is slightly above the ideal 3-15 range, but each tool targets a specific analytics need and none feel redundant. The count is justified for the scope of an analytics server.
Completeness5/5
The tool set covers app listing, core metrics, periodic statistics, top dimension breakdowns, event properties, live sessions, and historical session detail. This is a comprehensive analytics surface with no obvious dead ends for the stated domain.
Average 3.1/5 across 17 of 17 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits but does not. It fails to state that this is a read-only operation, clarify what 'currently active' means, or mention any limitations or side effects. The agent is left without crucial safety and behavior context.
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 sentence with no waste, but it is under-specified. Terms like 'recent' and 'live' overlap with 'currently active,' adding mild redundancy. It lacks a clear verb and feels more like a fragment than a complete instruction.
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 relatively simple but has no output schema, so the description should convey what the returned sessions look like. It does not mention return format, fields, or how 'recent' relates to 'live.' The presence of siblings like get_session_details further underscores the need for 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?
Schema description coverage is 100%, with both appId and buildMode having reasonable descriptions. The schema already explains the parameters, and the tool description adds no extra parameter semantics. According to the baseline rule for high schema coverage, a score of 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 "Recent/live sessions currently active for an app" conveys the resource (sessions) and temporal state (live/active), but it is a noun phrase rather than a clear verb+resource construction. It does not explicitly differentiate from siblings like get_historical_sessions or get_session_details.
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. The description doesn't mention that get_historical_sessions should be used for past sessions or that get_live_geo is for geographical data, leaving the agent to infer the appropriate 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, what the return format is, or any side effects. The cryptic '(year, month, events)' also fails to clarify actual 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 a single short sentence, making it concise and front-loaded. However, it is somewhat cryptic and the parenthetical adds ambiguity rather than clarity, so it is not a perfect example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain what is returned and how it fits among siblings. It barely does so, and the lack of differentiation from similar tools makes it incomplete for an 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 100% for both parameters, so the baseline is 3. The description adds no meaningful parameter information and the parenthetical '(year, month, events)' could confuse an agent by suggesting parameters that do not exist.
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 it returns 'monthly event usage counts for billing/quota', giving a specific resource and purpose. However, the parenthetical '(year, month, events)' is ambiguous and does not correspond to actual parameters, and it does not clearly differentiate from sibling tools like get_metrics or get_periodic_stats.
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 any exclusions, preconditions, or recommended use cases beyond the vague 'for billing/quota'. The description does not help an agent choose between this and similar analytics 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 present, so the description must carry behavioral disclosure. It only restates the high-level concept of 'top countries by unique sessions' without explaining return format, sorting, default period behavior, or how filters interact. This is minimal 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single vague sentence. While it is technically concise, it is under-specified for an 11-parameter analytics tool. It lacks a verb, any structural breakdown, or useful details, making it more of an underspecification than a well-structured summary.
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?
With 11 parameters, no output schema, and no annotations, this tool needs a much richer description. The one-line summary does not explain return values, default time periods, filtering semantics, or relationship to sibling tools, leaving the agent with insufficient context 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 coverage is 100%, with all 11 parameters described in the input schema. The baseline for high coverage is 3. The description itself adds no parameter semantics, but it doesn't need to because the schema already provides detailed explanations.
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 the resource (countries), metric (unique sessions), and time context (period). It is clear about what the tool returns, but it lacks a verb and does not differentiate from sibling tools like get_top_regions, so it stops short of a full 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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of the required appId, how country differs from region, or when to prefer this over other top-N tools. The description gives no usage context 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 indicates the metric (unique sessions) and that it returns 'top' items (implying sorting), but it does not disclose return format, limits, pagination, or any side effects. The operation is clearly read-only, but this is not explicitly stated.
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 that efficiently states the core purpose. However, it omits essential context such as filtering options or default behavior, so its brevity comes at the cost of completeness. It is more under-specified than genuinely 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 11 parameters, no output schema, and no annotations, yet the description provides minimal context. It does not mention the flexible period/date parameters, filter parameters, or what the output shape is. For a tool with this complexity, the description is insufficient for an agent to use it correctly without additional exploration.
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 and their meanings. The description adds no parameter-specific meaning beyond what the schema provides. This meets the baseline for 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 states a specific verb and resource: it returns top operating systems by unique sessions. This clearly identifies the tool's core function. However, it does not differentiate from sibling tools like get_top_os_versions, which might be confused with this tool.
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 that get_top_os_versions is for OS-level versions or that get_top_countries is for country-level breakdowns. There are no exclusions or preferred contexts 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?
Annotations are absent, so the description must disclose behavior. It only says 'Historical sessions... with optional filters,' which is a summary rather than behavioral details. No mention of return format, potential data volume, pagination, timezone handling, or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short phrase with no wasted words, achieving a high level of conciseness. However, it is not a complete sentence and reads more like a label, which slightly reduces structure quality.
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 12 parameters and no output schema, the description is insufficient. It does not indicate what fields are returned, whether results are paginated, how filters interact with the time period, or what the output structure looks like. The schema covers parameters but not return semantics.
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 thorough descriptions for all 12 parameters (100% coverage), so the description does not need to add parameter details. The schema already explains period vs. startDate/endDate, filters, and defaults, making the description's omission acceptable.
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 tool as providing historical sessions for an app over a period, with the term 'historical' distinguishing it from live session tools. However, it lacks an explicit verb like 'retrieves' or 'lists,' making it a noun phrase rather than a full action-oriented sentence.
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 get_live_sessions or get_session_details. It only states what it does, not when to prefer it or when to use other 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, the description carries full responsibility for behavioral disclosure. It only says 'live geographic distribution of current users,' but does not explain what 'current' means (e.g., time window), whether special permissions are needed, data latency, or what the response contains. This lack of detail leaves the agent guessing about operational 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 a single, focused sentence with no filler or repetition. It is front-loaded with the key concept. However, it is slightly under-specified for a tool with no output schema, though this is more a completeness issue than a conciseness one.
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?
No output schema or annotations exist, so the description must explain both the operation and the return value. The description only states the general concept, leaving out crucial details like response format, the definition of 'current users,' and how the geographic data is structured. This is inadequate for a tool that returns a dynamic distribution.
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 nothing beyond the schema for parameters; it mentions 'for an app' but the schema already explains appId and buildMode. No additional semantic insight is provided, making the baseline score 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 identifies the resource: live geographic distribution of current users for an app. It distinguishes from siblings like get_top_countries and get_live_sessions by emphasizing 'live' and 'current users,' but lacks an explicit verb like 'retrieve' or 'list,' making it slightly less direct than 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?
No guidance is provided on when to use this tool versus alternatives. The 'live' qualifier implies real-time use, but there are no explicit exclusions or references to sibling tools like get_top_countries for historical data. The description simply states what the tool does without contextual usage 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 the full burden of behavioral disclosure. It only states the output metric and period, but fails to mention side effects (or lack thereof), default behavior, sorting, filtering, or any other operational characteristics. For a stats tool, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundancy or fluff. It is efficient, though it may be too terse given the tool's complexity. Still, it scores well on pure conciseness and structure.
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), lack of output schema, and absent annotations, this description is severely incomplete. It does not explain the output format, default period, or how filters interact with the results. An AI agent would struggle to understand what to expect from 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 input schema has 100% description coverage for all 11 parameters, so the baseline is 3. The tool description adds no parameter-specific information beyond what the schema already provides, which is acceptable but not additive.
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 indicates the resource (app versions) and metric (unique sessions), and the period context. It distinguishes from siblings by focusing on app versions specifically, though it lacks an explicit verb like 'get' or 'list', relying on the tool name to imply retrieval.
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 get_top_os_versions or get_metrics. There is no mention of typical use cases, limitations, or when to prefer this over other stats 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, the description carries the full burden. It discloses that counting is by 'unique sessions' and that a period is used, but omits details like default build mode, sorting behavior, response format, or filtering nuances. This is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that captures the core purpose without waste. However, it is arguably too terse to serve as a standalone guide, though it earns points for brevity and front-loading.
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 11 parameters and no output schema, the description does not explain key context: how OS versions are aggregated, the effect of filters like osName or countryCode, default periods, or whether buildMode is considered. It is minimally complete for a simple listing tool but falls short for this 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%, so baseline 3 applies. The description adds no meaning beyond the schema; it doesn't explain how parameters like osName or appVersion interact with 'OS versions' or provide examples. It remains neutral.
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 tool's output: top OS versions ranked by unique sessions for a given period. It distinguishes from siblings like get_top_os by specifying 'versions' rather than just OS names, but 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 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 get_top_os or get_top_app_versions. The description merely states what it returns without contextual exclusions or prerequisites.
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 states only the output (top regions by unique sessions) but does not describe pagination, sorting direction, timezone handling, data granularity, or potential limitations. It adds minimal value beyond what the name implies.
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 efficiently states the core function. Every word earns its place, and it is front-loaded with the key outcome. It could arguably be more informative, but as far as conciseness goes, it is 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 11 parameters and no output schema, yet the description provides minimal context about expected return format or how filters interact. It does not explain what 'regions' means, how 'unique sessions' are counted, or what the response will look like. Given the complexity, the description is incomplete.
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 11 parameters are already documented in the input schema. The description adds no additional parameter semantics, and this is acceptable given the high schema coverage. 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 identifies the tool's output: top regions ranked by unique session count over a period. The verb is implied ('get'), but the resource (regions) and metric (unique sessions) are explicit. It partially distinguishes from siblings like get_top_countries, though not explicitly, so it lacks full 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?
No guidance is provided for when to use this tool versus alternatives. There is no mention of exclusions or relationships to sibling tools such as get_top_countries. The usage context is only minimally 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden of behavioral disclosure. It only states the basic get operation without revealing error handling, return value format, authentication needs, or any side effects, offering minimal 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, concise sentence with no unnecessary words. It is front-loaded with the verb and resource, making it extremely efficient 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?
Despite the tool's simplicity and complete schema coverage, the description lacks information about expected return values, error conditions, or how it fits among many siblings. This leaves the agent with an incomplete picture 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 schema already documents the only parameter (appId) with a description, achieving 100% coverage. The description's 'by id' is redundant and adds no extra 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 uses a specific verb ('Get'), a resource ('single Aptabase app'), and the lookup method ('by id'), clearly distinguishing it from sibling tools like list_apps (which retrieves multiple apps) and get_metrics (which retrieves metrics).
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 about when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent without direction on whether to select get_app or another sibling tool.
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 burden. It discloses one behavioral trait—previous-period comparison when a date range is set—and lists the core metrics returned. However, it does not mention read-only behavior, return structure, or what happens when neither period nor dates are set, leaving 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 two short sentences, direct and front-loaded with the metric list. Every word earns its place with no fluff or redundancy.
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 11 parameters, no output schema, no annotations, and 16 sibling tools, the description is too sparse. It lists metrics but does not explain output format, how filters interact, or when to prefer this over siblings, making it incomplete for a tool of this 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?
The input schema fully documents all 11 parameters with descriptions, achieving 100% coverage. The description adds no parameter-specific meaning beyond the date-range comparison, 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 clearly states the tool returns key metrics (daily users, sessions, events, avg duration) for an app over a period, using a specific verb and resource. However, it does not explicitly distinguish itself from sibling tools like get_periodic_stats or get_top_events beyond the generic 'key metrics' phrasing.
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 sibling tool names suggest distinctions, but the description neither mentions them nor provides any use-case context 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, but it only states that results are ranked by total event count. It does not disclose the return format, number of top events, default period, or how filters like osName or appVersion affect results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately communicates the core purpose without any 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?
Despite full schema parameter descriptions, the tool has 11 parameters, no output schema, and no annotations. The description omits crucial context such as default behavior, return value shape, and intended use cases, making it incomplete for such a feature-rich 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 input schema provides descriptions for all 11 parameters (100% coverage), so the baseline is 3. The tool description adds no parameter-specific meaning beyond the schema's existing descriptions.
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 that the tool returns top event names sorted by total event count for a given period. This specific resource (event names) sets it apart from sibling get_top_* tools such as get_top_countries, get_top_os, and get_top_devices.
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 explicit guidance on when to use this tool versus alternatives like get_metrics or get_event_props. There are no mentioned prerequisites, exclusions, or related tools, leaving usage only implied by the tool's 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?
No annotations are provided, so the description carries the full burden. It mentions the metric ('unique sessions') and period scope, but does not disclose aggregation behavior, limits on results, timezone handling, or return shape. For a read-only analytics tool, this is minimal but not misleading.
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 extraneous words. It conveys the core purpose efficiently and earns every word.
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 11-parameter schema and no output schema, the description is adequate but sparse. It clearly identifies the output as top device models and the metric as unique sessions, but it does not mention the default period, result count, or how filters interact. The schema covers parameters, so the description is minimally sufficient for a simple report 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?
All 11 parameters have descriptions in the input schema, providing high coverage. The tool description itself adds no parameter-specific semantics beyond 'period' and 'unique sessions', so it does not compensate for any gaps. The schema already handles parameter meaning, making this baseline 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 clearly states the tool's function: returning top device models ranked by unique sessions for a given time period. This distinguishes it from sibling tools like get_top_os or get_top_countries by naming the specific resource (device models).
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 explicit guidance on when to use this tool versus alternatives. It neither names alternative tools nor states conditions for preference, relying entirely on the tool name and implicit meaning.
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 property types and a required parameter but does not disclose the output format, aggregation behavior, pagination, or limitations. For a read tool without annotations, 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 a single, front-loaded sentence with no redundant words. It efficiently conveys the core purpose and a key requirement.
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 11 parameters, no output schema, and no annotations, the description should explain the return structure and how filters apply. It only gives a vague 'breakdown' without detailing what the result looks like or how properties are aggregated.
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%—every parameter has a description in the schema. The tool description adds no extra parameter semantics beyond restating that eventName is required, which the schema already communicates. 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 clearly states the tool's function: 'Breakdown of custom string/numeric properties for a specific event name.' It identifies the resource (event properties) and the specific verb (breakdown), and distinguishes from sibling analytics tools by focusing on per-event 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'for a specific event name' and 'Requires eventName', but it does not explicitly state when to prefer this tool over siblings or provide exclusions. It gives a prerequisite but no alternative 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 of disclosing behavior. It only mentions the metric types and bucketing, but does not explain defaults like the period preset, required appId, return format, or how filters interact. This is minimal for a tool with 11 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is efficient and front-loaded with the core purpose. However, it is somewhat under-specified for a tool with this complexity, though conciseness itself is not an issue. It delivers the key message without waste.
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 params, many filter options, no output schema) and the existence of many sibling tools, this description is too minimal. It does not cover the full scope of what the tool does, the period presets, or the default behavior, leaving significant gaps for an agent to correctly select and invoke it.
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 baseline is 3. The description adds no additional meaning for the parameters; it only mentions output metrics (users, sessions, events), which are not params. Thus it does not enhance or clarify the parameter semantics beyond what the schema already 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?
The description states a specific action (get) and resource (time-series stats for users, sessions, events) with explicit bucketing by hour/day/month for charts. This clearly differentiates it from sibling tools like get_metrics or get_top_events by emphasizing the periodic, chart-oriented nature.
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 when to use this tool: when you need time-series stats bucketed by period for charting. It does not explicitly mention when not to use it or name alternatives, but the context is sufficient to imply its intended use among the many sibling stats 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?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions the content of the response (events, props, device/geo metadata) but does not address read-only semantics, error conditions, or any need for authentication. Since this is a simple lookup, the description provides reasonable but not comprehensive 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, front-loaded sentence that explains the core purpose and key inclusions. No filler words; every element contributes to the tool's definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a straightforward lookup, listing the key return categories. However, it does not mention the required appId or buildMode parameters, which are available in the schema. Given the absence of an output schema, the description's list of data types is helpful but could be expanded slightly to note the need for both appId and sessionId.
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 three parameters with descriptions, so the description adds little beyond what's already specified. The mention of 'session id' aligns with the schema's sessionId field, but no additional meaning is given to appId or buildMode. The schema already documents the enum and default for buildMode.
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 tool's function: it returns session timeline details including events, props, and metadata for a given session ID. It distinguishes this tool from siblings like get_top_events or get_metrics, which focus on aggregated data. However, it lacks an explicit verb, relying on the tool name to convey the 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 implies usage when a session ID is available and timeline data is needed, but it provides no explicit guidance on when to choose this over alternatives or any exclusions. It doesn't mention prerequisites like requiring a valid appId or session ID, which are covered in the schema. No references to sibling tools are made.
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 full burden. It discloses the operational scope (authenticated account), the action (listing), and the return fields (id, name, appKey, ownership). For a zero-parameter read-only list operation, this is adequate, though it does not mention pagination or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource, includes scope and return fields, and contains no redundant or vague 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?
Given zero parameters, no output schema, and a simple read-only listing operation, the description fully covers what the tool does, what it returns, and its account scoping. It is complete for the tool's complexity and context.
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 schema coverage is trivially 100%. The description adds no parameter details because none exist. The baseline for 0 parameters is 4, and the description sufficiently complements the empty 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 ('List') and resource ('Aptabase apps') with a clear scope ('available to the authenticated account') and lists the returned fields (id, name, appKey, ownership). This distinguishes it from sibling tools like get_app (singular) and metrics-focused 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 implies when to use it: whenever you need to enumerate the apps available to the authenticated account. It does not explicitly name alternatives or state exclusions, but the sibling tool names and the plural 'List' make the use case clear.
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:

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

Score Badge

Copy to your README.md:

[![aptabase-mcp MCP server](https://glama.ai/mcp/servers/billylo1/aptabase-mcp/badges/score.svg)](https://glama.ai/mcp/servers/billylo1/aptabase-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/billylo1/aptabase-mcp'

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