F
licenseB
qualityD
maintenanceA Model Context Protocol (MCP) server that optimizes token usage by caching data during language model interactions, compatible with any language model and MCP client.
4
2
tokencost-mcp-server
by ankit-aglawe
The TokenCost MCP Server provides real-time LLM token pricing data and cost estimation tools for 60+ AI models across 15+ providers (OpenAI, Anthropic, Google, xAI, Meta, Mistral, DeepSeek, and more).
Get Model Pricing (
tokencost_get_model_pricing): Retrieve detailed pricing for a specific model (e.g., GPT-5, Claude Sonnet, Gemini Pro), including input/output costs per 1M tokens, context window size, and max output tokens.Compare Models (
tokencost_compare_models): Side-by-side pricing comparison of 2–10 models simultaneously, showing cost differences to help choose the best option.Estimate Cost (
tokencost_estimate_cost): Calculate the exact USD cost for a given number of input and output tokens with a specific model, broken down by input, output, and total.Find Cheapest Models (
tokencost_find_cheapest): Discover the most cost-effective models, with optional filters by provider, minimum context window, and sorting by input, output, or combined cost.List All Models (
tokencost_list_models): Browse all 60+ available models with IDs, names, and providers, optionally filtered by provider.List Providers (
tokencost_list_providers): View all supported providers with their model counts and pricing ranges.
Pricing data is kept up-to-date within days of official changes and can be queried via natural language through AI assistants like Claude Desktop, Cursor, or Windsurf.
Provides real-time pricing data, cost estimation, and model comparisons for Amazon AI models like Nova.
Provides real-time pricing data, cost estimation, and model comparisons for Google AI models like Gemini.
Provides real-time pricing data, cost estimation, and model comparisons for Meta AI models like Llama.
Provides real-time pricing data, cost estimation, and model comparisons for NVIDIA AI models.
Provides real-time pricing data, cost estimation, and model comparisons for OpenAI AI models like GPT-4 and GPT-5.
Provides real-time pricing data, cost estimation, and model comparisons for Perplexity AI models.
TokenCost MCP Server
An MCP (Model Context Protocol) server that provides real-time LLM token pricing data for 60+ AI models across 15 providers.
Query, compare, and estimate costs for models from OpenAI, Anthropic, Google, Meta, xAI, Mistral, DeepSeek, and more — directly from your AI assistant.
Built by TokenCost — the free LLM token cost calculator.
Tools
Tool | Description |
| Get pricing for a specific model |
| Side-by-side pricing comparison |
| Calculate cost for given token counts |
| Find cheapest models with filters |
| List all available models |
| List all providers with pricing ranges |
Related MCP server: UsageWall
Quick Start
Claude Desktop / Cursor / Windsurf
Add to your MCP config:
{
"mcpServers": {
"tokencost": {
"command": "npx",
"args": ["-y", "tokencost-mcp-server"]
}
}
}From Source
git clone https://github.com/ankit-aglawe/tokencost-mcp-server
cd tokencost-mcp-server
npm install
npm run build
npm startExample Usage
"How much would it cost to process 1M input tokens with GPT-5?"
→ Uses tokencost_estimate_cost with model="gpt-5", input_tokens=1000000, output_tokens=0
"Compare Claude Sonnet 4.6 vs GPT-5 vs Gemini 3 Pro pricing"
→ Uses tokencost_compare_models with ["claude-sonnet-4.6", "gpt-5", "gemini-3-pro"]
"What's the cheapest model with at least 200K context?"
→ Uses tokencost_find_cheapest with min_context=200000
Supported Providers
OpenAI, Anthropic, Google, xAI, Meta, Mistral, DeepSeek, Alibaba (Qwen), Amazon (Nova), NVIDIA, Cohere, Perplexity, Moonshot (Kimi), Zhipu (GLM), MiniMax
Pricing Data
Pricing is kept accurate and up to date by the TokenCost team. We track official provider announcements and update pricing as soon as changes are published — new models, price cuts, and deprecations are reflected within days.
If you notice outdated pricing or a missing model, open an issue and we'll get it updated.
License
MIT
Available Tools
6 toolstokencost_compare_modelsCompare Model PricingARead-onlyIdempotent
Compare pricing across multiple LLM models side by side.
Args:
models (string[]): Array of model IDs or names to compare (2-10 models)
Returns: Side-by-side comparison table with input/output costs, context windows, and relative cost differences.
Examples:
["gpt-5", "claude-sonnet-4.6"] → Compare OpenAI vs Anthropic pricing
["gpt-5-mini", "gemini-3-flash", "claude-haiku-4.5"] → Compare budget models
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| models | Yes | Model IDs or names to compare |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and idempotent behavior, but the description adds useful context about the return format (side-by-side comparison table with specific columns) and model count constraints (2-10 models), which goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, organized sections for Args, Returns, and Examples, and every sentence adds value without redundancy. It efficiently communicates essential information in a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, rich annotations, and 100% schema coverage, the description is mostly complete. It lacks an output schema but describes the return format adequately. A minor gap is no explicit mention of data sources or update frequency for pricing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the 'models' parameter. The description adds minimal value beyond the schema by restating the parameter name and providing examples, but does not explain semantics like model ID formats or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('compare') and resource ('pricing across multiple LLM models'), and distinguishes it from siblings like 'estimate_cost' or 'find_cheapest' by emphasizing side-by-side comparison rather than single calculations or optimization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (comparing multiple models side-by-side), but does not explicitly state when not to use it or name alternatives among siblings. The examples imply usage for direct model comparisons rather than other pricing tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tokencost_estimate_costEstimate Token CostARead-onlyIdempotent
Calculate the cost for a specific number of input and output tokens with a given model.
Args:
model (string): Model ID or name
input_tokens (number): Number of input tokens (0 to 100B)
output_tokens (number): Number of output tokens (0 to 100B)
Returns: Cost breakdown with input cost, output cost, and total cost in USD.
Examples:
model="gpt-5", input_tokens=1000, output_tokens=500 → Cost for a typical API call
model="claude-sonnet-4.6", input_tokens=100000, output_tokens=4000 → Cost for a long context call
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model ID or name | |
| input_tokens | Yes | Number of input tokens | |
| output_tokens | Yes | Number of output tokens |
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds value by specifying the return format ('Cost breakdown with input cost, output cost, and total cost in USD') and providing examples, but does not disclose additional behavioral traits like rate limits or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, Args, Returns, Examples) and front-loaded key information. It is appropriately sized, though the examples could be slightly more concise. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema), the description is mostly complete. It covers purpose, parameters, returns, and examples. However, it lacks explicit usage guidelines against siblings and does not detail output structure beyond a high-level description, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter clearly documented in the schema. The description adds minimal value beyond the schema by listing parameters in the Args section and providing examples, but does not explain semantics like token ranges or model formats beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Calculate') and resource ('cost for a specific number of input and output tokens with a given model'). It distinguishes from siblings like 'compare_models' or 'find_cheapest' by focusing on cost estimation for a single model rather than comparison or optimization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to calculate token costs for a model), but it does not explicitly state when not to use it or name alternatives. Sibling tools like 'compare_models' or 'find_cheapest' are implied alternatives for different use cases, but no explicit guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tokencost_find_cheapestFind Cheapest ModelsARead-onlyIdempotent
Find the cheapest LLM models, optionally filtered by provider or minimum context window.
Args:
provider (string, optional): Filter by provider (e.g., "OpenAI", "Anthropic", "Google")
min_context (number, optional): Minimum context window size in tokens
sort_by (string, optional): Sort by "input", "output", or "combined" cost (default: "combined")
limit (number, optional): Number of results to return (default: 10, max: 30)
Returns: Ranked list of cheapest models with pricing details.
Examples:
{} → Top 10 cheapest models overall
{ provider: "OpenAI" } → Cheapest OpenAI models
{ min_context: 200000, sort_by: "input" } → Cheapest 200K+ context models by input price
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Filter by provider name (e.g., 'OpenAI', 'Anthropic') | |
| min_context | No | Minimum context window size in tokens | |
| sort_by | No | Sort by input, output, or combined cost | combined |
| limit | No | Number of results to return |
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover key behavioral traits (read-only, non-destructive, idempotent, closed-world), so the description adds minimal value beyond this. It does not disclose additional context such as rate limits, authentication needs, or data sources. However, it does not contradict the annotations, as 'Find' aligns with read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with a clear purpose statement, followed by structured sections for args, returns, and examples. However, the 'Args' section is somewhat redundant with the schema, and the examples could be more concise, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, rich annotations, and full schema coverage, the description is mostly complete. It explains the tool's purpose, parameters, and outputs with examples, though it lacks details on output format (e.g., structure of pricing details) and does not have an output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description repeats parameter information in the 'Args' section without adding significant meaning beyond what the schema provides, such as clarifying edge cases or usage nuances. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Find') and resource ('cheapest LLM models'), and distinguishes it from siblings by focusing on cost optimization rather than comparison, estimation, listing, or provider listing. It specifies the core function of identifying the most economical models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage through examples that show when to apply filters (e.g., by provider or context window), but it does not explicitly state when to use this tool versus alternatives like 'tokencost_compare_models' or 'tokencost_list_models'. The examples imply usage scenarios but lack direct sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tokencost_get_model_pricingGet Model PricingARead-onlyIdempotent
Get pricing details for a specific LLM model.
Args:
model (string): Model ID or name to look up (e.g., "gpt-5", "claude-sonnet-4.6", "gemini-3-pro")
Returns: Model pricing details including input/output costs per 1M tokens, context window, and max output. Returns an error message if the model is not found, with suggestions for similar models.
Examples:
"gpt-5" → GPT-5 pricing from OpenAI
"claude-opus-4.6" → Claude Opus 4.6 pricing from Anthropic
"gemini" → First matching Gemini model
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model ID or name (e.g., 'gpt-5', 'claude-sonnet-4.6') |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable context beyond annotations: it specifies that it returns pricing details (input/output costs, context window, max output) and error handling (error message with suggestions if model not found), which are not captured in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by clear sections for Args, Returns, and Examples. Each sentence adds value without redundancy, and the examples are concise and illustrative, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema), the description is mostly complete: it explains the purpose, parameter usage, return details, and error behavior. However, it lacks explicit guidance on when to use this tool versus siblings, which is a minor gap in contextual completeness for a server with multiple related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the schema fully documenting the 'model' parameter. The description adds minimal semantics beyond the schema—it provides examples of model IDs (e.g., 'gpt-5', 'claude-sonnet-4.6') but no additional constraints or usage notes. This meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get pricing details') and resource ('for a specific LLM model'), distinguishing it from siblings like 'list_models' (which lists models) or 'compare_models' (which compares multiple). The examples reinforce this specificity by showing concrete model lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through examples (e.g., looking up specific models like 'gpt-5'), but does not explicitly state when to use this tool versus alternatives like 'tokencost_list_models' (for browsing) or 'tokencost_compare_models' (for comparisons). It provides clear input-output behavior but lacks explicit guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tokencost_list_modelsList All ModelsARead-onlyIdempotent
List all available LLM models with pricing data, optionally filtered by provider.
Args:
provider (string, optional): Filter by provider (e.g., "OpenAI", "Anthropic", "Google")
Returns: List of all models with IDs, names, and providers. Use model IDs with other tools.
Examples:
{} → All 60+ models
{ provider: "Anthropic" } → All Anthropic Claude models
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Filter by provider name |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable context beyond annotations: it reveals the scale ('60+ models'), mentions that results include 'pricing data', and specifies that model IDs should be used with other tools—useful behavioral details not captured in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise: it starts with a clear purpose statement, followed by well-organized sections for Args, Returns, and Examples. Every sentence adds value—no wasted words—and information is front-loaded with the core functionality stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter), rich annotations, and 100% schema coverage, the description is nearly complete. It covers purpose, usage, parameter examples, and output format. The only minor gap is lack of an output schema, but the description adequately describes the return format. It effectively complements the structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the schema fully documenting the optional 'provider' parameter. The description adds minimal value beyond the schema: it provides example provider values ('OpenAI', 'Anthropic', 'Google') and shows usage examples, but doesn't explain parameter semantics beyond what the schema already states. This meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all available LLM models with pricing data'), and explicitly distinguishes this tool from siblings by specifying it returns 'all models with IDs, names, and providers' and noting 'Use model IDs with other tools'—differentiating it from compare_models, estimate_cost, find_cheapest, get_model_pricing, and list_providers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs alternatives: it specifies 'List all available LLM models with pricing data' and includes examples showing both unfiltered and provider-filtered usage. It implicitly contrasts with siblings like list_providers (which lists providers only) and get_model_pricing (which gets pricing for specific models).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tokencost_list_providersList ProvidersARead-onlyIdempotent
List all LLM providers with model counts and pricing ranges.
Returns: All providers with the number of models and pricing range for each.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a read-only, non-destructive, idempotent operation with a closed world, but the description adds useful context by specifying the return content (model counts and pricing ranges). It does not contradict annotations and provides behavioral details beyond them, though it lacks information on rate limits or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and uses a second sentence to clarify the return format, with no wasted words. It is appropriately sized for a simple tool with no parameters, making every sentence earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema) and rich annotations, the description is mostly complete by specifying what is returned. However, it could be slightly enhanced by mentioning the lack of filtering or sorting options, though this is not critical for a list-all tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline is 4 as there are no parameters to document. The description does not need to compensate for any gaps, and it efficiently states the tool's purpose without redundant parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all LLM providers') and the resources returned ('with model counts and pricing ranges for each'), distinguishing it from siblings like 'tokencost_list_models' which lists models rather than providers. It precisely defines the verb and scope without redundancy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying what it returns (providers with counts and pricing), but does not explicitly state when to use this tool versus alternatives like 'tokencost_list_models' or 'tokencost_get_model_pricing'. No exclusions or prerequisites are mentioned, leaving some ambiguity in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A4.3/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: compare_models for side-by-side comparisons, estimate_cost for specific token calculations, find_cheapest for budget optimization, get_model_pricing for detailed lookups, list_models for catalog browsing, and list_providers for provider overview. The descriptions clearly differentiate their functions, eliminating any confusion about which tool to use for a given task.
Naming Consistency5/5
All tools follow a perfect verb_noun pattern with the 'tokencost_' prefix: compare_models, estimate_cost, find_cheapest, get_model_pricing, list_models, and list_providers. The naming is completely consistent, using descriptive verbs that accurately reflect each tool's function, making the set highly predictable and easy to navigate.
Tool Count5/5
Six tools is an ideal number for this server's purpose of LLM cost analysis. Each tool serves a distinct, valuable function in the workflow—from browsing models and providers to detailed comparisons and cost estimations—without any redundancy. The count is well-scoped, covering all essential operations without being overwhelming or insufficient for the domain.
Completeness5/5
The tool set provides complete coverage for LLM cost analysis: list_providers and list_models for discovery, get_model_pricing for detailed lookups, estimate_cost for calculations, compare_models for side-by-side analysis, and find_cheapest for optimization. There are no obvious gaps; agents can perform all typical cost-related tasks from exploration to decision-making without dead ends.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Connect MCP clients to 2,000+ AI models without managing provider API keys.
Unlock the power of real-time cryptocurrency data with our Crypto Price Insights MCP server.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceLive LLM pricing as an MCP server. Ask Claude or any MCP client 'how much does this prompt cost?' and get real numbers from a hand-checked pricing table for every major LLM.MIT
- AlicenseAqualityFmaintenanceMCP server that provides AI assistants with real-time, current information about AI models from OpenAI, Anthropic, and Google, including pricing, capabilities, and context windows.4MIT
- AlicenseAqualityAmaintenanceDaily-verified LLM API pricing dataset (44+ models, CN & global) with a hosted MCP server for live price queries and token cost estimation.2CC BY-4.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ankit-aglawe/tokencost-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server