How do I use @easynodexyz/mcp-x402?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@easynodexyz/mcp-x402 List available VPS products" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

@easynodexyz/mcp-x402

by easynodexyz

Overview Schema Related Servers Score Discussions

Python

Remote

npm Node Docs

@easynodexyz/mcp-x402

MCP server for AI agents to purchase VPS and blockchain node products via Easy Node's x402 API with USDC on Base.

Overview

This package provides a Model Context Protocol (MCP) server that enables AI assistants to:

List available VPS and blockchain node products
Purchase products using USDC on Base network
Check order status
Manage running instances (list, view details, renew, rename)

The x402 payment flow is handled automatically - the agent simply calls the tools and payments are processed seamlessly.

Related MCP server: Nexus MCP

Quick Start

1. Install & Setup

npx @easynodexyz/mcp-x402 setup

This interactive wizard will:

Prompt for your wallet private key
Save configuration to ~/.easy-node/.env
Output the IDE config to copy

2. Configure Your IDE

Choose your IDE and add the MCP server configuration.

Install as Claude Code Plugin

/plugin add easynodexyz/mcp-x402

Documentation

Full documentation available at x402.easy-node.xyz.

IDE Configurations

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "easynode-x402": {
      "command": "npx",
      "args": ["@easynodexyz/mcp-x402"]
    }
  }
}

Config file locations:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

Claude Code (CLI)

Add MCP server using the /mcp command:

claude /mcp add @easynodexyz/mcp-x402 -- npx @easynodexyz/mcp-x402

Or manually add to your Claude Code settings (~/.claude/settings.json):

{
  "mcpServers": {
    "easynode-x402": {
      "command": "npx",
      "args": ["@easynodexyz/mcp-x402"]
    }
  }
}

Config file locations:

macOS/Linux: ~/.claude/settings.json
Windows: %USERPROFILE%\.claude\settings.json

Cursor

Add to your Cursor settings (.cursor/mcp.json in your project or global config):

{
  "mcpServers": {
    "easynode-x402": {
      "command": "npx",
      "args": ["@easynodexyz/mcp-x402"]
    }
  }
}

Config file locations:

Project: .cursor/mcp.json in project root
Global macOS: ~/.cursor/mcp.json
Global Windows: %USERPROFILE%\.cursor\mcp.json

VS Code + Continue

Add to your Continue configuration (~/.continue/config.json):

{
  "experimental": {
    "modelContextProtocolServers": [
      {
        "transport": {
          "type": "stdio",
          "command": "npx",
          "args": ["@easynodexyz/mcp-x402"]
        }
      }
    ]
  }
}

Other MCP-Compatible Tools

For any MCP-compatible tool, use this stdio transport configuration:

Field	Value
Command	`npx`
Args	`["@easynodexyz/mcp-x402"]`
Transport	`stdio`

With environment variables:

{
  "command": "npx",
  "args": ["@easynodexyz/mcp-x402"],
  "env": {
    "EASYNODE_PRIVATE_KEY": "0x...",
    "EASYNODE_API_URL": "..."
  }
}

3. Restart Your IDE

Restart to load the MCP server.

4. Use It

Ask your AI assistant:

"List available VPS products"
"Purchase 1 month of the VPS-XS product"
"Check the status of order abc123"
"List my instances"
"Get connection details for instance xyz"
"Renew instance xyz for 3 months"

Configuration

Environment Variables

Variable	Required	Default	Description
`EASYNODE_PRIVATE_KEY`	Yes	-	Wallet private key (0x...)
`EASYNODE_API_URL`	No	https://api.easy-node.xyz/api	API base URL
`EASYNODE_MAX_PAYMENT`	No	100	Max USDC per transaction

Config Resolution Order

Configuration is loaded from multiple sources (later overrides earlier):

~/.easy-node/.env - Global config
./.env - Project-level config
Environment variables - Highest priority

Alternative: Manual Configuration

Instead of running setup, you can configure manually:

Option A: Pass env vars in MCP config

