What can you do with this server?

This server provides unified cloud cost management across AWS, OpenAI, and Anthropic via an MCP interface. * Retrieve Cost Data: Query costs by provider, date range, and granularity (daily/monthly/total), with grouping by dimensions like service or region. * List Providers: Check which providers are configured, active, and have valid credentials. * Check Provider Balance: View remaining credits or balances for a specific provider. * OpenAI Detailed Costs: Model-by-model breakdown (e.g., GPT-4, GPT-3.5) with token usage statistics. * Anthropic Detailed Costs: Model-level breakdown (e.g., Claude 3.5 Sonnet, Haiku) with token usage, prompt caching info, and support for both cost and usage report APIs. * AWS Detailed Costs: Service-level breakdown (EC2, S3, RDS), filtering by service, grouping by SERVICE/REGION/INSTANCE_TYPE/LINKED_ACCOUNT, and optional cost forecasts. * Compare Providers: Side-by-side cost comparison across all configured providers with optional ASCII chart visualization. * Analyze Cost Trends: Historical trend detection (increasing/decreasing/stable), volatility analysis, and spike detection over periods up to 1 year at daily/weekly/monthly granularity. * Detailed Cost Breakdown: Multi-dimensional analysis by service, region, date, or tag, with top-N and percentage-based threshold filtering. * Compare Time Periods: Period-over-period comparison with absolute and percentage changes, service-level breakdowns, and detection of new/discontinued services.

Which integrations are available for this server?

Enables monitoring and analysis of Amazon EC2 costs as part of AWS cost management, providing service-level breakdowns, optimization tips, and high-spend warnings. Enables monitoring and analysis of Amazon S3 costs as part of AWS cost management, providing service-level breakdowns and cost optimization recommendations. Provides detailed OpenAI cost and usage tracking, offering model-specific breakdowns (e.g., GPT-4), token usage statistics, and recommendations for cost optimization.

How do I use Cost Management MCP?

1. Click on "Install 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., "@Cost Management MCP Compare my AWS and OpenAI spending for the last 30 days" 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.

Cost Management MCP

by knishioka

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Cost Management MCP

Security Scan Release License: MIT Node.js Version TypeScript codecov

A Model Context Protocol (MCP) server for unified cost management across cloud providers and API services.

English | 日本語

🚀 Quick Examples

Once integrated with Claude Desktop, you can ask:

📊 "What are my AWS costs for December 2024?"
📈 "Show me OpenAI API usage trends for the last 30 days"
🤖 "What are my Anthropic API costs this month?"
🔍 "Break down my cloud expenses by service"
📋 "Which providers are currently configured?"
💰 "How much have I spent across all services this month?"

Related MCP server: nable (finops-mcp)

Features

🔍 Unified cost tracking across AWS, OpenAI, and Anthropic
💾 Intelligent caching to minimize API costs
📊 Flexible date ranges and granularity options
🔐 Secure credential management via environment variables
🚀 Easy integration with Claude Desktop and other MCP clients
⚡ Written in TypeScript with full type safety
🧪 Comprehensive test coverage
🔄 Automatic retry logic with exponential backoff
🛡️ Security scanning with CodeQL and Trufflehog
📦 Automated dependency updates with Dependabot

🛠️ MCP Tools

This server provides three powerful tools for cost management:

📊 `cost_get`

Get detailed cost breakdowns

Check costs for any date range
Filter by specific provider (AWS, OpenAI, Anthropic)
View daily, monthly, or total costs
See service-level breakdowns

Example questions in Claude:

"What are my AWS costs for this month?"
"Show me daily OpenAI usage for the last week"
"Break down my cloud costs by service"

📋 `provider_list`

Check provider status

See which providers are configured
Verify API credentials are valid
Quick health check for all integrations

Example usage:

"List all my cloud providers"
"Which cost tracking services are active?"

💰 `provider_balance`

Check remaining credits (Coming soon)

View prepaid balances
Monitor API credit usage
Get alerts before credits expire

📊 `openai_costs`

Get detailed OpenAI usage

Model-by-model breakdown (GPT-4, GPT-3.5, etc.)
Token usage statistics
Cost optimization recommendations

Example usage:

"Show my OpenAI costs grouped by model"
"How many tokens did I use with GPT-4 this week?"

🤖 `anthropic_costs`

Get detailed Anthropic usage

Model-by-model breakdown (Claude 3.5 Sonnet, Haiku, etc.)
Token usage statistics with prompt caching details
Cost optimization recommendations
Support for both cost report and usage report APIs

Example usage:

"Show my Anthropic costs grouped by model"
"How much did I spend on Claude 3.5 Sonnet this month?"
"What are my Anthropic costs with token-level details?"

☁️ `aws_costs`

AWS cost analysis with insights

Service-level breakdown (EC2, S3, RDS, etc.)
Filter by specific AWS service
Automatic cost optimization tips
High spend warnings

Example usage:

"What are my EC2 costs this month?"
"Show AWS costs grouped by service"
"Give me AWS cost optimization tips"

📈 `provider_compare`

Compare costs across providers

Side-by-side cost comparison
ASCII chart visualization
Vendor lock-in warnings
Cost distribution insights

Example usage:

"Compare my costs across all cloud providers"
"Show me a chart of provider costs"
"Which provider is most expensive?"

📊 `cost_trends`

Analyze cost trends over time

Historical cost analysis (30d, 60d, 90d, 6m, 1y)
Trend detection (increasing/decreasing/stable)
Volatility analysis
Spike detection
Daily/weekly/monthly granularity

Example usage:

"Show me cost trends for the last 30 days"
"Are my AWS costs increasing?"
"Detect any cost spikes in the past month"

🔍 `cost_breakdown`

Detailed cost breakdown analysis

Multi-dimensional breakdown (service, region, date, tag)
Top N cost drivers
Percentage-based filtering
Hierarchical drill-down
Cost concentration analysis

Example usage:

