Metricairn
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| METRICAIRN_API_URL | Yes | The URL of the Metricairn API server, e.g. http://localhost:8000 | |
| METRICAIRN_READ_KEY | Yes | Your Metricairn read key, e.g. alr_YOUR_READ_KEY |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_metricsA | Catalog of available metrics and dimensions. Start here to discover what you can query. |
| query_metricsC | Time series for a metric. metric: visitors|pageviews|sessions|events|revenue. interval: day|hour. |
| breakdownB | Top values for a dimension: path, referrer, utm_source, utm_medium, utm_campaign, device, browser, os, country, event. |
| list_dimension_valuesB | Discover which values a dimension actually has (e.g. real page paths, real UTM sources). |
| funnel_reportA | Conversion report for a funnel (match by name or id). Steps must be completed in order. Pass segment_by (e.g. 'device', 'utm_source') to compare conversion per segment — a visitor's segment is the dimension value on their entry-step event. |
| revenue_attributionC | Revenue total, transactions, revenue-per-visitor, and breakdown by traffic source. |
| compareA | Compare an equal-length previous period: traffic, custom events and revenue. Changes are descriptive. Null percent change means the previous baseline was zero. |
| detect_anomaliesB | Unusual spikes/dips (screening signals, not significance tests) in pageviews and revenue (robust historical scores). |
| askC | Ask a natural-language question about your analytics, e.g. 'why did revenue dip last Tuesday?' |
| integration_healthA | Is the instrumentation actually flowing? Checklist: tracker pageviews, revenue events, custom events, funnels, recency. Run this first when answers look empty or suspicious — most 'wrong' answers are missing data, not wrong analysis. |
| get_realtimeB | Live activity: visitors, pageviews and top pages in the last 30 minutes. |
| mcp_usageB | How AI agents are using this MCP server: tool-call counts, error rates, and recent questions. |
| list_notesA | Timeline annotations: launches, deploys, campaigns the founder (or an agent) logged. Newest first. |
| run_queryA | Execute a typed analytics plan without AI or SQL. Fields: metric (pageviews|visitors|sessions|events|event_count), mode (total|timeseries|breakdown), event_name (required for event_count), dimension (for breakdown), interval (day|hour), date_from/date_to (ISO UTC), limit (1..100), filters ([{field, values}]). Filter fields: path, utm_source, utm_medium, utm_campaign, device, browser, os, country, event. Filters are ANDed; values within each filter are ORed. Returns resolved plan and caveats. Example: {"metric":"event_count","event_name":"signup","mode":"breakdown","dimension":"device"}. |
| investigate_changeA | Investigate changes in pageviews, events, or event_count (requires event_name). Returns equal-duration comparison, additive source/device/browser/path changes, coverage, timeline notes, caveats and next checks. This describes associations, not causes. Use date_from/date_to together to fix an exact window; otherwise days determines it. |
| list_goalsA | Discover named custom-event conversion goals and their IDs. |
| goal_reportB | Period conversion: unique visitors with a pageview then this goal. Reports denominator, repeated occurrences and missing identity. Use date_from/date_to together for an exact window; otherwise days determines it. |
| retention_reportA | Weekly first-observed visitor cohorts, weeks 0..12. Incomplete cells are null; identities and acquisition history affect accuracy. event_name optionally restricts returning activity, not the first-observed cohort definition. Use date_from/date_to together for an exact window; otherwise days determines it. |
| list_investigationsC | Recent saved evidence records, their IDs and human review status. |
| get_investigationB | Read an immutable saved investigation and its separate human review note. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 20 tools
Several tools overlap heavily: run_query subsumes query_metrics and breakdown (total/timeseries/breakdown modes), while compare and investigate_change both perform equal-duration period comparisons, and ask overlaps with the structured query tools. Funnel/goal/retention reports and the note/investigation lifecycle are clearly distinct, but the querying layer has fuzzy boundaries that invite misselection.
There is a recognizable verb_noun pattern for many tools (list_metrics, query_metrics, run_query, list_goals, get_realtime, detect_anomalies, investigate_change, get_investigation), but it is broken by bare nouns and ambiguous names (breakdown, compare, ask, funnel_report, revenue_attribution, mcp_usage). The mix is readable but not a predictable convention.
At 20 tools this is on the heavy side for an analytics server, and the count is inflated by overlapping query paths that could be consolidated (e.g. query_metrics/breakdown folded into run_query). It is not egregious—each tool maps to a plausible analytics task—but it sits at the borderline of too many.
The surface covers the analytics lifecycle well: discovery (list_metrics, list_dimension_values), querying, funnel/goal/retention/attribution reporting, anomaly detection, realtime, data-health checks, and investigation save/review. Minor gaps exist (e.g. no explicit breakdown-by-metric filter builder output, no scheduling), but core workflows are covered without dead ends.