@easynodexyz/mcp-x402

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.3
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.
Average 4/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on February 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Business Source License 1.1.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-x402 MCP server](https://glama.ai/mcp/servers/easynodexyz/mcp-x402/badges/card.svg)](https://glama.ai/mcp/servers/easynodexyz/mcp-x402)

Score Badge

Copy to your README.md:

[![mcp-x402 MCP server](https://glama.ai/mcp/servers/easynodexyz/mcp-x402/badges/score.svg)](https://glama.ai/mcp/servers/easynodexyz/mcp-x402)

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