Cost estimation tools as an MCP server for VS Code + Copilot, enabling cost estimation and reporting for agent tasks.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tokencast estimate cost for refactoring 3 modules, medium complexity"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Pre-execution cost estimation for LLM agent workflows. Get a cost estimate before running any agent task, then let tokencast learn from actuals to improve accuracy over time.
Available as a Claude Code plugin (recommended — one command delivers everything) or as an MCP server for Cursor, VS Code + Copilot, and Windsurf.
Install tokencast as a Claude Code plugin — delivers the MCP server, calibration hooks, and estimation skill in two commands:
/plugin marketplace add krulewis/tokencast
/plugin install tokencast@tokencastThe first command registers the tokencast marketplace. The second installs the plugin from it.
Prerequisites:
uvmust be installed for the MCP server to function. Install with:curl -LsSf https://astral.sh/uv/install.sh | sh
This delivers:
MCP server (estimate_cost, get_calibration_status, get_cost_history, report_session, report_step_cost)
Calibration hooks (auto-learning at session end, mid-session cost warnings, agent timeline tracking)
SKILL.md (estimation algorithm auto-trigger after plans)
Calibration data is stored in ~/.tokencast/calibration/ (global across projects, preserved on uninstall).
Scope options:
--scope user(recommended — installs globally for all projects) or--scope project(per-project only).
Install the package:
pip install tokencastOr with uvx (no install required — runs directly from PyPI):
uvx tokencastConfigure your IDE — replace /path/to/your/project with your actual project path in the config snippets below.
Create or update .cursor/mcp.json in your project root:
{
"mcpServers": {
"tokencast": {
"command": "tokencast-mcp",
"args": [
"--calibration-dir", "/path/to/your/project/calibration",
"--project-dir", "/path/to/your/project"
]
}
}
}Create or update .vscode/mcp.json in your project root:
{
"servers": {
"tokencast": {
"type": "stdio",
"command": "tokencast-mcp",
"args": [
"--calibration-dir", "/path/to/your/project/calibration",
"--project-dir", "/path/to/your/project"
]
}
}
}Add to your Windsurf MCP config:
{
"mcpServers": {
"tokencast": {
"command": "tokencast-mcp",
"args": [
"--calibration-dir", "/path/to/your/project/calibration",
"--project-dir", "/path/to/your/project"
]
}
}
}Full config examples are in docs/ide-configs/.
Once configured, tokencast exposes five MCP tools in your IDE:
Tool | What it does |
| Estimate API cost for a planned task before running it |
| Check whether your estimates are well-calibrated |
| Browse past estimates vs actuals |
| Report actual cost at session end to improve calibration |
| Record the cost of a single pipeline step during a session |
Example — estimate before starting work:
Estimate the cost for: size=M, files=8, complexity=highExample — report actuals after finishing:
Report session cost: actual_cost=4.20Related MCP server: AgentCost MCP Server
tokencast includes opt-out anonymous usage telemetry. It is on by default — data is collected unless you explicitly disable it.
What is collected: session count, mean accuracy ratio, calibrated factor count, client name, framework, tool name, package version. What is NOT collected: project names, file paths, cost amounts, or any personal data.
To disable:
Call the disable_telemetry MCP tool (permanent opt-out, creates ~/.tokencast/no-telemetry)
Pass --no-telemetry to the MCP server command
Set TOKENCAST_TELEMETRY=0 in your environment
Precedence (highest to lowest):
TOKENCAST_TELEMETRY=0 → always disables
TOKENCAST_TELEMETRY=1 → always enables (overrides --no-telemetry and the no-telemetry file)
~/.tokencast/no-telemetry file exists → disables
Default (no flags, no env var) → enabled
To delete your install ID: rm ~/.tokencast/install_id.
Data is sent to PostHog (US region). A random UUID is generated locally as your install ID — it contains no personal information. See the wiki for full details.
Flag | Default | Description |
|
| Where calibration data is stored |
| None | Project root for file measurement |
| Off | Disable anonymous usage telemetry (on by default) |
| Print version and exit |
The Claude Code plugin (recommended) delivers everything in one command. Use this only if you prefer the SKILL.md workflow without the plugin system.
If you use Claude Code and prefer the skill-based (SKILL.md) workflow, you can install tokencast as a Claude Code skill instead:
# Clone the repo (anywhere — it doesn't need to live inside your project)
git clone https://github.com/krulewis/tokencast.git
# Install into your project (quote paths with spaces)
bash tokencast/scripts/install-hooks.sh "/path/to/your-project"Paths with spaces: Always wrap the project path in quotes. Without them the install script will fail on paths like
/Volumes/Macintosh HD2/....
This does three things:
Symlinks the skill into <project>/.claude/skills/tokencast/
Adds a Stop hook for auto-learning at session end
Adds a PostToolUse hook to nudge estimation after planning agents
The SKILL.md workflow is Claude Code-specific. The MCP server works in any MCP-compatible client and is the recommended path for new users.
Infers size, file count, complexity from the plan in conversation
Reads reference files for pricing and token heuristics
Loads learned calibration factors (if any exist)
Computes per-step token estimates using activity decomposition
Applies complexity multiplier, context accumulation (K+1)/2, and cache rates
Splits into Optimistic / Expected / Pessimistic bands
If PR Review Loop is in scope, computes loop cost using geometric decay across N review cycles
Applies calibration correction to Expected band
Records the estimate for later comparison with actuals
Example output:
## tokencast estimate
Change: size=M, files=5, complexity=medium
Calibration: 1.12x from 8 prior runs
| Step | Model | Optimistic | Expected | Pessimistic |
|-----------------------|--------|------------|----------|-------------|
| Research Agent | Sonnet | $0.60 | $1.17 | $4.47 |
| Architect Agent | Opus | $0.67 | $1.18 | $3.97 |
| ... | ... | ... | ... | ... |
| TOTAL | | $3.37 | $6.26 | $22.64 |Band | Cache Hit | Multiplier | Meaning |
Optimistic | 60% | 0.6x | Best case — focused agent work |
Expected | 50% | 1.0x | Typical run |
Pessimistic | 30% | 3.0x | With rework loops, debugging, retries |
Calibration is fully automatic once you report actuals:
0-2 sessions: No correction applied. "Collecting data" status.
3-10 sessions: Global correction factor via trimmed mean of actual/expected ratios (trim_fraction=0.1).
10+ sessions: EWMA with recency weighting. Per-size-class factors activate when a class has 3+ samples.
Outlier filtering: Sessions with actual/expected ratio >3.0x or <0.2x are excluded from calibration.
Calibration data lives in ~/.tokencast/calibration/ (gitignored, local to each user).
from tokencast import estimate_cost, report_session, report_step_cost
from tokencast import get_calibration_status, get_cost_history
# Estimate before running a task
result = estimate_cost(
{"size": "M", "files": 5, "complexity": "medium"},
calibration_dir="./calibration",
)
# Report actuals at session end
report_session({"actual_cost": 4.20}, calibration_dir="./calibration")
# Check calibration health
status = get_calibration_status({}, calibration_dir="./calibration")
# Browse history
history = get_cost_history({"window": "30d"}, calibration_dir="./calibration")
# Report a single step's cost
report_step_cost(
{"step_name": "Research Agent", "cost": 0.85},
calibration_dir="./calibration",
)In Claude Code with SKILL.md installed, you can invoke explicitly:
/tokencast size=L files=12 complexity=high
/tokencast steps=implement,test,qa
/tokencast review_cycles=3
/tokencast review_cycles=0SKILL.md — Skill definition (auto-trigger, algorithm)
references/pricing.md — Model prices, cache rates, step→model map
references/heuristics.md — Token budgets, pipeline decompositions, multipliers
references/examples.md — Worked examples with arithmetic
references/calibration-algorithm.md — Detailed calibration algorithm reference
docs/ide-configs/ — Per-IDE MCP config examples
src/tokencast/ — Core estimation engine (Python package)
src/tokencast_mcp/ — MCP server (Python package)
scripts/
install-hooks.sh — One-time project setup (skill mode)
disable.sh — Remove from project (skill mode)
tokencast-learn.sh — Stop hook: auto-captures actuals (skill mode)
tokencast-track.sh — PostToolUse hook: nudges estimation after plans
sum-session-tokens.py — Parses session JSONL for actual costs
update-factors.py — Computes calibration factors from history
calibration/ — Per-user local data (gitignored)
history.jsonl — Estimate vs actual records
factors.json — Learned correction factors
active-estimate.json — Transient marker for current estimatePipeline step names reflect a default workflow — map your own steps to the closest defaults. Formulas are pipeline-agnostic (see references/heuristics.md)
Heuristics assume typical 150-300 line source files
Calibration requires 3+ completed sessions before corrections activate
Pricing data embedded; check last_updated in references/pricing.md
Multi-session tasks only capture the session containing the estimate
MIT
Permanently disable anonymous telemetry. Creates ~/.tokencast/no-telemetry file. Use this to opt out of usage data collection.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the file creation side effect (~/.tokencast/no-telemetry), the permanence of the action, and clarifies the scope to anonymous telemetry. It doesn't mention reversibility or impact on already collected data, but for a simple opt-out toggle, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two crisp sentences, front-loaded with the primary verb and purpose, with no filler. Every word adds value, including the file path and opt-out context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description fully explains what it does, how it does it (file creation), and when to use it. Further elaboration would be redundant given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is 100% covered (though empty). The description doesn't need to explain param semantics since none exist, and it still clarifies the tool's behavior without them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Permanently disable anonymous telemetry'), identifies the specific resource, and even mentions the side effect of creating a file. This clearly distinguishes it from sibling tools focused on cost estimation and reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use this to opt out of usage data collection' provides explicit when-to-use guidance. No alternatives are needed since sibling tools serve entirely different purposes (cost, calibration, reporting), making the intended use unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate Anthropic API token costs for a development plan before execution
| Name | Required | Description | Default |
|---|---|---|---|
| size | Yes | ||
| files | Yes | ||
| steps | No | ||
| language | No | ||
| complexity | Yes | ||
| file_paths | No | ||
| project_type | No | ||
| review_cycles | No | ||
| avg_file_lines | No | ||
| parallel_groups | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states the tool estimates costs, implying a non-mutating calculation, but does not reveal whether it makes network calls, how the estimate is computed, what the return format is, or any side effects. For a tool with 10 parameters, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of under 15 words. It contains no fluff and efficiently communicates the core purpose, achieving high clarity per word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (10 params, no output schema, no annotations), yet the description provides only a minimal one-sentence purpose. It gives no information about expected inputs, output structure, or behavioral nuances, making it wholly inadequate for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not explain any of the 10 parameters. Required fields like size, files, and complexity are not mentioned, and even the enums (XS/S/M/L, low/medium/high) are left undocumented. The description fails to compensate for the schema's lack of semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Estimate') and identifies the resource ('Anthropic API token costs') and context ('for a development plan before execution'). This clearly distinguishes it from sibling tools that report or record costs, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before execution' provides clear contextual guidance for when to use this tool, implying it is for planning rather than after-the-fact reporting. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get calibration health and accuracy metrics for cost estimates
| Name | Required | Description | Default |
|---|---|---|---|
| window | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. As a 'get' operation, it implies read-only behavior, and 'health and accuracy metrics' adds some context. But it does not mention data format, side effects, or prerequisites beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and object. Every word contributes meaning, and there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description leaves key details undefined: the meaning of the 'window' parameter, the exact nature of the returned metrics, and any behavioral caveats. While the tool is simple, the missing parameter documentation makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter ('window') with 0% description coverage, and the description does not mention it at all. The agent has no way to know what 'window' accepts or means, making this a critical gap that the description fails to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('calibration health and accuracy metrics for cost estimates'), clearly distinguishing this from sibling tools like estimate_cost or get_cost_history. It immediately conveys the tool's purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: one would call this to review calibration status. However, there is no explicit guidance on when to use it versus alternatives, nor any exclusion criteria. It lacks clear context about the intended scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query historical cost estimation records and actuals
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | ||
| include_outliers | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Query' (implying a read operation) but does not disclose return format, data scope, cost implications, or any side effects. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, achieving good conciseness. However, it is so brief that it sacrifices informative content, though it does front-load the core purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of annotations or output schema, the description is incomplete. It does not explain what the history records include, how the 'window' parameter behaves, or what 'include_outliers' does, leaving an agent without enough context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters ('window' and 'include_outliers') with no descriptions, and schema description coverage is 0%. The description does not explain or even mention these parameters, leaving their meaning and valid values completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Query' and identifies the resource as 'historical cost estimation records and actuals.' It clearly distinguishes itself from sibling tools like 'estimate_cost' (which estimates) and 'report_step_cost' (which reports individual costs), positioning this as the tool for historical queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention typical use cases, prerequisites, or exclusions, leaving the agent to infer its role from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report actual session cost to improve future calibration
| Name | Required | Description | Default |
|---|---|---|---|
| turn_count | No | ||
| actual_cost | Yes | ||
| step_actuals | No | ||
| review_cycles_actual | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the action but does not disclose any behavioral traits like whether this is a read-only operation, data transmission, or any side effects. No detail is provided about how the report is stored or used.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words, focusing on the core action and purpose. It is appropriately brief, though it under-specifies details that are penalized in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters, one required, and a nested object, with no output schema or annotations. The description gives no information about required inputs, format, or expected behavior, making it inadequate for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameters. The tool has four parameters including a required actual_cost and a nested step_actuals object, but the description fails to explain their meaning or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Report') and resource ('actual session cost'), and notes the purpose of improving calibration. It doesn't explicitly distinguish from sibling tools like report_step_cost, but the session-level scope provides some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as report_step_cost or estimate_cost. The phrase 'to improve future calibration' hints at a post-session reporting context, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record the cost of a completed pipeline step. Costs accumulate per step and are flushed when report_session is called.
| Name | Required | Description | Default |
|---|---|---|---|
| cost | No | ||
| model | No | ||
| step_name | Yes | ||
| tokens_in | No | ||
| tokens_out | No | ||
| tokens_cache_read | No | ||
| tokens_cache_write | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the burden of behavioral disclosure. It does disclose the accumulation and flushing behavior, which is key context. However, it does not mention whether this is a mutation operation, any side effects, authentication requirements, or what happens on success/failure. The provided behavior is useful but incomplete for a write tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences. The first sentence states the purpose directly, and the second provides critical behavioral context about accumulation and flushing. Every word is necessary, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavioral context (accumulation and flushing) that is not evident from the schema. However, for a tool with 7 parameters, no annotations, and no output schema, it lacks details about parameter usage, required fields, and what happens during execution. It is not completely inadequate but leaves significant gaps in how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 7 parameters with 0% description coverage. The description does not mention any parameter names, meanings, or constraints beyond the generic phrase 'cost of a completed pipeline step.' It fails to explain required parameters (step_name) or the token fields, leaving the agent to infer from names alone. The description adds no value to parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific action: 'Record the cost of a completed pipeline step.' This uses a precise verb ('Record') and identifies the resource ('cost of a completed pipeline step'). It also distinguishes itself from siblings by focusing on per-step cost recording, whereas siblings like estimate_cost and report_session serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that costs accumulate per step and are flushed when report_session is called, implying this tool is for incremental recording before a final session report. This provides clear context for when to use it, though it does not explicitly name alternatives or state when not to use it. The sibling tools (estimate_cost, report_session) are implicitly differentiated by this behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.4disable_telemetryestimate_costget_calibration_statusget_cost_historyreport_sessionreport_step_costEach tool targets a distinct concern: telemetry opt-out, cost estimation, calibration metrics, historical queries, and cost reporting at different granularities. No two tools overlap in purpose or action.
All tool names follow a consistent verb_noun pattern in lowercase snake_case (disable_telemetry, estimate_cost, get_calibration_status, get_cost_history, report_session, report_step_cost). The naming style is uniform and predictable.
Six tools is well-scoped for a cost estimation and calibration server. Each tool contributes a necessary function without redundant or bloated additions.
The toolset covers the essential workflow: estimate costs, report actuals, inspect calibration, and query history. Minor gaps exist (e.g., no way to enable telemetry after disabling, no per-estimate detail retrieval), but they do not break the core usage flow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Budget & cost control for AI agents — per-agent spend caps + rate limits before each call.
Cost-optimized LLM model routing recommendations for autonomous AI agents
Verified cloud cost forecasting for AI agents. AWS, GCP, Azure pricing matrix.
Verified cloud cost forecasting for AI agents. AWS, GCP, Azure pricing matrix.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/krulewis/tokencast'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
