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., "@Xental MCP Server Create a virtual account for Bob and simulate a 2000 naira deposit"
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.
A Model Context Protocol server that lets any MCP-capable agent (Claude Desktop, Claude Code, and others) operate a Xental merchant account through typed tools — provision virtual accounts, watch reconciled transactions, run payouts, and drive the sandbox, all in natural language.
Instead of an agent scraping the dashboard, it talks to Xental over the same public API you use. This is the "agent plane": your AI assistant becomes a first-class operator of your payments.
Tool | What it does |
| Reads |
| List / fetch NUBANs with balance + reconciliation state |
| Provision a NUBAN for a customer (sandbox on test keys) |
| Remove an account with no activity |
| Reconciled inflows/outflows + totals |
| Payout bank list + name enquiry |
| Send a payout (idempotent) / list payouts |
| Sandbox: drive a real reconciliation with no bank movement |
All money is integer kobo (₦1 = 100 kobo). Money-moving calls are idempotent on a caller-supplied reference.
Related MCP server: paystack-mcp-server
git clone https://github.com/XENTAL-PayLibre/xental-mcp.git
cd xental-mcp
npm install
npm run buildThis produces build/index.js — the executable server.
Create an API key in the Xental dashboard (Settings → Developers) and copy the client id and client secret (the secret is shown once). Start with a test-mode key — it works immediately and moves zero real money; live keys require approved KYC/KYB.
Env var | Default | Notes |
| — | required |
| — | required |
|
| use |
Add to claude_desktop_config.json:
{
"mcpServers": {
"xental": {
"command": "node",
"args": ["/absolute/path/to/xental-mcp/build/index.js"],
"env": {
"XENTAL_API_BASE": "https://api.staging.xental.online",
"XENTAL_CLIENT_ID": "your-client-id",
"XENTAL_CLIENT_SECRET": "your-client-secret"
}
}
}
}Restart Claude Desktop, then try:
"Create a test virtual account for Ada, simulate a ₦5,000 deposit, and show me the reconciliation."
claude mcp add xental \
--env XENTAL_API_BASE=https://api.staging.xental.online \
--env XENTAL_CLIENT_ID=your-client-id \
--env XENTAL_CLIENT_SECRET=your-client-secret \
-- node /absolute/path/to/xental-mcp/build/index.jsThe server exchanges your client credentials at POST /api/v1/auth/token for a short-lived bearer
token, caches it, and refreshes automatically on expiry or a 401. Your secret never leaves the
machine the server runs on.
Xental docs: https://xental.online/documentation
MCP guide: https://xental.online/documentation/mcp
Agent discovery (llms.txt): https://api.xental.online/.well-known/llms.txt
MIT
Provision a dedicated virtual account (NUBAN) for a customer. On test-mode keys this creates a sandbox account. Money is integer kobo (₦1 = 100 kobo).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Customer / account holder name. | |
| No | |||
| phone | No | ||
| accountRef | No | Optional unique reference; the server generates one if omitted. | |
| expectedAmountKobo | No | Expected amount in kobo, for reconciliation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that money is in integer kobo (1 Naira = 100 kobo) and that test-mode keys create sandbox accounts. However, it does not mention authorization requirements, side effects, or whether the operation is reversible.
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, front-loading the main purpose. Every word serves a purpose: creation, test-mode distinction, and unit clarification. No unnecessary details.
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, the description omits what the tool returns (e.g., account number, status). It covers test-mode behavior and unit convention, but lacks guidance on reconciliation or next steps. For a tool with 5 parameters, it is moderately complete but could be richer.
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 60%, so the description adds moderate value. It clarifies that 'expectedAmountKobo' is in integer kobo, which is already in the schema. Other parameters like name, email, phone, and accountRef are not elaborated beyond schema descriptions. The test-mode context is implicit, not parameter-specific.
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 'Provision a dedicated virtual account (NUBAN) for a customer,' using a specific verb and resource. It distinguishes from sibling tools like delete_virtual_account and get_virtual_account by implying creation. The mention of test-mode behavior adds clarity.
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 gives no explicit guidance on when to use this tool versus alternatives like list_virtual_accounts or simulate_deposit. It only mentions test-mode behavior, but does not specify use cases or preconditions. The agent must infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a virtual account that has no payment activity.
| Name | Required | Description | Default |
|---|---|---|---|
| accountRef | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the destructive action ('delete') and adds a condition ('no payment activity'), which is useful. However, it omits details like permission requirements, irreversibility, or behavior when the condition is not met.
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 succinct sentence that front-loads the action and condition. It is efficient for its purpose, though it could be slightly improved by briefly mentioning the required parameter.
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 simplicity of the tool (one parameter, no output schema, no annotations), the description provides the essential purpose and a key constraint. However, it lacks parameter explanation, error handling hints, and return value info, leaving gaps for a fully informed invocation.
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?
With 0% schema description coverage and no explanation of 'accountRef' in the description, the agent must rely solely on the parameter name. The description does not clarify that accountRef is the identifier for the virtual account to delete, adding minimal semantic 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 'Delete' and the resource 'virtual account,' with a specific condition 'that has no payment activity,' which distinguishes it from sibling tools like create_virtual_account or list_virtual_accounts.
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 when to use (delete an inactive virtual account) but does not provide explicit when-not-to-use or alternatives. It lacks guidance on prerequisites or consequences if the account has payment activity, leaving the agent to infer context from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the Xental agent orientation (llms.txt): auth, core flow, and differentiators.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description indicates it is a read operation with no side effects, but lacks details like caching, response format, or authentication requirements.
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 specifies the document's content. 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?
Adequate for a read-only tool with no parameters; describes the document's content. Could specify the return format or explicit use case but otherwise 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?
Zero parameters, so schema coverage is 100%. Description adds context that the tool reads an orientation document with specific content areas.
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 tool reads an orientation document covering auth, core flow, and differentiators, distinguishing it from sibling tools that are transactional.
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 guidance on when to use or not use this tool; usage is implied as a preliminary step to understand the system before using transactional tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one transaction by its reference.
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description shoulders the burden of behavioral disclosure. It only states the operation is a get, but fails to mention handling of missing references, response format, or any side effects. Minimal behavioral context.
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, no extraneous words, directly states purpose. Efficiently structured for quick parsing.
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, no annotations, and low schema coverage, the description is too sparse. It does not specify return values, error behavior, or any additional context needed for correct invocation.
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 0%, yet the description adds no extra meaning for the 'reference' parameter beyond its name. No format details, examples, or constraints are given, leaving the agent to rely solely on the schema type string.
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 the action (get one transaction) and the identifier (by its reference), which distinguishes it from sibling tools like list_transactions (multiple) and transactions_summary (aggregate).
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 have a specific transaction reference, but no explicit guidance on when to use this tool versus alternatives like list_transactions or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one virtual account by its reference, including balance and reconciliation state.
| Name | Required | Description | Default |
|---|---|---|---|
| accountRef | Yes | The account reference (accountRef). |
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 discloses that the tool returns balance and reconciliation state, which is good. However, it does not mention side effects, authentication requirements, or error conditions. The read-only nature is implied but not stated.
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 of 12 words, efficiently conveying the tool's purpose and key return fields. It is front-loaded and contains no unnecessary information.
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 get-by-ID tool with one parameter and no output schema, the description covers the essential purpose and return fields. It does not mention that the reference is required, but that is specified in the schema. Slightly incomplete but adequate.
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 a single parameter that already has a description in the schema. The tool description adds 'by its reference' which aligns with but does not significantly enhance the schema description. 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?
Description clearly states the tool gets one virtual account by reference, including balance and reconciliation state. It uses a specific verb ('Get') and a specific resource ('virtual account'), and the stated detail distinguishes it from siblings like list_virtual_accounts.
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 for retrieving a single virtual account with detailed state, but it does not explicitly state when to use this tool versus alternatives like list_virtual_accounts or create_virtual_account. No when-not-to-use or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a payout to a bank account. MOVES REAL MONEY on live keys. Idempotent on merchantTxRef. Amount in kobo.
| Name | Required | Description | Default |
|---|---|---|---|
| bankCode | Yes | ||
| narration | No | ||
| amountKobo | Yes | ||
| accountNumber | Yes | ||
| merchantTxRef | Yes | Caller-supplied unique reference (idempotency key). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses key behaviors: moves real money (destructive), idempotent on merchantTxRef, amount in kobo. This is critical for agent safety.
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?
Four concise sentences, each adding distinct value. Front-loaded with purpose. 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?
Covers core behavioral aspects and key parameter semantics, but lacks information on return values, error handling, or prerequisites. For a real-money tool, minor gaps remain.
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?
Adds meaning for 'merchantTxRef' (idempotency key) and 'amountKobo' (unit), but 'bankCode', 'accountNumber', and 'narration' lack description. Schema coverage is low (20%), so more compensation needed.
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 verb 'send a payout', the resource 'bank account', and critical constraints (real money, idempotency, kobo unit). Distinguishes from sibling tools like 'list_transfers' or 'create_virtual_account'.
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?
Implies use for sending payouts but lacks explicit when-to-use or when-not-to-use guidance relative to sibling tools. No mention of prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List supported banks for payouts (name + bank code).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states the tool lists banks, but does not disclose behavioral traits such as idempotency, rate limits, or side effects. The read-only nature is implied but not explicit.
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 with no wasted words. It is front-loaded and efficient.
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 simplicity (no parameters, no output schema, no nested objects), the description is complete. It explains the purpose and the output format, which is sufficient 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?
There are no parameters, so the description adequately covers parameter semantics by omission. The baseline for zero parameters is 4, and the description correctly implies no inputs are needed.
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', the resource 'supported banks', and the purpose 'for payouts'. It also specifies the output format (name + bank code), distinguishing it from sibling tools.
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 needing bank codes for payouts, but does not explicitly state when to use or not use this tool compared to alternatives. No guidance on exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List reconciled inflows/outflows for the merchant.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it returns reconciled transactions. It fails to disclose important behavioral traits like pagination, ordering, limits, or whether the list is exhaustive.
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?
Extremely concise: a single sentence with no wasted words. Every word adds value.
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 parameters, the description is sufficient for basic understanding but lacks details on response format, pagination, or sorting. It is adequate but incomplete for an agent needing to fully predict behavior.
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 zero parameters and schema coverage is 100%, so baseline score is 4. The description adds no parameter information, which is acceptable given no parameters exist.
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 lists reconciled inflows/outflows for the merchant, using a specific verb and resource. It implicitly distinguishes from sibling tools like get_transaction (single) and transactions_summary (summary), but does not explicitly differentiate.
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 versus alternatives such as get_transaction or transactions_summary. The description does not mention context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List outbound transfers (payouts).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks any behavioral details (e.g., pagination, ordering, limits). For a listing operation, this 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 very short (3 words) and front-loaded, but it barely earns its place. Could be slightly expanded without harm.
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, low complexity, and 0 params, the description is adequate but lacks completeness: no mention of output format, limits, or ordering.
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 no parameters (100% coverage trivially), so the description need not add param info. Baseline for 0 params is 4.
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 lists outbound transfers (payouts), specifying the resource and action. It distinguishes from siblings like list_transactions, though it doesn't explicitly contrast them.
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 such as list_transactions, which may include transfers. The agent gets no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the merchant's dedicated virtual accounts (NUBANs) with balances and payment state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It implies a read-only operation but does not mention pagination, rate limits, auth requirements, or what 'payment state' entails.
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 of 11 words. Every word contributes meaning, with no 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?
For a simple list with no parameters, the description covers the basics but lacks detail on return format or pagination. The ambiguous term 'payment state' reduces 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?
No parameters exist, and schema coverage is 100%. Baseline score 4 applies as per guidelines since the description cannot add value 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 'List the merchant's dedicated virtual accounts (NUBANs) with balances and payment state.' The verb and resource are specific. However, it does not explicitly distinguish its scope (all accounts) from the singular get_virtual_account sibling.
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 versus alternatives like get_virtual_account. The description merely states its function without context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve an account name from an account number + bank code (name enquiry).
| Name | Required | Description | Default |
|---|---|---|---|
| bankCode | Yes | ||
| accountNumber | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It mentions the lookup operation but does not disclose behavioral traits such as side effects (likely none), error handling, or response format. Minimal 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?
A single, concise sentence with no filler words. It efficiently conveys the tool's purpose, though it could be slightly more structured (e.g., clarifying input and output).
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 has 2 simple string parameters and no output schema or annotations, the description is too minimal. It lacks return format, error conditions, and usage context, making it incomplete for reliable agent invocation.
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 0%; parameters have no descriptions in the schema. The description mentions 'account number' and 'bank code' but adds no further meaning beyond the parameter names. It does not specify accepted formats, lengths, 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 the tool resolves an account name from account number and bank code, using specific verb 'Resolve' and resource 'account name', distinguishing it from sibling tools that create, delete, or list entities.
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 versus alternatives (e.g., get_virtual_account, list_banks). The description only states the function without contextualizing its place among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sandbox only (test-mode keys): drive a real reconciliation with no bank movement — create an account, simulate a payment, watch it reconcile end-to-end. Amount in kobo.
| Name | Required | Description | Default |
|---|---|---|---|
| reversal | No | ||
| accountRef | Yes | ||
| amountKobo | Yes | ||
| senderName | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions behavior like 'drive real reconciliation with no bank movement', but lacks details on side effects (e.g., account creation) and response format. Somewhat vague.
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 sentence packing key information: environment, purpose, behavior, and unit. Could be slightly more structured but efficient.
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?
With 4 parameters, no output schema, and no annotations, the description is incomplete. It doesn't explain return values, the effect of reversal, or the role of senderName. Acceptable for sandbox but could be more thorough.
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 0%, and the description only explains 'Amount in kobo' for amountKobo. No explanation for accountRef, reversal, or senderName. Minimal value added beyond 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?
The description clearly states it is for sandbox/test-mode and its purpose: to drive reconciliation by simulating a deposit without real bank movement. Uses specific verbs and distinguishes from real transaction tools.
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?
Explicitly says 'Sandbox only (test-mode keys)', telling when to use. Implies it's for testing reconciliation without alternatives, but no explicit exclusions or when-not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate transaction totals and reconciliation breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It states aggregation and reconciliation but lacks details on scope (e.g., time range), side effects (read-only assumed), or output format.
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?
A single sentence front-loading the action is concise and contains no filler.
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 parameters, the description is minimal. It explains the core function but leaves ambiguity about what 'reconciliation breakdown' entails.
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?
There are no parameters, so the schema provides full coverage. The description adds no parameter information, but none is needed.
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 uses a specific verb ('aggregate') and resource ('transaction totals and reconciliation breakdown'), clearly distinguishing it from siblings like list_transactions and get_transaction.
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 given on when to use this tool versus alternatives such as list_transactions or get_transaction, nor any exclusions or prerequisites.
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.
v0.1.0create_virtual_accountdelete_virtual_accountget_agent_guideget_transactionget_virtual_accountinitiate_transferlist_bankslist_transactionslist_transferslist_virtual_accountslookup_bank_accountsimulate_deposittransactions_summaryScored across 13 tools
Each tool has a clearly distinct purpose. For example, get_transaction, list_transactions, and transactions_summary all serve different query scopes. The CRUD operations for virtual accounts and transfers are well-separated.
Most tools follow a verb_noun pattern (e.g., create_virtual_account, list_banks). The only deviation is transactions_summary, which uses noun_verb, causing a minor inconsistency.
13 tools is a reasonable count for a payment/virtual account server. Each tool covers a necessary operation without being overwhelming or too sparse.
Core operations are covered: CRUD on virtual accounts, transaction retrieval, transfer initiation, bank account lookup, and simulation. Minor gaps include no get_transfer tool to fetch a single transfer by reference.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Payment infrastructure for AI agents: spending rules, approval flows, single-use virtual cards.
Complete financial infrastructure for AI agents — payments, lending, escrow & more.
Connect AI agents to bank accounts, transactions, balances, and investments.
Connect AI agents to financial institution origination, analytics, and compliance workflows.
