Skip to main content
Glama
stucchi

nexi-xpay-mcp-server

by stucchi
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Server Quality Checklist

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

  • Latest release: v1.2.1

  • Disambiguation5/5

    Each tool targets a distinct resource or aspect: orders list, order details, payment methods, and warnings. There is no overlap in purpose, making it easy for an agent to select the correct tool.

    Naming Consistency4/5

    All tool names use snake_case, which is consistent. However, the pattern is not uniform: 'list_orders' follows verb_noun, while 'order_details', 'payment_methods', and 'warnings' are noun_noun or noun-only. This minor inconsistency prevents a perfect score.

    Tool Count4/5

    With 4 tools, the server is scoped to a focused set of read operations. While slightly low, it covers the essential queries for the Nexi XPay Back Office without unnecessary bloat, making it appropriate for its purpose.

    Completeness4/5

    The tools cover the main read operations: listing orders, getting details, viewing payment methods, and checking warnings. Missing operations like creating or updating orders are not expected if the server is read-only, so the surface is largely complete for its intended use.

  • Average 3.5/5 across 4 of 4 tools scored. Lowest: 2.7/5.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • No commit activity data available
    • No stable releases found
    • No critical vulnerability alerts
    • No high-severity vulnerability alerts
    • No code scanning findings
    • CI status not available

  • This repository is licensed under MIT License.

  • 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

  • Behavior2/5

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

    No annotations provided, so description carries full burden. Only states it retrieves active payment methods, but does not disclose behavioral traits like authentication requirements, rate limits, or data freshness.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness3/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    One sentence, concise, but under-specified. No wasted words, but lacks necessary detail.

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

    Completeness2/5

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

    Has output schema but description does not hint at return values. With 0% schema coverage, fails to fill parameter gaps. Incomplete for a 3-parameter tool.

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

    Parameters1/5

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

    Schema description coverage is 0%, and the description does not explain the three parameters (platform, platformVers, pluginVers). No added meaning 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?

    Clearly states the action (retrieve), resource (active payment methods), and context (for a merchant from Nexi XPay Back Office). Distinguishes from siblings which are about orders and warnings.

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

    Usage Guidelines2/5

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

    No guidance on when to use this tool versus alternatives or any prerequisites. The description is a single statement without context for appropriate use.

    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?

    No annotations are provided, so the description must handle behavioral disclosure. It implies a read operation but doesn't specify error handling or data scope, which is adequate but not enriched.

    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?

    Single sentence with no wasted words, front-loaded with core purpose.

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

    Completeness3/5

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

    Given an output schema exists, the description doesn't need to explain returns, but lacks context on error cases or workflow with siblings like list_orders.

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

    Parameters2/5

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

    Schema coverage is 0%, and the description only mentions the parameter indirectly ('by transaction code'), adding minimal semantic detail beyond the name.

    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 retrieves full details of a specific order using a transaction code, distinguishing it from sibling tools like list_orders (listing) and payment_methods.

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

    Usage Guidelines2/5

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

    No guidance on when to use vs alternatives; no mention of prerequisites like obtaining a transaction code via list_orders first.

    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 must carry the full burden. It only states that the tool retrieves warnings, with no disclosure about side effects, authentication needs, or rate limits. The behavior is implied to be read-only but not explicitly confirmed.

    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 extremely concise at two sentences (15 words) while still conveying the core purpose and filter capabilities. Every word serves a purpose, with no fluff.

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

    Completeness3/5

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

    For a simple retrieval tool with three optional parameters and an output schema (presumably listing warnings), the description covers the basic goal. However, it lacks details about the output format, error handling, or any limitations, leaving gaps for an agent unfamiliar with the Nexi system.

    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 input schema has 0% description coverage, but the description adds meaning by linking 'codiceTransazione' to 'transaction code' and the two date params to 'date range'. This compensates partially, but the exact format or constraints are not given, 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 the action ('Retrieve') and the resource ('warnings/anomalies from Nexi XPay Back Office'). It distinguishes itself from sibling tools (list_orders, order_details, payment_methods) by focusing on a different entity (warnings).

    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 mentions filtering options ('by transaction code or date range'), giving some context on when to use. However, it does not provide explicit when-not-to-use advice or compare with alternatives, leaving the agent to infer based on the resource name alone.

    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?

    No annotations are provided, so the description must cover behavior. It indicates a read operation ('Retrieve') but does not disclose pagination, rate limits, or error handling. The presence of an output schema reduces the need to describe return values.

    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 a single sentence, front-loaded with the main action ('Retrieve the list of orders'), and includes key functionality without unnecessary 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?

    Given the tool's complexity (4 params, output schema exists), the description adequately covers purpose and parameters. It omits details like required parameter format or default values, but the output schema likely fills some gaps. Still, slight incompleteness keeps it from a 5.

    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 description coverage is 0%, but the description maps all four parameters to filters (period, channel, status, transaction code), adding context that the schema lacks (e.g., 'codiceTransazione' is transaction code). This compensates for the lack of schema descriptions.

    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 'Retrieve the list of orders' (specific verb+resource) and distinguishes from siblings like 'order_details' (which implies single order retrieval). The mention of filters further specifies the scope.

    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 says 'Supports filters by...' which implies usage when filtering by those criteria. It does not provide explicit when-not or alternatives, but the context is clear enough for an agent.

    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

nexi-xpay-mcp-server MCP server

Copy to your README.md:

Score Badge

nexi-xpay-mcp-server MCP server

Copy to your README.md:

Latest Blog Posts

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/stucchi/nexi-xpay-mcp-server'

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