Chainstack

Contact 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 their org name and ID will be included so the team can find their account and reply faster.
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, on-chain account details, or anything else the user hasn't explicitly approved sharing

Writing an effective message

Include what you know: what they're building and at what scale, current plan and usage, what they need, what they've tried, and specific numbers.

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."

Not for incidents or urgent outages — point users to https://support.chainstack.com/hc/en-us/requests/new and https://status.chainstack.com. Not for feature requests — point users to https://ideas.chainstack.com (product) or https://github.com/chainstacklabs/mcp-server/issues/new (MCP server).

Works with or without an API key; with one, the org info is attached.

Input 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

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.6/5.0

Behavior4/5

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

The description does real work beyond the annotations: it discloses a mandatory draft-show-confirm workflow, that the message posts to an external contact form, that org name/ID is attached when an API key exists, and a concrete prohibition list on sensitive content. The only gap is that it never says whether the user gets a transcript or confirmation back — but an output schema exists, so that is partly covered elsewhere.

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?

Well front-loaded: purpose, then pre-call checklist, then message guidance, then exclusions. It is long and repeats some message-composition guidance already present in the message parameter description, but the headings make it scannable and most lines carry actionable instruction.

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 non-idempotent, externally-posting tool with destructiveHint=true, the description supplies exactly the missing context: consent requirement, forbidden payload contents, audience routing, and escalation alternatives. Combined with a full output schema and 100% parameter coverage, nothing an agent needs to call this safely is absent.

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. The description still adds value by telling the agent to draft from conversation context, shows a bad-vs-good message example that improves message quality, and explains the side effect of the API-key path on submitted payload — information the schema does not convey.

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 anchors it to a known channel (chainstack.com/contact/). It is unambiguously distinct from read-only siblings like get_chainstack_pricing, get_platform_status, and search_docs, which it explicitly routes away from.

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?

Enumerates the triggering intents (pricing, quotes, upgrades, Enterprise customizations, problem reports) and then gives explicit exclusions with named alternatives: support portal + status page for incidents, ideas site for product requests, GitHub issues for MCP server bugs. Little is left to inference.

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.