Skip to main content
Glama
Sign In

Agent Control — Action Gate

by net.agent-control
OverviewDiscussionsAdmin

Buy an Agent Meter pass

meter_buy_pass

Can I pay this address? Buy looks_20 pack ($0.20) or look $0.10. Stamp ticket $0.05. No inbox. Call with sku looks_20 (or omit) to buy a pack that mints/extends X-Agent-Pass. look $0.10 is optional one-shot. Returns a payable invoice as tool content (ok:true / status payment_required) with pay_to, base_pay_to, accepts (Base USDC EIP-3009 exact), amount_usd, amount_base_units, reference, pay_url (stored POST invoice only), watch_url, adapter_url, base_adapter_url, preferred_rail, pay_page, next_tool, tool_fields, sign_exact, adapter_snippet, next_steps. Pay Base EIP-3009 exact to base_pay_to then meter_watch with payment when the invoice has an invoice_id. Use sign_exact + adapter_snippet to finish in-process (payMeterPassBase / signTypedData). Fetch base_adapter_url only if you need the full file. A GET challenge has no invoice id: retry that request with PAYMENT-SIGNATURE. We never take keys. Packs: looks_20 / addresses_100 / stamp_tx. No human account.

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": "meter_buy_pass"
  }
}

Input Schema

NameRequiredDescriptionDefault
skuNoCatalog id from meter_pricing. Omit or looks_20 is the paid pack. look $0.10 is optional one-shot. Packs: looks_20, addresses_100, stamp_tx. pass_1h stays in catalog only.
proofNoPayment proof. { type: dev } only when METER_DEV_GRANT=1. Never send a secret key.
paymentNoOptional Base EIP-3009 exact payload. Same JSON as PAYMENT-SIGNATURE. Never send a secret key.
signatureNoOptional on-chain tx signature after you sign locally. Not a private key.
pass_tokenNoExisting X-Agent-Pass to extend with a pack.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / sku / description
      Previous value: -"Catalog id from meter_pricing. Omit or looks_20 is the pack after free-5. look $0.10 is optional one-shot. Packs: looks_20, addresses_100, stamp_tx. pass_1h stays in catalog only."New value: +"Catalog id from meter_pricing. Omit or looks_20 is the paid pack. look $0.10 is optional one-shot. Packs: looks_20, addresses_100, stamp_tx. pass_1h stays in catalog only."
  2. Changed1 schema field changed
    • changedInput schema / properties / sku / description
      Previous value: -"Catalog id from meter_pricing. Omit or looks_20 is the pack after 5 free. sku look is $0.10 one-shot. Packs: looks_20, addresses_100, stamp_tx. pass_1h stays in catalog only."New value: +"Catalog id from meter_pricing. Omit or looks_20 is the pack after free-5. look $0.10 is optional one-shot. Packs: looks_20, addresses_100, stamp_tx. pass_1h stays in catalog only."
  3. Changed3 schema fields changed
    • addedInput schema / properties / pass_token / description
      Added value: +"Existing X-Agent-Pass to extend with a pack."
    • addedInput schema / properties / payment
      Added value: +{
+  "description": "Optional Base EIP-3009 exact payload. Same JSON as PAYMENT-SIGNATURE. Never send a secret key.",
+  "type": "object"
+}
    • changedInput schema / properties / sku / description
      Previous value: -"Catalog id from meter_pricing. Default look (current door). Packs: looks_20, addresses_100, stamp_tx. pass_1h stays in catalog only."New value: +"Catalog id from meter_pricing. Omit or looks_20 is the pack after 5 free. sku look is $0.10 one-shot. Packs: looks_20, addresses_100, stamp_tx. pass_1h stays in catalog only."
  4. Changed3 schema fields changed
    • changedInput schema / properties / proof / description
      Previous value: -"Payment proof. { type: dev } only when METER_DEV_GRANT=1"New value: +"Payment proof. { type: dev } only when METER_DEV_GRANT=1. Never send a secret key."
    • addedInput schema / properties / signature
      Added value: +{
+  "description": "Optional on-chain tx signature after you sign locally. Not a private key.",
+  "type": "string"
+}
    • changedInput schema / properties / sku / description
      Previous value: -"look (default $0.02), looks_20 ($0.20), addresses_100 ($0.15), stamp_tx ($0.05). pass_1h stays in catalog only."New value: +"Catalog id from meter_pricing. Default look (current door). Packs: looks_20, addresses_100, stamp_tx. pass_1h stays in catalog only."
  5. Changed1 schema field changed
    • changedInput schema / properties / sku / description
      Previous value: -"pass_1h (default $0.25), pass_24h, calls_1k, stamp_tx, or scan_batch"New value: +"look (default $0.02), looks_20 ($0.20), addresses_100 ($0.15), stamp_tx ($0.05). pass_1h stays in catalog only."
  6. Changed1 schema field changed
    • changedInput schema / properties / sku / description
      Previous value: -"pass_1h"New value: +"pass_1h (default $0.25), pass_24h, calls_1k, stamp_tx, or scan_batch"
  7. Added

TDQS

A3.6/5.0
Behavior3/5

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

Annotations declare readOnlyHint=false and destructiveHint=false (a non-destructive write), and the description adds real context: it mints/extends X-Agent-Pass, returns a payable invoice with a documented field set, and states 'We never take keys' and 'No human account.' That is meaningful beyond the annotations. It falls short of a 5 because the invoice/payment mechanics are described in a compressed, partly overlapping way rather than cleanly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The content is information-dense and most of it earns its place, but it is delivered as a long, telegraphic run-on with a weak opener and a full field enumeration (pay_to, base_pay_to, accepts, etc.). Structure is only loosely organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the burden of explaining the return payload, and it does enumerate the invoice fields and the payment/signing flow. For a multi-step payment tool with nested objects, this is close to complete, though the ordering of steps could be clearer.

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 five parameters and their constraints. The description reinforces the sku values and the extend-vs-mint behavior but largely restates what the schema provides, so baseline 3 is appropriate.

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

Purpose4/5

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

The description states a concrete verb and resource ('Buy an Agent Meter pass'), names the three SKUs with prices, and ties the catalog to meter_pricing. It is clearly distinguishable from siblings, though the 'Can I pay this address?' opener and dense phrasing muddy the front edge slightly.

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 concrete routing: call with sku looks_20 or omit to buy a pack, then meter_watch with payment when the invoice has an invoice_id, and retry a GET challenge with PAYMENT-SIGNATURE when there is no invoice id. It names meter_watch and meter_pricing as the adjacent tools, though it doesn't state explicit when-not conditions.

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

All Agent Control — Action Gate toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources