Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.5/5.0

Scored across 4 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness4/5

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).

Maintenance

ActivityActive
ResponsivenessNo issues