llm-latency-tracker
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_ai_api_latencyA | Rank hosted AI inference API providers (46 tracked: OpenAI, Anthropic, Google, Groq, Fireworks, OpenRouter and others) by measured network latency inside a probe region over the last 24 hours. Use it to answer 'which provider responds fastest from Europe/US/Tokyo/Sao Paulo' or to pick an endpoint close to your users. To follow one named provider across regions use get_provider_latency instead. Values are edge TTFB (DNS+TCP+TLS+first byte from probes every 5 minutes, direct connections, no gateway), not tokens per second or model quality. Returns the region label, dataset timestamp and the ranked rows; omit region to get all four regions at once (larger response). |
| get_provider_latencyA | Show how a single AI API provider performs from every probe region (Germany, USA, Tokyo, Sao Paulo): its rank in that region, median and p95 time to first byte, uptime and sample count over the last 24 hours. Use it for questions like 'is the Anthropic API slower from Asia than from Europe' or 'was OpenAI reachable today'. For the full leaderboard of a region use get_ai_api_latency. An unknown provider id returns an error that lists the valid ids. |
| get_model_deprecationsA | List announced shutdowns of AI models (OpenAI, Anthropic, Mistral, Azure OpenAI and others) with announcement date, shutdown date, recommended replacement and the provider page each entry was verified against, plus how many days of notice each provider typically gives (median/min/max). Use it before pinning a model version, to plan migrations, or to check whether a model ID still works. Returns upcoming shutdowns by default; set include_past to also get already-retired models. This is calendar data, not latency; for speed use get_ai_api_latency. |
| get_coding_agent_healthA | Report whether the Claude Code or Codex CLI coding agents (on consumer subscriptions) got slower, think less or answer worse than their own recent baseline. Gives output speed (tokens/s and ms per token), thinking tokens, time to first token and error rate for the last 24 h versus the previous 7 days with Mann-Whitney significance flags, plus accuracy on a fixed hard question panel. Use it when someone asks 'is Claude Code slow / nerfed today'. Measured hourly from one EU server, one account per vendor, so it reflects that vantage point; for raw API latency use get_ai_api_latency. |
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 4 tools
The two latency tools have overlapping subject matter, but each description explicitly points to the other with a clear boundary rule (leaderboard vs. single-provider across regions). The deprecations and coding-agent-health tools are in entirely different domains, and each description reiterates its scope ('calendar data, not latency', 'for raw API latency use...'). An agent can pick correctly without guessing.
All four tools use the same get_<subject> snake_case pattern with no deviation in verb or casing. The names are predictable and readability is high. Minor quibble: get_ai_api_latency actually returns a ranked leaderboard rather than a single latency value, but the convention itself is uniform.
Four tools is compact and none feel redundant, which fits a narrowly scoped observability server. It is on the lean side given it spans three distinct areas (API latency, model deprecations, coding-agent health), leaving little room for supporting lookups.
The surface covers the core questions: regional ranking, per-provider detail, deprecation planning, and agent regression checks. Gaps are minor and workaroundable (no provider-list endpoint, though errors enumerate valid ids; no historical time series beyond the fixed 24h window).