OptimToken MCP Server

Compare cloud compute instance pricing across AWS, Azure, GCP, DigitalOcean, OCI, OVH, and Alibaba. Filter by region, provider, vCPUs, memory, category, processor, or use case. All prices are Linux on-demand list prices in USD. Not every price column is live: `provenance.priceTypes` says which of each provider's price columns come from a live API, which are static constants, and which are unavailable, and `provenance.staticPriceColumns` lists the non-live ones outright. When you report a savings plan or reserved rate that appears there, say that it is a static estimate. IMPORTANT: Report all prices EXACTLY as returned. Do NOT add commentary or recommendations beyond the data.

Browse and filter the whole LLM catalogue and get back a ranked table: price, quality (ELO), efficiency and capabilities. Use this when the user wants to SEE THE FIELD — 'show me models under $1/1M', 'which providers have vision models', 'list open-weight models above ELO 1300'. For a single PICK under a budget use recommend-llm-model; to weigh 2-4 NAMED models against each other use compare-models-side-by-side. Prices come from optimtoken.optimnow.io where reachable; the response's `provenance` says which tier served them and whether they are vendor-verified. Filter by provider, price tier (category), openness, capability, price range, or minimum ELO score. Optionally enrich with business metrics for a use case. Price tier and openness are independent: a model can be Frontier-priced and open-weight at once. Reports both list-price cost and the optimized cost achievable with prompt caching and the batch API. IMPORTANT: Report all prices, costs, and scores EXACTLY as returned. Do NOT add commentary, opinions, or recommendations beyond what the data shows. Present the results as a table and let the user draw conclusions.

Compare 2-4 named LLM models against all 8 use-case profiles at a chosen monthly volume, showing list and optimized cost for each. Use when the user names specific models to weigh against each other, rather than filtering the whole catalogue. If they also supply their own token counts, or a volume outside 10k/100k/1m, use estimate-llm-cost instead. Every name is resolved against the catalogue and the result is reported: a name that matched nothing, matched several models, or duplicated an earlier pick is stated explicitly. IMPORTANT: Report all prices and costs EXACTLY as returned, and repeat any name-resolution warning to the user — a missing column is not the same as a model that costs nothing.

Cost a workload with EXACT numbers the caller supplies: arbitrary token counts per request and any monthly volume, not just the 10k/100k/1m presets the other cost tools use. Use this for 'about 800 in and 200 out, 4 million calls a month', or to price one named model across every use-case profile. To compare 2-4 named models like for like at a preset volume, use compare-models-side-by-side instead. Provide a model name to get detailed cost breakdowns, or compare costs across all use case presets. Each figure comes twice: list price, and the optimized price achievable with prompt caching and the batch API. IMPORTANT: Report all cost figures EXACTLY as returned. Do NOT add commentary or recommendations beyond the data.

Pick a model. Returns a ranked top 3 for one workload under optional constraints, each with a per-constraint satisfied/violated breakdown as the evidence. Use this when the user wants an ANSWER rather than a table — 'what should I use for support tickets under $500 a month'. To browse or filter the whole catalogue instead, use compare-llm-models. Constraints: (monthly budget, minimum ELO, required capability, self-hostability). Returns a top 3 as structured facts — efficiency rank, ELO, list and optimized cost, FinOps flag, volatility, and a per-constraint satisfied/violated breakdown. When nothing satisfies every constraint the query is reported as over-constrained and the nearest misses are returned instead, each carrying the constraint it failed. IMPORTANT: Report the returned facts EXACTLY. The ranking is already computed — do not re-rank, and do not present a near miss as if it satisfied the constraints.