unofficial-trackjs-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TRACKJS_API_KEY | Yes | TrackJS Data API key. Sent in the Authorization header. Required — if missing, the server exits at startup. Treat it as a secret. | |
| TRACKJS_CUSTOMER_ID | Yes | Your TrackJS Customer ID, used in the API URL (https://api.trackjs.com/{CUSTOMER_ID}/v1/...). Required — if missing, the server exits at startup. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_errorsA | List individual JavaScript error occurrences captured by TrackJS, newest first (GET /errors). Use |
| top_messagesA | Error counts grouped by error message, with affected-user counts, triage status, first/last seen and a TrackJS link (GET /errors/messages). Sorted by count descending by default. Best starting point for 'what are our most common / most impactful errors?'. Sort by usercount to rank by number of affected users. |
| errors_by_urlA | Error counts grouped by the page URL where errors happened, with affected-user counts and a TrackJS link (GET /errors/urls). Sorted by count descending by default. Use to find which pages are most broken. |
| errors_by_dayA | Daily error totals with affected-user counts and TrackJS links (GET /errors/daily), newest day first by default. Use for trends, spotting spikes and comparing before/after a deploy. Set size to the number of days you need (max 1000). |
| errors_by_hourA | Hourly error totals with affected-user counts and TrackJS links (GET /errors/hourly), newest hour first by default. Use to pinpoint when a spike started. Pass date-times (e.g. 2026-10-18T06:00:00Z) to narrow the window. |
| page_views_by_dayA | Daily page view counts (times the TrackJS agent loaded) newest first (GET /hits/daily). Combine with errors_by_day to compute an error rate and tell real regressions apart from traffic changes. |
| page_views_by_hourA | Hourly page view counts (times the TrackJS agent loaded) newest first (GET /hits/hourly). Combine with errors_by_hour to see whether a spike in errors is just a spike in traffic. |
| usage_by_hourA | Account-wide usage per hour, oldest first (GET /usage/hourly): page views, total/processed/ignored/dropped errors and errors per page view. Not broken down by application. Useful for checking plan usage, ignore-rule effects and dropped (over-quota) errors. Set granularity=day to roll hours up into UTC days for long ranges. Always pass a startDate/endDate window; long hourly ranges produce many rows. |
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 8 tools
Each tool targets a distinct aggregation dimension (individual errors, by message, by URL, by day, by hour, page views, usage), and descriptions explicitly state when to prefer one over another (e.g. top_messages before list_errors). The main potential confusion is between the parallel day/hour variants and between page_views_by_hour and usage_by_hour, but the granularity/scope wording keeps them distinguishable.
Six of eight tools follow a clean resource_by_dimension pattern (errors_by_url, errors_by_day, page_views_by_hour, usage_by_hour). Two outliers use verb-first naming (list_errors, top_messages) which is readable and arguably intentional for 'list raw items' vs 'aggregate', but breaks strict uniformity.
Eight tools is well-scoped for an error-analytics server; each tool covers a distinct report shape (raw errors, groupings, time series, traffic, account usage) with no redundant entries.
The read-oriented analytics surface is solid (individual errors, groupings, daily/hourly trends, traffic for error-rate math), but triage status is only ever read, never updated, and there are no breakdowns by browser, release, or application despite such data being present in error records. Agents can answer 'what is breaking' questions but cannot manage or slice errors beyond URL/time.