{
  "mcpServers": {
    "easynode-x402": {
      "command": "npx",
      "args": ["@easynodexyz/mcp-x402"],
      "env": {
        "EASYNODE_PRIVATE_KEY": "0x..."
      }
    }
  }
}

Option B: Create config file manually

Create ~/.easy-node/.env:

EASYNODE_PRIVATE_KEY=0x...
EASYNODE_API_URL=https://api.easy-node.xyz/api
EASYNODE_MAX_PAYMENT=1000

MCP Tools

list_products

List available VPS and blockchain node products with USDC pricing.

Parameters:

category (optional): Filter by "vps" or "node"

Example:

List all VPS products available for purchase

create_order

Purchase a product using USDC on Base. Handles x402 payment automatically.

Parameters:

productId (required): Product ID to purchase
period (required): Subscription period in months
quantity (optional): Number of instances (default: 1)
customName (optional): Custom name for the instance (max 100 characters)

Example:

Purchase 3 months of product abc123

get_order

Check the status of an existing order.

Parameters:

orderId (required): Order ID to look up

Example:

Check status of order xyz789

list_instances

List all instances owned by the wallet.

Example:

List all my instances

get_instance

Get detailed instance information including connection details.

Parameters:

instanceId (required): Instance ID to look up
type (required): Instance type ("node" or "vps")

Example:

Get connection details for VPS instance abc123

renew_instance

Renew an existing instance subscription.

Parameters:

instanceId (required): Instance ID to renew
period (required): Renewal period in months
type (required): Instance type ("node" or "vps")

Example:

Renew my VPS instance abc123 for 3 months

update_custom_name

Set or update the custom name of an instance.

Parameters:

instanceId (required): Instance ID to update
type (required): Instance type ("node" or "vps")
customName (required): Custom name (max 100 characters)

Example:

Rename instance abc123 to "my-validator"

Security

Private keys are stored with 600 permissions (owner read/write only)
Max payment limit prevents accidental large transactions
Wallet only signs EIP-3009 TransferWithAuthorization for USDC

How x402 Works

Agent calls create_order with product details
First request returns HTTP 402 with payment requirements
Client signs USDC transfer authorization (EIP-3009)
Retry with payment signature
Server verifies, settles on-chain, creates order
Order returned to agent

Troubleshooting

"EASYNODE_PRIVATE_KEY is required"

Run npx @easynodexyz/mcp-x402 setup or set the environment variable.

"Payment amount exceeds maximum"

Increase EASYNODE_MAX_PAYMENT in your config or env vars.

"402 response missing payment-required header"

The API endpoint may not support x402. Check you're using the correct API URL.

MCP server not appearing in IDE

Verify the config file location is correct for your OS
Check JSON syntax is valid
Restart the IDE completely (not just reload)
Check IDE logs for MCP connection errors

Contributing

Found a bug or have a feature request? Please open an issue at github.com/easynodexyz/mcp-x402/issues.

License

BUSL-1.1

Available Tools

7 tools

create_orderA

Purchase a VPS or blockchain node product using USDC on Base. Handles the x402 payment flow automatically. Returns order details with ID and status.

ParametersJSON Schema

Name	Required	Description
`period`	Yes	Subscription period in months
`quantity`	No	Number of instances to purchase (default: 1)
`productId`	Yes	Product ID to purchase
`customName`	No	Custom name for the instance (max 100 characters)

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure. It adds useful context about the currency, blockchain, and automatic payment handling, but does not mention potential side effects like charges, failure modes, or provisioning delays. This is more transparent than a bare 'create', but still incomplete.

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?

Two sentences, each earning its place. The description is front-loaded with the core purpose and adds payment/return details without fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating tool with no output schema, the description provides a reasonable overview of what to expect (order ID and status). It could mention potential async behavior or failure handling, but it is sufficient for a tool of this complexity.

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

Parameters3/5

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

The schema covers all parameters with descriptions, so the baseline is 3. The description does not add any additional semantic meaning to the parameters beyond what the schema already provides.

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's action: purchasing a VPS or blockchain node product via USDC on Base. It specifies the payment flow and return value, distinguishing it from sibling tools that list, get, renew, or rename instances.

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 implies this is the tool for purchasing, with context about the payment method and automatic flow. However, it does not explicitly mention when to use this over alternatives, though the sibling names make it evident this is the creation/purchase tool.

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

