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., "@tabby-mcp Create a Tabby checkout session for 500 AED"
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 Tabby BNPL (Buy Now Pay Later) platform (UAE/Saudi/Kuwait/Bahrain). Manage checkout sessions, payments, captures, refunds, and voids.
Tool | Description |
| Create a BNPL checkout session |
| Get session details |
| Create a payment from session |
| Get payment details |
| Capture authorized payment |
| Refund captured payment |
| Void authorized payment |
| List payments with filters |
Related MCP server: io.github.stucchi/telnyx
{
"mcpServers": {
"tabby": {
"command": "npx",
"args": ["-y", "@theyahia/tabby-mcp"],
"env": {
"TABBY_SECRET_KEY": "<YOUR_SECRET_KEY>"
}
}
}
}Variable | Required | Description |
| Yes | Secret API key from Tabby dashboard |
"Create a Tabby checkout session for 500 AED"
"Check session sess_abc123 status"
"Capture payment pay_xyz789"
"Refund 200 AED from payment pay_xyz789"
"List all authorized payments"
MIT
Capture an authorized payment.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_id | Yes | Payment ID to capture | |
| amount | No | Partial capture amount (omit for full) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It implies mutation ('capture') but fails to describe side effects (e.g., authorization consumed, funds settled), idempotency, or error scenarios if payment is not authorized.
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 concise sentence with no wasted words. However, it could include additional context like return value or prerequisite without losing 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 the absence of an output schema and sibling tools, the description is incomplete. It lacks information on return values, error handling, and how to distinguish from similar actions like 'void' or 'refund'.
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 description adds no extra meaning beyond the input schema, which already fully describes both parameters (payment_id required, amount optional for partial capture). Schema coverage is 100%, so 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 'Capture an authorized payment' clearly states the action (capture) and resource (authorized payment). It is distinct from sibling tools like 'create_payment' and 'refund' in a general sense, but does not explicitly differentiate from 'void' or specify the payment's state requirement.
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 usage guidance is provided. The description does not state when to use capture versus alternatives like refund or void, nor does it mention required preconditions (e.g., payment must be in 'authorized' state).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a payment from an approved session.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Payment amount | |
| currency | No | Currency code | AED |
| description | No | Payment description | |
| order_reference | No | Merchant order reference |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates a create/mutation action but provides no details on side effects, permissions, or outcomes. The mention of 'approved session' hints at a precondition but 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 with no wasted words, but it is arguably too terse for a 4-parameter tool. It is front-loaded but lacks depth.
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 (4 params, no output schema, no annotations), the description is incomplete. It omits details on prerequisites, return values, and error conditions, leaving gaps for the 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?
Schema description coverage is 100%, so baseline is 3. The description adds no direct parameter guidance beyond what the schema already provides, which is adequate but not enhanced.
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 ('Create') and the resource ('payment'), with a qualifying condition ('from an approved session'). It distinguishes from siblings like 'capture' by implying a prerequisite, though not explicitly.
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 does not provide guidance on when to use this tool versus alternatives (e.g., 'capture', 'void'). It mentions a prerequisite ('approved session') but does not elaborate on when not to use it or clarify the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Tabby checkout session for BNPL.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Payment amount as string (e.g. '100.00') | |
| currency | No | Currency code | AED |
| buyer_email | Yes | Buyer email address | |
| buyer_phone | Yes | Buyer phone number | |
| buyer_name | No | Buyer full name | |
| description | No | Order description | |
| merchant_urls_success | Yes | Redirect URL on success | |
| merchant_urls_cancel | Yes | Redirect URL on cancel | |
| merchant_urls_failure | Yes | Redirect URL on failure |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'create' implying mutation, but lacks information on side effects, idempotency, authentication needs, or rate limits. No behavioral details beyond the creation 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 a single concise sentence with no filler. It is front-loaded and efficient, though it could benefit from slightly more context without becoming verbose.
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 9 parameters, 6 required, and no output schema, the description is too brief. It fails to explain what a 'Tabby checkout session' is, what the response contains, or any post-creation steps (e.g., redirects). The agent lacks critical context 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?
Input schema coverage is 100%, with each parameter described. The tool description adds no extra parameter meaning. Baseline score of 3 is appropriate since the schema already provides sufficient 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 clearly states the tool creates a 'Tabby checkout session for BNPL', specifying the verb, resource, and context. It distinguishes from sibling tools like 'create_payment' or 'get_session' by naming the specific payment method (BNPL).
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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like 'create_payment' or 'capture', nor does it mention prerequisites 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 payment details by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_id | Yes | Payment ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits such as read-only nature, idempotency, authentication requirements, or error behavior. Since no annotations are provided, the description carries the full burden, and it fails to go beyond stating the basic operation.
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 redundant words. It efficiently conveys the core purpose without any 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?
For a simple get-by-ID tool with one parameter and no output schema, the description is adequate but minimal. It does not cover return format, error cases, or any additional behavior. Given the simplicity, a score of 3 is reasonable.
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, so the baseline is 3. The description adds no additional meaning beyond what the schema provides (both say 'by ID' and 'Payment ID'). No format or constraints are elaborated.
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 retrieves payment details by ID. It uses a specific verb 'Get' and resource 'payment details', which is unambiguous. However, it does not explicitly differentiate from sibling tools like list_payments or get_session, which slightly reduces the score from a perfect 5.
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 implies usage when a payment ID is known, but there is no explicit context or exclusions (e.g., 'use get_payment when you have a specific ID, use list_payments to browse').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get checkout session details.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Checkout session ID |
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 'Get' which implies a read operation, but does not disclose authentication needs, error handling (e.g., session not found), or any side effects. For a simple retrieval, 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 a single short sentence, which is concise but under-specified. It lacks important context that would warrant higher score for efficiency.
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), the description is incomplete. It does not explain return format, error conditions, or that it is a read-only operation. Sibling tools suggest broader payment operations, but this tool's context is not fully covered.
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 a single parameter described as 'Checkout session ID'. The tool description adds no additional meaning beyond what the schema already provides, so 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 'Get checkout session details' uses a specific verb and resource, clearly indicating retrieval of session info. It distinguishes well from sibling tools like create_session (create) and get_payment (different 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?
The description provides no explicit guidance on when to use this tool versus alternatives (e.g., when to use get_session instead of get_payment or list_payments). Usage must be inferred solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List payments with filters.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| limit | No | Items per page | |
| status | No | Filter by status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fails to mention key behaviors such as pagination (page/limit parameters), default ordering, idempotency, or any side effects. The simple phrase 'with filters' does not convey that results are paginated or limited to a maximum of 100 items per page, which is essential for correct invocation.
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?
At three words, the description is very concise and front-loaded. However, it sacrifices informative content for brevity. While not verbose, it could be improved by adding a short sentence about pagination or filtering options without becoming overly long.
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 lack of output schema and annotations, the description is insufficiently complete. It does not mention the response format, default pagination behavior, or ordering of results. For a list tool with 3 parameters and no output schema, the description should provide more context about the returned data and any limitations (e.g., maximum results).
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 three parameters (page, limit, status) have descriptions in the input schema, achieving 100% coverage. The tool description adds no extra meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List payments with filters' clearly states the tool's purpose: to retrieve a list of payments with optional filtering. However, it does not explicitly differentiate from sibling tools like get_payment (which retrieves a single payment) or capture/refund (which modify payments), but the verb 'list' and the mention of filters provide sufficient context for distinction.
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_payment for a specific payment or capture for modifying payment state. The description lacks context on typical use cases or prerequisites, leaving the agent to infer usage without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refund a captured payment.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_id | Yes | Payment ID to refund | |
| amount | Yes | Refund amount | |
| reason | No | Refund reason |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It only says 'Refund a captured payment,' which indicates mutation but does not disclose side effects (e.g., whether refund is partial/full, if payment becomes refunded, or if it triggers notifications). The behavioral impact is underspecified.
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, which is concise but lacks helpful structure. It is front-loaded, but the sentence is brief. It earns its place but could be slightly expanded for clarity without becoming verbose.
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 sibling tools like capture and void, the description does not explain how refund differs or what returns from the tool (no output schema). For a mutation action, this is incomplete; missing error conditions or required payment state.
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 no extra meaning beyond the schema property descriptions (e.g., 'Payment ID to refund'). It does not clarify formats, constraints, or relationships between parameters.
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 'Refund a captured payment' clearly states the verb (refund) and the specific resource (captured payment). It effectively distinguishes from siblings like capture, void, or create_payment, which handle different stages.
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 refund versus alternatives like void. For example, it does not mention that the payment must be in a 'captured' state or that refunds may not be possible after a certain time. The description implies usage but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Void an authorized payment.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_id | Yes | Payment ID to void |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as destructiveness, irreversibility, or required permissions. The description is too minimal to convey necessary 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?
The description is extremely concise at three words, but it is not a tautology—it adds 'authorized payment' context. It earns its place without any waste.
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 one parameter and no output schema, the description is too minimal. It lacks explanation of effects, prerequisites, or postconditions, 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?
Schema description coverage is 100% (the one parameter has a description). The description adds no extra meaning beyond the schema, 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 clearly states the action ('void') and the resource ('authorized payment'), which is a specific verb+resource pair. It distinguishes from siblings like 'capture' and 'refund' by the term 'void', but does not explicitly differentiate from 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?
The description gives no guidance on when to use this tool versus alternatives like 'refund' or 'capture'. It only implies the context ('authorized payment'), but no explicit conditions or exclusions.
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.
v1.0.0capturecreate_paymentcreate_sessionget_paymentget_sessionlist_paymentsrefundvoidEach tool targets a distinct operation in the payment lifecycle: session creation, payment creation, capture, refund, void, and retrieval. No overlap or ambiguity.
All tools follow a consistent verb_noun pattern in snake_case (e.g., create_session, get_payment, list_payments). No deviations.
8 tools is well-scoped for payment processing and checkout sessions. Each tool has a clear role without redundancy.
Covers the core BNPL flow: session creation, payment creation, capture, refund, void, and retrieval. Minor gap: no update or cancel session, but the essential operations are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create and manage checkout pages, event ticketing, forms, customers, payments and subscriptions.
Read payment settings, orders and receipts, create payment links and API keys.
Search Checkout.com docs and API reference, plus manage payments, refunds, and payment links.
Create payment orders, checkout, subscriptions & UPI via PineLabs Plural PG gateway
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/theYahia/tabby-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
