Admin: flag/unflag a meter as test/synthetic so its events are excluded from usage statistics by default. Touches meter metadata only — never events, never the hash chain, never billing accruals. Requires the server's VIRIDIS_ADMIN_TOKEN.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| is_test | Yes | ||
| meter_id | Yes | ||
| admin_token | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly details what the tool affects (meter metadata only) and crucially what it does not affect (events, hash chain, billing accruals). With no annotations provided, this clarity is essential and well provided.
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 concise with two sentences delivering purpose, scope, and authorization. No redundant information; every sentence adds value.
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 provides core purpose and constraints (auth, scope). An output schema exists, so return values need not be described. However, it lacks guidance on when to flag/unflag or how the test status interacts with other tools, but this is minor given the clear purpose.
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?
With 0% schema description coverage, the description must compensate but only mentions the admin_token requirement. Parameters like meter_id, is_test, and note are not explained, leaving the agent to infer from names. The description adds minimal semantic 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?
Description clearly states the action (flag/unflag), the resource (meter as test/synthetic), and the purpose (exclude events from usage statistics). It distinguishes itself from sibling tools like create_meter or list_meters by specifying an admin-only metadata update.
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 specifies a key prerequisite: requires the VIRIDIS_ADMIN_TOKEN. It implies administrative use through the 'Admin:' prefix, but does not explicitly state when to use this tool versus alternatives or 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.
Add one secure layer between your agents and this server.
Each tool targets a distinct aspect of usage metering: creating meters, recording events, generating reports, flagging synthetic data, closing periods, and verifying chain integrity. No two tools have overlapping purposes.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., close_period, create_meter, list_events). No deviations or mixed conventions.
With 11 tools, the set is well-scoped for a metering server. It covers creation, recording, listing, reporting, admin flags, period closing, and chain verification without being unnecessarily large.
The core lifecycle is covered: create meter, record usage, list events, generate reports, close period. Missing are tools to update/delete meters or retrieve invoices, but these are minor gaps given the immutable design intent.