"Break down my costs by service"
"Show top 5 cost drivers"
"What services make up 80% of my costs?"

📅 `cost_periods`

Compare costs between time periods

Period-over-period comparison
Absolute and percentage changes
Service-level change tracking
Daily average comparison
New/discontinued service detection

Example usage:

"Compare this month vs last month"
"How much did costs increase since Q1?"
"Which services grew the most?"

Installation

Prerequisites

Node.js 18 or higher
npm or yarn
Active accounts with the cloud providers you want to monitor

CI currently verifies Node.js 18.x, 20.x, 22.x, and 24.x. Node.js 20.x is the primary lane for coverage upload and representative build checks.

Steps

Clone the repository:

git clone https://github.com/knishioka/cost-management-mcp.git
cd cost-management-mcp

Install dependencies:

npm install

Copy the environment template:

cp .env.example .env

Edit .env and add your credentials (see Provider Setup)
Build the project:

npm run build

Quick Start

Running Standalone

# Development mode (with hot reload)
npm run dev

# Production mode
npm start

Integration with Claude Desktop

Build the project first:

npm run build

Add to your Claude Desktop configuration (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "cost-management": {
      "command": "node",
      "args": ["/absolute/path/to/cost-management-mcp/dist/index.js"],
      "env": {
        "AWS_ACCESS_KEY_ID": "your-key",
        "AWS_SECRET_ACCESS_KEY": "your-secret",
        "AWS_REGION": "us-east-1",
        "OPENAI_API_KEY": "your-key",
        "CACHE_TTL": "3600",
        "LOG_LEVEL": "info"
      }
    }
  }
}

Restart Claude Desktop
Use the tools in your conversation:

Can you check my AWS costs for this month?
What are my OpenAI API costs for the last 7 days?
List all my configured cloud providers.

Integration with Claude Code

Claude Code supports MCP servers through two configuration methods:

Method 1: Project-specific configuration (Recommended)

Create a .mcp.json file in your project root:

{
  "mcpServers": {
    "cost-management": {
      "command": "node",
      "args": ["/absolute/path/to/cost-management-mcp/dist/index.js"],
      "env": {
        "AWS_ACCESS_KEY_ID": "your-aws-access-key",
        "AWS_SECRET_ACCESS_KEY": "your-aws-secret-key",
        "AWS_REGION": "us-east-1",
        "OPENAI_API_KEY": "sk-...your-openai-key",
        "ANTHROPIC_API_KEY": "sk-ant-admin-...your-admin-key",
        "CACHE_TTL": "3600",
        "LOG_LEVEL": "info"
      }
    }
  }
}

This configuration will be automatically loaded when you open the project in Claude Code.

Method 2: VS Code settings (Global configuration)

Open VS Code Settings (Cmd/Ctrl + ,)
Search for "Claude Code MCP Servers"
Click "Edit in settings.json"
Add the cost management server configuration:

{
  "claudeCode.mcpServers": {
    "cost-management": {
      "command": "node",
      "args": ["/absolute/path/to/cost-management-mcp/dist/index.js"],
      "env": {
        "AWS_ACCESS_KEY_ID": "your-aws-access-key",
        "AWS_SECRET_ACCESS_KEY": "your-aws-secret-key",
        "AWS_REGION": "us-east-1",
        "OPENAI_API_KEY": "sk-...your-openai-key",
        "ANTHROPIC_API_KEY": "sk-ant-admin-...your-admin-key",
        "CACHE_TTL": "3600",
        "LOG_LEVEL": "info"
      }
    }
  }
}

Reload VS Code window (Cmd/Ctrl + Shift + P → "Developer: Reload Window")

Using the Cost Management Server

Once configured, you can ask Claude Code about your cloud costs:

📊 "What are my AWS costs for this month?"
📈 "Show me OpenAI API usage trends"
🔍 "Break down my cloud expenses by service"
💰 "Compare costs across all providers"

Security Note:

For project-specific .mcp.json, add it to .gitignore to avoid committing sensitive API keys
Consider using environment variables or a secrets manager for production use
The cache is optional - if not configured, the server will work without caching

Available Tools

cost_get

Retrieve cost data for specified providers and time periods.

Parameters:

provider (optional): Specific provider to query ('aws', 'openai', 'anthropic')
startDate (required): Start date in YYYY-MM-DD format
endDate (required): End date in YYYY-MM-DD format
granularity (optional): 'daily', 'monthly', or 'total' (default: 'total')
groupBy (optional): Array of dimensions to group by (e.g., ['SERVICE', 'REGION'])

Example Request:

{
  "provider": "aws",
  "startDate": "2024-01-01",
  "endDate": "2024-01-31",
  "granularity": "daily",
  "groupBy": ["SERVICE"]
}

Example Response:

{
  "success": true,
  "data": {
    "provider": "aws",
    "period": {
      "start": "2024-01-01T00:00:00.000Z",
      "end": "2024-01-31T23:59:59.999Z"
    },
    "costs": {
      "total": 1234.56,
      "currency": "USD",
      "breakdown": [
        {
          "service": "Amazon EC2",
          "amount": 800.0,
          "usage": {
            "quantity": 720,
            "unit": "Hours"
          }
        },
        {
          "service": "Amazon S3",
          "amount": 434.56
        }
      ]
    },
    "metadata": {
      "lastUpdated": "2024-01-31T12:00:00.000Z",
      "source": "api"
    }
  }
}

provider_list

List all configured providers and their connection status.

Response includes:

Provider name
Configuration status
Credential validation status

Example Response:

{
  "success": true,
  "data": {
    "providers": [
      {
        "name": "aws",
        "status": "active",
        "configured": true
      },
      {
        "name": "openai",
        "status": "active",
        "configured": true
    ],
    "configured": 2,
    "total": 3
  }
}

provider_balance

Check remaining balance or credits (provider-specific). Note: Currently not implemented for most providers

Provider Setup

AWS

Enable Cost Explorer in AWS Console
- Navigate to AWS Cost Management → Cost Explorer
- Click "Enable Cost Explorer" (⚠️ This action is irreversible)
- Wait 24 hours for data to be available

Create IAM User with minimal permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ce:GetCostAndUsage", "ce:GetCostForecast", "ce:GetDimensionValues"],
      "Resource": "*"
    }
  ]
}

