Hash Encoding Direct Credits

Get payment information

get_payment_info

Read-onlyIdempotent

Return the complete purchase and redemption instructions for this service's prepaid API credits. Use this before paying or when an agent needs the Base Mainnet network, native USDC contract, receiver address, exact package amount, credit quantity, buyer-gas requirement, or redemption steps. This call is free and does not require a bearer token. It does not return a balance; use get_credit_balance after you already have a redeemed bearer token. This payment scheme is direct USDC credits, not x402.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`asset`	Yes	Native Circle USDC contract address on Base Mainnet.
`scheme`	Yes	Payment scheme identifier: direct-usdc-credits-v1.
`chainId`	Yes	EVM chain ID for Base Mainnet.
`network`	Yes	CAIP-2 network identifier for Base Mainnet.
`packages`	Yes	Available prepaid credit packages.
`receiver`	Yes	Public wallet address that receives the exact USDC package payment.
`redeemFlow`	Yes	Ordered manual API steps required to redeem a qualifying payment into API credits.
`buyerPaysGas`	Yes	Whether the buyer pays the on-chain transaction gas.
`purchasePath`	Yes	Same-origin browser path for the self-service purchase and redemption flow.
`assetDecimals`	Yes	USDC decimal precision.
`x402Compatible`	Yes	Whether this direct-credit flow is x402-compatible.
`facilitatorRequired`	Yes	Whether a payment facilitator is required.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 7, 2026

addedOutput schema / properties / purchasePath

Added value: +{
+  "description": "Same-origin browser path for the self-service purchase and redemption flow.",
+  "type": "string"
+}

changedOutput schema / properties / redeemFlow / description

Previous value: -"Ordered steps required to redeem a qualifying payment into API credits."New value: +"Ordered manual API steps required to redeem a qualifying payment into API credits."

changedOutput schema / required

Previous value: -[
-  "scheme",
-  "network",
-  "chainId",
-  "asset",
-  "assetDecimals",
-  "receiver",
-  "packages",
-  "buyerPaysGas",
-  "facilitatorRequired",
-  "x402Compatible",
-  "redeemFlow"
-]New value: +[
+  "scheme",
+  "network",
+  "chainId",
+  "asset",
+  "assetDecimals",
+  "receiver",
+  "packages",
+  "buyerPaysGas",
+  "facilitatorRequired",
+  "x402Compatible",
+  "purchasePath",
+  "redeemFlow"
+]

Changed1 schema field changedOct 7, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "asset": {
+      "description": "Native Circle USDC contract address on Base Mainnet.",
+      "type": "string"
+    },
+    "assetDecimals": {
+      "description": "USDC decimal precision.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "buyerPaysGas": {
+      "description": "Whether the buyer pays the on-chain transaction gas.",
+      "type": "boolean"
+    },
+    "chainId": {
+      "description": "EVM chain ID for Base Mainnet.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "facilitatorRequired": {
+      "description": "Whether a payment facilitator is required.",
+      "type": "boolean"
+    },
+    "network": {
+      "description": "CAIP-2 network identifier for Base Mainnet.",
+      "type": "string"
+    },
+    "packages": {
+      "description": "Available prepaid credit packages.",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "amountAtomic": {
+            "description": "Exact USDC amount in atomic 6-decimal units.",
+            "type": "string"
+          },
+          "credits": {
+            "description": "Credits issued after successful redemption.",
+            "exclusiveMinimum": 0,
+            "maximum": 9007199254740991,
+            "type": "integer"
+          }
+        },
+        "required": [
+          "amountAtomic",
+          "credits"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "receiver": {
+      "description": "Public wallet address that receives the exact USDC package payment.",
+      "type": "string"
+    },
+    "redeemFlow": {
+      "description": "Ordered steps required to redeem a qualifying payment into API credits.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "scheme": {
+      "description": "Payment scheme identifier: direct-usdc-credits-v1.",
+      "type": "string"
+    },
+    "x402Compatible": {
+      "description": "Whether this direct-credit flow is x402-compatible.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "scheme",
+    "network",
+    "chainId",
+    "asset",
+    "assetDecimals",
+    "receiver",
+    "packages",
+    "buyerPaysGas",
+    "facilitatorRequired",
+    "x402Compatible",
+    "redeemFlow"
+  ],
+  "type": "object"
+}

First observedOct 7, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds materially new behavior: the call is free, requires no bearer token, and the payment scheme is direct USDC credits rather than x402. These are exactly the facts an agent needs and that structured fields cannot express.

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?

Four tight sentences with no filler; the core purpose is front-loaded, followed by usage, cost/auth facts, and the sibling handoff. Every sentence carries distinct, actionable information.

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?

Even though an output schema exists (so return values needn't be explained), the description fully covers the agent's decision needs: cost, auth, scope limits, sibling routing, and scheme disambiguation. Nothing required to call this tool correctly is missing.

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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It usefully enumerates the data the response carries (network, USDC contract, receiver address, amount, credit quantity, gas, redemption steps), which compensates by characterizing output rather than inputs.

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?

States a specific verb and resource ('Return the complete purchase and redemption instructions for prepaid API credits') and explicitly distinguishes itself from the sibling get_credit_balance as well as from the x402 scheme. An agent can identify and differentiate this tool without opening any schema.

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?

Gives explicit when-to-use ('before paying or when an agent needs the Base Mainnet network...') and explicit when-not ('does not return a balance; use get_credit_balance after you already have a redeemed bearer token'). The alternative tool and the selecting condition are both named.

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

All Hash Encoding Direct Credits tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?