Skip to main content
Glama
bruhsb
by bruhsb

paperclip_report_cost_event

Record LLM token usage and cost for an agent to enable budget tracking and spend analytics. Logs input/output tokens, provider, model, and timestamp.

Instructions

Report an agent's token usage and cost event to Paperclip for budget tracking.

Args:

  • agentId: string — ID of the agent that incurred the cost (example: "agt_abc123")

  • provider: string — LLM provider name (example: "anthropic")

  • model: string — Model identifier (example: "claude-sonnet-4-6")

  • inputTokens: integer — Number of input tokens consumed

  • outputTokens: integer — Number of output tokens generated

  • costCents: number — Total cost in cents (non-negative)

  • occurredAt: string — ISO 8601 timestamp (example: "2026-04-16T12:00:00.000Z")

Returns: Returns the created cost event record: id, agentId, provider, model, costCents, occurredAt.

Examples:

  • Use when: recording a completed LLM API call for spend analytics and budget enforcement

  • Don't use when: you want a cost summary — use paperclip_get_cost_summary or paperclip_get_costs_by_agent

Error Handling:

  • 400: validation failure → check costCents ≥ 0, occurredAt is valid ISO 8601, tokens are integers

  • 401: authentication failed → check PAPERCLIP_API_KEY

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agentIdYesID of the agent that incurred the cost
providerYesLLM provider name (e.g. anthropic, openai)
modelYesModel name (e.g. claude-sonnet-4-6)
inputTokensYesNumber of input tokens consumed
outputTokensYesNumber of output tokens generated
costCentsYesTotal cost in cents
occurredAtYesISO 8601 timestamp of when the cost was incurred
Behavior4/5

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so description does not need to repeat that. It adds value by detailing error conditions, validation requirements (costCents ≥0, valid ISO 8601), and the return structure. 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.

Conciseness5/5

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

Description is well-organized with clear sections (Args, Returns, Examples, Don't use when, Error Handling). Each sentence adds unique value, no redundancy.

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 7-required-parameter tool with no output schema, the description covers all necessary aspects: purpose, parameters, return fields, usage guidance, and error handling. It is complete for reliable invocation.

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. Description adds examples for some fields (agentId, provider, model, occurredAt) and clarifies constraints (non-negative cost, integer tokens). This provides marginal extra value, justifying a score of 3.

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 it reports token usage and cost events for budget tracking, with examples. Distinguishes from sibling tools like paperclip_get_cost_summary and paperclip_get_costs_by_agent.

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?

Explicitly says when to use (recording a completed LLM API call) and when not to use (for cost summary, use alternatives). Provides error handling guidance for 400 and 401 errors.

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

Install Server

Other Tools

Latest Blog Posts

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/bruhsb/paperclip-mcp'

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