Provides tools for querying cost and optimization data from Google Kubernetes Engine (GKE) clusters, including cost breakdowns, per-pod costs, and actionable savings recommendations.
Enables analysis of Kubernetes clusters across multiple providers, offering cost summaries, rightsizing recommendations, HPA, storage, and node pool optimization tools.
The Cost Engineer for Kubernetes
KubeOpt analyzes your Kubernetes clusters, identifies cost optimization opportunities, and generates actionable implementation plans with copy-paste kubectl commands.
Works with Azure AKS, AWS EKS, and Google GKE.
Connects to your cloud provider APIs and Kubernetes clusters
Runs 16 optimization algorithms (rightsizing, HPA, storage, networking, node pools, anomaly detection)
Calculates actual vs optimal costs with specific dollar savings per resource
Generates a 3-week implementation plan with kubectl commands ready to execute
Dashboard with cost breakdowns, workload analysis, and optimization scores
Related MCP server: Kubernetes + Prometheus SRE MCP Server
Run a Kubernetes cost scan on every pull request or on a schedule. The action posts a savings summary as a PR comment (upserted on re-runs) and writes results to the GitHub Step Summary.
What you get on each PR:
## KubeOpt Cost Scan — 2026-04-27
| Cluster | Provider | Monthly Spend | Savings Available |
|------------------|----------|---------------|-------------------|
| prod-eks-us-east | AWS | $4,120 | $890/mo |
| staging-aks-weu | Azure | $1,340 | $210/mo |
**Total potential savings: $1,100/mo**
<details>
<summary>Top opportunities</summary>
1. $540/mo — prod-eks-us-east — Rightsize 6 over-provisioned node groups
2. $350/mo — prod-eks-us-east — Enable HPA on 4 deployments with static replicas
3. $210/mo — staging-aks-weu — Remove 3 idle nodes outside business hours
</details>Setup — two steps:
1. Add secrets (Settings → Secrets and variables → Actions):
Secret | Value |
| URL of your KubeOpt instance (e.g. |
| KubeOpt username |
| KubeOpt password |
2. Create .github/workflows/cost-scan.yml:
name: K8s Cost Scan
on:
pull_request:
types: [opened, synchronize]
schedule:
- cron: '0 8 * * 1' # Every Monday at 08:00 UTC
workflow_dispatch:
permissions:
contents: read
pull-requests: write
jobs:
cost-scan:
runs-on: ubuntu-latest
steps:
- uses: kubeopt/kubeopt@v1
with:
kubeopt-url: ${{ secrets.KUBEOPT_URL }}
kubeopt-username: ${{ secrets.KUBEOPT_USERNAME }}
kubeopt-password: ${{ secrets.KUBEOPT_PASSWORD }}The action is read-only — it never modifies your cluster. PR comments are upserted so re-runs update the existing comment rather than adding a new one.
Full inputs, outputs, and advanced usage
Ask Claude about your Kubernetes costs in plain English.
KubeOpt ships an MCP server (mcp_server/) that exposes 6 tools over stdio transport. Once connected, Claude Desktop, Cursor, or Windsurf can query your cluster data directly — no copy-pasting dashboards.
Tools exposed:
Tool | What it does |
| List all monitored clusters with cost data |
| Portfolio-level cost summary across all clusters |
| Detailed analysis for a specific cluster |
| Actionable recommendations sorted by savings impact |
| Trigger a fresh analysis and poll until complete |
| Per-pod cost breakdown, filterable by namespace |
KubeOpt running locally (python main.py) or deployed on Railway
Python virtual environment with dependencies installed (pip install -r requirements.txt)
Edit ~/.claude/claude_desktop_config.json:
{
"mcpServers": {
"kubeopt": {
"command": "uvx",
"args": ["kubeopt-mcp"],
"env": {
"KUBEOPT_API_URL": "https://your-kubeopt-instance.com",
"KUBEOPT_USERNAME": "kubeopt",
"KUBEOPT_PASSWORD": "your-password"
}
}
}
}Restart Claude Desktop after saving.
Open Cursor Settings → MCP and add a new server entry:
{
"kubeopt": {
"command": "uvx",
"args": ["kubeopt-mcp"],
"env": {
"KUBEOPT_API_URL": "https://your-kubeopt-instance.com",
"KUBEOPT_USERNAME": "kubeopt",
"KUBEOPT_PASSWORD": "your-password"
}
}
}Edit ~/.codeium/windsurf/mcp_config.json (create it if it doesn't exist):
{
"mcpServers": {
"kubeopt": {
"command": "uvx",
"args": ["kubeopt-mcp"],
"env": {
"KUBEOPT_API_URL": "https://your-kubeopt-instance.com",
"KUBEOPT_USERNAME": "kubeopt",
"KUBEOPT_PASSWORD": "your-password"
}
}
}
}Restart Windsurf after saving.
What are my top 3 cost savings opportunities across all clusters?
Which pods are costing the most in the production namespace?
Give me a summary of total Kubernetes spend this month.
What's the optimization score for my staging cluster?
Trigger a fresh analysis on cluster prod-aks-eastus and report back.For more on the protocol: modelcontextprotocol.io
Run a Kubernetes cost scan on every pull request or on a schedule. The action posts a summary as a PR comment (upserted on re-runs) and writes results to the GitHub Step Summary.
What you get on each PR:
## KubeOpt Cost Scan — 2026-04-27
| Cluster | Provider | Monthly Spend | Savings Available |
|------------------|----------|---------------|-------------------|
| prod-eks-us-east | AWS | $4,120 | $890/mo |
| staging-aks-weu | Azure | $1,340 | $210/mo |
**Total potential savings: $1,100/mo**
<details>
<summary>Top opportunities</summary>
1. $540/mo — prod-eks-us-east — Rightsize 6 over-provisioned node groups
2. $350/mo — prod-eks-us-east — Enable HPA on 4 deployments with static replicas
3. $210/mo — staging-aks-weu — Remove 3 idle nodes outside business hours
</details>1. Add secrets to your repository
Go to Settings → Secrets and variables → Actions and add:
Secret | Value |
| URL of your KubeOpt instance (e.g. |
| KubeOpt username |
| KubeOpt password |
2. Create .github/workflows/cost-scan.yml
name: K8s Cost Scan
on:
pull_request:
types: [opened, synchronize]
schedule:
- cron: '0 8 * * 1' # Every Monday at 08:00 UTC
workflow_dispatch:
permissions:
contents: read
pull-requests: write
jobs:
cost-scan:
name: KubeOpt Cost Scan
runs-on: ubuntu-latest
steps:
- name: Run KubeOpt cost scan
id: kubeopt
uses: kubeopt/kubeopt@v1
with:
kubeopt-url: ${{ secrets.KUBEOPT_URL }}
kubeopt-username: ${{ secrets.KUBEOPT_USERNAME }}
kubeopt-password: ${{ secrets.KUBEOPT_PASSWORD }}
top: 5
post-comment: ${{ github.event_name == 'pull_request' && 'true' || 'false' }}
- name: Print savings to log
if: always()
run: echo "Total savings available: ${{ steps.kubeopt.outputs.total-savings }}/mo"Input | Required | Default | Description |
| yes | URL of your KubeOpt instance | |
| yes |
| KubeOpt username |
| yes | KubeOpt password | |
| no | (all clusters) | Scan a specific cluster only |
| no |
| Number of top savings opportunities to show |
| no |
| Post results as a PR comment |
Output | Description |
| Total potential monthly savings in USD |
| Full markdown summary (use in downstream steps) |
- uses: kubeopt/kubeopt@v1
with:
kubeopt-url: ${{ secrets.KUBEOPT_URL }}
kubeopt-username: ${{ secrets.KUBEOPT_USERNAME }}
kubeopt-password: ${{ secrets.KUBEOPT_PASSWORD }}
cluster-id: prod-eks-us-east-1
top: 10The action checks out kubeopt/kubeopt@v1 at runtime to run the scan. No local install needed.
PR comments are upserted: re-running the action updates the existing comment rather than adding a new one.
Requires pull-requests: write permission to post comments.
The action does not modify your cluster. It is read-only.
KubeOpt Platform
+----------------------------------------------------------+
| |
| React SPA (Recharts) FastAPI REST API (v2) |
| frontend/dist/ presentation/api/v2/ |
| |
+---------------------------+------------------------------+
|
+------------------+------------------+
| | |
+-------v------+ +-------v------+ +--------v-------+
| Algorithms | | Analytics | | ML Models |
| (16 modules)| | Collectors | | Anomaly Det. |
| rightsizing | | Processors | | CPU Optimizer |
| HPA, storage| | Scorer | | Workload Cls |
+--------------+ +--------------+ +----------------+
| | |
+-------v------------------v------------------v-------+
| Cloud Provider Abstraction |
| 6 interfaces: Auth, Executor, Metrics, Costs, |
| Accounts, Inspector |
+---+-----------------+-----------------+-------------+
| | |
+---v---+ +----v----+ +----v----+
| Azure | | AWS | | GCP |
| (AKS) | | (EKS) | | (GKE) |
+-------+ +---------+ +---------+Service | Purpose | Endpoint |
Plan Generation | Generates optimization plans | plan.kubeopt.com |
AI Chat | Conversational cluster analysis | ai.kubeopt.com |
License Manager | License validation | license.kubeopt.com |
These services require a PRO or ENTERPRISE license. The core analysis engine works without them.
Python 3.11+
Node.js 18+ (for frontend build)
Cloud provider credentials (Azure, AWS, or GCP)
# Clone and install
git clone https://github.com/kubeopt/kubeopt.git
cd kubeopt
pip install -r requirements.txt
# Set up credentials (copy and fill in your values)
cp .env.example .env
# Build frontend
cd frontend && npm install && npm run build && cd ..
# Run
python main.py
# Open http://localhost:5001docker build -t kubeopt .
docker run -p 5001:5001 --env-file .env kubeoptnpx kubeopt clusters # List clusters
npx kubeopt analyze <id> # Run analysis
npx kubeopt report <id> # View reportSet these environment variables:
AZURE_SUBSCRIPTION_ID=your-subscription-id
AZURE_CLIENT_ID=your-client-id
AZURE_CLIENT_SECRET=your-client-secret
AZURE_TENANT_ID=your-tenant-idRequires a Service Principal with Reader role. See docs/setup/AZURE-SETUP.md.
AWS_ACCESS_KEY_ID=your-access-key
AWS_SECRET_ACCESS_KEY=your-secret-key
AWS_DEFAULT_REGION=us-east-1Requires IAM user with EKS, Cost Explorer, and CloudWatch read access.
GCP_SERVICE_ACCOUNT_KEY={"type":"service_account",...}
GCP_BILLING_DATASET=your_billing_dataset
GCP_BILLING_ACCOUNT_ID=your-billing-account-idSee docs/setup/GCP-BILLING-SETUP.md.
kubeopt/
algorithms/ 16 optimization algorithm modules
analytics/ Cost collectors, processors, cluster scorer
application/ Orchestrator, command generators
infrastructure/
cloud_providers/ Azure, AWS, GCP adapters (6 interfaces each)
services/ Auth, caching, license validation, settings
persistence/ Database, analysis engine
machine_learning/ Anomaly detection, CPU optimizer, workload classifier
presentation/
api/v2/ FastAPI routers, schemas, dependencies
frontend/ React SPA (TypeScript, Recharts, Tailwind)
shared/
standards/ 16 YAML-based optimization standards
config/ Application configuration
mcp_server/ MCP server (6 tools, stdio transport)Component | Technology |
Backend | Python 3.11+, FastAPI, uvicorn |
Frontend | React 19, TypeScript, Vite, Recharts, Tailwind CSS |
ML | Pandas, NumPy, Scikit-learn |
Cloud | Azure SDK, boto3, google-cloud SDK |
Database | SQLite (dev), PostgreSQL (prod) |
Deployment | Docker, Railway, Kubernetes |
Apache License 2.0. See LICENSE.
The core analysis engine is open source and free to use. Plan generation and AI chat are hosted services that require a PRO or ENTERPRISE license.
See CONTRIBUTING.md for guidelines.
To report security vulnerabilities, email support@kubeopt.com. See SECURITY.md.
Built by Nivaya Technologies
Trigger a fresh cost analysis for a cluster. This runs in the background and takes 1-15 minutes depending on cluster size and cloud provider. Polls for completion and returns the results.
| Name | Required | Description | Default |
|---|---|---|---|
| cluster_id | Yes | The cluster ID to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers async behavior (background, 1-15 min, polling) but omits details like authentication or result format.
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 sentences, front-loaded with purpose, no wasted words.
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?
Fairly complete for a simple async tool, though missing result structure and error handling.
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 already describes the parameter; description adds no additional meaning beyond the schema.
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 verb 'Trigger' and resource 'cost analysis' for a cluster, distinguishing it from sibling get_* tools.
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 implies this tool is for fresh analysis (vs. retrieving existing results) but does not explicitly compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed cost analysis for a specific cluster including cost breakdown, resource utilization, node recommendations, and anomaly detection
| Name | Required | Description | Default |
|---|---|---|---|
| cluster_id | Yes | The cluster ID to analyze (use list_clusters to find IDs) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, or side effects. The name suggests a read operation, but this is not explicitly stated, leaving a transparency gap.
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 20 words, front-loaded with the main action and purpose. No redundant information is present.
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 lists the analysis components but does not specify output format, time range, or whether data is real-time or historical. Since there is no output schema, additional context would be beneficial for an agent.
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 100% for the single parameter, which already includes guidance to use list_clusters. The tool description does not add any additional parameter meaning beyond what the schema provides.
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 verb 'Get' and the resource 'cluster analysis'. It lists specific aspects (cost breakdown, resource utilization, node recommendations, anomaly detection), which distinguishes it from siblings like get_cost_summary (cost-only) and get_recommendations (recommendations-only).
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 implies usage for a specific cluster but does not explicitly compare with siblings. The parameter hint to use list_clusters provides some context, but there is no guidance on when to use this tool versus analyze_cluster or get_pod_costs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get portfolio-level cost summary across all clusters
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses basic purpose but omits behavioral traits like read-only hint, caching, rate limits, or what data is excluded. Minimal transparency.
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?
Single sentence with front-loaded verb and resource. Every word adds value; no fluff. Efficient and clear.
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?
No output schema exists, but description does not explain return format or typical fields. Adequate for a trivial tool but could be more complete (e.g., 'returns total cost, average cost per cluster').
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?
Zero parameters and schema coverage is 100% (trivially). Description adds no extra parameter semantics, but none are needed. Baseline 4 is appropriate given no parameters to document.
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 provides a 'portfolio-level cost summary across all clusters', with specific verb 'Get' and resource 'cost summary'. This effectively distinguishes it from sibling tools like get_pod_costs (per-pod) and get_recommendations.
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. Missing context such as 'use for high-level overview; use get_pod_costs for detailed pod-level costs'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get per-pod cost breakdown for a cluster, useful for identifying expensive workloads. Optionally filter by namespace.
| Name | Required | Description | Default |
|---|---|---|---|
| cluster_id | Yes | The cluster ID to get pod costs for | |
| namespace | No | Optional: filter pods to this Kubernetes namespace |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states the tool 'gets' a breakdown but does not describe the output format, whether the data is live or cached, any rate limits, or required permissions. The behavioral information is minimal.
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 concise sentences clearly convey purpose and key option. No redundant words or fluff.
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?
Without an output schema, the description should indicate what the breakdown includes (e.g., fields like pod name, cost, CPU/memory). It does not. Additionally, no comparison to siblings is provided, leaving the agent to infer the tool's full scope.
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 coverage is 100%, so baseline is 3. The description adds context for 'namespace' as an optional filter, but does not expand on 'cluster_id' beyond the schema. This adds marginal value.
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 action 'get', the resource 'per-pod cost breakdown for a cluster', and the purpose 'useful for identifying expensive workloads'. This differentiates from sibling like 'get_cost_summary' which likely provides a broader view, but does not explicitly distinguish from all siblings.
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 implies usage for identifying expensive workloads, but does not provide explicit guidance on when to use versus alternatives like 'get_cost_summary' or when not to use. 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.
Get actionable optimization recommendations for a cluster, sorted by estimated savings impact
| Name | Required | Description | Default |
|---|---|---|---|
| cluster_id | Yes | The cluster ID to get recommendations for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states sorting behavior; lacks details on read-only nature, caching, permissions, or rate limits. Minimal behavioral disclosure.
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?
Single sentence, front-loaded with key action and resource. No wasted words; efficient and clear.
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?
Despite low complexity (1 param, no output schema), description omits return format, types of recommendations, and how they relate to sibling tools. Incomplete for effective agent use.
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 100% for the single parameter 'cluster_id'. Description adds no extra meaning beyond the schema's own description.
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?
Description clearly states verb 'Get', resource 'optimization recommendations for a cluster', and unique sorting 'by estimated savings impact'. Distinguishes from sibling tools like 'list_clusters' and 'get_cost_summary'.
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?
Implied usage for obtaining optimization recommendations sorted by savings, but no explicit when-to-use vs siblings like 'analyze_cluster' or 'get_cluster_analysis'. Lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Kubernetes clusters being monitored with their latest cost and optimization data
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses the tool lists data but lacks details on behavioral aspects such as data freshness, pagination, authorization requirements, or any side effects. The read-only nature is inferred but not explicitly stated.
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, concise and front-loaded with the main verb and key nouns. Every word adds value with no 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?
Given no output schema and no annotations, the description is minimal. It provides the core purpose but lacks contextual details like the structure of returned data (e.g., cluster names, cost fields, optimization metrics) or any constraints. For a tool with no parameters, it is adequate but could be more complete.
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 zero parameters with 100% coverage, so the description does not need to elaborate on parameters. Baseline score of 4 is appropriate as there is nothing to add beyond the schema.
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 verb 'List', the resource 'Kubernetes clusters being monitored', and the scope 'with their latest cost and optimization data'. It effectively distinguishes itself from sibling tools like 'analyze_cluster' or 'get_cost_summary' by indicating it provides a list of all clusters with combined cost and optimization data.
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 implies basic usage (listing clusters) but provides no explicit guidance on when to use this tool versus alternatives like 'get_cost_summary' for cost details or 'get_recommendations' for optimization. There is no mention of prerequisites or contextual cues for selection.
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.
v1.0.0analyze_clusterget_cluster_analysisget_cost_summaryget_pod_costsget_recommendationslist_clustersScored across 6 tools
Each tool has a clearly distinct purpose: triggering analysis, retrieving cluster-level results, portfolio summary, pod-level costs, recommendations, and listing clusters. No overlap or ambiguity.
All tools follow a consistent verb_noun snake_case pattern (e.g., analyze_cluster, get_cluster_analysis, list_clusters), making them predictable and easy to distinguish.
Six tools is well-scoped for a Kubernetes cost analysis server, covering the core workflows without being excessive or insufficient.
The tool surface covers the full lifecycle: triggering analysis, retrieving detailed results (cluster, pod, portfolio), recommendations, and listing—no obvious gaps for the stated purpose.
Query cloud, AI and SaaS spend across 25+ providers: costs, budgets, anomalies, unit economics.
Ask your AI assistant a cost question. Get allocation, correlation, and explanation in one response. Costory connects Claude, Codex, or Cursor to normalized cost data across AWS, GCP, Azure, Datadog, OpenAI, and Anthropic. https://costory.io Free trial 14 days, 250 USD / month up to 10M Spend
FinOps MCP: query allocated, correlated cloud and AI cost across AWS, GCP, Azure and Snowflake.
Ask about AWS, Azure, GCP, OpenAI, Anthropic and Snowflake costs, budgets, and anomalies.