Set environment variables:

AWS_ACCESS_KEY_ID=your-access-key
AWS_SECRET_ACCESS_KEY=your-secret-key
AWS_REGION=us-east-1  # Cost Explorer only works in us-east-1

⚠️ Important: AWS charges $0.01 per Cost Explorer API request. Caching is enabled by default (1 hour) to minimize costs.

OpenAI

Get API Key from OpenAI Dashboard
Ensure you have:
- A paid account with usage history
- API access enabled
Set environment variable:
```
OPENAI_API_KEY=sk-...your-api-key
```

⚠️ Note: The Usage API is relatively new (December 2024). Ensure your account has access.

Anthropic

Get Admin API Key from Anthropic Console
Requirements:
- Organization account (individual accounts are not supported)
- Admin role to provision Admin API keys
- Admin API key starts with sk-ant-admin... (different from regular API keys)

Set environment variable:

ANTHROPIC_API_KEY=sk-ant-admin-...your-admin-api-key

⚠️ Important Notes:

Only Admin API keys can access cost and usage data
Cost data is available through two APIs:
- Cost Report API: Provides actual billing data in USD
- Usage Report API: Provides token-level details with calculated costs
Data typically appears within 5 minutes of API request completion
Supports prompt caching cost tracking

Configuration

Environment Variables

Variable	Description	Default	Required
`AWS_ACCESS_KEY_ID`	AWS access key	-	For AWS
`AWS_SECRET_ACCESS_KEY`	AWS secret key	-	For AWS
`AWS_REGION`	AWS region	us-east-1	For AWS
`OPENAI_API_KEY`	OpenAI API key	-	For OpenAI
`ANTHROPIC_API_KEY`	Anthropic Admin API key	-	For Anthropic
`CACHE_TTL`	Cache time-to-live in seconds	3600	No
`CACHE_TYPE`	Cache backend (memory/redis)	memory	No
`REDIS_URL`	Redis connection URL	-	If using Redis
`LOG_LEVEL`	Log verbosity (debug/info/warn/error)	info	No
`MCP_SERVER_PORT`	Server port	3000	No

Cache Configuration

The cache helps reduce API costs and improve performance:

Memory Cache (default): Fast, no setup required, data lost on restart
Redis Cache: Persistent, shared across instances, requires Redis server

To use Redis:

CACHE_TYPE=redis
REDIS_URL=redis://localhost:6379

Logging

Structured JSON logging is used for easy parsing:

# View logs in development
npm run dev

# View logs in production with jq
npm start 2>&1 | jq '.'

# Filter errors only
npm start 2>&1 | jq 'select(.level == "error")'

Development

Project Structure

cost-management-mcp/
├── src/
│   ├── common/          # Shared utilities and types
│   │   ├── cache.ts     # Caching implementation
│   │   ├── config.ts    # Configuration management
│   │   ├── errors.ts    # Custom error classes
│   │   ├── types.ts     # TypeScript interfaces
│   │   └── utils.ts     # Helper functions
│   ├── providers/       # Provider implementations
│   │   ├── aws/         # AWS Cost Explorer
│   │   ├── openai/      # OpenAI Usage API
│   │   ├── anthropic/   # Anthropic Admin API
│   ├── tools/           # MCP tool implementations
│   │   ├── getCosts.ts
│   │   ├── listProviders.ts
│   │   └── checkBalance.ts
│   ├── server.ts        # MCP server setup
│   └── index.ts         # Entry point
├── tests/               # Test files
├── docs/                # Additional documentation
└── scripts/             # Utility scripts

Commands

# Development with hot reload
npm run dev

# Build TypeScript to JavaScript
npm run build

# Run production server
npm start

# Run all tests
npm test

# Run tests with coverage
npm run test:coverage

# Run tests in watch mode
npm run test:watch

# Lint code
npm run lint

# Fix linting issues
npm run lint:fix

# Type check without building
npm run typecheck

# Clean build artifacts
npm run clean

Adding a New Provider

Create provider directory:

mkdir -p src/providers/newprovider

Implement required files:

types.ts - TypeScript interfaces
transformer.ts - Convert API response to unified format
client.ts - API client implementing ProviderClient
index.ts - Public exports

Update server.ts to include the new provider
Add tests in tests/providers/newprovider/

Testing

Tests use Jest with TypeScript support:

# Run all tests
npm test

# Run tests for specific provider
npm test -- aws

# Run with coverage
npm run test:coverage

# Debug tests
node --inspect-brk node_modules/.bin/jest --runInBand

Architecture

Design Principles

Unified Interface: All providers implement the same ProviderClient interface
Error Resilience: Automatic retry with exponential backoff
Cost Optimization: Aggressive caching to minimize API calls
Type Safety: Full TypeScript coverage with strict mode
Extensibility: Easy to add new providers or tools

Data Flow

User Request → MCP Tool → Provider Client → Cache Check
                                              ↓ (miss)
                                          External API
                                              ↓
                                          Transformer
                                              ↓
                                          Cache Store
                                              ↓
                                          Response

Error Handling

The system implements a hierarchical error handling strategy:

Provider Errors: Specific to each cloud provider
Authentication Errors: Invalid or expired credentials
Rate Limit Errors: Automatic retry with backoff
Validation Errors: Invalid input parameters
Network Errors: Retryable connection issues

Troubleshooting

Common Issues

"Authentication failed" error

Verify your API keys/credentials are correct
Check if the credentials have the required permissions
For AWS, ensure you're using us-east-1 region for Cost Explorer

No cost data returned

