Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Centrapay MCP Server Create a $25 NZD payment request"
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.
An MCP server for the Centrapay payments API — bring NZ payment-flow testing directly into Claude Code, Claude Desktop, and any MCP-compatible AI tool.
Ask Claude things like:
"Create a $25 NZD payment request under config X"
"What's the status of payment request abc123?"
"List the merchants on this account"
Centrapay is structured Account → Merchant Config (configId) → Payment Request. A payment request is always created under a merchant config, and money is expressed as a value object with the amount in minor units as a string ({ "amount": "2500", "currency": "NZD" } = $25.00).
This server speaks that model directly — endpoints, methods, and field names are matched to the live API (see Verification below).
Related MCP server: PayBridgeNP MCP Server
Tool | What it does | Endpoint |
| Create a request under a |
|
| Get a request by id |
|
| Void (cancel) a request |
|
| List by |
|
| Settle a paid request — live call (test vs live depends on key + |
|
| Refund a paid request ( |
|
| Merchants visible to the API key |
|
| Merchant details by id |
|
| Create a merchant under an account |
|
Auth is via the x-api-key header.
1. Credentials — a public test key is documented at docs.centrapay.com/api/auth; for your own merchant config, contact integrations@centrapay.com.
2. Install and build
git clone https://github.com/CedricConday/centrapay-mcp
cd centrapay-mcp
npm install && npm run build3. Add to Claude Code
claude mcp add centrapay-mcp node /path/to/centrapay-mcp/dist/index.js \
-e CENTRAPAY_API_KEY=your_keyThe request contract (endpoints, methods, body shapes, x-api-key auth) is pinned by contract tests (src/__tests__/payments.test.ts) that mock fetch and assert the exact method, path, and body for create / pay / refund — including the required refund idempotencyKey. Note: Centrapay has no separate sandbox host — service.centrapay.com is production, and test vs live is determined by your API key and the asset types you settle with, so pay / refund are real money-moving calls. A full create → pay → refund round-trip needs a configId under your own merchant account, so response formatting stays defensive (known fields with fallbacks, plus raw passthrough) until pinned against a live create.
Centrapay builds the payment infrastructure NZ merchants use daily. I built this to understand their API from the outside — what integrating actually feels like, and where the friction is. If you're interviewing a candidate who already shipped a correct MCP server around your API, they've done the reading.
npm test
# Tests run against the real source (not reimplemented copies):
# amount → minor-unit-string coercion, and defensive response formatting.TypeScript · Node.js · @modelcontextprotocol/sdk · Centrapay REST API
MIT
Create a merchant under an account.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Merchant business name | |
| accountId | Yes | Account id the merchant belongs to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It only states 'Create' without disclosing side effects, permissions, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One clear sentence that is front-loaded and efficient. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with no output schema, it is adequate but lacks details on return values or error conditions given zero annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The tool description adds no extra meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a merchant under an account' uses a specific verb and resource, and distinguishes from sibling tools like create_payment_request or list_merchants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like create_payment_request or get_merchant. The description does not explain context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Centrapay payment request under a merchant config. Returns a payment URL and request id.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount in minor units (e.g. 10000 = $100.00 NZD) | |
| configId | Yes | Merchant Config id the request is created under | |
| currency | Yes | Currency code, e.g. NZD | |
| externalRef | No | Optional caller reference for later lookup | |
| idempotencyKey | No | Optional idempotency key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description bears full responsibility for behavioral traits. It only states it creates a payment request and returns output, omitting details like idempotency support (despite idempotencyKey in schema), authorization needs, side effects, or whether the payment is immediately actionable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, very concise and front-loaded with the key action. No unnecessary words. However, it is slightly too terse and could benefit from a bit more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite moderate complexity (5 params, no output schema), the description is minimal. It does not explain the return structure beyond 'payment URL and request id', nor does it clarify how the payment URL is used or any expiry. The absence of output schema increases the need for a fuller description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds no extra meaning beyond schema; it only summarizes output. Parameter descriptions in schema are adequate, but the tool description does not augment them with usage context or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a Centrapay payment request under a merchant config and returns a payment URL and request id. It uses specific verbs and resource names, and distinguishes from sibling tools like create_merchant or create_refund.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites (e.g., needing a merchant config first) or scenarios where this tool should or should not be used, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refund a paid payment request. amount is in MINOR units (cents): 2500 = $25.00, must not exceed the original. Requires an idempotencyKey — a refund moves money irreversibly, so a retry without one would double-refund.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Payment request id to refund | |
| amount | Yes | Refund amount in MINOR units (cents): 2500 = $25.00. Must not exceed the original. | |
| currency | Yes | Currency code, e.g. NZD | |
| externalRef | Yes | Caller reference for the refund | |
| idempotencyKey | Yes | Unique key that makes the refund safe to retry (prevents a double-refund). Reuse the same key for the same logical refund. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses that refunds move money irreversibly and that retrying without an idempotencyKey could cause double-refund. This is excellent behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first sentence states purpose and key parameter facts, second sentence explains behavioral reasoning. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All 5 required parameters are covered in description or schema. The description explains critical behavior. However, no output schema exists and the description doesn't hint at the return value, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining MINOR units with an example (2500 = $25.00) and emphasizing why idempotencyKey is critical, which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Refund a paid payment request', which is a specific verb and resource. It clearly distinguishes from sibling tools like pay_payment_request and void_payment_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the need for an idempotencyKey due to irreversible money movement, which provides guidance on safe usage. It implicitly differentiates from voiding but could explicitly state when to refund vs other actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a Centrapay merchant by id.
| Name | Required | Description | Default |
|---|---|---|---|
| merchantId | Yes | Merchant id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as whether the operation is read-only, authentication requirements, rate limits, or error handling. Simply stating 'get details' is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is remarkably concise: a single sentence that is front-loaded with the key action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema), the description is mostly adequate. However, it could mention the return value or common error scenarios to be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameter descriptions provided. The description does not add additional meaning beyond what the schema already specifies for 'merchantId'. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'details for a Centrapay merchant by id'. It effectively distinguishes from siblings like 'list_merchants' (which lists all) and 'create_merchant' (which creates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need details of a specific merchant but provides no explicit guidance on when to use this tool versus alternatives like 'list_merchants' or other tools. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current status of a Centrapay payment request by id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Payment request id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided; the description indicates a read-only operation ('Get'), which is appropriate. However, it does not disclose error behavior or edge cases (e.g., invalid id). For a simple read, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one simple parameter and no output schema. The description sufficiently explains what the tool does and how to use it. A slightly higher score is warranted because no additional details are needed for this straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'id', described as 'Payment request id' in both schema and description. The description adds no extra meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get the current status') and the resource ('Centrapay payment request by id'). It distinguishes from sibling tools like create_payment_request or pay_payment_request, which are for creation or modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when checking payment status, but provides no explicit when-not-to-use or alternative tools. Sibling names are available but not referenced in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List merchants visible to the API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only mentions authorization scope ('visible to the API key') but omits pagination, rate limits, or what constitutes visibility. Behavior is under-described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and a simple list tool. Description lacks details on return format, pagination, or ordering, making it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100% vacuously. Description adds minimal value beyond schema; 'visible to the API key' hints at filtering but no details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List merchants visible to the API key' – a specific verb and resource, distinguishing it from siblings like get_merchant (single) and create_merchant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not guidance. Context is clear for a general listing tool, but no mention of alternatives like get_merchant for specific merchants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List payment requests matching an externalRef for a merchant account (Centrapay has no flat list-all).
| Name | Required | Description | Default |
|---|---|---|---|
| externalRef | Yes | The externalRef set at creation | |
| merchantAccountId | Yes | Merchant account id to scope the lookup |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavior. It reveals that filtering is mandatory and there is no unspecificed list-all, but does not discuss output format, pagination, permissions, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the action and includes an important contextual note. No extra words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two required parameters and no output schema, the description covers the essential purpose and filtering constraint. However, it could briefly mention the return format (list of payment requests) to improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters fully (100% coverage). The description adds the context that the parameters are required for filtering beyond what the schema says, but does not provide additional semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List payment requests matching an externalRef for a merchant account', clearly indicating the verb and resource. It also distinguishes itself from a flat list-all by noting the constraint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes the key guideline that 'Centrapay has no flat list-all', implying that this tool must be used with specific filters. However, it does not explicitly compare to other listing tools or state when to use over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Settle a payment request in the sandbox. Requires an assetType and asset reference — used to test webhook/settlement flows.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Payment request id to pay | |
| assetId | Yes | Asset id funding the payment | |
| assetType | Yes | Asset type, e.g. centrapay.nzd.test | |
| idempotencyKey | Yes | Idempotency key for the pay action |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the main action (settle) and testing purpose, but does not describe side effects like irreversible changes, error responses, or permissions needed. With no annotations, more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. Purpose and key constraints are efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks details on return value, error conditions, prerequisites (e.g., payment request must exist and be pending), and overall behavior. For a mutation tool with no output schema or annotations, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are documented in the schema with 100% coverage. The description mentions assetType and asset reference but adds no new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool settles a payment request, specifying it's sandbox-only and for testing webhook/settlement flows. Distinct from siblings like create_payment_request or void_payment_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that tool is for testing webhook/settlement flows, implying when to use. However, no explicit when-not-to-use or comparison to alternatives like void_payment_request or create_refund.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Void (cancel) an active Centrapay payment request.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Payment request id to void |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states 'void (cancel) an active...' but omits what happens if the request is already voided, required authentication, or any side effects. The behavioral scope is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but lacks key details (e.g., prerequisites, error conditions). While front-loaded with the action and object, it is too sparse to be fully effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is minimal. It does not specify expected result, error scenarios, or any additional context needed for correct invocation. For a void operation, more details on state transitions are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains the 'id' parameter as 'Payment request id to void'. The description adds no additional semantic value beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Void' and the resource 'payment request', and includes a parenthetical synonym 'cancel'. It effectively distinguishes this from sibling tools like 'pay_payment_request' and 'create_refund'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention conditions such as the payment request must be active, nor does it differentiate from related operations like refund or pay.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.0create_refund3 fields changedInput schema / properties / amount / descriptionPrevious value: -"Refund amount in minor units"New value: +"Refund amount in MINOR units (cents): 2500 = $25.00. Must not exceed the original."Input schema / properties / idempotencyKeyAdded value: +{
+ "description": "Unique key that makes the refund safe to retry (prevents a double-refund). Reuse the same key for the same logical refund.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "id",
- "amount",
- "currency",
- "externalRef"
-]New value: +[
+ "id",
+ "amount",
+ "currency",
+ "idempotencyKey",
+ "externalRef"
+]v0.1.0create_merchantcreate_payment_requestcreate_refundget_merchantget_payment_statuslist_merchantslist_payment_requestspay_payment_requestvoid_payment_requestEach tool targets a distinct resource (merchant or payment request) and action (create, get, list, pay, void, refund). No overlap between merchant and payment operations, and payment operations are clearly differentiated by action.
All tools follow a consistent verb_noun pattern with underscores (e.g., create_merchant, get_payment_status, void_payment_request). No mixing of styles or ambiguous names.
9 tools is well-scoped for a payment/merchant server covering core CRUD and lifecycle operations. Not excessive nor insufficient for the domain.
The tool set covers merchant management (create, get, list) and full payment lifecycle (create, status, list, pay, void, refund). No obvious gaps for the intended use case.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
New Zealand payments for AI agents — cards / Apple Pay via Stripe. Never holds funds.
Query and manage Mercoa AP/AR bill-pay: entities, invoices, transactions and payment methods.
Read payment settings, orders and receipts, create payment links and API keys.
Taiwan payments (ECPay 綠界 + NewebPay 藍新) & e-invoices for AI agents. Stateless, never holds funds.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/CedricConday/centrapay-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