get_instanceA

Get detailed information about a specific instance including connection details (IP address, SSH port, admin credentials). Secrets are encrypted and decrypted locally.

ParametersJSON Schema

Name	Required	Description	Default
`type`	Yes	Instance type: "node" or "vps"
`instanceId`	Yes	Instance ID (userNode or userVps ID) to get details for

TDQS

A4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds an important security-relevant behavior: 'Secrets are encrypted and decrypted locally.' It also implies a read-only operation via 'Get', which is clear. However, it does not mention any side effects or prerequisites, but for a get operation this is acceptable.

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 two concise sentences, front-loaded with the core purpose and valuable detail about return contents. The second sentence about encryption is relevant and not redundant. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description should explain return values. It does mention connection details (IP, SSH port, admin credentials) and the local decryption behavior. It could be more explicit about other possible fields, but for a get tool with a clear scope, it is sufficiently complete.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description does not add additional meaning to the parameters (e.g., how instanceId differs between node and vps, or how type affects the return). Since the schema covers everything, a baseline of 3 is appropriate.

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 action ('Get detailed information') and the resource ('a specific instance'). It specifies the kind of details including IP address, SSH port, and admin credentials, which differentiates it from list_instances that likely provides summary information for many instances.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The tool's purpose implies when to use it (when needing a single instance's details), but it does not explicitly mention when not to use it or suggest alternatives like list_instances for broad listing. The usage context is implied rather than explicitly stated.

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

get_orderA

Get the status and details of an existing order by ID. Returns order status, products, and payment information.

ParametersJSON Schema

Name	Required	Description	Default
`orderId`	Yes	Order ID to look up

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the full transparency burden. It discloses that this is a read operation and specifies return contents, but omits details like error handling, authentication needs, or behavior for non-existent IDs. Acceptable but not rich.

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?

Two short sentences front-load the action and immediately specify the return payload. Every word earns its place; no fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter retrieval tool with no output schema, the description covers the core context: purpose, lookup key, and returned fields. It could mention edge-case behavior or read-only intent explicitly, but the coverage is strong for its simplicity.

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

Parameters3/5

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

Schema coverage is 100% for the only parameter (orderId), and the schema already describes its purpose. The description adds no extra semantic depth beyond 'by ID', so the baseline score of 3 is appropriate.

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 uses a specific verb ('Get') with a clear resource ('order') and states the exact lookup key ('by ID'). It also lists what data is returned (status, products, payment), which effectively distinguishes it from create_order and instance-related sibling tools.

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 clearly implies the tool should be used whenever an existing order's details are needed. It does not explicitly exclude alternatives, but the read-vs-create distinction is inferable from sibling names. Lacks formal 'use this instead of' guidance, but context is clear.

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

list_instancesA

List all VPS and Node instances owned by the wallet. Returns instance IDs, types, statuses, and subscription dates.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses the key behavior: it lists all instances owned by the wallet and returns specific fields. It stops short of explicitly stating it is read-only or describing pagination, but for a simple list operation, the provided transparency is adequate and adds context beyond a bare statement.

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 two sentences long and entirely purposeful. The first sentence states the core function, and the second clarifies the return contents. No filler or irrelevant details are present.

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, no annotations, and no output schema, the description is complete. It explains both what the tool does and what information it returns, which is sufficient for an agent to invoke and interpret the result without needing further clarification.

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 no parameters, so the 0-parameter baseline applies. The description adds no parameter documentation, but none is needed. It correctly implies that no parameters are required for the tool.

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 action ('List all VPS and Node instances') and scope ('owned by the wallet'), using a specific verb and resource. It also enumerates the return fields (IDs, types, statuses, subscription dates), which distinguishes it from siblings like get_instance (single instance) and list_products (different resource).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool by stating it lists all wallet-owned instances, but it does not explicitly contrast with alternatives like get_instance (for a specific instance) or mention exclusions. The word 'all' hints at its broader scope, but no direct when/when-not guidance is provided.

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

