Click on "Deploy 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., "@Nomba MCP Server show my recent transactions"
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.
MCP server for Nomba payment and POS platform (Nigeria).
Tool | Description |
| Create a checkout page |
| Get transaction details |
| List transactions |
| Create a bank transfer |
| Get account balance |
| List POS terminals |
| Create a virtual account |
| Get virtual account details |
Related MCP server: paystack-mcp-server
{
"mcpServers": {
"nomba": {
"command": "npx",
"args": ["-y", "@theyahia/nomba-mcp"],
"env": {
"NOMBA_CLIENT_ID": "<YOUR_NOMBA_CLIENT_ID>",
"NOMBA_CLIENT_SECRET": "<YOUR_NOMBA_CLIENT_SECRET>",
"NOMBA_ACCOUNT_ID": "<YOUR_NOMBA_ACCOUNT_ID>"
}
}
}
}Variable | Required | Description |
| Yes | OAuth client ID |
| Yes | OAuth client secret |
| Yes | Nomba account ID |
MIT
Create a checkout page
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | Your order reference | |
| amount | Yes | Amount in kobo | |
| customer_email | Yes | Customer email |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Create a checkout page' implies a write operation that likely generates a payment interface, but it doesn't disclose behavioral traits like authentication requirements, rate limits, whether it's idempotent, what happens on failure, or what the expected output might be (e.g., a URL or confirmation).
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 extremely concise ('Create a checkout page') with no wasted words, making it front-loaded and easy to parse. However, it borders on under-specification given the tool's complexity, as it omits necessary context that would help an agent use it effectively.
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 complexity (a write operation with 3 required parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a checkout URL, status), error conditions, or integration details, leaving significant gaps for an AI agent to infer.
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%, with clear parameter documentation (order_id, amount in kobo, customer_email). The description adds no additional meaning beyond what the schema provides, so it meets the baseline of 3 for adequate coverage without enhancement.
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 checkout page' clearly states the action (create) and resource (checkout page), but it's vague about what a 'checkout page' entails in this context. It distinguishes from siblings like 'create_transfer' or 'create_virtual_account' by focusing on checkout functionality, but lacks specificity about the platform or service involved.
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 provides no guidance on when to use this tool versus alternatives. With siblings like 'create_transfer' and 'create_virtual_account' that might handle different payment-related tasks, there's no indication of prerequisites, typical scenarios, or exclusions for this checkout tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a bank transfer
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount in kobo | |
| account_number | Yes | Recipient account | |
| bank_code | Yes | Bank code | |
| narration | Yes | Transfer description |
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. 'Create a bank transfer' implies a write operation with financial consequences, but it doesn't disclose critical traits like authentication needs, rate limits, whether transfers are reversible, or what happens on failure. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Create a bank transfer' is front-loaded and appropriately sized for the tool's purpose. Every word earns its place without redundancy.
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 complexity of a bank transfer tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits, error handling, and return values, which are crucial for safe and effective use in a financial context.
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%, so the input schema fully documents all four parameters (amount, account_number, bank_code, narration). The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, meeting the baseline for high schema coverage.
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 bank transfer' clearly states the verb ('Create') and resource ('bank transfer'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_checkout' or 'create_virtual_account', which also create financial entities, so it lacks sibling differentiation.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., sufficient balance), exclusions, or comparisons to siblings like 'create_checkout' for payments or 'create_virtual_account' for account creation, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a virtual account
| Name | Required | Description | Default |
|---|---|---|---|
| account_name | Yes | Account name | |
| permanent | No | Permanent or temporary |
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 but offers none. 'Create a virtual account' implies a write/mutation operation but doesn't disclose any behavioral traits: no information about permissions required, whether this operation is reversible, what happens on success/failure, rate limits, or what the virtual account enables. This is particularly problematic for a creation tool with zero annotation coverage.
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 maximally concise at just three words. While this represents under-specification rather than ideal conciseness, according to the scoring guidelines, conciseness is evaluated separately from completeness. The description contains zero wasted words and is perfectly front-loaded with the core action.
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 that this is a creation/mutation tool with no annotations, no output schema, and a minimal description, the description is completely inadequate. It doesn't explain what a virtual account is, what it enables, what happens after creation, or any behavioral characteristics. The agent would have insufficient information to understand the tool's role in the broader system context.
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 description coverage is 100%, with both parameters ('account_name' and 'permanent') having clear descriptions in the schema. The tool description adds no parameter information beyond what's already documented in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
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 virtual account' is a tautology that essentially restates the tool name without adding meaningful clarification. While it identifies the verb ('create') and resource ('virtual account'), it doesn't specify what a virtual account is or how it differs from other account types, nor does it distinguish this tool from siblings like 'create_checkout' or 'create_transfer' beyond the obvious resource difference.
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 provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, typical use cases, or comparisons to sibling tools like 'create_transfer' or 'get_virtual_account'. An agent would have no contextual information about when this operation is appropriate versus other creation or retrieval operations in the system.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get account balance
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Get account balance' implies a read operation but doesn't specify whether this requires authentication, returns real-time vs cached data, includes currency information, or has rate limits. For a financial tool with zero annotation coverage, this leaves significant behavioral gaps.
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 perfectly concise at three words with zero wasted language. It's front-loaded with the essential action and resource. Every word earns its place, making it immediately understandable without unnecessary elaboration.
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 this is a financial tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what format the balance returns (e.g., currency, amount, timestamp), whether it's for a specific account or all accounts, or any authentication requirements. For a tool that presumably returns sensitive financial data, 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?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description doesn't need to compensate for any parameter gaps. A baseline of 4 is appropriate since there are no parameters to explain beyond what the empty schema already indicates.
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 'Get account balance' clearly states the verb ('Get') and resource ('account balance'), making the purpose immediately understandable. It distinguishes from siblings like 'get_transaction' or 'get_virtual_account' by focusing specifically on balance rather than transactions or account details. However, it doesn't specify whose account (e.g., current user, specific account ID) which prevents a perfect score.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like authentication, nor does it differentiate from sibling tools like 'get_transaction' or 'list_transactions' which might provide related financial data. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get transaction details
| Name | Required | Description | Default |
|---|---|---|---|
| transaction_id | Yes | Transaction ID |
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. 'Get transaction details' implies a read-only operation, but it doesn't specify if authentication is needed, rate limits apply, or what format/details are returned. It lacks crucial context for safe and effective use.
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 extremely concise with just three words, making it front-loaded and efficient. However, it borders on under-specification, as it could benefit from slightly more detail without becoming verbose, earning a 4 for brevity but not perfect clarity.
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 annotations, no output schema, and a simple parameter, the description is incomplete. It doesn't explain what 'details' include, error handling, or behavioral traits, leaving gaps for the agent to navigate. For a tool with minimal structured data, more descriptive 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?
The input schema has 100% description coverage, with 'transaction_id' clearly documented. The description adds no additional meaning beyond the schema, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema handles parameter documentation adequately.
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 'Get transaction details' states a clear verb ('Get') and resource ('transaction details'), making the basic purpose understandable. However, it doesn't differentiate from sibling tools like 'list_transactions' or specify what details are retrieved, making it somewhat vague rather than specific.
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 provides no guidance on when to use this tool versus alternatives like 'list_transactions' or 'get_balance'. There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get virtual account details
| Name | Required | Description | Default |
|---|---|---|---|
| account_ref | Yes | Virtual account reference |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states 'Get virtual account details' without disclosing behavioral traits. It doesn't mention whether this is a read-only operation, requires authentication, has rate limits, or what the return format might be, leaving significant gaps for a tool with no annotation coverage.
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, efficient sentence with no wasted words. It's appropriately sized for a simple tool, though it could be more informative without sacrificing brevity.
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 annotations and no output schema, the description is incomplete. It doesn't explain what 'details' are returned, error conditions, or behavioral context. For a tool with one parameter but no structured output information, the description should provide more completeness to guide the agent effectively.
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%, so the schema already documents the 'account_ref' parameter. The description doesn't add any meaning beyond what the schema provides, such as explaining what a 'virtual account reference' is or providing examples. Baseline 3 is appropriate when the schema does the heavy lifting.
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 'Get virtual account details' states the action (get) and resource (virtual account), but it's vague about what 'details' includes. It distinguishes from siblings like 'create_virtual_account' by being a read operation, but doesn't specify scope or content beyond the basic verb+resource.
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 like 'get_balance' or 'get_transaction'. The description doesn't mention prerequisites, context, or exclusions, leaving the agent with no usage direction beyond the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List POS terminals
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page | |
| limit | No | Limit |
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. 'List POS terminals' implies a read-only operation, but it doesn't specify whether this requires authentication, how results are returned (e.g., pagination details beyond the schema), or any rate limits. The description adds minimal behavioral context beyond the basic action.
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 extremely concise at three words, with zero wasted language. It's front-loaded with the core action and resource, making it efficient and easy to parse.
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 tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'POS terminals' are in this context, what data is returned, or how to interpret results. Given the complexity of listing resources and the lack of structured metadata, more context is needed for effective use.
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 input schema has 100% description coverage, with both parameters ('page' and 'limit') documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.
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 ('List') and resource ('POS terminals'), making the tool's purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling list operations (like 'list_transactions'), which prevents a perfect score.
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 provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, context for listing terminals, or comparison with other tools like 'get_virtual_account' or 'list_transactions' that might serve related purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List transactions
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page | |
| limit | No | Limit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List transactions' implies a read operation, but it doesn't specify whether this is safe, requires authentication, involves pagination, or returns a specific format. The description lacks any behavioral traits beyond the basic verb, making it inadequate for a tool with parameters.
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 overly concise to the point of under-specification. 'List transactions' is a single phrase that fails to convey necessary details, making it inefficient rather than appropriately brief. It lacks front-loaded information and doesn't earn its place with useful content, resulting in poor structure.
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 complexity of a list operation with pagination parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'transactions' entail, how results are returned, or any behavioral aspects. For a tool with two parameters and sibling alternatives, this minimal description fails to provide sufficient context for effective use.
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 input schema has 100% description coverage, with parameters 'page' and 'limit' clearly documented as 'Page' and 'Limit.' The description adds no additional meaning beyond what the schema provides, such as explaining pagination behavior or default values. However, with high schema coverage, the baseline score is 3, as the schema handles the parameter documentation adequately.
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 'List transactions' is a tautology that restates the tool name without adding specificity. It doesn't distinguish this tool from sibling tools like 'get_transaction' or 'get_balance,' nor does it clarify what kind of transactions are being listed (e.g., financial, user-specific). This minimal description fails to provide meaningful context beyond the obvious.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_transaction' (for single transactions) or 'create_transfer' (for creating transactions), nor does it specify any context, prerequisites, or exclusions. This leaves the agent with no usage direction.
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.
v1.0.1create_checkoutcreate_transfercreate_virtual_accountget_balanceget_transactionget_virtual_accountlist_terminalslist_transactionsScored across 8 tools
Each tool has a clearly distinct purpose targeting specific resources and actions: creating different financial entities (checkout, transfer, virtual account), retrieving balance or transaction details, and listing terminals or transactions. There is no overlap or ambiguity in functionality.
All tools follow a consistent verb_noun pattern with clear action prefixes (create_, get_, list_) and descriptive nouns. The naming is uniform and predictable throughout the set.
With 8 tools, the server is well-scoped for a payment/financial domain, covering key operations like creation, retrieval, and listing without being overly broad or sparse. Each tool serves a clear, necessary function.
The toolset provides strong coverage for core financial workflows, including creation and retrieval of transactions, virtual accounts, and checkouts, plus balance and terminal listing. A minor gap exists in update/delete operations for resources like virtual accounts or transactions, but agents can work around this.
Nigeria payments for AI agents — bank transfer / USSD via Paystack. Never holds funds.
Ghana payments for AI agents — MTN MoMo via Paystack. Never holds funds.
Enable AI assistants to interact seamlessly with Feeef e-commerce stores, products, and orders usi…
Vietnam payments for AI agents — MoMo wallet QR, ATM, cards. Zero-setup sandbox. Never holds funds.
