Claude 또는 MCP를 지원하는 모든 에이전트에서 쿼리할 수 있는 OpenClaw용 토큰 비용 텔레메트리. 에이전트별 + 공급자별 비용 귀속, 비용 급증에 대한 이상 징후 탐지, 모델 라우팅 권장 사항, 30일 예측을 제공합니다. silentwatch-mcp 및 openclaw-health-mcp와 함께 사용하는 보조 도구입니다.
프로덕션 AI 배포는 여러 공급자, 수십 개의 에이전트, 수백 번의 스킬 호출에 걸쳐 토큰 비용을 발생시킵니다. 월말에 청구서가 도착하면 "우리 돈이 어디로 갔지?"라는 질문에 대한 답은 10만 줄의 로그 속에 묻혀버립니다. 이 MCP 서버는 해당 데이터를 실시간으로 표면화하여 Claude 내부에서 평이한 영어로 쿼리할 수 있게 합니다:
> claude: where did our LLM spend go this week?
[MCP tools: cost_overview + top_cost_drivers]
Total spend last 7 days: $42.18
By provider:
Anthropic $30.40 (72%) — claude-sonnet-4 dominates
OpenAI $9.20 (22%) — chat-bot agent
Gemini $1.86 (4%) — cron-summarizer (cheap-route working)
Ollama $0.00 (local, free)
Top 3 cost drivers:
data-extraction-agent $28.50 (68%)
chat-bot $9.20 (22%)
cron-summarizer $1.86 (4%)
1 anomaly flagged — see find_cost_anomalies for details.> claude: any cheaper-routing opportunities?
[MCP tool: model_routing_recommendations]
Recommendation: data-extraction-agent currently runs claude-sonnet-4
with avg 400-token completions — extraction-style work that
gemini-2.5-flash usually handles at ~95% quality for ~5% the cost.
Estimated savings: $27.10/30d if migrated. Test on a 10% slice first.Related MCP server: nikhilnt
openclaw-cost-tracker-mcp를 사용하는 이유기존 도구(공급자 청구 대시보드, 일반적인 FinOps 도구, 사용자 지정 스크립트)가 수행하지 못하는 세 가지 기능:
공급자별 합계가 아닌 에이전트별 귀속. 공급자 대시보드는 "Anthropic에 $X 지출"이라고 표시하지만, 6개의 에이전트 중 어느 것이 그 비용의 78%를 유발했는지는 알려주지 않습니다. 비용 추적기는 OpenClaw의 요청별 비용 로그 JSONL을 읽고 agent_id를 유지한 채 집계합니다.
에이전트별 비용 급증 이상 징후 탐지. 채팅에 12만 토큰을 한 번 붙여넣는 것은 일반적인 트래픽의 일주일치 비용보다 더 많이 들 수 있습니다. 기본값인 에이전트별 중앙값의 3배 임계값은 월말 청구서에 나타나기 전에 이를 플래그 지정합니다.
실제 사용량에 기반한 라우팅 권장 사항. 일반적인 "더 저렴한 모델 사용" 조언은 쓸모가 없습니다. 이 서버는 볼륨 + 완료 길이 패턴이 더 저렴한 공급자로도 동일한 결과를 얻을 수 있음을 시사하는 특정 에이전트를 식별하며, 구체적인 30일 절감액 추정치를 제공합니다.
실제 비용이 발생하는 프로덕션 환경에서 OpenClaw를 운영하는 프로덕션 AI 운영자를 위해 구축되었습니다.
도구 | 반환 내용 |
| 총 지출 + 공급자별 + 상위 에이전트 + 상위 모델 + 특정 기간의 이상 징후 수 |
| 요청당 평균 비용 + 총액 점유율을 포함한 에이전트별 분석 |
| 토큰 수를 포함한 공급자별 분석 |
| 에이전트 중앙값 비용의 3배 이상으로 플래그 지정된 요청 |
| 상위 N개의 지출 에이전트 + 모델 (기타 노이즈 제외) |
| 30일 절감액 추정치가 포함된 구체적인 저렴한 모델 제안 |
| 신뢰도 참고 사항과 함께 30일 총액 + 공급자별 예측 |
리소스:
cost://overview — 7일 스냅샷
cost://forecast — 30일 예측
cost://anomalies — 최근 플래그 지정된 이상 징후
프롬프트:
diagnose-cost-spike — 최근 급증의 근본 원인 파악 + 시정 조치
weekly-cost-digest — 200단어 분량의 주간 비용 요약
pip install openclaw-cost-tracker-mcp~/Library/Application Support/Claude/claude_desktop_config.json(macOS) 또는 %APPDATA%\Claude\claude_desktop_config.json(Windows)에 추가하세요:
{
"mcpServers": {
"openclaw-cost": {
"command": "python",
"args": ["-m", "openclaw_cost_tracker_mcp"],
"env": {
"OPENCLAW_COST_BACKEND": "mock"
}
}
}
}백엔드 | 상태 | 설명 |
| ✅ v1.0 | 프로토콜 검증을 위한 의도적인 이상 징후 + 라우팅 기회가 포함된 샘플 데이터 |
| ✅ v1.0 | OpenClaw의 기본 비용 로그 JSONL 파일 파싱 (기본값 |
| ⏳ v1.1 | Anthropic + OpenAI 청구 API를 직접 읽음 (로그 심 필요 없음) |
각 줄은 하나의 JSON 레코드입니다:
{"request_id":"req-abc123","timestamp":"2026-05-04T12:34:56Z","provider":"anthropic","model":"claude-sonnet-4","agent_id":"data-extraction-agent","skill_id":"extract-structured-data","prompt_tokens":8500,"completion_tokens":600,"total_tokens":9100,"cost_usd":0.0345,"duration_ms":4823}OpenClaw 배포가 이 형식을 내보내지 않는 경우, 작은 로깅 심(shim)으로 공급자 호출을 래핑하세요. 샘플 심은 examples/에 있습니다.
버전 | 범위 | 상태 |
v1.0 | mock + openclaw-jsonl 백엔드, 7개 도구 / 3개 리소스 / 2개 프롬프트, 이상 징후 탐지 + 라우팅 + 예측, GitHub Actions CI 매트릭스, PyPI 신뢰할 수 있는 게시 | ✅ |
v1.1 |
| ⏳ |
v1.2 | 백엔드 연합; 예산 알림 + 임계값 위반 탐지 | ⏳ |
v1.x | 채널별 비용 귀속; 예산 알림을 위한 웹훅 이미터 | ⏳ |
AI 배포에 OpenClaw의 비용 로그 형식을 사용하지 않거나(다른 에이전트 하네스, 사용자 지정 로깅, AWS Bedrock 미터링, 공급업체 청구 API 등), 동일한 귀속 + 이상 징후 + 라우팅 가시성을 원하신다면 맞춤형 MCP 빌드 참여가 가능합니다.
티어 | 범위 | 투자 | 타임라인 |
단순 | 기존 비용 데이터 소스를 위한 단일 백엔드 어댑터 | $8,000–$10,000 | 1–2주 |
표준 | 사용자 지정 백엔드 + 사용자 지정 이상 징후 규칙 + 알림 통합 | $15,000–$20,000 | 2–4주 |
복합 | 다중 백엔드 연합 + 예산 집행 + 사용자 지정 라우팅 로직 | $25,000–$35,000 | 4–8주 |
참여 방법:
temur@pixelette.tech로 제목을 Custom MCP Build inquiry로 하여 이메일 발송
포함 내용: 스택에 대한 1단락 설명 + 고려 중인 티어
2영업일 이내에 30분 발견 통화 슬롯으로 회신
이 서버는 프로덕션 AI 인프라 MCP 제품군의 일부이며, silentwatch-mcp(크론 자동 실패 탐지) 및 openclaw-health-mcp(배포 상태)와 함께 사용됩니다. 전체 운영 가시성을 위해 세 가지 모두 설치하세요.
프로덕션 AI를 운영 중이며 외부 전문가가 준비 상태를 평가하고, 이미 존재하는 실패 패턴(비용 초과가 가장 흔한 패턴 중 하나)을 찾아 시정 조치 계획을 작성하기를 원하신다면:
티어 | 범위 | 투자 | 타임라인 |
감사 라이트 | 단일 시스템, 상위 5개 발견 사항, 서면 보고서 | $1,500 | 1주 |
감사 표준 | 전체 감사, 14개 패턴 모두, 5 Cs 발견 사항, 90일 후속 조치 | $3,000 | 2–3주 |
감사 + 워크숍 | 표준 감사 + 2일 팀 워크숍 + 첫 번째 월간 감사 포함 | $7,500 | 3–4주 |
동일한 이메일 채널: temur@pixelette.tech, 제목 AI audit inquiry.
PR을 환영합니다. 백엔드는 플러그인 가능합니다. 계약 내용은 src/openclaw_cost_tracker_mcp/backends/를 참조하세요.
새 백엔드를 추가하려면:
backends/<your_backend>.py에서 CostBackend를 서브클래싱합니다.
get_entries()를 구현합니다.
backends/__init__.py에 등록합니다.
tests/test_backend_<your_backend>.py에 테스트를 추가합니다.
버그 보고서 + 기능 요청: GitHub 이슈를 여세요.
MIT — LICENSE를 참조하세요.
silentwatch-mcp — 크론 자동 실패 탐지
openclaw-health-mcp — 배포 상태
AI Production Discipline Framework — Notion 템플릿, $29 — 이 MCP 도구들이 구현하는 방법론 (비용 초과는 카탈로그의 P3.x 패턴입니다)
SPEC.md — 전체 서버 설계
제작자: Temur Khan — 프로덕션 AI 시스템 독립 실무자. 연락처: temur@pixelette.tech
Top-level cost summary for a window — total spend, request count, by-provider breakdown, top agents, top models, anomaly count. Use this first for a single-pane view.
| Name | Required | Description | Default |
|---|---|---|---|
| window_hours | No | Lookback window in hours (default 168 = 7 days, max 720 = 30 days) | |
| top_n | No | How many top agents + models to include (default 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. Description implies read-only behavior (cost summary), but does not explicitly state non-destructiveness, rate limits, or other traits.
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 with zero waste. Front-loaded with output items. Every sentence earns its place.
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, but description lists all expected return components (total spend, request count, breakdowns, top agents/models, anomalies). Adequate for a top-level summary tool.
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% (both parameters described). Description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.
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 (summary) and specific resource (top-level cost for a window). It lists the exact components returned and distinguishes from siblings via 'use this first for a single-pane view'.
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?
Explicitly says 'Use this first for a single-pane view', implying it's the entry point. No explicit when-not or alternatives, but the sibling list provides context for other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-agent cost breakdown — total spend + request count + avg cost-per-request + primary provider/model + share of total spend, sorted by cost descending.
| Name | Required | Description | Default |
|---|---|---|---|
| window_hours | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only, destructive, or has auth/rate limits. Since it likely just queries data, a note about idempotency would be beneficial.
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 that efficiently lists all output fields and the sort order. No unnecessary 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?
The description explains the output well but omits the single input parameter entirely. Given no output schema, this is a notable gap for input comprehension.
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 one optional parameter (window_hours) with 0% schema description coverage. The description does not mention this parameter at all, failing to explain its meaning or effect on results. The description adds no value 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 it provides a per-agent cost breakdown with specific metrics (total spend, request count, avg cost-per-request, primary provider/model, share of total spend, sorted by cost descending). This distinguishes it from sibling tools like cost_overview (likely overall) or costs_by_provider.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied from the purpose (use when you need per-agent costs), but there is no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no mention of when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-provider cost breakdown — total spend + request count + token counts + share of total, sorted by cost descending.
| Name | Required | Description | Default |
|---|---|---|---|
| window_hours | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is responsible for behavioral disclosure. It mentions output metrics and sorting but omits key details such as that it is a read-only operation, how the time window (window_hours) affects results, or any limits/pagination.
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 concise sentence that front-loads the key information (what the tool returns and how it is sorted), with no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter, no output schema, and several siblings, the description fails to explain the parameter or provide usage guidance, making it incomplete despite adequately covering purpose and basic output.
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 one parameter (window_hours) with 0% description coverage in the schema. The description does not mention window_hours at all, leaving the agent unaware of how to specify the time range for the breakdown.
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 it provides a per-provider cost breakdown with specific metrics (total spend, request count, token counts, share of total) sorted by cost descending, which distinguishes it from siblings like costs_by_agent and cost_overview.
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 the tool is for per-provider breakdowns but does not explicitly state when to use it over alternatives like costs_by_agent or cost_overview, nor does it provide exclusions or context for when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Requests whose cost is threshold_multiplierx or more above their agent's median request cost. Default 3.0x. Surfaces giant-context-paste accidents, runaway loops, model regressions, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| window_hours | No | ||
| threshold_multiplier | No | Multiplier above agent median to flag (default 3.0, min 1.5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the tool flags requests exceeding a threshold, but does not disclose if it modifies data, requires permissions, or the format of returned anomalies. This is adequate but leaves gaps.
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 suffice to convey purpose, examples, and default values. Information is front-loaded and no unnecessary words are 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?
Given no output schema, the description could elaborate on the output format. However, the context of sibling cost tools and the clear examples provide sufficient completeness for a diagnostic tool.
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 50% with only threshold_multiplier having a description. The tool description adds meaning by explaining the purpose of threshold_multiplier (default 3.0x, min 1.5) and implies window_hours as a time window. This provides useful context 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 uses a specific verb 'find' and resource 'cost anomalies', clearly distinguishes from sibling tools like cost_overview or top_cost_drivers, and provides concrete use cases (giant-context-paste accidents, runaway loops).
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 detecting anomalous cost spikes with examples, but does not explicitly state when not to use it or compare to alternatives. However, the context of sibling tools makes its purpose distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Projects 30-day total spend from the observed window's run rate. Returns per-provider 30d projection + confidence note. Re-run with longer window for stability.
| Name | Required | Description | Default |
|---|---|---|---|
| window_hours | No | Hours of observed data to project from (default 168 = 7 days) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns a per-provider projection and confidence note and suggests re-running for stability, but does not explicitly state whether the operation is read-only or discuss any side effects or permissions needed.
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 three short, front-loaded sentences with no filler. Each sentence adds value: purpose, return structure, and usage advice. It is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description adequately covers what it does and returns (per-provider projection, confidence note). It is mostly complete, though it could specify the format of the projection or confidence level more precisely.
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 already provides 100% coverage (window_hours with description and default). The description adds no new parameter meaning beyond the schema, only context about stability. Baseline 3 is appropriate as the description does not detract but adds minimal extra 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 tool projects 30-day total spend from observed run rate, with a specific verb ('projects') and resource ('30-day total spend'). It distinguishes from sibling tools like cost_overview or costs_by_provider by focusing on forecasting rather than current breakdowns.
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 advises re-running with a longer window for stability, implying when to adjust the parameter, but it does not explicitly state when to use this tool versus alternatives like find_cost_anomalies or top_cost_drivers. No when-not or comparator guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggestions to route some volume to cheaper providers/models — e.g., claude-sonnet-4 → gemini-2.5-flash for extraction-style work, gpt-4o → gpt-4o-mini for short chats. Each rec includes 30d estimated savings.
| Name | Required | Description | Default |
|---|---|---|---|
| window_hours | No | Window over which to find candidates (default 720 = 30 days) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It lacks details on side effects (e.g., does it modify anything?), permissions, limitations, or how suggestions are generated. The description only states output (suggestions with savings) but not behavior beyond that.
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 two sentences, front-loaded with the main purpose, and uses concrete examples to clarify. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a recommendation tool but lacks details on output format, number of suggestions, or prerequisites (e.g., required cost data). Without output schema, more behavioral context would be helpful for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'window_hours' is fully described in the schema (coverage 100%). The description adds no additional meaning beyond what the schema provides, so baseline score of 3 applies.
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 it provides suggestions to route volume to cheaper providers/models, with specific examples and mention of 30d estimated savings. It is easily distinguishable from sibling tools which focus on cost analysis rather than 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?
The description does not explicitly state when to use this tool versus alternatives. While the sibling tool names give implicit context, there is no guidance on when to recommend routing vs. other cost actions, or exclusions for certain scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Highest-spend agents + models in the window — flat list, no per-provider or anomaly noise. Useful for 'where's our money going' digest format.
| Name | Required | Description | Default |
|---|---|---|---|
| window_hours | No | ||
| top_n | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that results are a flat list without per-provider or anomaly noise, which is sufficient for a simple query tool. Lacks mention of data freshness or side effects, but none expected.
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?
One concise sentence plus a usage suggestion; no filler words. Front-loaded with key information.
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 low complexity (2 optional params, no output schema), description adequately covers purpose, format, and use case. Could add details on output fields or ordering, but not critical for a digest.
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 0%, so description must compensate. It does not explicitly explain window_hours or top_n parameters, only implying a time window and top N via context. Defaults are in schema but not described.
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 explicitly states it identifies 'highest-spend agents + models' and contrasts with siblings by saying 'flat list, no per-provider or anomaly noise,' making purpose and differentiation clear.
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?
Explicitly suggests use case: 'where's our money going' digest format, and implicitly advises against using when per-provider breakdowns or anomalies are needed, referencing sibling tools.
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.0cost_overviewcosts_by_agentcosts_by_providerfind_cost_anomaliesforecast_monthly_costmodel_routing_recommendationstop_cost_driversScored across 7 tools
Each tool targets a distinct cost analysis aspect: overview, agent/provider breakdown, anomalies, forecasting, recommendations, and top drivers. No overlap in functionality.
All tool names use consistent lowercase underscore pattern, clearly indicating their purpose (e.g., cost_overview, find_cost_anomalies). Pattern is predictable and readable.
Seven tools is ideal for a focused cost tracker; each tool covers a specific need without redundancy or bloat.
Covers core cost analysis needs (overview, breakdowns, anomalies, forecasting, optimization). Minor gaps like filtering or export are acceptable given the scope.
Cost per run, tool, model and day for AI agents, from one call or an OpenTelemetry export.
Analytics for MCP servers. Query your tool calls, first-call success, retries and schema cost.
Agent Cost Allocator MCP — multi-tenant LLM cost attribution for chargeback billing. Companion to
Costory is the FinOps agent your team builds on. Claude plus a single provider's MCP works for one person and one cloud. It breaks when you add more providers, more people, and more tools to maintain. - Multiple providers: AWS, GCP, Azure, LLM APIs and data clouds normalized and allocated to teams and features in one model, including allocation from telemetry (Kubernetes, Datadog, dbt). - Multiple users: one hosted setup with OAuth, per-user access and enterprise SSO, instead of local credentials and prompts per person. - Maintained for you: tools, skills and connectors kept up to date by Costory, so reorgs and new services don't break your agent. Your agent finds savings, explains every change in spend and issues recommendations that your coding agent can implement. It works in Claude, Cursor and any MCP client, plus Slack. Customers include Alan, Deezer, Delivery Hero, Voodoo and Pennylane. Pricing: Starter from $300/month, flat: unlimited users and data sources, and a fair use that 80% of customers never outgrow. Nothing is ever cut off, and agents connected through the MCP use no AI credits. 30-day free trial.
