Skip to main content
Glama

Amplitude

by io.github.pipeworx-io

Amp Get Active Users

amp_get_active_users
Read-onlyIdempotent

Get active user counts by granularity (daily, weekly, or monthly) for a date range. Returns totals and trend data.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
mNoMetric: "active" (DAU), "new", or "returning" (default "active")
endYesEnd date (YYYYMMDD)
startYesStart date (YYYYMMDD)
_apiKeyYesAmplitude API key
_secretKeyYesAmplitude secret key

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNoDetailed user metrics by granularity
seriesNoActive user counts by time period

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "data": {
+      "description": "Detailed user metrics by granularity",
+      "type": "object"
+    },
+    "series": {
+      "description": "Active user counts by time period",
+      "items": {
+        "properties": {
+          "date": {
+            "description": "Date period (YYYYMMDD)",
+            "type": "string"
+          },
+          "value": {
+            "description": "Active user count",
+            "type": "number"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}
  2. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "_apiKey": "your-amplitude-api-key",
+    "_secretKey": "your-amplitude-secret-key",
+    "end": "20240131",
+    "start": "20240101"
+  },
+  {
+    "_apiKey": "your-amplitude-api-key",
+    "_secretKey": "your-amplitude-secret-key",
+    "end": "20240131",
+    "m": "new",
+    "start": "20240101"
+  }
+]
  3. First observed

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the bar is lower. The description adds that it 'Returns totals and trend data,' which is useful but does not disclose additional behavioral traits such as rate limits or data freshness.

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?

Two sentences front-loaded with the verb and resource. Concise with no wasted words. However, the granularity phrasing could be more precise to avoid confusion.

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 presence of a rich annotation set and an output schema, the description covers the tool's purpose and key features (totals, trend data, granularity). It is adequate for a simple data retrieval tool, though minor inaccuracies around granularity exist.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description mentions 'granularity (daily, weekly, or monthly),' which is not reflected in the schema (the 'm' parameter is for metric, not granularity). This adds context but potentially introduces inconsistency.

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 verb 'Get', resource 'active user counts', and specifies the returned data (totals and trend data). It distinguishes from sibling tools like amp_get_events or amp_get_retention by focusing on active user counts.

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 mentions granularity options (daily, weekly, monthly) and date range, which implies usage context, but lacks explicit guidance on when to use this tool versus alternatives like amp_get_events. No when-not or exclusion criteria are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Amplitude toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.5/5.0
Disambiguation2/5

Several tools have heavily overlapping purposes: ask_pipeworx, ask_pipeworx_beta (currently identical), ask_pipeworx_grounded, deep_research, and validate_claim all answer natural-language questions over the same underlying data sources. ai_visibility_check and scan_competitor_ai_presence also overlap as single vs. comparative variants. The detailed descriptions help, but the boundaries between the query/research tools remain genuinely ambiguous for an agent.

Naming Consistency2/5

No consistent global naming convention. There are prefix families (amp_*, pipeworx_*, polymarket_*) but within them the structure varies (amp_get_events vs amp_user_search; ask_pipeworx vs polymarket_fill_risk), and many tools are bare verbs or noun phrases (remember, recall, forget, bet_research, search_within, recent_alerts). The mix of verb-first and noun-first names with irregular prefixes makes predicting tool names unreliable.

Tool Count2/5

36 tools is too many for the server's nominal purpose: only 5 of them (amp_*) relate to Amplitude analytics, while the other 31 form a sprawling all-in-one data/research/prediction-market platform. Even accepting that broader scope, many tools could be consolidated (ask_pipeworx_beta duplicates ask_pipeworx, several polymarket tools are specialized but still numerous), making the count feel padded rather than focused.

Completeness3/5

The Pipeworx side is thorough: lookups, grounded verification, deep research, entity profiles, comparisons, subscriptions, and memory cover most of that domain well. However, the Amplitude analytics side is thin — it only queries events, active users, retention, and user activity, with no way to manage projects, cohorts, event definitions, or user properties. There is also no general web search tool and no direct database/SQL exploration, leaving notable gaps for the advertised all-in-one positioning.

Resources