Aptabase MCP Server

Official

by aptabase

Overview Schema Related Servers Score Discussions

TypeScript

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 are clearly distinct, with specific query purposes like top countries vs top OS. However, some overlap exists between get_metrics and get_periodic_stats, and the many get_top_* variants could be confused without reading descriptions closely. Overall, descriptions help distinguish them.
Naming Consistency4/5
The vast majority follow a consistent get_<resource> pattern. The main deviation is list_apps instead of get_apps, which breaks the pattern slightly. All other tools use get_ consistently, making the naming predictable and readable.
Tool Count3/5
With 17 tools, the server sits in the heavy range (16-25). While each tool serves a distinct analytical purpose, the sheer number of top_* getters (12 variants) makes the surface feel somewhat bloated. A few could be combined into parameterized queries, but the count is not unreasonable for an analytics domain.
Completeness4/5
The tool surface covers a broad range of analytics needs: app management, live and historical sessions, metrics, time-series, geographic breakdowns, device/OS details, event properties, and usage counts. Minor gaps exist (e.g., no funnel or retention analysis), but for a read-only analytics MCP, it is quite comprehensive.
Average 3.3/5 across 17 of 17 tools scored.
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. It only restates the basic function without disclosing default period behavior, result limits, sorting order, or interaction with filters. This is insufficient for an agent to predict side effects or output characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It conveys the essential purpose in a compact form, though it does not include additional context.
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, the description is far too minimal. It omits return format, default period, the meaning of 'unique sessions', and how filters affect results, making the tool under-documented 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%, so the schema fully documents all 11 parameters. The description adds no parameter-level meaning beyond what the schema provides, hence the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource ('regions') and metric ('unique sessions') with a time scope ('for the period'). It distinguishes from sibling tools like get_top_countries by focusing on regions rather than countries.
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 on when to use this tool versus alternatives such as get_top_countries or get_top_devices. It does not mention any exclusions, prerequisites, or common scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, but it only mentions the eventName requirement. It does not disclose filtering behavior, time-period handling, aggregation details, or return format, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no fluff, front-loading 'Breakdown of custom string/numeric properties' and stating the required parameter. It is concise and structured, though slightly under-specified.
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 tool with 11 parameters and no output schema or annotations, the description is too sparse. It fails to explain how the numerous optional filters interact, the role of the 'period' parameter, or what the breakdown output looks like, making it incomplete for 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?
Schema description coverage is 100%, so the schema already documents all 11 parameters. The description adds no extra parameter semantics beyond the schema, but it does not need to given the high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: breaking down custom string/numeric properties for a specific event name. It distinguishes from sibling tools like get_top_events and get_event_props requires an eventName, which is specified.
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 on when to use this tool vs alternatives. The only usage hint is 'Requires eventName,' which is a prerequisite, not a usage context. Sibling tools are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose return structure, default period behavior, pagination, or any side effects. The phrase 'with optional filters' hints at customization but adds no concrete behavioral detail.
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 redundant words. It is front-loaded and easy to parse, though it is brief to the point of under-specification.
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 12 parameters, multiple enum-based period presets, and no output schema, the description is far from complete. It omits critical context like what the returned sessions look like, how filters combine, or the default period behavior, which is particularly informative in the schema.
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 each parameter already has a description. The tool description only mentions 'optional filters' without adding meaning to specific parameters, thus it does not go beyond the baseline.
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 it provides 'Historical sessions for an app over a period,' which clearly indicates it retrieves past session data. It differentiates from siblings like get_live_sessions by the 'Historical' qualifier, though it lacks an explicit verb like 'get' or 'retrieve'.
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 such as get_session_details or get_live_sessions. The description simply states what it does without any contextual cues 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. It adds that the data is 'live' and for 'current users', but does not disclose return format, aggregation level, pagination, or whether the operation is read-only. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It is optimally short and front-loaded.
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 output schema and annotations, the description is too sparse. It does not define what 'geographic distribution' entails (countries, regions, coordinates) or how it contrasts with sibling geo tools. A more complete description is needed.
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 descriptions for appId and buildMode. The tool description itself adds no parameter context, but the schema already documents the parameters sufficiently, 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 identifies the tool's purpose: showing the live geographic distribution of current users for an app. It specifies the resource and temporal scope (live/current), but lacks an explicit verb and does not differentiate it from sibling tools like get_top_countries or get_top_regions.
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 usage guidance is provided. The description does not explain when to prefer this tool over alternatives or mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only mentions 'unique sessions' as the metric, but omits important traits such as whether the results are sorted, how many countries are returned, date range handling, timezone sensitivity, or that it is a read-only operation. 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, front-loaded sentence with no wasted words. It effectively communicates the core purpose, though it is minimal. The brevity is commendable, but it sacrifices essential context that would make it more robust.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no output schema, no annotations), the description is far too sparse. It lacks information about return format, default period behavior, country grouping logic, and how it relates to sibling geographic tools. This leaves significant gaps for an agent attempting correct invocation and result interpretation.
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 parameters are fully documented in the schema. The description adds no parameter-specific meaning beyond what the schema already provides, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns top countries by unique sessions for a specified period. It specifies the resource (countries), measure (unique sessions), and time scope (period). However, it does not distinguish from sibling tools like get_top_regions, which could confuse users about geographic granularity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No exclusions or sibling comparisons are provided, leaving the agent without direction on selecting this tool over get_top_regions or 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'currently active' but does not clarify what constitutes 'active,' whether the data is real-time or cached, how recent the 'recent' window is, or whether any side effects or state changes occur. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but it is somewhat redundant ('Recent/live' and 'currently active' overlap). It lacks a verb and reads more as a fragment than a clear functional statement. While it is front-loaded, it could be tightened and made more informative without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and only a minimal description, the tool's expected return value and behavior are under-specified. The agent does not know what fields the response contains, whether pagination applies, or how this tool compares to similar siblings like get_session_details or get_live_geo. Given the simple parameter set but lack of contextual info, the description is not complete enough.
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 both parameters (appId and buildMode), achieving 100% coverage. The description does not add any additional meaning beyond what the schema already states, such as the buildMode behavior of querying appId_DEBUG. Per the rubric, baseline 3 is appropriate when the schema covers all 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 'Recent/live sessions currently active for an app' clearly indicates the tool retrieves current live sessions for a specific app, which is a specific verb+resource. It distinguishes from historical sessions by emphasizing 'currently active,' but it does not explicitly name sibling alternatives 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for current/live sessions rather than historical ones, but it provides no explicit when-to-use or when-not-to-use guidance. There are no exclusions or alternatives mentioned, leaving the agent to infer based on the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates the tool returns usage counts but offers no details on read-only behavior, response format, aggregation logic, or any constraints. This leaves the agent without important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and free of filler. It is a single fragment, but every word contributes meaning, and the key point about billing/quota usage is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clearly explain what the tool returns. It mentions 'year, month, events' but does not specify the structure, grouping, or whether 'events' refers to counts, names, or a breakdown. This is insufficient for an agent to fully understand the result shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters (appId and buildMode), so the baseline is 3. The description adds nothing about the parameters themselves; the parenthetical '(year, month, events)' appears to describe output fields, not parameter semantics.
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 monthly event usage counts for billing/quota purposes. The resource and scope are clear, though it lacks an explicit verb and does not distinguish itself 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for billing/quota' implies the intended use case, giving some context on when to use the tool. However, it does not mention alternatives or explicitly state when not to use it, so usage guidance is only implied.
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 adds the 'unique sessions' metric and period scope but does not mention sorting, limits, default period, return format, or any operational caveats. Minimal context 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 with no redundancy; every word contributes to the core meaning. However, it is a fragment rather than a full sentence and is under-specified, which slightly reduces the structural 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?
This is a complex analytics tool with 11 parameters, no output schema, and no annotations. The one-sentence description does not explain the return shape, default period behavior, filtering defaults, or how it relates to sibling tools. Inadequate for an agent to fully understand the tool's usage 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 descriptions cover 100% of the 11 parameters, so the baseline of 3 applies. The description itself adds no extra parameter semantics, but the schema fully documents each parameter's purpose and constraints, so no significant gap exists.
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 specifies the resource (top OS versions), the metric (unique sessions), and the time scope (period). It implicitly distinguishes from sibling tools like get_top_os (which likely groups by OS name) and get_top_app_versions (which focuses on app versions).
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 offers no guidance on when to use this tool versus get_top_os or other top_* tools. It lacks any explicit context, alternatives, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the output concept. It does not explain output structure, default period handling, or that this is a read-only query, leaving the agent without key behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence without redundancy, making it concise. However, its brevity contributes to under-specification, omitting important details about output and behavior, so it is not maximally effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters, no annotations, and no output schema, the description is incomplete. It does not explain the return format (e.g., a list of app versions with session counts) or any behavioral defaults beyond what the schema already documents.
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 11 parameters, covering defaults and filter semantics. The description adds no parameter-specific meaning, so it meets the baseline for full schema coverage.
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: retrieving top app versions ranked by unique sessions for a given period. It distinguishes from sibling tools like get_top_os_versions by specifying 'app versions' and from get_top_events by the metric 'unique sessions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the agent needs top app versions, but it does not explicitly mention when to prefer this over sibling tools such as get_top_os_versions or get_metrics. No exclusions or alternative tool suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It mentions 'unique sessions' but does not explain whether sessions are de-duplicated per user, how ties are broken, whether 'Unknown' OS values are included, or how period boundaries are handled. These are significant gaps for a stats tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose. It is concise, front-loaded, and contains no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters and no output schema, the description is brief but conveys the core purpose. However, it does not clarify what 'top' means (e.g., sort order), how the period interacts with filters, or whether the result is a list of OS names with counts. For an agent to invoke correctly, it would need to infer these from the schema and sibling 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%, so the baseline is 3. The description adds no additional meaning beyond the schema, as it simply references 'period' without explaining its default or interaction with startDate/endDate. The schema already documents all parameters, so the description neither enhances nor detracts.
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 returns top operating systems by unique sessions for the period, specifying both the resource (operating systems) and the metric (unique sessions). It distinguishes itself from the sibling get_top_os_versions by focusing on OS names rather than versions.
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 does not mention when to prefer this over get_top_os_versions or how period/filters affect its usage. The only implied context is that it is for top OS statistics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of disclosing behavior. It states that the result is top device models by unique sessions, but does not mention ordering, default limits, pagination, side effects, authentication needs, or that this is a read-only operation. The agent is left without safety or operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly states the tool's purpose without superfluous words. It earns its place and is easy to parse at a glance.
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 a complex 11-parameter schema and no output schema, the description provides minimal context. It does not describe the return format (e.g., list of objects, count of top items), default sorting, how filters interact, or what happens when no data matches. The lack of annotations further increases the need for a richer description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds the key semantic that 'top' is measured by unique sessions, which is not present in any parameter description. This clarifies the meaning of the result and helps interpret filters like granularity and period.
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 identifies the output as top device models by unique sessions, which is a specific query/resource. It distinguishes from sibling tools like get_top_os and get_top_countries by naming the device model dimension.
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. It does not mention exclusions, prerequisites, or compare with sibling tools. The phrase 'for the period' is a vague temporal hint but not actionable 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, the description carries full responsibility for behavioral disclosure. It does not mention sorting direction, whether the result is limited (e.g., top N), how aggregation works, or whether empty/missing event names are included. This leaves significant ambiguity about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words. It directly states the tool's purpose, making it appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters, no output schema, and many sibling tools, the description is too sparse. It does not explain the output format, the meaning of 'period' in context, or how this tool differs from other stats tools. This leaves 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?
Input schema coverage is 100%, so all 11 parameters are already described in the schema. The tool description adds no additional parameter meaning or usage hints beyond what the schema provides, landing at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'Top event names by total event count for the period.' This is a specific resource (event names) and operation (ranking by count), which distinguishes it from sibling tools like get_top_os or get_top_countries.
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 the user needs top event names by count, but it does not explicitly state when to use this tool versus alternatives like get_event_props or get_metrics. There are no exclusions or alternative mentions, so the guidance is only implied.
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 only summarizes output ('time-series stats') and mentions bucketing, but does not disclose response format, default period behavior, limits, or other operational traits. This is insufficient for a tool with 11 parameters.
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 information. Every word adds value: 'time-series', 'stats', 'bucketed', and 'for charts'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is rich, but there is no output schema. The description gives a high-level overview but omits details like granularity override, filter interactions, and response structure. It is adequate but incomplete for a complex tool with 11 parameters.
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 parameters are documented in the schema. The tool description adds no parameter-specific meaning, but the schema carries the heavy lifting, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns time-series stats (users, sessions, events) bucketed by hour/day/month, which distinguishes it from sibling tools like get_top_events or get_live_sessions. The specific verbs and resources are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for charts' implies a use case, but there is no explicit guidance on when to use this tool versus alternatives, no exclusions, and no mention of sibling tools. Usage context is only implied.
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 responsibility for behavior. It only lists content categories and does not disclose potential pagination, rate limits, error conditions, or whether data is limited to certain session types. This is insufficient for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that packs the essential purpose without any fluff. Every word contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description partially compensates by naming events, props, and device/geo metadata. However, it lacks details on response structure, ordering, error handling, or how the timeline is organized, leaving some ambiguity about the exact return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage, so the baseline is 3. The tool description adds little beyond restating 'for a session id' which aligns with sessionId; it does not clarify appId or buildMode semantics beyond what the schema already explains.
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 returns session timeline details (events, props, device/geo metadata) for a specific session ID. It distinguishes this from sibling list/aggregate tools like get_live_sessions or get_historical_sessions by indicating a single-session lookup.
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 you need detailed timeline data for a specific session ID, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. It relies on the user inferring context from the purpose.
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, and the description does not disclose any behavioral traits such as read-only nature, error handling, or authentication requirements. A simple 'Get' does not add meaningful transparency beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It is appropriately concise for a simple single-parameter get operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with full schema coverage, the description is adequate. It does not explain return values, but no output schema exists; the lack of annotations is partially mitigated by the obvious read-only nature of a 'get by id'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter described as 'Aptabase app id'. The description's 'by id' adds little beyond the schema, so it meets the baseline without enriching parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('a single Aptabase app'), and the distinguishing qualifier ('by id'), which separates it from list_apps and other get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by 'single' and 'by id', but there is no explicit mention of when to use this tool versus list_apps or other alternatives. The agent must infer that this is for one specific app.
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 description carries full burden. It discloses that previous-period comparison is included when a date range is set, adding behavioral context beyond the schema. However, it does not detail how filters interact with the comparison or describe output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 18 words, front-loaded with tool's purpose and return types. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 11-param tool with no output schema, the description summarizes return values (daily users, sessions, events, avg duration) and conditional comparison. It gives a sufficient overview, though more detail on time-series vs aggregate output could help.
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%; description adds no specific parameter semantics beyond what schema provides. The mention of 'date range' aligns with startDate/endDate but adds no new detail.
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?
Description clearly states 'Key metrics for an app over a period' and enumerates specific metrics (daily users, sessions, events, avg duration). It distinguishes from ranking tools but does not explicitly contrast with 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for overview key metrics but does not provide explicit guidance on when to choose this over sibling tools like get_periodic_stats or get_top_events. No exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states that the operation lists apps available to the authenticated account, effectively signaling a read-only scope. It also reveals the output fields, which is useful. It does not mention pagination or return format, but for a simple listing tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs in the action, resource, scope, and output fields without unnecessary words. Every element serves a purpose and the structure is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no params, no output schema, no annotations), the description is quite complete. It identifies the resource, scope, and returned fields. It could mention that the result is an array or include pagination behavior, but these are likely implicit for a list endpoint. The field enumeration helps compensate for the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so no parameter documentation is needed. The description adds no parameter-specific information because there are none to describe. A baseline score of 4 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 verb 'List' and the resource 'Aptabase apps', with the scope 'available to the authenticated account'. It also enumerates the returned fields (id, name, appKey, ownership), making its purpose unambiguous and distinguishing it from sibling get_* tools that focus on specific metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: users should call this tool to see all apps they have access to. However, there is no explicit guidance on when to use it versus alternatives like get_app, nor any mention of when not to use it. Sibling names suggest the distinction but the description doesn't state it directly.
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/aptabase/aptabase-mcp/badges/card.svg)](https://glama.ai/mcp/servers/aptabase/aptabase-mcp)

Score Badge

Copy to your README.md:

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

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