list_productsA

List available VPS and blockchain node products with USDC pricing. Returns product IDs, names, pricing, and availability.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	Filter by product category: "vps" or "node"

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It clearly indicates a read-only listing operation by using 'List' and states the return fields (IDs, names, pricing, availability). However, it does not explicitly state that no side effects occur, mention authentication requirements, or address rate limits or pagination behavior.

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 two sentences, front-loaded with the action and resource, and every sentence adds value. It avoids redundancy and clearly communicates the core purpose and return values without unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one optional parameter and no output schema. The description provides return values, which partially compensates for the missing output schema. It does not explicitly state what happens when 'category' is omitted (e.g., returns all products), which is a minor gap for a low-complexity listing tool.

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

Parameters3/5

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

The schema already documents the single optional 'category' parameter with an enum and a clear description, so schema coverage is 100%. The tool description adds only the product categories 'VPS and blockchain node' and USDC pricing, which aligns with but does not significantly extend the parameter 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 uses a specific verb ('List') with a clear resource ('available VPS and blockchain node products') and explicitly notes USDC pricing and returned fields. It clearly distinguishes from siblings like list_instances, which focuses on existing instances, and create_order, which handles ordering.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for browsing the product catalog before ordering, but it does not explicitly state when to use it versus list_instances or create_order. No exclusions or alternative tool names are mentioned, leaving the usage context to be inferred from sibling tool names.

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

renew_instanceA

Renew an existing VPS or Node instance subscription using USDC on Base. Extends the subscription period. Handles x402 payment flow automatically.

ParametersJSON Schema

Name	Required	Description
`type`	Yes	Instance type: "node" or "vps"
`period`	Yes	Renewal period in months
`instanceId`	Yes	Instance ID (userNode or userVps ID) to renew

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description must disclose behavior itself. It mentions the payment method (USDC on Base) and that the x402 payment flow is handled automatically, which adds useful context. However, it does not mention prerequisites (e.g., active instance), side effects, or failure behavior, leaving some gaps.

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 two sentences, immediately states the primary action, and includes relevant details without redundancy. Every sentence contributes value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple 3-parameter tool and no output schema, the description is fairly complete. It explains what the tool does and how payment is handled. Minor omissions like error handling or prerequisites prevent a perfect score, but it is adequate for usage.

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

Parameters3/5

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

Schema description coverage is 100%, so the description does not need to add parameter details. The description mentions the renewal period and instance type implicitly, but the schema already provides clear descriptions. It adds no extra semantic value beyond the 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 clearly states the action (renew), the target resource (existing VPS or Node instance subscription), and the method (using USDC on Base, extending the subscription period). This distinguishes it from sibling tools like create_order or get_instance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (renew existing subscriptions) but does not provide explicit alternatives or when-not-to-use guidance. For a tool with siblings like create_order and update_custom_name, it would benefit from mentioning that it is for renewals only, not for creating new instances.

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

update_custom_nameA

Set or update the custom name of a VPS or Node instance. Useful for labeling instances with friendly names.

ParametersJSON Schema

Name	Required	Description
`type`	Yes	Instance type: "node" or "vps"
`customName`	Yes	Custom name for the instance (max 100 characters)
`instanceId`	Yes	Instance ID (userNode or userVps ID) to update

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only says 'Set or update' which implies mutation, but does not disclose permissions, reversibility, side effects, or response behavior. This is a significant gap for a mutation tool.

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 two concise sentences, the first stating the action and the second giving the purpose. Every word contributes value with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 3-parameter mutation tool with complete schema coverage and no output schema, the description adequately covers purpose and parameters. Behavioral detail is lacking, but the tool is straightforward, so completeness is acceptable.

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

Parameters3/5

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

