Skip to main content
Glama

Chainstack

by com.chainstack

request_testnet_funds

Destructive

Top up a testnet address from Chainstack's faucet.

The faucet does not send a fixed amount — it tops the address up to the per-network maximum (e.g. 0.5 ETH for sepolia). If the address already sits above the cap, the call fails with an insufficient-balance error. Describe the behavior to the user as "top up" not "give", and surface the returned amountSent so they see the actual delta.

Supported networks and their native assets:

  • sepolia, hoodi — Ethereum testnets (ETH)

  • base — Base Sepolia (ETH)

  • amoy — Polygon Amoy (POL)

  • bnb-testnet — BNB Smart Chain testnet (BNB)

  • zksync-testnet — zkSync Sepolia (ETH)

  • robinhood — Robinhood Chain testnet (ETH)

  • hyperevm — HyperEVM testnet (HYPE)

  • plasma — Plasma testnet (XPL)

  • monad — Monad testnet (MON)

  • ton — TON testnet (TON)

  • solana — Solana devnet (SOL)

Per-address cooldown applies after each successful drip. On cooldown the faucet returns a nextFaucetAvailable timestamp (ISO 8601) that this tool surfaces in the error message.

Requires a Chainstack API key. The key is also the rate-limiting identity — the faucet tracks usage per organization. Get a key at https://console.chainstack.com/user/settings/api-keys and add it as Authorization: Bearer <key> in the MCP client config. Never ask the user to paste their API key in chat.

Args: network: Canonical testnet id (the schema enum advertises the set). Case-insensitive; common aliases are normalized to the canonical id. address: Destination address. EVM hex address for EVM networks, a TON address for ton, or a base58 Solana public key for solana. Validated server-side — format errors surface as 400.

Returns: On success: {network, amountSent, transaction}. amountSent is a string in the network's native unit (not wei/lamports).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
addressYes
networkYesTestnet to fund. Must be one of the canonical ids in `enum`. Common aliases (ethereum-sepolia, base-sepolia, solana-devnet, ...) are accepted and normalized to the canonical id.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
networkYes
amountSentNo
transactionNo

TDQS

A4.8/5.0
Behavior5/5

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

Annotations are minimal (readOnlyHint false, openWorldHint true, destructiveHint true), so the description carries the burden of behavioral disclosure. It goes far beyond: explains the non-fixed amount behavior, per-network caps, cooldown with nextFaucetAvailable timestamp, amountSent in native units, API key requirement and rate-limiting identity, and the instruction to describe the action as 'top up' rather than 'give' to set user expectations. No contradiction with annotations.

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?

The description is long but efficiently organized into sections: intro, behavior, network list, cooldown, auth, Args, Returns. Every sentence provides actionable information—even the phrasing guidance for user interaction. The front-loaded purpose makes the tool easily identifiable, and the structure supports quick reference.

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?

For a faucet tool with two parameters and no formal output schema, the description is remarkably complete. It covers return structure (network, amountSent, transaction), error conditions (cooldown timestamp, cap exceeded, format errors), supported networks, and authentication requirements. An agent has all information needed to select, invoke, and interpret the tool's result correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50% (address has no schema description). The description compensates fully: it explains network value normalization (case-insensitive, aliases), and details address format expectations per network (EVM hex, TON address, Solana base58), plus server-side validation yielding 400 errors. This adds significant meaning beyond the bare schema.

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?

The description opens with a specific verb+resource: 'Top up a testnet address from Chainstack's faucet.' It clearly identifies the tool's function and distinguishes it from sibling tools like create_node or list_nodes, which manage infrastructure rather than dispense testnet funds. The supported network list further clarifies scope.

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?

The description provides clear context on when to use the tool, including supported networks, required API key, and failure conditions (cap exceeded, cooldown). It does not explicitly name alternatives, but no direct alternative exists among siblings, so this is a minor gap. The guidance to never ask for the API key in chat is a valuable usage constraint.

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

All Chainstack toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

Each tool targets a distinct resource and action: nodes, projects, docs, pricing, status, org, faucet, and contact. There is no overlap between list/get, create/update/delete, or the doc search vs fetch tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (create_node, get_project, list_nodes, update_node, delete_project). Underscore separator and lowercase are used throughout with no mixed conventions.

Tool Count4/5

At 18 tools, the set is slightly above the typical 3-15 range but each tool serves a distinct purpose within the platform's domain. The count is appropriate for a platform with project, node, documentation, pricing, status, and faucet features.

Completeness5/5

The tool set provides full CRUD for both projects and nodes, plus deployment options, pricing, docs search/retrieval, platform status, organization info, testnet faucet, and a contact channel. There are no obvious dead ends for the workflows the server advertises.

Resources