AWS: Wait 24 hours after enabling Cost Explorer
OpenAI: Verify you have a paid account with usage

High AWS costs

Cost Explorer API charges $0.01 per request
Increase CACHE_TTL to reduce API calls
Use Redis cache for persistence across restarts

"Rate limit exceeded" error

The system automatically retries with exponential backoff
If persistent, check your API quotas
Consider increasing cache TTL

Debug Mode

Enable debug logging for more information:

LOG_LEVEL=debug npm run dev

Health Check

Test individual providers:

# In your MCP client
Use the provider_list tool to check all providers

Contributing

We welcome contributions! Please see our Contributing Guide for details.

Development Workflow

Fork the repository
Create a feature branch: git checkout -b feature/your-feature
Make your changes
Add tests for new functionality
Ensure all tests pass: npm test
Lint your code: npm run lint
Commit with descriptive message
Push to your fork and submit a PR

Code Style

Follow TypeScript best practices
Use meaningful variable names
Add JSDoc comments for public APIs
Keep functions small and focused
Write tests for new features

📊 Project Status

Build & Test

CI/CD: Automated testing on push and PR
Node Support: Runtime floor is Node.js 18+. CI verifies 18.x, 20.x, 22.x, and 24.x with 20.x as the primary lane for coverage upload and representative build checks.
Coverage: Comprehensive test suite with coverage reporting

Security

Dependency Scanning: Weekly automated updates
Secret Detection: Continuous monitoring for exposed credentials
Code Analysis: CodeQL security scanning

Quality

Type Safety: Strict TypeScript configuration
Linting: ESLint with auto-fix on commit
Formatting: Prettier code formatting

License

MIT License - see LICENSE file for details

日本語ドキュメント

概要

Cost Management MCPは、複数のクラウドプロバイダーとAPIサービスのコストを統一的に管理するためのModel Context Protocol (MCP)サーバーです。

主な機能

🔍 AWS、OpenAI、Anthropicのコストを一元管理
💾 APIコストを最小限に抑えるインテリジェントキャッシング
📊 柔軟な日付範囲と集計オプション
🔐 環境変数による安全な認証情報管理
🚀 Claude Desktopとの簡単な統合
⚡ TypeScriptによる型安全性
🧪 包括的なテストカバレッジ
🔄 指数バックオフによる自動リトライ
🛡️ CodeQLとTrufflehogによるセキュリティスキャン
📦 Dependabotによる自動依存関係更新

🛠️ 利用可能なMCPツール

このサーバーは、コスト管理のための3つの強力なツールを提供します：

📊 `cost.get`

詳細なコスト内訳を取得

任意の期間のコストをチェック
特定のプロバイダー（AWS、OpenAI）でフィルタリング
日次、月次、または合計コストを表示
サービスレベルの内訳を確認

Claudeでの使用例：

「今月のAWSのコストを教えて」
「過去1週間のOpenAIの日次使用量を表示して」
「クラウドコストをサービス別に分解して」

📋 `provider_list`

プロバイダーの状態を確認

設定されているプロバイダーを確認
API認証情報が有効かを検証
すべての統合のヘルスチェック

使用例：

「すべてのクラウドプロバイダーを一覧表示」
「どのコスト追跡サービスがアクティブ？」

💰 `provider_balance`

残高の確認 (近日公開)

プリペイド残高の表示
APIクレジット使用量の監視
クレジット期限前のアラート

インストール

前提条件

Node.js 18 以上
npm または yarn
監視対象クラウドプロバイダーのアカウント

CI は現在 Node.js 18.x / 20.x / 22.x / 24.x を検証しており、20.x をカバレッジアップロードおよび代表的なビルド検証用の主要レーンとして扱います。

# リポジトリのクローン
git clone https://github.com/knishioka/cost-management-mcp.git
cd cost-management-mcp

# 依存関係のインストール
npm install

# 環境変数の設定
cp .env.example .env
# .envファイルを編集して認証情報を追加

# ビルド
npm run build

Claude Desktopとの統合

Claude Desktopの設定ファイルに以下を追加：

{
  "mcpServers": {
    "cost-management": {
      "command": "node",
      "args": ["/path/to/cost-management-mcp/dist/index.js"],
      "env": {
        "AWS_ACCESS_KEY_ID": "your-key",
        "AWS_SECRET_ACCESS_KEY": "your-secret",
        "OPENAI_API_KEY": "your-key"
      }
    }
  }
}

Claude Codeとの統合

Claude Codeは2つの設定方法でMCPサーバーをサポートしています：

方法1: プロジェクト固有の設定（推奨）

プロジェクトのルートディレクトリに .mcp.json ファイルを作成：

{
  "mcpServers": {
    "cost-management": {
      "command": "node",
      "args": ["/absolute/path/to/cost-management-mcp/dist/index.js"],
      "env": {
        "AWS_ACCESS_KEY_ID": "your-aws-access-key",
        "AWS_SECRET_ACCESS_KEY": "your-aws-secret-key",
        "AWS_REGION": "us-east-1",
        "OPENAI_API_KEY": "sk-...your-openai-key",
        "ANTHROPIC_API_KEY": "sk-ant-admin-...your-admin-key",
        "CACHE_TTL": "3600",
        "LOG_LEVEL": "info"
      }
    }
  }
}

この設定は、Claude Codeでプロジェクトを開いたときに自動的に読み込まれます。

方法2: VS Code設定（グローバル設定）

VS Code設定を開く（Cmd/Ctrl + ,）
「Claude Code MCP Servers」を検索
「settings.jsonで編集」をクリック
コスト管理サーバーの設定を追加：

