What can you do with this server?

The infra-advisor-mcp server estimates GPU requirements, training/inference costs, and cloud vs. on-prem TCO for AI workloads using deterministic calculators — no LLM arithmetic involved. Workload Analysis – Parse a free-text description (e.g., "customer support chatbot for a 50-person startup") into structured parameters: scale, domain, latency requirements, and daily token volumes. Model Recommendations – Rank open-source and closed-source models for your use case, budget, and quality requirements, with pricing, strengths, and caveats. Training Cost Estimation – Calculate GPU-hours, wall-clock time, and dollar costs for pre-training, full SFT, LoRA/QLoRA fine-tuning, and RL — including recommended parallelism strategy (DDP, FSDP/ZeRO-3, Tensor+Pipeline Parallel). Inference Cost Comparison – Compare monthly costs across cloud API providers and self-hosted options, factoring in quantization (fp8/int8/int4), replica sizing for latency targets, and break-even analysis. Cloud vs. On-prem TCO – Full 1/3/5-year total cost of ownership comparison with a break-even month calculation. On-prem Maintenance Cost – Break down ongoing OpEx: power, cooling, rack/colocation, networking, hardware depreciation, software licenses, and ML staffing (FTE recommendations). Full Report Generation – Run all tools in sequence and produce a comprehensive Markdown report covering all analyses. Follow-up Question Answering – Get concise, calculator-backed answers to specific questions (e.g., "H100s vs A100s for training?") with an inline glossary. Save Reports – Export reports to .md and .html files. List Available GPUs – Browse all GPUs in the database with specs (VRAM, TDP, throughput) and pricing. Check Data Freshness – View last_updated timestamps for all pricing and hardware data. Reload Pricing Data – Refresh YAML data files (GPU specs, cloud pricing, model registry) without restarting the server.

Which integrations are available for this server?

Estimates inference costs using Google Gemini API models (e.g., Gemini 2.0 Flash) and compares them with self-hosted alternatives. Provides cost estimates and hardware sizing for self-hosting Meta's open-source models (e.g., LLaMA 3.1) for inference and training, including cloud vs. on-prem TCO. Estimates inference costs using OpenAI API models (e.g., GPT-4o Mini) and compares them with self-hosted alternatives.

How do I use infra-advisor-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@infra-advisor-mcp Cost estimate for fine-tuning a 7B model on 50B tokens" 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.

infra-advisor-mcp

by yangsong7

Overview Schema Source Related Servers Discussions Admin

Python

Local

infra-advisor-mcp

A Model Context Protocol (MCP) server that estimates GPU requirements, training/inference costs, and cloud-vs-on-prem TCO for AI workloads.

Describe a workload in plain English ("a customer-support chatbot for a 50-person startup", "continual pre-training a 7B model on 50B tokens") and the server returns model recommendations, monthly cost projections, hardware sizing, and a break-even analysis — as structured data or a full Markdown report.

All numbers are produced by deterministic Python calculators (scaling laws, VRAM math, TCO models). No LLM is invoked for the arithmetic, so results are reproducible and auditable. Pricing and hardware specs live in version-controlled YAML.

What it can answer

