LLM Usage & Cost Tracker

by zhaoyue722

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.2
Disambiguation5/5
Each tool has a clearly distinct purpose: compare_providers for cost projection, get_pricing for current rates, list_providers for provider info, query_spend for spending breakdown, recommend_provider for cheapest model, record_usage for logging calls, and usage_summary for period summaries. No overlap in functionality.
Naming Consistency4/5
Most tools follow a consistent verb_noun snake_case pattern (e.g., compare_providers, get_pricing, list_providers, query_spend, recommend_provider, record_usage). The only minor deviation is 'usage_summary' which is noun_noun but still clear and fits the style.
Tool Count5/5
With 7 tools, the set is well-scoped for an LLM usage and cost tracker. It covers listing, comparing, recommending, recording, and querying without being overwhelming or sparse.
Completeness4/5
The server provides core functionality for tracking usage and costs, including recording, querying, and cost projection. Minor gaps exist: no tool to update/delete usage records or manage provider/pricing data, but these are likely intentional for a read-focused tracker.
Average 4.2/5 across 7 of 7 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 49 commits in the last 12 weeks
- Last stable release on July 7, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses automatic cost computation and idempotency. However, it does not describe side effects such as failure handling, whether it updates existing records, or other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but its brevity sacrifices essential detail, especially parameter descriptions. It is not as helpful as it could be.
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 13 parameters and the presence of an output schema (not detailed), the description is incomplete. It lacks parameter explanations and output behavior, making it insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explanation for any of the 13 parameters (4 required). With 0% schema description coverage, the tool fails to help the agent understand parameter meaning 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 records a single LLM API call with token counts, and mentions automatic cost computation and idempotency. It distinguishes from sibling tools like query_spend or usage_summary, which are read-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for recording API calls, but does not explicitly state when not to use it or suggest alternative tools. The mention of idempotent recording via request_id provides some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries burden and adds behavioral context: filter combination logic and empty list return for unknown pairs. Does not cover rate limits or auth, but provides key behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by behavioral detail. No wasted words, efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, description explains key return behavior (empty list). Could mention output schema fields briefly, but is complete enough for selection. Slightly more detail on output would improve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains parameters as filters (model, provider) and their optionality, but lacks individual parameter details like format. Adequate but not thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Return current pricing for one model, one provider, or all models,' specifying the verb (return) and resource (pricing), and distinguishes from sibling tools that handle providers, comparisons, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains that both filters are optional and AND-combined, and describes behavior for unknown (provider, model) returning empty list, which guides usage. Could explicitly state when to use vs alternatives, but sibling differentiation is clear from purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the list depends on pricing_snapshot, that unseeded providers are omitted, and ordering is alphabetical. These are useful behavioral traits for a read-only list operation.
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 clear and front-loaded with the main purpose. It uses multiple sentences but each provides necessary detail about source, provider selection, and ordering. Could be slightly more terse, but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (not shown, but indicated), the description does not need to detail return values. It explains the source, ordering, and which providers appear. For a zero-parameter list tool, this is complete and informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description compensates by explaining the output content (models, flag) and ordering. This adds value beyond the empty schema, earning a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List every provider we know about, with their models and OpenAI-compat flag.' It specifies the action (list) and resource (providers), and adds details about what is included (models, flag) and ordering. This distinguishes it from sibling tools like compare_providers and get_pricing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that providers appear only if pricing is seeded, and after bootstrap it includes specific providers. However, it does not explicitly state when to use this tool versus alternatives, such as when to use compare_providers or get_pricing instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It explains the date boundaries, exclusions for failures, and the return of largest_call=None when empty. It does not explicitly state read-only nature but is thorough for a non-destructive tool.
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?
Every sentence is useful. The description is front-loaded with the main purpose, followed by parameter details in a clear and structured format. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 optional params and an output schema exists (though not provided), the description covers the essential behavior and edge cases. It could mention output currency or read-only nature, but it is complete for its intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description fully explains both parameters: period with enum values and calendar boundaries, include_failed with default and effect on totals/rollups. This adds complete meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns a one-shot summary of usage over a calendar period. It uses a specific verb 'return' and resource 'usage summary', and clearly distinguishes from sibling tools like query_spend (detailed query) and record_usage (recording).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for quick summaries but does not explicitly state when to use this tool over alternatives like query_spend or compare_providers. No when-not or alternative references provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does so thoroughly. It explains the output format (ranked by absolute cost, relative_cost_pct, variant_count), dedup behavior, snapshot inclusion, and that 'notes' is always None in v1. No behavioral traits are hidden.
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 slightly verbose but front-loads the main purpose. Each sentence adds value, though some details (like 'notes is always None') could be omitted or moved to an output schema. Overall structured well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers essential aspects: input parameters, dedup logic, and output ranking. An output schema exists (though not fully shown), and the description complements it. Minor gaps: no mention of error cases or rate limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning: 'models' restricts comparison, 'include_snapshots' controls dedup, and token parameters are implied. However, it does not explicitly restate the required token parameters' roles, though they are self-explanatory from their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Project the cost of a hypothetical workload across providers/models.' It uses a specific verb ('Project') and resource ('cost'), and distinguishes from siblings like 'list_providers' by focusing on cost projection and ranking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (for cost projection) and explains options like 'include_snapshots' and 'models'. However, it does not explicitly differentiate from sibling tools such as 'get_pricing' or 'recommend_provider', leaving some ambiguity about when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully discloses behavioral traits: tag semantics (NULL exclusion, multi-tag duplication), project semantics, ordering by cost-desc, and include_failed purpose (debugging vs honest spend). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with front-loaded purpose and detailed parameter explanations. It is slightly long but every sentence adds value. Minor redundancy in tag semantics, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, 1 enum, and a nested object, the description covers all input semantics comprehensively. An output schema exists but is not shown, so no need to explain return values. Complete for effective tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining each parameter: start/end format and default, group_by enum values, filter predicates, and include_failed meaning. Adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns spending broken down by a chosen axis over a time window. It specifies the verb "return" and resource "spending" with clear breakdown dimensions, distinguishing it from siblings like compare_providers and usage_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on default behavior (e.g., 30-day window, include_failed=False) but does not explicitly state when to use this tool versus alternatives like compare_providers or usage_summary. No exclusions or when-not-to-use guidance are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavioral traits: v1 cost-only, default token values, budget fallback, whitelist AND-combination, error on unmatched whitelist, and non-functional task_description. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer but well-structured with clear sections. Every sentence adds value, though slight trimming could be possible. Front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no required, no annotations), the description is extremely complete. It covers return reasoning, fallback behaviors, error cases, and future plans. The output schema exists but is not needed for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining each parameter's effect: models/providers as whitelists, budget_usd as filter with fallback, task_description as echoed only, and token defaults. Adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Recommend the cheapest priced model that fits the workload + budget.' It uses a specific verb ('Recommend') and resource ('cheapest priced model'), and distinguishes from sibling tools like compare_providers and get_pricing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed guidance on default behaviors, budget fallback, whitelist logic, and optional parameters. While it doesn't explicitly contrast with siblings, the context is clear enough for an agent to decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![llm-usage-mcp MCP server](https://glama.ai/mcp/servers/zhaoyue722/llm-usage-mcp/badges/card.svg)](https://glama.ai/mcp/servers/zhaoyue722/llm-usage-mcp)

Score Badge

Copy to your README.md:

[![llm-usage-mcp MCP server](https://glama.ai/mcp/servers/zhaoyue722/llm-usage-mcp/badges/score.svg)](https://glama.ai/mcp/servers/zhaoyue722/llm-usage-mcp)

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/zhaoyue722/llm-usage-mcp'

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