Skip to main content
Glama

Chainstack

by com.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:

  1. Draft the message based on your conversation context.

  2. Show the user the EXACT message, email, and name you will send.

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

  4. Ask: "Shall I send this to Chainstack? Please confirm there's no sensitive information you'd like removed."

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

Args: message: 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: 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". email: User's contact email. Required. Ask the user if you don't already have it. name: 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
emailYes
messageYes
categoryNogeneral

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
submittedYes
lead_sourceYes
alternative_channelsYes
estimated_response_timeYes

TDQS

A5/5.0
Behavior5/5

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

The description details the pre-call workflow: drafting, showing the user the exact message, asking for confirmation, and including org info when an API key is present. It also lists prohibited content (API keys, wallet addresses, RPC URLs) and clarifies side effects: it posts to the contact form and works with or without an API key. These disclosures complement the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=true) rather than contradict them.

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?

Though long, the description is organized into clear sections ('Before calling this tool', 'Writing an effective message', 'Args') and front-loaded with the core purpose. Each sentence carries operational instructions (confirmation step, exclusions, parameter details) that are essential for safe invocation.

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?

The description covers the tool's purpose, exact trigger conditions, exclusions, pre-call user confirmation, sensitive data handling, message-writing best practices, and complete parameter semantics. No gaps remain given the existing annotations and output schema, making it a complete reference for correct invocation.

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?

The schema has zero property descriptions, but the description's Args section thoroughly explains each parameter. It defines category with enumeration-like semantics, fallback behavior, and default; specifies that email and name are required and instructs the agent to ask the user; and gives guidance on composing the message with examples. This fully compensates for the schema's lack of documentation.

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 'Submit a message to Chainstack's sales and support team,' a specific verb+resource, and lists concrete use cases (pricing, custom quote, plan upgrade, support). This clearly distinguishes it from sibling tools like create_node or get_chainstack_pricing.

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?

The description explicitly states 'Use when the user wants to...' followed by scenarios, and provides exclusions: 'Not for incidents or urgent outages — point users to...' and 'For feature requests, do NOT use this tool.' It names alternative channels (support tickets, status page, ideas portal, GitHub), making alternatives unambiguous.

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