Which model should I use for this task, scale, and budget? (open-source vs. API)
What will inference cost per month across cloud APIs and self-hosted options?
What does a training run cost (SFT / continual pre-training / pre-training / RL) in GPU-hours, wall-clock time, and dollars?
How do I shard the model across those GPUs? — recommends a parallelism strategy (DDP, FSDP/ZeRO-3, or tensor+pipeline parallel) and degrees from the model footprint, GPU VRAM, and interconnect.
How many GPUs to actually serve the load? — sizes replicas to the daily output volume at the latency target (so a "cheaper" option can't be silently under-provisioned), and models quantization (fp8/int8/int4) shrinking VRAM and lifting throughput.
Cloud or on-prem? — full 1/3/5-year TCO with a break-even month.
What are the ongoing on-prem costs — power, cooling, rack, networking, depreciation, and ML-infra staffing?

Related MCP server: ai-cost-calculator-api

MCP tools

Tool	Purpose
`generate_full_report`	Main entry point. Runs every tool and returns a complete plain-English Markdown report.
`analyze_task`	Parse a free-text description into structured parameters (scale, use case, domain, token volumes).
`recommend_model`	Rank open- and closed-source models for the task.
`estimate_training_cost`	GPU-hours, wall-clock, cost, and sharding strategy (DDP/FSDP/TP+PP) for pretrain / continual-pretrain / SFT / RL.
`estimate_inference_cost`	Monthly cost across API providers and self-hosted options, with break-even, quantization (fp8/int8/int4), and replica sizing for the latency target.
`compare_cloud_vs_onprem`	Cloud vs. on-prem TCO over 1/3/5 years.
`estimate_maintenance_cost`	Detailed on-prem monthly OpEx + staffing.
`generate_followup_answer`	Focused answer to a single follow-up question with an inline glossary.
`save_report`	Write the report (and follow-ups) to `.md` and `.html`.
`list_available_gpus`	List all GPUs in the database with specs and pricing.
`get_data_freshness_info`	Report `last_updated` dates so you can tell if pricing is stale.
`reload_data`	Re-read the YAML data files without restarting the server.

Requirements

Python 3.11+
An MCP client (e.g. Claude Code, or any MCP-compatible host)

Installation

git clone https://github.com/yangsong7/infra-advisor-mcp.git
cd infra-advisor-mcp

python -m venv .venv
source .venv/bin/activate        # Windows: .venv\Scripts\activate

pip install -e ".[dev]"          # drop [dev] if you don't need tests/lint

This installs an infra-advisor console script that runs the MCP server over stdio.

Connecting to an MCP client

Important: an MCP client launches the server in its own environment — it does not inherit the venv you activated in your shell. Always point the client at the absolute path to the infra-advisor script inside your venv, so it works regardless of your PATH.

Get the absolute path:

echo "$(pwd)/.venv/bin/infra-advisor"
# e.g. /Users/you/infra-advisor-mcp/.venv/bin/infra-advisor

Claude Code

claude mcp add infra-advisor -- /absolute/path/to/infra-advisor-mcp/.venv/bin/infra-advisor

Verify it connected:

claude mcp list          # infra-advisor should show as connected

Generic MCP client (JSON config)

Add this to your client's MCP server configuration (e.g. claude_desktop_config.json for Claude Desktop):

{
  "mcpServers": {
    "infra-advisor": {
      "command": "/absolute/path/to/infra-advisor-mcp/.venv/bin/infra-advisor",
      "args": []
    }
  }
}

(If you installed the package into an environment that is on the client's PATH, you can use the bare "infra-advisor" as the command instead.)

Note: after editing any .py file, fully restart the MCP server for changes to take effect. YAML-only edits can be picked up with the reload_data tool — no restart needed.

Usage

Once connected, just talk to your MCP client in natural language. Example prompts:

"Generate a full infrastructure report for a customer-support chatbot serving a 50-person startup."
"We want to continually pre-train a 7B model on 50B tokens of legal text. What does it cost on H100s vs A100s?"
"At 5 million tokens/day, is it cheaper to use the OpenAI API or self-host Llama 3.1 8B?"
"Compare 5-year TCO of 8× H100 on AWS vs buying our own cluster at 70% utilization."

The client will call the relevant tools and return the estimates. Start with generate_full_report for a complete picture, then use generate_followup_answer for focused questions.

Using the calculators directly (Python)

The estimators are plain functions and can be imported without an MCP client:

from infra_advisor.tools.report import generate_full_report

print(generate_full_report("A coding assistant for a 50-person startup"))

Example output

Real output from the tools (abridged where noted). Every figure is computed from the bundled data/ — your numbers will track whatever's in those YAML files.

1. Parse a request — `analyze_task`

Ask: "Customer support chatbot for a 50-person SaaS startup, ~2 million tokens/day, near real-time."

{
  "use_case": "inference_only",
  "domain": "nlp",
  "scale": "startup",
  "quality_requirement": "medium",
  "latency_requirement": "realtime",
  "estimated_daily_input_tokens": 1400000,
  "estimated_daily_output_tokens": 600000,
  "team_ml_expertise": "low",
  "on_prem_preference": false,
  "key_constraints": ["Real-time latency required (<1s response)"],
  "open_questions": [
    "What is your monthly infrastructure budget?",
    "What is your acceptable latency (P50 / P99)?",
    "How many concurrent users or requests do you expect at peak?"
  ]
}

2. Full report — `generate_full_report` (abridged)

generate_full_report(...) returns one Markdown document. Its Executive Summary for the request above:

The five things you need to know before reading the full report:
1. What you're building: Inference Only system for a Startup in the nlp domain. Estimated 1.4M input + 0.6M output tokens per day. 2. Cloud vs. self-host: You're in the middle range where it depends on growth trajectory. Start with cloud APIs, monitor spend, and revisit self-hosting at 3× current volume. 3. Training cost: Not applicable — this is an inference-only workload. 4. Hardware: No hardware purchase recommended at this stage. Use cloud APIs or managed inference providers until monthly spend exceeds ~$5,000. 5. Staffing: A single ML engineer (or 0.5 FTE of an existing engineer) can manage a small self-hosted deployment.

…followed by the scored model shortlist:

Rank	Model	Type	Size	Context Window	Price (In / Out per 1M)	Cost Tier
1	OpenAI GPT-4o Mini	Closed Source	Undisclosed	128,000 tokens	$0.15 / $0.60	Very Low ($)
2	Google Gemini 2.0 Flash	Closed Source	Undisclosed	1,000,000 tokens	$0.03 / $0.17	Very Low ($)
5	Meta LLaMA 3.1 8B	Open Source	8.0B	128,000 tokens	Self-hosted	low (self-hosted) / medium (API)

The full report continues through eight sections — inference cost (cloud API vs self-hosted), training cost, cloud-vs-on-prem TCO with a break-even month, on-prem monthly OpEx, a decision checklist, and next steps — plus a plain-English glossary. A data-staleness banner appears automatically when the bundled prices are >30 days old.

3. Follow-up: training cost — `generate_followup_answer`

Ask: "How much does a QLoRA fine-tune of an 8B model cost on one H100?"

Training type: QLoRA Fine-Tuning (4-bit base + adapters) · Model: 8.0B · Dataset: 50,000,000 tokens

Metric	Value	Plain English
GPU config	1× H100 SXM	Minimum to fit the model in VRAM
Sharding	DDP × 1 GPU	Data Parallel — adapters fit on one GPU
GPU-hours	1	All GPUs × hours each
Wall-clock	~0 days	Real elapsed time

Provider	On-demand	Spot (35% off)
Lambda	$2	$1
AWS	$8	$3
On-prem (power only)	$1	excl. $30,000 hardware

Recommendation: Use spot instances to cut cost ~35%; checkpoint every 30 min. Budget for 3 experimental runs: $9–$25.

(QLoRA needs one GPU because only small adapters are trained — full fine-tuning of the same 8B model reports 8 GPUs / ~216 GB.)

4. Follow-up: self-hosting capacity & quantization

Ask (on a ~300M-tokens/day, realtime workload): "How many GPUs and what monthly cost to self-host an open model in int4 for our volume?"

Cheapest cloud API option: Meta LLaMA 3.1 8B via Groq at $531/month.

Self-hosted options — sized for ~3,125 output tok/s peak (realtime latency), int4 weights:

Model	GPU	Total GPUs	Serving Topology	Cloud GPU/mo	On-prem/mo	Break-even vs API
Meta LLaMA 3.1 8B	RTX 4090	4	Single GPU × 4	$1,008	$578	Never
Mistral Mixtral 8x7B	RTX 4090	8	TP=4 × 2	$2,016	$1,155	Never
Meta LLaMA 3.1 8B	A100 80GB SXM	4	Single GPU × 4	$3,715	$554	Never

Recommendation: Consider managed inference (Meta LLaMA 3.1 8B) unless you have ML-ops expertise to self-host.

This shows the two newest levers working together: GPUs are sized to the load (4 replicas to sustain the peak token rate), int4 shrinks each replica, and the tool is honest that at this volume the $531/mo managed API beats owning hardware ("Never" breaks even).

Keeping data current

All pricing and hardware data lives in version-controlled YAML under src/infra_advisor/data/:

File	Holds	Authoritative for
`gpu_specs.yaml`	GPU specs (VRAM, TDP, buy price, MFU, inference throughput), `onprem_overhead`, `planning` defaults, and fallback cloud rates	hardware specs, on-prem costs
`cloud_pricing.yaml`	AWS/GCP/Azure GPU instance rates, `reserved_discounts`, `egress`	cloud GPU-hour rates (overlaid onto `gpu_specs` at load time), committed-use discounts
`model_registry.yaml`	open/closed-source model catalog, managed `inference_providers`	model + API pricing

Each entry carries a last_updated date; reports show a staleness warning when data is older than 30 days, and the get_data_freshness_info tool lists every date.

The refresh loop

Run the relevant sync script (see below).
Review the changes — for model/API pricing this is mandatory (scrapers can misread a page).
Set last_updated to today on anything you accept.
Reload — call the reload_data MCP tool (or infra_advisor.data_loader.reload_all()); the YAML loaders are cached, so changes aren't picked up until you do. No server restart needed for YAML-only edits.

# Cloud GPU rates → cloud_pricing.yaml (which the calculators read via gpu_specs overlay)
python scripts/sync_cloud_pricing.py --auto          # --auto writes without the confirm prompt
python scripts/sync_cloud_pricing.py --provider aws  # one provider

# API / model pricing → writes pricing_review.md for you to verify; NEVER edits the registry
python scripts/sync_provider_pricing.py

# New open-source models → prints suggestions; NEVER edits the registry
python scripts/sync_models.py --min-downloads 500000

A GitHub Action (.github/workflows/sync-pricing.yml) runs all three Mondays at 9am UTC and opens a PR if data/ changed — review it carefully before merging.

Cloud-sync credentials

The cloud fetchers use official APIs and skip cleanly when credentials are absent (so the Action still runs — Azure needs no credentials):

Provider	Requirement	How
Azure	none	Public Retail Prices API
AWS	`boto3` + AWS credentials	`pip install -e ".[sync]"`, then standard AWS creds (`AWS_ACCESS_KEY_ID` / `AWS_SECRET_ACCESS_KEY`, IAM `pricing:GetProducts`). Uses the Price List Query API.
GCP	`GCP_BILLING_API_KEY` env var	A Cloud Billing Catalog API key. GCP machine prices are reassembled from component SKUs (GPU + vCPU + RAM); a price is emitted only if every component resolves, otherwise that instance is skipped.

GCP figures are assembled from component SKUs and should be verified against the console — SKU descriptions occasionally change. For CI, set AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and GCP_BILLING_API_KEY as repository secrets; the model/API price scraper remains review-only by design.

Development

pytest                 # run the test suite
ruff check src/ tests/ # lint

Tests split into pure-calculator unit tests (tests/test_calculators.py, no I/O) and full-stack integration tests against the real YAML (tests/test_tools.py).

Architecture

src/infra_advisor/
├── server.py        # FastMCP entry point — registers all @mcp.tool()s
├── constants.py     # shared time-base constants (DAYS/HOURS per month)
├── data_loader.py   # lru_cache YAML loaders; reload_all() clears caches
├── glossary.py      # plain-English term definitions (report + follow-up)
├── data/            # gpu_specs / model_registry / cloud_pricing YAML
├── calculators/     # pure math, no I/O (compute, memory, tco)
└── tools/           # MCP tool implementations (call calculators + data)

Data flow: server.py → tools/ (calls calculators + data_loader) → calculators/ (pure math) + data/ YAML.

Design invariant: calculators never import from tools/ or data_loader — they receive specs as plain dict arguments. See CLAUDE.md for deeper contributor notes.

A note on accuracy

These are directional estimates for planning, not precise budgets. Actual costs vary by region, negotiated rates, model architecture, serving stack, and utilization. Always validate with a small paid pilot before committing to infrastructure.

Contact

Questions or issues: sendoh.yang@gmail.com

License

MIT

Available Tools

12 tools

analyze_taskA

Parse a free-text task description into structured parameters.

Use this first to understand what the user needs before calling other tools. Returns scale, use_case, domain, latency requirements, and estimated token volumes.

ParametersJSON Schema

Name	Required	Description	Default
`task_description`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`use_case`	Yes
`domain`	Yes
`scale`	Yes
`quality_requirement`	Yes
`latency_requirement`	Yes
`estimated_daily_input_tokens`	Yes
`estimated_daily_output_tokens`	Yes
`estimated_daily_images`	No
`training_data_tokens`	Yes
`budget_usd_per_month`	Yes
`team_ml_expertise`	Yes
`on_prem_preference`	Yes
`summary`	Yes
`key_constraints`	Yes
`open_questions`	Yes

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses that returns structured data including scale, use_case, domain, latency, and token volumes. While no annotations are present, the description is transparent about the tool's output and purpose, though it does not mention safety or side effects (likely benign).

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?

Three focused sentences: first on action, second on usage positioning, third on output. No redundant words; perfectly front-loaded.

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 presence of an output schema, the description's list of returned fields is sufficient. It provides a complete picture for the agent to understand input and output expectations.

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?

The input parameter 'task_description' has no schema description, but the tool description explains it as 'free-text task description,' adding meaning beyond the schema. It compensates for the 0% coverage with clear context.

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 parses free-text into structured parameters, with specific verb 'Parse' and resource 'free-text task description'. It distinguishes from sibling tools like 'compare_cloud_vs_onprem' by positioning itself as an initial analysis step.

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?

Explicitly advises to 'Use this first to understand what the user needs before calling other tools,' giving clear guidance on when to invoke it within a workflow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compare_cloud_vs_onpremA

Compare total cost of ownership: cloud vs on-prem over 1/3/5 year horizons.

Returns cumulative costs, break-even month, and a recommendation.

ParametersJSON Schema

Name	Required	Description	Default
`gpu_key`	No	GPU type (h100_sxm, a100_80gb_sxm, h200_sxm, rtx_4090, l40s).	h100_sxm
`gpu_count`	No	Number of GPUs in the cluster.
`utilization`	No	Expected GPU utilization (0.0-1.0). 0.7 = 70%.
`preferred_cloud`	No	Cloud provider for comparison (aws, gcp, azure).	aws
`years`	No	Comparison horizon in years.

Output Schema

ParametersJSON Schema

Name	Required	Description
`gpu_type`	Yes
`gpu_count`	Yes
`utilization_pct`	Yes
`onprem_capex_usd`	Yes
`onprem_monthly_opex_usd`	Yes
`cloud_monthly_usd`	Yes
`cloud_provider`	Yes
`cloud_committed_monthly_usd`	No
`cloud_committed_term`	No
`cloud_committed_discount_pct`	No
`break_even_months`	Yes
`cumulative_cost_year_1`	Yes
`cumulative_cost_year_3`	Yes
`cumulative_cost_year_5`	Yes
`recommendation`	Yes
`onprem_monthly_breakdown`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses the tool's purpose and return values, but does not mention side effects, authentication needs, rate limits, or data sources. The behavior is clear but not deeply transparent.

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 two concise sentences with no wasted words. It front-loads the core purpose and immediately specifies the return values, making it efficient for agent parsing.

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 presence of an output schema and fully described parameters, the description is complete enough. It notes the key outputs (cumulative costs, break-even, recommendation). However, it could mention assumptions or data freshness for a slight improvement.

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?

Input schema coverage is 100%, so the schema already provides full parameter descriptions. The tool description adds no extra meaning beyond what the schema offers, thus meeting baseline expectations.

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 it compares total cost of ownership between cloud and on-prem, over specific horizons (1/3/5 years), and returns cumulative costs, break-even month, and a recommendation. This verb+resource combination is specific and distinguishes it from sibling tools like estimate_inference_cost or estimate_training_cost.

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 the tool is used when needing a TCO comparison, but it does not explicitly state when to use or avoid it, nor does it mention alternatives. It lacks when-not-to-use guidance or prerequisites, leaving the agent to infer appropriate context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

estimate_inference_costA

Compare cloud API and self-hosted inference costs for a given token volume.

Returns monthly cost for all major API providers and self-hosted options, with break-even analysis. Self-hosted sizing accounts for two levers:

quantization (fp8/int8/int4) shrinks model VRAM (so fewer GPUs per replica) and lifts throughput, at a small quality cost.
the latency target sizes how many replicas are needed to serve the daily output volume at peak load — so an option is only "cheaper" if it can actually keep up. Each self-hosted option reports per-replica topology, replicas_needed, and total GPUs.

ParametersJSON Schema

Name	Required	Description	Default
`daily_input_tokens`	Yes	Average input tokens per day.
`daily_output_tokens`	Yes	Average output tokens per day.
`daily_images`	No	Number of images processed per day (for vision/multimodal workloads). When non-zero, image costs are added to the monthly bill for vision-capable models.
`use_case`	No		general
`quality`	No		high
`latency`	No	Target responsiveness (realtime/near_realtime/batch/offline) — drives replica sizing.	near_realtime
`quantization`	No	Self-hosted serving precision (none/fp8/int8/int4).	none

Output Schema

ParametersJSON Schema

Name	Required	Description
`daily_input_tokens`	Yes
`daily_output_tokens`	Yes
`daily_images`	Yes
`monthly_input_tokens`	Yes
`monthly_output_tokens`	Yes
`quantization`	Yes
`required_throughput_tps`	Yes
`api_options`	Yes
`self_hosted_options`	Yes
`cheapest_api`	Yes
`cheapest_self_hosted`	Yes
`recommendation`	Yes

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description takes full burden. It details self-hosted sizing logic involving quantization and latency, and what returns are provided (break-even, topology, replicas). No contradictions.

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?

Description is a single paragraph with front-loaded purpose. It is informative but could be more structured (e.g., bullet points). No wasted sentences.

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 tool complexity and existence of an output schema (not shown), description adequately explains return values and key levers. It covers self-hosted sizing and break-even analysis sufficiently.

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?

Schema coverage is 71%; description adds meaningful context for quantization and latency (e.g., 'shrinks model VRAM' and 'latency target sizes replicas'), but does not elaborate on required parameters beyond schema.

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?

Description clearly states it compares cloud API and self-hosted inference costs for a given token volume, and distinguishes from siblings like estimate_training_cost or estimate_maintenance_cost by focusing on inference cost estimation specifically.

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?

Usage is implied but not explicitly guided: no statements on when to use vs alternatives like compare_cloud_vs_onprem. The description focuses on what it does, not when to invoke it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

estimate_maintenance_costA

Estimate all ongoing on-prem operational costs for a GPU cluster.

Includes power, cooling, rack/colocation, networking, labor, depreciation, and recommended ML infra headcount.

ParametersJSON Schema

Name	Required	Description	Default
`gpu_key`	No	GPU type key.	h100_sxm
`gpu_count`	No	Number of GPUs.
`utilization`	No	Expected GPU utilization (0.0-1.0).
`kwh_rate`	No	Electricity cost per kWh. Defaults to US average ($0.12).

Output Schema

ParametersJSON Schema

Name	Required	Description
`gpu_type`	Yes
`gpu_count`	Yes
`utilization_pct`	Yes
`power_usd_month`	Yes
`cooling_usd_month`	Yes
`rack_colocation_usd_month`	Yes
`networking_usd_month`	Yes
`maintenance_labor_usd_month`	Yes
`hardware_depreciation_usd_month`	Yes
`software_licenses_usd_month`	Yes
`total_monthly_opex_usd`	Yes
`recommended_ml_infra_fte`	Yes
`estimated_ml_infra_salary_usd_year`	Yes
`hardware_capex_usd`	Yes
`depreciation_years`	Yes
`recommended_refresh_years`	Yes
`total_annual_opex_usd`	Yes
`total_3yr_tco_usd`	Yes
`notes`	Yes

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It lists included cost categories but does not disclose any behavioral traits (e.g., whether the estimation is read-only, if it requires permissions, or if it triggers any side effects). The description is adequate but not detailed.

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 concise with two short sentences. It front-loads the primary purpose and then lists what is included. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description does not need to explain return values. It covers the tool's purpose, scope, and inputs adequately. All parameters are described in the schema.

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 coverage is 100% (all 4 parameters described). The description adds context about cost categories but does not enhance understanding of individual parameters beyond the schema. Baseline 3 applies.

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 estimates 'all ongoing on-prem operational costs for a GPU cluster' and enumerates cost categories (power, cooling, etc.). This distinguishes it from sibling tools like 'estimate_inference_cost' and 'estimate_training_cost', which focus on compute costs for specific tasks.

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?

No explicit guidance is given on when to use this tool versus alternatives. The context implies it is for on-prem maintenance cost estimation, but there is no 'when-not-to-use' or comparison to siblings like 'compare_cloud_vs_onprem'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

estimate_training_costA

Estimate GPU-hours, wall-clock time, cost, and sharding strategy for a training run.

Covers pre-training, continual pre-training, full SFT, parameter-efficient fine-tuning (LoRA / QLoRA), and RL. Uses Chinchilla scaling laws for pre-training compute estimates. LoRA/QLoRA train only small adapters, so they need far less VRAM and fewer GPUs than full fine-tuning (QLoRA quantizes the base to 4-bit). Also returns a recommended parallelism strategy (DDP / FSDP-ZeRO-3 / tensor+pipeline parallel) based on model footprint, GPU VRAM, and interconnect.

ParametersJSON Schema

Name	Required	Description	Default
`model_params_b`	Yes	Model size in billions of parameters (e.g. 7 for 7B).
`training_type`	No	One of pretrain, continual_pretrain, sft, lora, qlora, rl.	sft
`dataset_tokens`	No	Number of training tokens. Uses sensible defaults if omitted.
`gpu_key`	No	GPU type key (h100_sxm, a100_80gb_sxm, h200_sxm, rtx_4090, l40s).	h100_sxm
`num_gpus`	No	Override GPU count. Auto-calculated from VRAM if omitted.

Output Schema

ParametersJSON Schema

Name	Required	Description
`training_type`	Yes
`model_params_b`	Yes
`dataset_tokens`	Yes
`gpu_type`	Yes
`gpu_count`	Yes
`mfu`	Yes
`total_flops_exaflops`	Yes
`effective_gpu_hours`	Yes
`wall_clock_days`	Yes
`vram_required_gb`	Yes
`cloud_costs`	Yes
`onprem_cost_usd`	Yes
`onprem_capex_usd`	Yes
`chinchilla_optimal_tokens`	Yes
`parallelism_strategy`	Yes
`parallelism_degrees`	Yes
`parallelism_framework`	Yes
`notes`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description bears full burden. It mentions using Chinchilla scaling laws and explains LoRA/QLoRA behavior. But it omits limitations, assumptions, or accuracy notes, leaving gaps in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a dense paragraph covering many points. It is front-loaded with the core purpose but could be more structured (e.g., bullet points) for better readability. Some sentences could be merged.

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 presence of an output schema (not shown but known from context), the description does not need to detail return values. It covers training types, algorithm, and parallelism recommendation. Missing explicit prerequisites or context requirements, but overall sufficient for an estimation tool.

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 coverage is 100% and describes all parameters well. The description adds minor value (e.g., 'sensible defaults' for dataset_tokens, enumeration of GPU types) but doesn't significantly extend beyond schema.

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 estimates GPU-hours, wall-clock time, cost, and sharding strategy for training runs, with specific verb 'estimate' and resource 'training cost'. It lists covered training types and distinguishes from sibling tools like estimate_inference_cost and estimate_maintenance_cost.

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 explains when to use the tool (for various training runs) and differentiates between training types (e.g., LoRA/QLoRA vs full fine-tuning). However, it does not explicitly state when not to use it or direct to alternatives, though sibling tools provide implicit differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_followup_answerA

Answer a specific follow-up question with calculator-backed data and an inline glossary.

Use this instead of generate_full_report when the user asks a focused follow-up (e.g. "what's the training cost?", "cloud vs on-prem for this?", "which GPU?"). Returns a concise answer: direct response, data table, recommendation, and jargon glossary.

ParametersJSON Schema

Name	Required	Description	Default
`original_query`	Yes	The original task description (provides context for scale, domain, token volumes, and constraints).
`followup_question`	Yes	The specific follow-up question to answer.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses that the answer is 'calculator-backed' (implies computation) and returns specific components. However, it does not explicitly mention idempotency, permission requirements, or side effects. Still, the description gives a good overview of behavior without hiding critical traits.

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?

Four sentences, each serving a purpose: main function, usage guideline, examples, return components. No redundant text, well-structured and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the moderate complexity (two string parameters, output schema exists), the description covers when to use, what to expect, and differentiates from sibling tools. It is complete enough for an agent to correctly select and invoke the 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?

Schema coverage is 100% with descriptions for both parameters. The tool description adds meaning by clarifying that the followup_question should be focused and provides examples. This goes beyond the schema by giving usage context, though the schema already adequately describes parameters.

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?

Description clearly defines that the tool answers specific follow-up questions with calculator-backed data and an inline glossary. It explicitly distinguishes itself from generate_full_report by stating when to use this tool instead, and lists the components of the return (direct response, data table, recommendation, jargon glossary).

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?

Explicitly states when to use: 'when the user asks a focused follow-up' and provides concrete examples like 'what's the training cost?'. Also says to use generate_full_report instead for full reports, giving clear guidance on alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_full_reportA

Generate a comprehensive markdown infrastructure report for any task.

This is the main entry point. Runs all tools in sequence and returns a complete report covering: task analysis, model recommendations, inference costs, training costs (if relevant), cloud vs on-prem TCO, and maintenance costs.

ParametersJSON Schema

Name	Required	Description	Default
`task_description`	Yes	Plain English description of the task or use case.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description discloses sequential execution and report coverage, but omits potential side effects or execution time.

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?

Two sentences, no wasted words; first sentence states action, second elaborates on content.

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?

Complete enough given output schema exists; covers purpose, scope, and composition; could mention it is a heavy operation.

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 coverage is 100% and parameter description in schema already clarifies 'Plain English description'; tool description adds no extra semantic value.

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?

Description states 'Generate a comprehensive markdown infrastructure report' and clarifies it runs all tools in sequence, distinguishing it from sibling tools that are individual components.

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?

Explicitly labeled 'main entry point', implying use for full reports, but does not explicitly state when to avoid it, e.g., for partial analysis.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_data_freshness_infoA

Return last_updated timestamps for all data entries.

Use this to check if pricing data is stale before relying on estimates.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description only states it returns timestamps. Does not disclose if it requires authentication, rate limits, or side effects. For a read-only operation, the behavior is implied but not explicit.

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?

Two short sentences: first states what it does, second gives usage guidance. No unnecessary words, front-loaded with purpose.

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 and the presence of output schema, the description covers purpose and use case. Could add a note about being read-only or safe to call frequently, but overall adequate.

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?

No parameters in input schema, so description adds value by explaining the output (timestamps) and use case. Schema coverage is 100%, baseline is 3, but the description provides meaningful context beyond the empty schema.

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 'Return' and the resource 'last_updated timestamps for all data entries', distinguishing this tool from siblings like estimate costs or analysis.

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?

Explicitly says 'Use this to check if pricing data is stale before relying on estimates', providing a specific use case. Lacks explicit when-not-to-use or alternatives, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_available_gpusA

List all GPU types in the database with specs and pricing.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It indicates a read operation ('list') but does not explicitly state that it is safe, idempotent, or free of side effects. For a listing tool, this is adequate but not rich—it lacks details on authentication or data freshness.

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 a single, well-structured sentence that front-loads the action ('List all GPU types') and adds context ('with specs and pricing'). It is concise and contains no unnecessary words.

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 that the tool has no parameters and an output schema exists, the description is mostly complete. It clearly states what is returned. However, it could mention that the list is unfiltered (all GPUs) and possibly include note about sorting or pagination, but overall it is sufficient.

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?

There are zero parameters, so the baseline is 4. The description adds no parameter-specific meaning, but none is needed. It correctly implies the tool returns all GPUs without filters.

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 lists all GPU types in the database with specs and pricing, which is a specific verb-resource pair. It distinguishes itself from sibling tools that focus on analysis, estimation, or reporting (e.g., estimate_training_cost, compare_cloud_vs_onprem).

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 the tool is used when the user wants to see available GPU options, but it does not provide explicit guidance on when to use it versus alternatives like compare_cloud_vs_onprem or recommend_model. No exclusions or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

recommend_modelB

Recommend ranked open-source and closed-source models for a task.

Pass parameters from analyze_task output for best results. Returns up to 8 ranked models with pricing, strengths, and caveats.

ParametersJSON Schema

Name	Required	Default
`use_case`	No	inference_only
`domain`	No	general
`scale`	No	startup
`quality`	No	high
`latency`	No	near_realtime
`on_prem_preference`	No
`budget_usd_per_month`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior3/5

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 states the return includes ranked models with pricing, strengths, and caveats, implying a read-only operation. However, it does not explicitly mention safety, rate limits, or any potential side effects, leaving some ambiguity.

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 extremely concise with three sentences, each delivering distinct value: purpose, usage tip, and output summary. No extraneous words, and the most critical information appears first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (7 parameters, no annotations) and the presence of an output schema, the description lacks parameter explanations. It does provide a usage link to 'analyze_task', partially compensating. Still, the agent would need to infer parameter semantics from names, which is a significant gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

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 explain the 7 parameters (use_case, domain, scale, etc.) beyond passing them from 'analyze_task'. The agent must infer meanings from parameter names alone, which is insufficient for correct invocation.

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 recommends ranked open-source and closed-source models for a task, specifying the verb 'recommend', resource 'models', and scope 'open-source and closed-source'. This distinguishes it from sibling tools like 'analyze_task' (analyzes task) and 'compare_cloud_vs_onprem' (compares hosting).

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 advises passing parameters from 'analyze_task' output for best results, providing a context for use. However, it does not explicitly state when not to use this tool or mention alternatives like 'compare_cloud_vs_onprem' or 'estimate_inference_cost' that might be more appropriate for specific use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reload_dataA

Reload all YAML data files from disk without restarting the server.

Call this after running sync scripts to pick up updated pricing.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the key behavior—reloading data from disk without restarting—and mentions it picks up updated pricing. However, it does not detail side effects (e.g., whether in-memory state is cleared, if it is safe for concurrent access, or any prerequisites). This is adequate for a simple reload tool but lacks depth.

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?

Two sentences long, front-loaded with the core action, and every word adds value. No wasted text.

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?

The tool is simple with no parameters and an output schema that likely documents return values. The description covers purpose and usage context adequately. It could mention if it requires special permissions or if it is a non-destructive operation, but overall it is sufficiently complete for its complexity.

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?

The tool has zero parameters, and the input schema is an empty object with 100% coverage. Per the rule for 0 parameters, baseline is 4. The description does not need to add parameter details, and it does not mislead.

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?

Description clearly states it reloads all YAML data files from disk without restarting the server. The verb 'reload' and resource 'YAML data files' are specific, and the description implicitly distinguishes this administrative tool from the analytical sibling tools (e.g., analyze_task, compare_cloud_vs_onprem).

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?

Explicit guidance is given: 'Call this after running sync scripts to pick up updated pricing.' This provides a clear use case and context. It does not explicitly state when not to use, but the guidance is sufficient for the tool's purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

save_reportA

Save the final report (and any follow-ups) to .md and .html files.

Call this when the user is satisfied with the report — this is the explicit finalize action. Pass all follow-up answers accumulated during the session.

ParametersJSON Schema

Name	Required	Description	Default
`report_content`	Yes	Main report markdown from generate_full_report.
`followups`	No	Follow-up answer strings from generate_followup_answer, in order.
`filename`	No	Base filename without extension. Auto-generated from timestamp + slug if omitted.
`output_dir`	No	Directory to write files into (created if needed). Defaults to "reports/".	reports

Output Schema

ParametersJSON Schema

Name	Required	Description
`md_path`	Yes
`html_path`	Yes
`filename_stem`	Yes
`saved_at`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It mentions saving to .md and .html files and that output_dir is 'created if needed', but does not disclose what happens if files already exist (overwrite? append?), any authentication requirements, or possible side effects.

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 concise: two sentences with the main action front-loaded. Every sentence adds value with no filler.

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?

The tool has an output schema (though not shown), so the description need not explain return values. It covers the core functionality adequately, but could mention what the tool returns (e.g., success confirmation or file paths).

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 documents all parameters well. The description adds minor context by mentioning 'Pass all follow-up answers', but does not significantly extend beyond the schema descriptions. Baseline 3 is appropriate.

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 action ('Save') and the resources (final report and follow-ups to .md and .html files). It also implicitly distinguishes itself from sibling tools like generate_full_report and generate_followup_answer, which focus on generation rather than saving.

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 tells when to call the tool ('when the user is satisfied with the report — this is the explicit finalize action') and what to pass ('Pass all follow-up answers accumulated during the session'). It does not explicitly state when not to use it, but the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

12 tool updatesv0.1.0Jun 13, 2026
- First observedanalyze_task
- First observedcompare_cloud_vs_onprem
- First observedestimate_inference_cost
- First observedestimate_maintenance_cost
- First observedestimate_training_cost
- First observedgenerate_followup_answer
- First observedgenerate_full_report
- First observedget_data_freshness_info
- First observedlist_available_gpus
- First observedrecommend_model
- First observedreload_data
- First observedsave_report

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-06-13 10:40 across 12 tools

Disambiguation5/5

Each tool has a clearly distinct purpose, from task analysis to cost estimation and report generation. No overlapping functionalities; descriptions clearly differentiate between inference cost, maintenance, training, and comparison tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., analyze_task, estimate_inference_cost, generate_full_report). No mixing of conventions or vague verbs.

Tool Count5/5

With 12 tools, the server covers the full lifecycle of infrastructure planning without being bloated. Each tool serves a necessary function, and the count is ideal for the domain.

Completeness5/5

The tool set comprehensively addresses the domain: task analysis, model recommendation, inference/training/maintenance cost estimation, TCO comparison, data freshness checks, and report generation/saving. No obvious gaps for the stated purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

OptimToken A
io.github.OptimNow
Compare LLM API pricing, estimate workload costs, and benchmark cloud compute. By OptimNow.
AI & Machine Learning Cloud Platforms Finance
1
Octura Solutions Site Tools C
com.octurasolutions
Deterministic Odoo ERP calculators: implementation cost, ROI, TCO, tax, payroll, inventory.
ERP Systems Finance
301
scenariosim-mcp A
io.github.inity13
Deterministic what-if & scenario simulation for AI agents: projections, sensitivity & break-even.
Finance Agent Orchestration
611
IntegrityPulse FinOps
io.github.maryadawson-code
Verified cloud cost forecasting for AI agents. AWS, GCP, Azure pricing matrix.
Cloud Platforms Finance AI & Machine Learning
2

Related MCP Servers

atom-mcp-server
AI & Machine Learning Search Finance
A7OM-AI
A
license
A
quality
D
maintenance
Global price benchmarking for AI inference across 2,600+ SKUs from 47 vendors. Query live pricing, market indexes, and model specs via 8 tools. Free tier available.
Updated 3 months ago (2026-06-23 07:47 UTC)
8
78 npm
MIT
ai-cost-calculator-api
AI & Machine Learning Developer Tools Finance
lazymac2x
F
license
Not graded
quality
D
maintenance
Enables AI cost calculation, comparison, and optimization across major providers like Anthropic, OpenAI, Google, Meta, and Mistral. Supports cost estimation, budget-aware model finding, and token estimation through a simple API and MCP integration.
Updated 5 months ago (2026-04-11 00:57 UTC)
-
@compute-finance/mcp
AI & Machine Learning Finance
compute-finance
A
license
A
quality
A
maintenance
Provides real-time AI compute pricing and cost analysis across LLM providers, enabling session cost tracking, model price comparisons, and historical data queries.
Updated 3 days ago (2026-09-18 12:54 UTC)
22
250 npm
MIT
chimeraforge
AI & Machine Learning Monitoring Developer Tools
Sahil170595
A
license
A
quality
A
maintenance
LLM deployment planner: given a model and a GPU, answers will it fit, will it hit your SLO, and what will it cost. Sizes VRAM and KV-cache from the model's real architecture, and labels every number measured, estimated, or unknown.
Updated 6 days ago (2026-09-15 21:58 UTC)
5
735 PyPI
2
MIT

infra-advisor-mcp

What it can answer

MCP tools

Requirements

Installation

Connecting to an MCP client

Claude Code

Generic MCP client (JSON config)

Usage

Using the calculators directly (Python)

Example output

1. Parse a request — analyze_task

2. Full report — generate_full_report (abridged)

3. Follow-up: training cost — generate_followup_answer

4. Follow-up: self-hosting capacity & quantization

Keeping data current

The refresh loop

Cloud-sync credentials

Development

Architecture

A note on accuracy

Contact

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

1. Parse a request — `analyze_task`

2. Full report — `generate_full_report` (abridged)

3. Follow-up: training cost — `generate_followup_answer`