Schema description coverage is 100%, with all three parameters clearly described. The description adds no extra semantic meaning beyond the schema, so the baseline of 3 is appropriate.

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 'Set or update the custom name of a VPS or Node instance' with a specific verb and resource, and it distinguishes this tool from sibling tools like list_instances or renew_instance by focusing on the labeling action.

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 phrase 'Useful for labeling instances with friendly names' provides clear context for when to use the tool. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv0.1.3Aug 9, 2026
- First observedcreate_order
- First observedget_instance
- First observedget_order
- First observedlist_instances
- First observedlist_products
- First observedrenew_instance
- First observedupdate_custom_name

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool targets a distinct resource and action: products vs orders vs instances, with clear separation between listing, getting, creating, renewing, and updating. No two tools could be confused.

Naming Consistency5/5

All tools follow the same verb_noun pattern with snake_case (list_products, create_order, get_instance, etc.). Naming is perfectly consistent and predictable.

Tool Count5/5

Seven tools is well-scoped for a VPS/node purchasing and management server. Each tool covers a distinct operation without bloat or triviality.

Completeness4/5

The core lifecycle is covered: product discovery, order creation/status, instance listing/detail/renewal, and naming. Missing cancel/termination operations are a minor gap, but agents can work around by not needing them or relying on external cancellation.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

eqvps A
io.github.Poiuyhje
No-KYC crypto VPS AI agents rent & run over MCP — 57 tools, pay USDC/USDT on Base/Eth/Polygon/Solana
Virtualization Cloud Platforms
272
sovereign-engine A
io.github.invertedhoologan
15 paid AI agent primitives via x402 (USDC on Base). Pay-per-call MCP server.
AI & Machine Learning Payments & Billing Cryptocurrency
2
PayGate MCP — Monetization Gateway for AI Agents A
io.github.geoacpfilho
Monetize any MCP server: x402 paywall, pay-per-call billing in USDC on Base, agent marketplace.
Payments & Billing Cryptocurrency Blockchain
61
Pyrimid Protocol A
ai.pyrimid
Agent-commerce MCP server for x402/USDC payments and affiliate splits on Base.
Cryptocurrency Blockchain Payments & Billing
2

Related MCP Servers

opendexterofficial
Payments & Billing Cryptocurrency
Dexter-DAO
A
license
Not graded
quality
C
maintenance
An MCP server that enables AI agents to search, pay for, and call paid APIs using the x402 protocol, with automatic USDC settlement.
Updated a day ago (2026-09-05 01:39 UTC)
2
MIT
Nexus MCP
Blockchain Cryptocurrency Web3 & Decentralized Tech
borishalachev1
A
license
Not graded
quality
C
maintenance
MCP server with X402 payment integration, enabling AI agents to access paid tools like weather, web search, and image generation with crypto payments via MetaMask on Base network.
Updated 6 months ago (2026-03-21 13:33 UTC)
MIT
EQVPS
Virtualization Cryptocurrency Autonomous Agents
Poiuyhje
A
license
A
quality
B
maintenance
No-KYC crypto VPS hosting with an MCP server that lets AI agents provision VPS programmatically. Pay with USDC/USDT on Base and Ethereum, no accounts or verification required.
Updated 4 days ago (2026-09-02 15:45 UTC)
21
MIT
AgentServices
Cryptocurrency Blockchain AI & Machine Learning
vbkotecha
A
license
Not graded
quality
C
maintenance
MCP server providing 50+ crypto, market intelligence, and AI inference endpoints with x402 pay-per-request micropayments on Base.
Updated 2 days ago (2026-09-04 17:02 UTC)
1
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/easynodexyz/mcp-x402'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

@easynodexyz/mcp-x402

Overview

Quick Start

1. Install & Setup

2. Configure Your IDE

Install as Claude Code Plugin

Documentation

IDE Configurations

Claude Desktop

Claude Code (CLI)

Cursor

VS Code + Continue

Other MCP-Compatible Tools

3. Restart Your IDE

4. Use It

Configuration

Environment Variables

Config Resolution Order

Alternative: Manual Configuration

MCP Tools

list_products

create_order

get_order

list_instances

get_instance

renew_instance

update_custom_name

Security

How x402 Works

Troubleshooting

"EASYNODE_PRIVATE_KEY is required"

"Payment amount exceeds maximum"

"402 response missing payment-required header"

MCP server not appearing in IDE

Contributing

Links

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

opendexterofficial

Latest Blog Posts

MCP directory API