Skip to main content
Glama
chrischall

gemini-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

gemini_token_usage

Read-only

Measure token usage and estimated USD cost for Gemini API calls. Call before and after a workflow, then subtract to attribute spend per call or session.

Instructions

Token usage for this session so far — what every generation has cost in tokens, added up. Call it before and after a workflow and subtract to get that workflow's cost; call it after a single generation for that call's. Reports tokens AND an estimated USD cost, priced per call against each call's own model and stamped with the date its rates were read (override with GEMINI_RATE_CARD). Note there is no account-balance endpoint to query — Google Cloud is post-paid and its billing data lags by hours — so this is the accurate way to attribute spend to a call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
resetNoZero the running total after reporting it, so the next call measures from here. Use it to bracket a workflow without arithmetic.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Addedv1.11.1

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only indicate readOnlyHint=true, and the description adds substantial behavioral context: it reports tokens and estimated cost, prices per model, stamps rates with a date, supports GEMINI_RATE_CARD override, and explains the post-paid billing limitation. No contradiction with annotations.

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 dense but every sentence earns its place: core purpose, usage pattern, output type, cost calculation nuance, and why this tool is necessary. It is front-loaded with the main function and avoids fluff.

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?

For a simple read-only tool with one optional parameter and no output schema, the description is complete: it explains scope, output content, usage patterns, the reset workflow indirectly, and the pricing/rate-card behavior. An agent has everything needed to call it correctly.

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 fully documents the reset parameter. The description adds useful context about cost calculation and rate-card override, but it does not add semantic detail about the parameter beyond what the schema provides. Baseline 3 is appropriate.

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

Purpose5/5

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

The description states a specific verb and resource: it reports cumulative token usage and estimated USD cost for the session. It clearly distinguishes itself from the generation and file-management siblings by being a meter/attribution tool rather than a generative or file operation.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use instructions: call before and after a workflow and subtract, or after a single generation. It also explains that no account-balance endpoint exists and billing data lags, positioning this tool as the reliable way to attribute spend.

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

Deploy Server

Other Tools