{
  "claudeCode.mcpServers": {
    "cost-management": {
      "command": "node",
      "args": ["/absolute/path/to/cost-management-mcp/dist/index.js"],
      "env": {
        "AWS_ACCESS_KEY_ID": "your-aws-access-key",
        "AWS_SECRET_ACCESS_KEY": "your-aws-secret-key",
        "AWS_REGION": "us-east-1",
        "OPENAI_API_KEY": "sk-...your-openai-key",
        "GOOGLE_APPLICATION_CREDENTIALS": "/path/to/gcp-service-account.json",
        "GCP_BILLING_ACCOUNT_ID": "your-billing-account-id"
      }
    }
  }
}

VS Codeウィンドウをリロード（Cmd/Ctrl + Shift + P → 「開発者: ウィンドウの再読み込み」）

コスト管理サーバーの使用

設定が完了したら、Claude Codeでクラウドコストについて質問できます：

📊 「今月のAWSコストを教えて」
📈 「OpenAI APIの使用傾向を表示」
🔍 「サービス別にクラウド費用を分析」
💰 「全プロバイダーのコストを比較」

セキュリティに関する注意:

プロジェクト固有の .mcp.json は .gitignore に追加して、APIキーをコミットしないようにしてください
本番環境では環境変数やシークレット管理ツールの使用を検討してください
キャッシュはオプションです - 設定されていない場合、サーバーはキャッシュなしで動作します

使用例

今月のAWSのコストを教えて
過去7日間のOpenAI APIの使用料金は？
設定されているクラウドプロバイダーを一覧表示して

プロバイダーの設定

各プロバイダーの詳細な設定方法は英語版ドキュメントを参照してください。

開発

# 開発モード（ホットリロード付き）
npm run dev

# テストの実行
npm test

# リントチェック
npm run lint

# 型チェック
npm run typecheck

📊 プロジェクトステータス

ビルド＆テスト

CI/CD: プッシュとPR時の自動テスト
Node サポート: 動作要件（runtime floor）は Node.js 18+。CI は 18.x / 20.x / 22.x / 24.x を検証し、 20.x を主要なカバレッジアップロードおよびビルド検証用レーン（primary coverage lane）として扱います
カバレッジ: カバレッジレポート付きの包括的なテストスイート

セキュリティ

依存関係スキャン: 週次自動更新
シークレット検出: 公開された認証情報の継続的監視
コード分析: CodeQLセキュリティスキャン

品質

型安全性: 厳格なTypeScript設定
リンティング: コミット時のESLint自動修正
フォーマット: Prettierコードフォーマット

ライセンス

MIT License

Built with ❤️ using TypeScript and MCP

Available Tools

10 tools

anthropic_costsB

Get detailed Anthropic costs with model breakdown and token usage

ParametersJSON Schema

Name	Required	Description
`startDate`	Yes	Start date in YYYY-MM-DD format
`endDate`	Yes	End date in YYYY-MM-DD format
`groupByModel`	No	Group costs by model
`includeTokenUsage`	No	Include token usage statistics
`useUsageReport`	No	Use usage report API instead of cost report (provides token-level details with calculated costs)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but lacks critical behavioral details such as whether this is a read-only operation, if it requires specific permissions, rate limits, or what the output format looks like. For a tool with multiple parameters and no annotations, this is a significant gap.

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, efficient sentence that front-loads the core purpose without any unnecessary words. Every part of the sentence contributes directly to understanding the tool's function, making it highly concise and well-structured.

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 tool's moderate complexity (5 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, output format, and usage context. Without annotations or an output schema, the description should provide more completeness to guide the agent effectively.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all parameters. The description mentions 'model breakdown' and 'token usage', which loosely correspond to 'groupByModel' and 'includeTokenUsage' parameters, but adds no additional semantic context beyond what the schema provides. The baseline score of 3 is appropriate given the high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('detailed Anthropic costs'), including what details are provided ('model breakdown and token usage'). It distinguishes from some siblings like 'aws_costs' or 'openai_costs' by specifying the provider, but doesn't differentiate from generic cost tools like 'cost_breakdown' or 'cost_get' in terms of functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or comparisons to sibling tools like 'cost_breakdown' or 'provider_compare', leaving the agent to infer usage based on the tool name alone.

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

aws_costsC

Get detailed AWS costs with service breakdown and optimization tips

ParametersJSON Schema

Name	Required	Description	Default
`startDate`	Yes	Start date in YYYY-MM-DD format
`endDate`	Yes	End date in YYYY-MM-DD format
`granularity`	No	Cost aggregation granularity	daily
`groupBy`	No	Dimensions to group costs by
`service`	No	Filter by specific AWS service
`includeForecast`	No	Include cost forecast

TDQS

C2.9/5.0

Behavior2/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 mentions 'optimization tips' as an output, which adds some context beyond basic cost retrieval, but fails to address critical aspects like authentication requirements, rate limits, error handling, or whether this is a read-only operation. For a tool with 6 parameters and no annotations, this is a significant gap.

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, efficient sentence that front-loads the core purpose. Every word earns its place by specifying AWS costs, service breakdowns, and optimization tips without redundancy or fluff.

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

Completeness2/5

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

