Shabaas Pay MCP Sever
Server Details
ShaBaas Pay MCP lets AI agents securely create PayTo agreements, initiate payments, and check statuses via structured tools. Authenticate with your ShaBaas Pay API key and control tool access from the dashboard.
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose with no overlap. create_payment_agreement and get_payment_agreement handle agreement lifecycle, while initiate_payment and get_payment_initiation handle payment operations, and get_auth_token is a separate authentication utility. The descriptions reinforce these distinct roles, making misselection unlikely.
All tool names follow a consistent verb_noun pattern using snake_case. The verbs (create, get, initiate) are clear and appropriate for their actions, and the nouns (payment_agreement, auth_token, payment_initiation) consistently describe the resources. There are no deviations in naming conventions.
With 5 tools, this server is well-scoped for payment processing. It covers core operations like agreement management and payment initiation, plus authentication, without being overly sparse or bloated. Each tool earns its place in supporting typical payment workflows.
The toolset provides good coverage for payment initiation and agreement management, including create and get operations. However, it lacks update or delete tools for agreements or payments, which could limit agent flexibility in handling modifications or cancellations. The authentication tool is a useful addition, but minor gaps exist in lifecycle management.
Available Tools
5 toolscreate_payment_agreementCInspect
Create a new payment agreement. Remote MCP (HTTP): session is authenticated via OAuth or Authorization header—do not ask the user for an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| bsb | No | Mandatory if type is bsb | |
| name | Yes | Payment agreement name / account owner name | |
| type | Yes | Payment agreement type. Allowed values: email, phone, org, abn, bsb. | |
| enrich | No | If true include business enrichment such as readiness, next actions, and reconciliation tips | |
| pay_id | No | PayID that will be charged. Mandatory if type is email, phone, org, or abn. Example sample@shabaas.com | |
| end_date | No | End date | |
| frequency | Yes | Frequency. Stored codes: ADHO, DAIL, FRTN, INDA, MIAN, MNTH, QURT, WEEK, YEAR. Accepted aliases include DAILY and ADHOC. | |
| start_date | No | Start date | |
| include_raw | No | Include raw API response for debugging | |
| phone_number | No | Phone number to save and view transaction status | |
| account_number | No | Mandatory if type is bsb | |
| agreement_type | No | Agreement type | |
| maximum_amount | Yes | Maximum amount, example 10 or 10.00 | |
| number_of_transactions_permitted | Yes | Number of transactions permitted, example 1 |
Tool Definition Quality
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. It only mentions authentication method (OAuth/Authorization header) but fails to describe what 'create' entails: whether this is a write operation, what permissions are needed, what happens on success/failure, or any rate limits. For a creation tool with zero annotation coverage, this is inadequate.
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 appropriately brief (two sentences) and front-loaded with the core purpose. The authentication note is relevant but could be more integrated. There's minimal waste, though the second sentence about authentication feels somewhat tacked on rather than seamlessly integrated.
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 creation tool with 14 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what gets created, what the response looks like, error conditions, or business context. The authentication note is helpful but doesn't compensate for the missing behavioral and output information needed for a complete understanding.
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 all 14 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.
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 ('Create') and resource ('payment agreement'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its siblings (like 'initiate_payment'), which would require a 5. The description is specific about what it does but lacks sibling comparison.
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 'initiate_payment' or 'get_payment_agreement'. It mentions authentication context but doesn't address functional alternatives or prerequisites beyond authentication. This leaves the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_auth_tokenCInspect
Get ShaBaas API authorization token
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | ShaBaas API key |
Tool Definition Quality
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 what the tool does without behavioral details. It doesn't disclose whether this is a one-time or reusable token, expiration behavior, rate limits, error conditions, or what the response contains. 'Get' implies a read operation, but authentication tools often have side effects.
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 wasted words. It's appropriately sized for a simple authentication tool and gets straight to the point 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?
For an authentication tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the token is used for, how long it's valid, what format it returns, or error scenarios. Given the complexity of authentication and lack of structured 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?
Schema description coverage is 100% (the single parameter 'api_key' is fully documented in the schema), so the baseline is 3. The description doesn't add any parameter information beyond what's already in the schema, but doesn't need to since schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('ShaBaas API authorization token'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools (all payment-related), which would require mentioning this is for authentication rather than payment operations.
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 about when to use this tool versus alternatives. The description doesn't mention prerequisites (like needing this token for other API calls), when authentication is required, or how this relates to the payment-focused sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_payment_agreementBInspect
Retrieve payment agreement details with AI insights. Remote MCP (HTTP): session is authenticated via OAuth or Authorization header—do not ask the user for an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| enrich | No | If true include business enrichment such as readiness, customer copy, operational checks and references | |
| include_raw | No | Include raw API response for debugging | |
| payment_agreement_id | Yes | The payment agreement ID to retrieve |
Tool Definition Quality
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. It mentions authentication requirements (OAuth/Authorization header) which is valuable context, but doesn't address rate limits, error handling, or what 'AI insights' specifically entails. The description adds some behavioral context but leaves significant 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 reasonably concise with two sentences, though the authentication instruction could be more efficiently integrated. It's front-loaded with the core purpose, but the authentication detail feels somewhat tacked on rather than seamlessly incorporated.
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 'payment agreement details' or 'AI insights' actually include, nor does it describe the return format or potential error conditions. The authentication note is helpful but doesn't compensate for the broader contextual gaps.
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 fully documents all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score 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 clearly states the verb 'retrieve' and resource 'payment agreement details', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_payment_initiation' or 'create_payment_agreement', which would require more specific scope definition.
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 'get_payment_initiation' or 'create_payment_agreement'. It only mentions authentication requirements, which doesn't help with tool selection decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_payment_initiationBInspect
Retrieve payment initiation by ID. Remote MCP (HTTP): session is authenticated via OAuth or Authorization header—do not ask the user for an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| enrich | No | If true include PayTo context such as readiness, next actions, and reconciliation tips | |
| include_raw | No | Include raw API response for debugging | |
| payment_initiation_id | Yes | The payment initiation ID to retrieve |
Tool Definition Quality
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 authentication behavior (OAuth/Authorization header) and warns not to ask for an API key, which is useful context. However, it lacks details on rate limits, error handling, or what the retrieval entails beyond the ID, leaving 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 appropriately sized with two sentences: the first states the purpose, and the second adds authentication context. It's front-loaded with the core function, though the authentication detail might be slightly verbose for a tool description.
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 provides basic purpose and authentication context but lacks details on return values, error cases, or how it differs from siblings. It's minimally adequate for a retrieval tool but incomplete for full agent understanding.
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 fully documents all three parameters. The description adds no additional meaning about parameters beyond implying the 'payment_initiation_id' is required, which is already clear from the schema. This meets 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 clearly states the verb ('Retrieve') and resource ('payment initiation by ID'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_payment_agreement' or 'initiate_payment', which would require mentioning it's specifically for retrieving payment initiations rather than agreements or creating payments.
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 'get_payment_agreement' or 'initiate_payment'. It mentions authentication details but doesn't help the agent choose between sibling tools based on context or requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
initiate_paymentCInspect
Initiate a payment against an agreement. Remote MCP (HTTP): session is authenticated via OAuth or Authorization header—do not ask the user for an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Optional note stored by backend for this payment initiation. | |
| amount | Yes | Amount to charge. Use a number (e.g. 50.00) or numeric string. | |
| enrich | No | If true include PayTo context such as readiness, next actions, and reconciliation tips | |
| description | No | Legacy alias for notes. If provided without notes, it will be forwarded as notes. | |
| include_raw | No | Include raw API response for debugging | |
| payment_agreement_id | Yes | The payment agreement ID to charge |
Tool Definition Quality
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. While it mentions authentication (OAuth/Authorization header), it doesn't disclose whether this is a destructive/mutative operation (implied by 'initiate' but not explicit), what happens after initiation (e.g., payment processing flow), rate limits, error conditions, or what the response contains. For a payment tool with zero annotation coverage, 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 appropriately concise with two sentences that each serve a purpose: the first states the core function, the second provides authentication context. However, the second sentence about authentication could be more integrated with the tool's purpose rather than appearing as an afterthought.
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 payment initiation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after initiation, what the expected response looks like, error handling, or how this differs from related payment operations. The authentication note is helpful but doesn't compensate for the missing behavioral 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 schema already documents all 6 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.
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 ('Initiate a payment') and the target resource ('against an agreement'), which provides a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'get_payment_initiation', which appears to be a read operation versus this write operation.
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 'create_payment_agreement' or 'get_payment_initiation'. It mentions authentication details but doesn't help the agent understand the appropriate context for payment initiation versus agreement creation or retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!