Skip to main content
Glama

usage_ia_claude

Reads Claude API token consumption and invoices from a usage folder, returning totals, monthly breakdowns by project and model, rankings, and invoice lists; optionally filters to one YYYY-MM month.

Instructions

Usage de l'API Claude de l'utilisateur : tokens consommés et factures, lus en direct depuis le dossier usage/ (réglable par PILOTAGE_DOSSIER_USAGE). Source des tokens : un export CSV par mois (un token compte pour de l'entrée, cache compris, ou de la sortie), déposé à la main par l'utilisateur. Source des factures : un tableau tenu à la main, indépendant des exports de tokens (il mélange abonnement et usage mesuré, les montants ne se déduisent pas des tokens). Sans paramètre, renvoie la période complète : totaux, détail mois par mois avec répartition par projet et par modèle, classement des projets et des modèles sur toute la période, et la liste des factures. Avec « mois », se concentre sur un seul mois (répartition par projet et par modèle de ce mois-là uniquement) ; les factures restent toujours renvoyées en entier car leurs dates ne correspondent pas forcément au mois d'usage. Utile pour écrire un article de blog transparent sur le coût ou l'usage de l'IA : les chiffres sont prêts à citer, avec leurs libellés en clair. Strictement en lecture : ne modifie jamais les fichiers du dossier usage/.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "usage_ia_claude"
  }
}

Input Schema

NameRequiredDescriptionDefault
moisNoMois précis à isoler, au format AAAA-MM. Si absent, toute la période disponible est renvoyée.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full burden and does so thoroughly: it declares strict read-only behavior (never modifies files in usage/), explains data provenance (hand-placed monthly CSV for tokens, separately hand-maintained invoice table), and warns that invoice amounts cannot be derived from token counts because subscription and measured usage are mixed.

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?

Front-loaded with purpose before provenance and mode behavior, and every sentence contributes (sources, default behavior, month behavior, read-only guarantee). It is a single dense block, so a line break or two around the parameter modes would improve scannability, but there is no filler.

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?

No output schema exists, so the description must describe returns and it does: totals, month-by-month detail with per-project and per-model splits, rankings across the whole period, and the invoice list. Combined with the read-only guarantee and provenance notes, an agent has everything needed to call it correctly and interpret results.

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 coverage is 100%, so the format AAAA-MM is already documented, but the description adds real meaning: the month filter narrows only the per-project and per-model breakdown, while invoices are always returned in full because their dates may not match the usage month. That nuance is not inferable from the schema alone.

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?

Opens with a specific verb and resource: reading the user's Claude API usage (consumed tokens and invoices) live from the usage/ folder. It also names the configurable location (PILOTAGE_DOSSIER_USAGE) and distinguishes the resource from anything the sibling tools (projets, git, fichiers) cover.

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?

Gives a concrete use case (writing a transparent blog post about AI cost/usage with citable figures) and spells out the two invocation modes: no parameter for the full period, « mois » for a single month. It does not name an alternative tool to prefer or avoid, but no sibling in the list appears to overlap with usage/cost data.

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