Add credits when your $5 free balance runs out. Pay via USDC crypto (provide tx_hash) or get a Stripe checkout link for your human operator to complete.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount in USD to add | |
| method | Yes | Payment method | |
| api_key | Yes | Your API key | |
| tx_hash | No | USDC transaction hash (for crypto payments) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure. It states the operation (adds credits), mentions that USDC requires a tx_hash, and notes that Stripe generates a checkout link for a human operator. This gives some insight into the side effects and payment workflows, but doesn't mention details like processing time, fees, or what happens on failure. Adequate but not rich.
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, well-structured sentence that packs in the purpose, trigger, and two payment methods without wasting words. Every clause adds relevant 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 tool is relatively simple, with 4 parameters and no output schema. The description covers the essential context: when to use it, how to pay, and what information to provide. It doesn't describe the response format, but given the simplicity and lack of output schema, this is not a major gap. It also implies that tx_hash is required for USDC, which a human might need to know.
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 100%, so the baseline is 3. The description adds extra meaning by explaining that tx_hash is for USDC payments and that the Stripe method produces a checkout link for humans. It also clarifies the conditional nature of tx_hash ('provide tx_hash' for crypto payments), which is not obvious from the schema alone.
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's purpose: 'Add credits' when the free balance runs out. It identifies the resource (credits) and provides a precise trigger condition, distinguishing it from sibling tools like purchase_data (buying data) and check_balance (checking balance).
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 gives a clear usage trigger: 'when your $5 free balance runs out.' It also explains the two payment methods (USDC vs. Stripe) and when each applies. It doesn't explicitly mention alternatives like 'use purchase_data for data purchases,' but the context is sufficient.
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.
Most tools target distinct actions (register, list, purchase, fetch, verify). The only ambiguity is between get_zk_provenance and verify_footprint, both providing cryptographic proofs, but they serve slightly different purposes (record provenance vs dataset footprint).
All tools follow a consistent snake_case verb_noun pattern (e.g., list_datasets, purchase_data, check_balance), making the set predictable.
10 tools is appropriate for the server's scope, covering user management, data browsing, purchasing, and verification without redundancy.
The set supports the full workflow: register, browse products/datasets, purchase, fetch data, check/top-up credits, and verify provenance. Minor gap: no way to view purchase history or account details, but core functionality is complete.