Skip to main content
Glama

Chainstack

by com.chainstack

get_chainstack_pricing

Read-only

Fetch Chainstack's public pricing and return a normalized snapshot.

Use this to answer pricing questions before quoting the user: plan fit, overage math, per-chain dedicated-node costs, and add-on pricing (Unlimited Node flat-fee tiers, Yellowstone gRPC streams, Warp transactions, dedicated-node base rates).

This tool returns the menu, not the bill — the calling agent does the arithmetic. All prices are list prices in USD; disclaimers are surfaced in the disclaimers field.

Design: we pass pricing.md through as raw markdown. Marketing owns that file and its structure changes freely; parsing it server-side would couple us to heading text and table column names we don't control. The LLM reads markdown natively, so handing the raw text to the agent keeps us correct regardless of how the page is restructured.

pricing_current.json is parsed into dedicated_catalog because it has a stable engineering-owned schema, and the catalog benefits from filtering (to user-orderable SKUs only), unit conversion (cents → USD, milli-cores → cores), and region humanization (via region_legend).

Per-method RU billing rules are NOT in these sources. Plan-level rates (Full Node = 1 RU, Archive Node = 2 RU) are in the markdown, but some EVM archive-state methods (eth_getBalance, eth_call, eth_getProof, eth_getStorageAt, eth_getCode, eth_getTransactionCount, eth_callMany, eth_createAccessList) and all debug_* / trace_* methods are billed at 2 RU on a full node when called against old blocks. For method-level detail, call search_docs with "request units" or get_doc_page("docs/request-units").

No API key required — sources are fully public. Each call fetches both sources fresh (no caching), so a stale result isn't possible.

Returns: A dict with fields: - pricing_markdown: raw markdown from chainstack.com/pricing.md. Read this for plan tiers, feature matrix, add-on pricing, support levels, PAYG details, and provider comparisons. - dedicated_catalog: user-orderable per-chain dedicated-node SKUs with flavor, regions (as infra slugs like "sgp1"), hourly and monthly prices in USD. Already filtered to the ~87 orderable SKUs and unit-converted. - region_legend: slug → human city name map covering every region slug that appears in dedicated_catalog. Use region_legend[slug] to translate for display; regions keeps the slug as the canonical identifier. - disclaimers: list-price caveats (Enterprise "from" pricing, etc.). - sources: URL + ok/error per source; the JSON source carries its own updated_at. - warnings: populated when a source is unreachable or the JSON parser failed. The tool still returns best-effort results. - fetched_at: UTC timestamp of this call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourcesYes
warningsYes
fetched_atYes
disclaimersYes
region_legendYes
pricing_markdownYes
dedicated_catalogYes

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint, openWorldHint, destructiveHint), the description discloses the tool's freshness (fetches both sources fresh, no caching), lack of auth requirements, and best-effort behavior with warnings on source failures. This exceeds what annotations provide.

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

Conciseness4/5

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

The description is dense but well-structured, front-loaded with purpose and usage, then design rationale and return field semantics. Every sentence adds value, but the length is substantial; no fluff, but could be more compressed for a zero-param tool.

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 tool with no parameters and a rich output, the description is complete. It covers what the tool returns, how to interpret the fields (e.g., region_legend[slug]), error handling, and points to alternatives for RU rates. Even with an output schema, the semantic detail here is necessary.

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 input schema has zero parameters, so the description doesn't need to add parameter meaning. The baseline for 0 params is 4. The description includes relevant context (no API key required, fresh fetch) but nothing parameter-specific.

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 clearly states the tool 'Fetch Chainstack's public pricing and return a normalized snapshot.' It distinguishes from siblings by naming specific pricing use cases (plan fit, overage math, per-chain dedicated-node costs) and explicitly contrasts with search_docs for method-level billing.

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?

It explicitly says 'Use this to answer pricing questions before quoting the user' and provides exclusions: 'Per-method RU billing rules are NOT in these sources' with direct alternatives (search_docs, get_doc_page). Also clarifies the division of labor ('this tool returns the menu, not the bill').

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