agent-metering
Server Details
Usage metering + SLA accounting for agent services — the meter behind x402.
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.3/5 across 8 of 8 tools scored. Lowest: 2/5.
Each tool has a clearly distinct purpose covering different aspects of metering: creation, recording, listing, summaries, closing, SLA, and chain verification. The only outlier, describe_agent, is a standard introspection tool and does not cause confusion.
Tools follow a consistent verb_noun pattern in snake_case (e.g., close_period, create_meter, list_meters, record_usage, verify_chain). Even acronyms like sla_report fit the pattern.
With 8 tools, the server covers the essential metering operations without being bloated or sparse. Each tool earns its place in the workflow.
The core metering lifecycle is well-covered (create, record, list, summarize, close, verify). Minor gaps exist, such as lacking a tool to retrieve a specific meter's full details or to fetch the invoice generated by close_period, but these are not critical dead-ends.
Available Tools
8 toolsclose_periodAInspect
Freeze all open events into an immutable invoice (exactly-once). The invoice amount is what agent-escrow-agent should settle.
| Name | Required | Description | Default |
|---|---|---|---|
| meter_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'immutable invoice' and 'exactly-once', indicating idempotency and irreversibility. However, it does not disclose what happens if the period is already closed or if there are side effects beyond freezing.
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?
Two sentences front-load the key action and consequence. Every sentence adds value with no unnecessary words.
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?
Given the tool has an output schema, the description does not need to explain return values. However, for a mutation tool with no annotations, it lacks details on prerequisites (e.g., at least some usage recorded) and error conditions. It is adequate but minimal.
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?
The only parameter, meter_id, is not described in the description. With 0% schema description coverage, the description adds no meaning beyond the schema, leaving the agent to guess its role (likely identifying which meter's period to close).
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?
The description clearly states the tool freezes open events into an immutable invoice, using the verb 'freeze' and specifying the result is an invoice. This distinguishes it from sibling tools like 'record_usage' or 'create_meter', as it closes a billing period.
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 implies usage when you want to finalize a period and generate an invoice, with 'exactly-once' hinting at idempotency. However, it does not explicitly state when not to use it or mention prerequisites like having recorded usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_meterCInspect
Create a usage meter between a provider and a consumer agent.
unit: what is being counted (call, token, kwh, ...). Price is in minor
currency units (cents) per unit. Returns the meter_id.| Name | Required | Description | Default |
|---|---|---|---|
| unit | Yes | ||
| consumer | Yes | ||
| currency | No | USD | |
| provider | Yes | ||
| sla_target | No | ||
| price_minor_per_unit | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions return of meter_id but does not disclose side effects (e.g., persistent creation), authentication needs, or behavior for missing parameters. Partial coverage of unit and price_minor_per_unit only.
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?
Description is concise with two sentences and parameter explanation, but lacks structured separation of purpose and parameter details. Efficient for its length.
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?
Given 6 parameters, no annotations, and an output schema, the description is incomplete. It does not cover all parameters or provide context for prerequisites or error conditions. For a creation tool, more detail is needed.
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?
Schema description coverage is 0%, so description should compensate. It explains unit and price_minor_per_unit, but ignores 4 of 6 parameters: provider, consumer, currency, sla_target. Insufficient addition to 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 tool creates a usage meter between a provider and consumer agent, with specific verb and resource. It is distinguishable from sibling tools like list_meters and record_usage.
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?
No guidance on when to use this tool versus alternatives, no prerequisites mentioned. The description only states what it does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_agentCInspect
Fleet-standard self-description.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose any behavioral traits (e.g., read-only, side effects, rate limits). 'Self-description' gives no insight into behavior.
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?
Extremely short but under-specified. Every sentence should earn its place; this single phrase is too vague to be useful.
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?
Despite having an output schema, the description is too brief to guide the agent. Jargon like 'Fleet-standard' is undefined. No context about the tool's role among siblings.
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?
Schema has zero parameters (100% coverage). Description adds minimal meaning ('self-description'), but baseline for 0 params is 3 (not 4 because description adds little value).
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 says 'self-description' but does not specify what entity it describes. 'Fleet-standard' is vague jargon. It fails to clearly state the tool's purpose.
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?
No guidance on when to use this tool vs alternatives. No context about typical usage scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_metersAInspect
List all meters with event/invoice counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description implies a read-only operation, but does not disclose potential side effects, authorization needs, or rate limits. The listed outputs (event/invoice counts) add some context, but deeper behavioral traits are missing.
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 a single, clear sentence that gets straight to the point with no redundancy.
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?
Given the simplicity of the tool (zero parameters, output schema provided), the description is nearly complete. It could mention that the operation is read-only, but this is implied.
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?
There are no parameters, and schema coverage is 100%. The description neither adds nor needs to add parameter information. The baseline of 4 applies here.
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?
The description clearly states the verb 'list' and the resource 'meters', and specifies that event/invoice counts are included. This effectively distinguishes it from sibling tools like create_meter or close_period.
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 implies its use for retrieving all meters, but does not provide explicit guidance on when to use it versus alternatives, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
record_usageBInspect
Record a usage event. Idempotent on event_id (safe to retry — never double-billed). outcome is 'ok' or 'error' and feeds the SLA report.
| Name | Required | Description | Default |
|---|---|---|---|
| outcome | No | ok | |
| event_id | Yes | ||
| metadata | No | ||
| meter_id | Yes | ||
| quantity | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden. It discloses idempotency (safe to retry, no double billing) and possible outcome values. Missing are authentication needs, side effects, or whether it modifies state beyond insertion. Adequate but not thorough.
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?
Two well-structured sentences with no waste. The purpose is front-loaded, and essential behavioral notes (idempotency, outcome) are included.
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?
Given the output schema exists, return value explanation is not needed. However, several input parameters are undocumented, and there is no mention of prerequisites or error conditions. The description covers idempotency and outcome but lacks completeness for a full understanding.
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?
Schema coverage is 0%, so description must compensate. It only explains 'outcome' (ok/error) and implies 'event_id' is the idempotency key. No meaning added for 'meter_id', 'quantity', or 'metadata'. This is insufficient for a 5-parameter tool.
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?
The description clearly states 'Record a usage event' with a specific verb and resource. It adds detail about idempotency and outcome, but does not explicitly contrast with sibling tools like 'usage_summary' or 'sla_report', though the resource is distinct enough.
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?
It mentions idempotency and that outcome feeds the SLA report, which hints at appropriate usage. However, it does not provide explicit when-to-use or when-not-to-use guidance relative to siblings, nor does it list prerequisites like meter existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sla_reportAInspect
Pure SLA report: success_rate vs sla_target, breach flag. No mutation.
| Name | Required | Description | Default |
|---|---|---|---|
| meter_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool is read-only ('No mutation') and describes output fields, but omits details like whether it is idempotent, cost implications, or access requirements, which would be valuable for a reporting tool.
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 single-sentence description is extremely concise, conveying purpose, key output fields, and behavioral trait with zero wasted words. It front-loads the core information.
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?
Despite having an output schema, the tool's single required parameter is undocumented both in schema and description. The description fails to explain what meter_id represents or how to use it, which is critical for a tool with no annotation support.
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?
The only parameter, meter_id, has 0% schema description coverage, and the description does not mention it at all. There is no guidance on format, allowed values, or how to obtain a valid meter_id, leaving the agent to infer from the schema's minimal label.
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?
The description clearly states the tool produces an SLA report comparing success_rate to sla_target with a breach flag, explicitly indicating a read-only operation. This distinguishes it from sibling tools like close_period or create_meter which involve mutations.
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 provides clear context about the tool's purpose (SLA reporting) and explicitly notes it is non-mutating, but does not directly state when to use it over alternatives like usage_summary, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
usage_summaryBInspect
Totals for a meter: event count, total quantity, accrued minor units.
| Name | Required | Description | Default |
|---|---|---|---|
| meter_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description lists output fields but does not explain side effects (read-only), error conditions, or authentication needs. It is minimally transparent.
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?
One sentence containing the core purpose and outputs. No redundant information.
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 is adequate for a simple tool with an output schema, but it omits prerequisites (meter existence) and fails to integrate with the sibling context. Could mention usage context.
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?
The single parameter meter_id has 0% schema description coverage. The description only says 'for a meter', adding little semantic meaning beyond the parameter name. No format or example provided.
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?
The description clearly states it provides 'Totals for a meter' and specifies the returned fields: event count, total quantity, accrued minor units. It distinguishes from sibling tools like record_usage (recording) and list_meters (listing).
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?
No guidance on when to use this tool versus alternatives such as sla_report or list_meters. Neither prerequisites nor exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_chainBInspect
Verify the tamper-evident event hash chain for a meter.
| Name | Required | Description | Default |
|---|---|---|---|
| meter_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'verify'. No mention of read-only nature, side effects, authorization needs, or outcomes if the chain is invalid.
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?
Extremely concise single sentence that front-loads the action. No unnecessary words.
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?
For a simple tool with one parameter and an output schema, the description is minimal. It lacks explanation of the concept 'tamper-evident event hash chain' or what the output contains, which would aid completeness.
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?
Schema coverage is 0%, and the description adds no meaning to the only parameter 'meter_id' beyond its name. No format, source, or usage hints are provided.
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?
The description clearly states the action ('verify') and the resource ('tamper-evident event hash chain for a meter'). It distinguishes this tool from siblings like list_meters or record_usage.
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?
No guidance on when to use this tool versus alternatives. No prerequisites or context for when verification is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!