This MCP server provides LLM capacity planning tools focused on estimating VRAM usage, compute requirements, latency, and GPU topology for agents. The serverβs documented purpose is performance estimation for agent deployments, using those measurements to support planning and selection decisions.
π οΈ Key Features
Estimates VRAM requirements
Estimates compute needs
Estimates latency
Analyzes GPU topology
π Use Cases
Planning LLM agent deployments by hardware capability
Comparing compute/latency implications across GPU configurations
Estimating resource requirements to guide infrastructure selection
β‘ Developer Benefits
Provides planning inputs for VRAM, compute, and latency estimates
Supports topology-aware planning via GPU topology estimation
β οΈ Limitations
Source data does not specify available tools, interfaces, or toolCount beyond the described estimation scope
Plan your LLM deployment before you rent the GPUs.
Switch model β multi-GPU β long-context capacity planner β Build vs Buy β Reference catalog β Live GPU pricing
tokcalc turns your LLM traffic, context length, latency SLOs, cache behavior,
and model choice into a defensible serving topology and cost plan β
with transparent formulas and cited benchmarks.
It's the engineering-grade pre-deployment decision layer for LLM inference.
Not another static "tokens per second" calculator.
Every PR that touches the plan gets a comment with the VRAM budget, KV-cache
sizing, throughput, TTFT/ITL, and cost β so a reviewer can check the model/GPU
choice without leaving the diff.
Pin to a release tag (as above) rather than @main, so the action can't
change under you between runs.
The action runs tokcalc's own src/lib/token-calc.ts from this repository, so
the numbers it reports are the same ones the site and the MCP tools produce.
There is no second implementation to drift.
Any field can be overridden per-run, or you can skip the config file entirely:
npx @tokcalc/mcp-server plan --config .tokcalc.json
npx @tokcalc/mcp-server plan --model llama3-70b --gpu h100-sxm --quant fp8 --format json
Exit code is 0 when the plan fits, 2 when it does not, 1 on a usage error
β so it works as a CI gate.
Why tokcalc?
The market has dozens of "tokens per second" calculators and self-host-vs-API
break-even tools (induwara.lk, gigagpu, kickllm, cloudparity, curlscape,
profitable.ai). None of them are unified capacity planners β and none show
their math.
What tokcalc answers that competitors can't
"Can I serve Qwen 2.5 72B at 128K context on 2Γ H100 with 20 concurrent users?"
"How many H200s do I need for 1,000 req/min with P95 TTFT < 2s?"
"Does FP8 or AWQ save more money once quality, KV cache, and engine support are included?"
"At what daily volume does an H100 beat GPT-4o pricing?"
"What's the cheapest H100 right now across Azure / AWS / GCP / Vast.ai?"
"What happens to cost and latency if an agent makes 8 model calls, has 3 tool calls, and its context grows by 5K tokens each turn?"
"Would prefix caching, continuous batching, or PD disaggregation save more for this workload?"
Features
Calculator tab
Feature
What it computes
Model fit / VRAM
Will the model + KV cache fit in the GPU's memory?
The π΄ Live pricing sub-tab in Reference fetches real-time GPU prices from 4 providers in parallel via Promise.allSettled:
Provider
API
Auth
Cache TTL
Azure
Retail Prices API
None (public)
24h
AWS
EC2 bulk pricing file
None (public)
24h
GCP
Cloud Billing Catalog API
GCP_API_KEY env var
24h
Vast.ai
Marketplace bundles API
None (public)
5m (spot prices change rapidly)
Each provider shows a LIVE badge with timestamp + cache state. The comparison table shows the cheapest price per GPU across all 4 providers (highlighted in emerald) + per-provider breakdown.
If any provider fails (e.g., GCP_API_KEY not set), the others still work β graceful degradation per provider.
The math, transparently
Every number above comes from a formula you can inspect. No black boxes.
Critical caveat: There is no universal continuous batching multiplier. vLLM
reported 14β24Γ vs HF Transformers (extreme), 2.2β2.5Γ vs TGI. SOSP paper
finds 2β4Γ typical vs FasterTransformer/Orca. tokcalc defaults to a
conservative 1.5Γ and lets you tune.
The decisive term is effective utilization β not peak throughput. A GPU
running at 10% utilization pays 10Γ more per token than the theoretical minimum.
β Single-core MCP architecture β one src/lib/mcp/core.ts, shimmed into both the
hosted endpoint and the npm package, so the two surfaces cannot drift
β Published to the MCP Registry and kept
current by an OIDC workflow on every v* tag
β Correct MoE accounting β resident (full) weights and active (per-token)
parameters reported separately, instead of conflating them
β Strict tool schemas β Zod 4 native JSON Schema; unknown parameters are rejected
with the valid names suggested back
β Public hosted MCP endpoint at tokcalc.vercel.app/api/mcp with bearer auth + Upstash Redis rate limiting
β Self-serve API key generation at tokcalc.vercel.app/mcp (email β instant key)
i18n (Chinese / Japanese / Korean) β permanent translation maintenance across
39 models Γ 30 GPUs Γ 11 tools, and traffic is currently overwhelmingly CI and agent
installs rather than human readers. Revisit only if CJK traffic shows up in analytics.
OAuth 2.1 / PKCE β auth infrastructure for a product with one user. Self-serve key
issuance plus Upstash rate limiting already covers the real need. Revisit on demand.
Training/fine-tuning FLOPs, energy/carbon, embedding mode β each of these is a
separate product in a separate domain. "Capacity planner" is a sharp position; widening
it into a general AI-infra calculator suite costs more than it earns.
Open core model
tokcalc is open core β the calculator and catalog are open source; the
cloud/data/team features are paid.
Asset
License
Notes
Source code
Apache 2.0
This repo. Free to use, modify, distribute
Model/GPU/quant catalog
CC0 1.0
Public domain data. Anyone can use, no attribution required
Benchmark provenance data
CC-BY-SA 4.0
Anyone can use, but must attribute + share-alike
Documentation
CC-BY 4.0
Attribution required if copied
"tokcalc" name + logo
Trademark
Even without formal registration, common-law rights apply
Cloud SaaS layer
Proprietary
Real-time pricing API, benchmark DB, team workspaces (coming soon)
Why this structure
Trust: Open-source formulas build credibility vs opaque competitors
Community: Contributors can submit models, GPUs, quants, benchmarks
Defensibility: Trademark + cloud features + URL-share viral loop protect against forks
Revenue: Cloud tier funds ongoing development + pricing/benchmark data maintenance
npm install -g @tokcalc/mcp-server
tokcalc-mcp-http # defaults to port 3000
Set MCP_API_KEY, UPSTASH_REDIS_REST_URL, UPSTASH_REDIS_REST_TOKEN env vars for auth + rate limiting.
Example agent prompt
"I need to serve Llama 3.3 70B at 32K context for 50 concurrent users. What GPU topology do you recommend, and how much will it cost per month?"
The agent calls list_models β list_gpus β recommend_topology β estimate_capacity β returns a structured plan with VRAM, throughput, latency, cost, and confidence.
Development & testing
bash
# Typecheck (must stay at zero errors)
bunx tsc --noEmit
# Golden-number suite (33 tests) β hand-verified oracle values
bun test tests/mcp-golden.test.ts
# Surface-parity suite (9 tests) β every surface advertises the same 11 tools
bun test tests/mcp-surface-parity.test.ts
# Build the npm server dist + prepublish guard (freshness + version sync)cd mini-services/mcp-server && bun run build && node scripts/prepublish-check.js
# 35-check black-box stdio QA battery against the freshly built distcd ../.. && node tests/qa-live-probe.mjs local# β¦or against the PUBLISHED npm tarball:
node tests/qa-live-probe.mjs 0.2.9
# 20-check HTTP smoke probe against the hosted /api/mcp surface
MCP_API_KEY=<key> EXPECTED_VERSION=0.2.9 node tests/http-smoke.mjs http://localhost:3001
# β¦or against production:
MCP_API_KEY=<key> node tests/http-smoke.mjs https://tokcalc.vercel.app
GitHub Actions runs all of the above (except the published-tarball mode) on every push β see .github/workflows/ci.yml.