Chainstack

contact_chainstack

Destructive

Submit a message to Chainstack's sales and support team.

Use when the user wants to ask about pricing, get a custom quote, request a plan upgrade, request node customizations (Enterprise), report a problem, or reach Chainstack for any reason. Posts to the same contact form as chainstack.com/contact/.

Before calling this tool

CRITICAL — follow these steps EVERY time:

Draft the message based on your conversation context.
Show the user the EXACT message, email, and name you will send.
If the user has a Chainstack API key configured, tell them: "I'll also include your Chainstack account info (org name and ID) so the team can pull up your account immediately — this means significantly faster handling and a more tailored response."
Ask: "Shall I send this to Chainstack? Please confirm there's no sensitive information you'd like removed."
Only call this tool after the user explicitly confirms.

NEVER include in the message:

API keys, tokens, passwords, private keys, wallet seeds, mnemonics
RPC endpoint URLs (Chainstack or any other provider)
Wallet addresses, transaction hashes, or on-chain account details the user hasn't approved sharing
Any information the user hasn't explicitly approved sharing

If the user shared sensitive data during the conversation, do NOT include it unless they specifically approve it in the review step.

Writing an effective message

A great message gets the user a faster, more tailored response. Include what you already know from the conversation:

What they're building and at what scale
Current plan and usage (e.g., "Pro plan, ~80M RU/month on Base")
What they need (upgrade, custom pricing, migration help, etc.)
What they've tried or what's not working
Specific numbers when available

Bad: "I have a question about pricing." Good: "Pro plan user running 200M RU/month across Base and Ethereum, evaluating Business plan for archive access and higher RPS. Looking for annual pricing or a trial."

The difference between a generic reply and a tailored proposal is the context you include.

Not for incidents or urgent outages — point users to https://support.chainstack.com/hc/en-us/requests/new to file a support ticket, and https://status.chainstack.com for live status.

For feature requests, do NOT use this tool — point users to https://ideas.chainstack.com (product) or https://github.com/chainstacklabs/mcp-server/issues/new (MCP server).

Works with or without a Chainstack API key. With a key, the submission includes the user's Chainstack org info for faster account identification and handling.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	User's name (full name is fine, will be split on first space). Required. Ask the user if you don't have it on hand.
`email`	Yes	User's contact email. Required. Ask the user if you don't already have it.
`message`	Yes	The full message to send. Compose from conversation context — what the user is building, their plan and usage, what they need — so the Chainstack team can respond with a tailored answer instead of a generic one.
`category`	No	Routing hint. One of: - sales — pricing, quotes, plan upgrades, custom terms. - support — errors, bugs, how-to, "something isn't working". - general — everything else. Case-insensitive. Unknown values fall back to "general". Default: "general".	general

Output Schema

TableJSON Schema

Name	Required	Description	Default
`submitted`	Yes
`lead_source`	Yes
`alternative_channels`	Yes
`estimated_response_time`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 6, 2026

addedInput schema / properties / category / description

Added value: +"Routing hint. One of:\n- sales — pricing, quotes, plan upgrades, custom terms.\n- support — errors, bugs, how-to, \"something isn't working\".\n- general — everything else.\nCase-insensitive. Unknown values fall back to \"general\".\nDefault: \"general\"."

addedInput schema / properties / email / description

Added value: +"User's contact email. Required. Ask the user if you don't\nalready have it."

addedInput schema / properties / message / description

Added value: +"The full message to send. Compose from\nconversation context — what the user is building, their plan\nand usage, what they need — so the Chainstack team can respond\nwith a tailored answer instead of a generic one."

addedInput schema / properties / name / description

Added value: +"User's name (full name is fine, will be split on first space).\nRequired. Ask the user if you don't have it on hand."

First observedAug 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations (openWorldHint, destructiveHint) are supplemented with rich behavioral context the structured fields cannot carry: a mandatory confirm-with-user workflow, an explicit prohibition list on sensitive data, the API-key behavior affecting org info inclusion, and the fact that submissions hit the same backend as chainstack.com/contact/. Nothing here contradicts the annotations.

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?

Long but front-loaded and sectioned with headers so an agent can parse it quickly. Every section (prerequisites, sensitive data, message quality, routing exclusions) carries operational weight, though the confirmation steps and the 'writing an effective message' rationale repeat the privacy rationale slightly.

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?

An output schema exists, so return values need no explanation. For a 4-param, open-world mutation tool with privacy implications, the description covers safety, prerequisites, alternatives, and message composition thoroughly — nothing an agent needs 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond it: guidance on composing the message for a tailored response, the fact that name is split on first space, and routing semantics for category (sales vs support vs general). This is genuinely additive rather than restated.

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 ('Submit a message to Chainstack's sales and support team') and enumerates the trigger scenarios (pricing, quotes, upgrades, customizations, problem reports). No sibling tool does anything comparable, so an agent can distinguish it immediately.

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?

Explicitly names alternatives and exclusions: incidents/outages route to the support ticket URL and status page, feature requests route to ideas.chainstack.com or GitHub. The 'when to use' list is concrete and the negative cases are spelled out.

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

All Chainstack tools Inspect

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.