Framedash Game Telemetry MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FRAMEDASH_API_KEY | Yes | API key with analytics:read for aggregate tools; the raw query tool additionally requires data:admin | |
| FRAMEDASH_BASE_URL | No | API base URL (default: https://app.framedash.dev) | |
| FRAMEDASH_PROJECT_ID | No | Default project UUID for project-scoped tools |
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": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| queryA | Execute a read-only SQL query against the ClickHouse events table. Returns up to |
| get_dashboardB | Get project dashboard metrics (KPIs, daily active users, top events). |
| get_retentionC | Get player retention cohort analysis. |
| get_funnelC | Analyze event funnels. Requires 2-8 event names as steps. |
| get_insightsC | Get aggregated insights for a metric grouped by a dimension. |
| get_heatmapA | Get heatmap grid data for a map. Returns performance metrics per cell. |
| list_projectsA | Show the project bound to the current API key. |
| get_project_statusB | Get the status of a project (event counts, last event time, etc.). |
| list_mapsB | List all maps in the project. |
| list_contentA | List content registry entries (event names, display labels, etc.). |
| list_alertsB | List all alert rules in the project. |
| get_alert_historyA | Get alert event history (trigger/resolve events). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| projects | Project bound to the current API key |
TDQS
Scored across 12 tools
The specialized analytics tools (get_retention, get_funnel, get_insights, etc.) have distinct purposes, but the generic `query` tool can duplicate any of them via SQL, causing potential misselection. Additionally, `get_dashboard` and `get_insights` both surface aggregated metrics, so their boundaries are not perfectly crisp.
Most tools follow a consistent `get_<resource>` or `list_<entity>` pattern, making names predictable. However, `query` stands out as a bare verb without a noun, breaking the otherwise uniform convention.
12 tools is within the well-scoped range for a telemetry server. Each tool serves a clear analytics function, and none feel redundant or unnecessary.
The tool surface covers the core analytics domain: raw query, dashboards, retention, funnels, insights, heatmaps, projects, maps, content registry, and alert history. Gaps include lack of alert CRUD and project management operations, but for a read-only telemetry MCP server, the coverage is strong.