Given the complexity (6 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the return format, how optimization tips are structured, or prerequisites like AWS account access. For a tool that likely involves financial data and multiple filtering options, more context is needed to guide effective use.

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 thoroughly. The description adds no specific parameter semantics beyond implying cost retrieval with breakdowns and tips. It doesn't explain how parameters like 'groupBy' or 'includeForecast' relate to the described outputs, so it meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get detailed AWS costs with service breakdown and optimization tips.' It specifies the verb ('Get'), resource ('AWS costs'), and additional outputs ('service breakdown and optimization tips'). However, it doesn't explicitly differentiate from sibling tools like 'cost_breakdown' or 'cost_get,' which appear similar.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like 'cost_breakdown,' 'cost_get,' and 'provider_compare,' there's no indication of when this AWS-specific tool is preferred or what distinguishes it from generic cost tools.

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

cost_breakdownC

Get detailed cost breakdown by multiple dimensions

ParametersJSON Schema

Name	Required	Description
`provider`	No	Specific provider to analyze (optional)
`startDate`	Yes	Start date in YYYY-MM-DD format
`endDate`	Yes	End date in YYYY-MM-DD format
`dimensions`	No	Dimensions to break down costs by
`topN`	No	Number of top items to show
`threshold`	No	Minimum percentage threshold to include

TDQS

C2.9/5.0

Behavior2/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. The description only states what the tool does ('Get detailed cost breakdown') without mentioning any behavioral aspects like authentication requirements, rate limits, data freshness, or what happens when parameters are omitted. For a tool with 6 parameters and no annotation coverage, this is inadequate.

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 - a single sentence that states the core functionality. There's zero wasted language, and it's front-loaded with the essential information. This is an excellent example of efficient communication.

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

Completeness2/5

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

Given the tool's complexity (6 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain what the output looks like, how results are structured, or provide any context about the breakdown format. For a multi-dimensional analysis tool with provider filtering and threshold parameters, more contextual information would be helpful.

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 thoroughly. The description adds no additional parameter semantics beyond what's in the schema. The baseline score of 3 is appropriate when the schema does all the parameter documentation work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get detailed cost breakdown by multiple dimensions.' It specifies the verb ('Get') and resource ('cost breakdown'), but doesn't distinguish it from sibling tools like 'cost_trends' or 'cost_get' which might have overlapping functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like 'cost_trends', 'cost_get', and provider-specific tools ('aws_costs', 'openai_costs'), there's no indication of when this multi-dimensional breakdown tool is preferred over those alternatives.

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

cost_getC

Get cost data for a specific provider and time period

ParametersJSON Schema

Name	Required	Description	Default
`provider`	No	The provider to get costs for (optional, defaults to all)
`startDate`	Yes	Start date in YYYY-MM-DD format
`endDate`	Yes	End date in YYYY-MM-DD format
`granularity`	No	Cost aggregation granularity	total
`groupBy`	No	Dimensions to group costs by (e.g., SERVICE, REGION)

TDQS

C2.9/5.0

Behavior2/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. While 'Get' implies a read operation, the description doesn't mention authentication requirements, rate limits, error conditions, response format, or whether this is a real-time query versus cached data. For a cost query tool with no annotation coverage, this leaves significant behavioral gaps.

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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for the tool's complexity and front-loads the essential information.

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

Completeness2/5

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

For a cost query tool with 5 parameters, no annotations, no output schema, and many sibling tools offering similar functionality, the description is inadequate. It doesn't explain what the tool returns, how it differs from siblings, or important behavioral aspects like authentication, rate limits, or data freshness.

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 5 parameters thoroughly. The description adds minimal value beyond what's in the schema - it mentions 'provider and time period' which aligns with the provider, startDate, and endDate parameters, but doesn't provide additional context about parameter interactions or usage patterns.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and resource 'cost data' with scope 'for a specific provider and time period', making the purpose immediately understandable. However, it doesn't distinguish this tool from its many siblings (like aws_costs, openai_costs, cost_trends, etc.), which appear to offer similar or overlapping functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus its many siblings. With tools like aws_costs, openai_costs, cost_trends, cost_breakdown, and provider_compare available, there's no indication of what makes this tool distinct or when it should be preferred over alternatives.

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

cost_periodsC

Compare costs between two time periods

ParametersJSON Schema

Name	Required	Description	Default
`provider`	No	Specific provider to analyze (optional)
`period1`	Yes
`period2`	Yes
`comparisonType`	No		both
`breakdown`	No	Include service-level breakdown

TDQS

C2.8/5.0

Behavior2/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 what the tool does ('compare costs') but doesn't describe how it behaves: whether it's read-only or mutating, what permissions are required, whether it has rate limits, what format the comparison output takes, or if there are any side effects. For a tool with no annotation coverage, this leaves significant gaps in understanding its operational characteristics.

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—a single sentence with zero wasted words. It's front-loaded with the core purpose and doesn't include any unnecessary information. This is an example of efficient communication, though it may be too brief for complete understanding.

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

Completeness2/5

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

Given the complexity (5 parameters with nested objects, no output schema, no annotations), the description is insufficient. It doesn't explain what the comparison output looks like, how dates should be formatted, what 'costs' specifically refer to, or how this tool differs from similar siblings. For a tool with this level of parameter complexity and no structured support, the description should provide more contextual information.

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

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 40% (2 out of 5 parameters have descriptions). The description 'Compare costs between two time periods' only hints at the 'period1' and 'period2' parameters. It doesn't mention the optional 'provider' parameter, the 'comparisonType' with its enum values, or the 'breakdown' flag. With low schema coverage, the description fails to compensate by explaining parameter meanings or usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Compare costs between two time periods'. This is a specific verb ('compare') with a clear resource ('costs') and scope ('two time periods'). However, it doesn't explicitly differentiate from sibling tools like 'cost_trends' or 'provider_compare', which might also involve cost comparisons.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools involving costs (e.g., 'cost_trends', 'provider_compare', 'anthropic_costs'), there's no indication of when this period comparison is preferred over other cost analysis tools. The user must infer usage from the name alone.

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

cost_trendsC

Analyze cost trends over time with insights

ParametersJSON Schema

Name	Required	Description	Default
`provider`	No	Specific provider to analyze (optional)
`period`	No	Time period to analyze	30d
`granularity`	No	Data granularity	daily

TDQS

C2.6/5.0

Behavior2/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 mentions 'analyze' and 'insights', which imply read-only operations, but doesn't specify whether this tool requires authentication, has rate limits, returns aggregated data, or handles errors. For a tool with no annotation coverage, this leaves significant behavioral gaps.

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

Conciseness4/5

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

The description is a single, efficient sentence with no wasted words, making it appropriately concise. However, it's not front-loaded with critical details like scope or differentiation from siblings, which slightly reduces its effectiveness despite the brevity.

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

Completeness2/5

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

Given the complexity of analyzing cost trends with multiple parameters and no output schema, the description is incomplete. It doesn't explain what 'insights' include, how results are formatted, or any dependencies on other tools. With no annotations and an unspecified output, this leaves the agent under-informed for proper usage.

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?

The input schema has 100% description coverage, with clear enums and defaults for all three parameters. The description adds no additional meaning beyond the schema, such as explaining how 'provider' interacts with 'period' or what 'insights' entail. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Analyze cost trends over time with insights' states a general purpose (analyzing cost trends) but lacks specificity about what resources or data it operates on. It doesn't distinguish itself from sibling tools like 'cost_breakdown' or 'cost_get', making it somewhat vague about its exact function within the toolset.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'cost_breakdown', 'cost_periods', or provider-specific tools such as 'aws_costs' or 'openai_costs'. The description offers no context about prerequisites, exclusions, or comparative use cases, leaving the agent without direction on tool selection.

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

openai_costsB

Get detailed OpenAI costs with model breakdown and token usage

ParametersJSON Schema

Name	Required	Description
`startDate`	Yes	Start date in YYYY-MM-DD format
`endDate`	Yes	End date in YYYY-MM-DD format
`groupByModel`	No	Group costs by model
`includeTokenUsage`	No	Include token usage statistics

TDQS

B3.1/5.0

Behavior2/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 mentions 'Get detailed OpenAI costs,' implying a read-only operation, but does not specify authentication needs, rate limits, error handling, or data freshness. For a tool with no annotations, this leaves significant behavioral gaps, though it avoids contradiction.

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, efficient sentence that front-loads the core purpose without unnecessary words. It directly communicates the tool's function and key outputs, making it easy to parse and understand quickly.

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 tool's moderate complexity (4 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on output format, error cases, or integration with siblings. Without annotations or output schema, more context would improve completeness, but it meets a basic threshold.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional semantic context beyond implying date range usage and model/token breakdowns, which are already covered by the schema. This meets the baseline for high schema coverage without extra value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('OpenAI costs'), and specifies the type of data returned ('detailed... with model breakdown and token usage'). However, it does not explicitly differentiate from sibling tools like 'cost_get' or 'cost_breakdown', which might have overlapping functionality, preventing a score of 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'cost_get' or 'provider_compare' among the siblings. It lacks any context about prerequisites, exclusions, or specific scenarios where this tool is preferred, leaving the agent with minimal usage direction.

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

provider_balanceB

Check remaining balance or credits for a provider

ParametersJSON Schema

Name	Required	Description	Default
`provider`	Yes	The provider to check balance for

TDQS

B3.1/5.0

Behavior2/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 mentions 'check' which implies a read-only operation, but doesn't specify whether this requires authentication, has rate limits, returns real-time or cached data, or what happens if the provider isn't supported beyond the enum. For a tool with no annotation coverage, this is a significant gap 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.

Conciseness5/5

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

The description is a single, efficient sentence with zero waste—it directly states the tool's function without unnecessary words. It's appropriately sized for a simple tool and front-loaded with the core purpose, making it easy to parse quickly.

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 tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic purpose but lacks details on usage context, behavioral traits, and how it fits with siblings. Without output schema or annotations, more guidance on expected returns or operational constraints would improve completeness.

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?

The description adds minimal meaning beyond the input schema, which has 100% coverage and fully documents the single 'provider' parameter with an enum. The description implies the tool checks balance for a provider, but doesn't elaborate on what 'balance or credits' means (e.g., monetary, API credits, usage limits). Baseline 3 is appropriate since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('check') and resource ('remaining balance or credits for a provider'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'aws_costs' or 'openai_costs', which might also relate to provider financial information but with different scopes (e.g., costs vs. balance).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'cost_breakdown', 'cost_trends', and provider-specific cost tools, there's no indication of whether this is for real-time balance checks, historical data, or how it differs from other financial tools. This leaves the agent guessing about appropriate contexts.

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

provider_compareB

Compare costs across all configured providers

ParametersJSON Schema

Name	Required	Description
`startDate`	Yes	Start date in YYYY-MM-DD format
`endDate`	Yes	End date in YYYY-MM-DD format
`includeChart`	No	Include ASCII chart visualization

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool's function but doesn't mention permissions, rate limits, data sources, or output format. For a tool that likely queries financial data, this is a significant gap 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.

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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 tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic purpose but lacks details on behavior, output, or integration with sibling tools, leaving gaps for the agent to infer.

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?

The schema description coverage is 100%, so the schema fully documents the parameters (startDate, endDate, includeChart). The description adds no additional meaning beyond what the schema provides, such as explaining how the comparison is performed or what 'configured providers' entails, resulting in a baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('compare costs') and scope ('across all configured providers'), which is specific and meaningful. However, it doesn't explicitly differentiate from sibling tools like 'cost_breakdown' or 'cost_trends', which might also involve cost analysis, so it doesn't reach the highest score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'cost_breakdown' or 'provider_balance'. It lacks context about prerequisites, exclusions, or comparisons to sibling tools, leaving the agent with minimal usage direction.

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

provider_listB

List all configured providers and their status

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only states what the tool does, not behavioral traits like permissions needed, rate limits, or what 'status' entails. It lacks details on output format, pagination, or error handling.

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, efficient sentence with no wasted words, clearly front-loading the purpose. Every part of the sentence contributes directly to understanding the tool's function.

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 tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose but lacks context about the 'status' meaning or how results are structured, leaving some gaps for an agent.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters with 100% schema coverage, so the schema already documents this fully. The description doesn't need to add parameter details, and it appropriately avoids redundancy, earning a baseline score for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('List') and resource ('all configured providers and their status'), making the purpose immediately understandable. It doesn't specifically differentiate from sibling tools like 'provider_balance' or 'provider_compare', which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives like 'provider_balance' or 'provider_compare'. The description implies usage for listing providers but doesn't specify context, prerequisites, or exclusions.

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. Dates show when Glama detected each change.

10 tool updatesv1.0.0Mar 14, 2026
- First observedanthropic_costs
- First observedaws_costs
- First observedcost_breakdown
- First observedcost_get
- First observedcost_periods
- First observedcost_trends
- First observedopenai_costs
- First observedprovider_balance
- First observedprovider_compare
- First observedprovider_list

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0

Disambiguation3/5

There is significant overlap between tools, particularly 'cost_breakdown', 'cost_get', 'cost_periods', and 'cost_trends', which all seem to retrieve and analyze cost data with subtle distinctions. However, provider-specific tools like 'anthropic_costs' and 'openai_costs' are clearly distinct, and descriptions help differentiate some overlaps, preventing complete confusion.

Naming Consistency4/5

The naming follows a consistent snake_case pattern throughout, with most tools using a clear 'provider_action' or 'cost_action' structure. Minor deviations exist, such as 'cost_get' using a generic verb while others like 'cost_breakdown' are more descriptive, but overall the naming is predictable and readable.

Tool Count5/5

With 10 tools, the count is well-scoped for a cost management server covering multiple providers and analysis dimensions. Each tool appears to serve a specific purpose, such as provider-specific costs, comparisons, and trend analysis, making the set comprehensive without being overwhelming.

Completeness4/5

The tool set covers core cost management workflows, including retrieving costs by provider, comparing providers and periods, analyzing trends, and checking balances. Minor gaps might include operations for setting budgets or configuring providers, but agents can likely work around these with the available tools for monitoring and analysis.

Maintenance

ActivitySlowing

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

CostPilot
com.mcpgatepro
Hosted MCP server for AWS cloud spend: service breakdowns, anomalies, savings and forecasts.
Cloud Platforms Finance Monitoring
1
TokenOracle
com.guffeyholdings
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Finance Monitoring
2
Costory FinOps MCP
io.costory
FinOps MCP: query allocated, correlated cloud and AI cost across AWS, GCP, Azure and Snowflake.
Cloud Platforms Finance
11
RampOAuth
com.ramp.ramp-mcp-remote
The Ramp MCP server enables users to securely connect Ramp with AI assistants like ChatGPT and Claude to query financial data and take actions using natural language. It transforms Ramp's developer API into a SQL interface that LLMs can query, allowing admins to analyze spend trends, identify cost savings, and run complex SQL analyses on comprehensive datasets (transactions, purchase orders, vendors, users), while all users can manage cards, view transactions, request reimbursements, and get expense policy answers.
Finance Databases Search
2

Related MCP Servers

cloudscope-mcp
Cloud Platforms Finance
alexpota
A
license
A
quality
B
maintenance
Cloud cost management MCP server for Azure. Ask your AI about your cloud bill.
Updated 25 days ago (2026-08-12 01:27 UTC)
15
80
1
MIT
nable (finops-mcp)
Finance Cloud Platforms Monitoring
getnable
A
license
A
quality
A
maintenance
Local-first FinOps MCP server. Ask about your AWS, Azure, GCP, and SaaS costs in plain English. Anomaly detection, rightsizing, idle-resource cleanup, and Jira/Linear ticketing. Credentials never leave your machine.
Updated a day ago (2026-09-04 20:58 UTC)
10
17
Apache 2.0
AI Admin API MCP Server
AI & Machine Learning Monitoring
Amaretto-Software-Labs
A
license
A
quality
A
maintenance
A read-only MCP server for querying AI provider administration APIs, providing normalized usage, cost, and dashboard data for OpenAI and Anthropic.
Updated a month ago (2026-08-02 01:57 UTC)
4
19
MIT
openai-usage-mcp
Monitoring AI & Machine Learning
dlaporte
A
license
A
quality
D
maintenance
MCP server for querying OpenAI usage and cost data, including spend summaries, daily breakdowns, month-over-month comparisons, and token usage by model.
Updated 5 months ago (2026-03-30 22:08 UTC)
3
MIT

Appeared in Searches

A tool for creating business plans and calculating various costs

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/knishioka/cost-management-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Cost Management MCP

🚀 Quick Examples

Features

🛠️ MCP Tools

📊 cost_get

📋 provider_list

💰 provider_balance

📊 openai_costs

🤖 anthropic_costs

☁️ aws_costs

📈 provider_compare

📊 cost_trends

🔍 cost_breakdown

📅 cost_periods

Table of Contents

Installation

Prerequisites

Steps

Quick Start

Running Standalone

Integration with Claude Desktop

Integration with Claude Code

Method 1: Project-specific configuration (Recommended)

Method 2: VS Code settings (Global configuration)

Using the Cost Management Server

Available Tools

cost_get

provider_list

provider_balance

Provider Setup

AWS

OpenAI

Anthropic

Configuration

Environment Variables

Cache Configuration

Logging

Development

Project Structure

Commands

Adding a New Provider

Testing

Architecture

Design Principles

Data Flow

Error Handling

Troubleshooting

Common Issues

"Authentication failed" error

No cost data returned

High AWS costs

"Rate limit exceeded" error

Debug Mode

Health Check

Contributing

Development Workflow

Code Style

📊 Project Status

Build & Test

Security

Quality

License

日本語ドキュメント

概要

主な機能

🛠️ 利用可能なMCPツール

📊 cost.get

📋 provider_list

💰 provider_balance

インストール

前提条件

Claude Desktopとの統合

Claude Codeとの統合

方法1: プロジェクト固有の設定（推奨）

方法2: VS Code設定（グローバル設定）

コスト管理サーバーの使用

使用例

プロバイダーの設定

開発

📊 プロジェクトステータス

📊 `cost_get`

📋 `provider_list`

💰 `provider_balance`

📊 `openai_costs`

🤖 `anthropic_costs`

☁️ `aws_costs`

📈 `provider_compare`

📊 `cost_trends`

🔍 `cost_breakdown`

📅 `cost_periods`

📊 `cost.get`

📋 `provider_list`

💰 `provider_balance`