The GoCardless MCP Server enables AI assistants to interact with GoCardless payment data through read operations and limited write capabilities.
Customer Management: List all customers, retrieve specific customer details by ID, and create new customers (requires email, optional name/company fields).
Payment Operations: List payments with filtering by status, mandate, or subscription; retrieve specific payment details by ID; and create new payments (requires amount, currency, and mandate ID).
Mandate Management: List mandates with optional customer filtering and retrieve specific mandate details by ID (mandates authorize recurring payments).
Subscription Management: List subscriptions with status filtering, retrieve basic subscription details, and get complete subscription information including associated mandate and customer data in a single call.
Payout Information: List recent payouts from the GoCardless account.
Additional Features: Automatic detection and parsing of Xero integration metadata (contact, invoice, and payment IDs); support for both sandbox and live GoCardless environments.
Limitations: Read-only API tokens recommended for most use cases; no update operations on existing records; no cancellation capabilities for subscriptions, mandates, or payments; write operations limited to customer and payment creation only.
Provides automatic detection and parsing of Xero contact, invoice, and payment IDs from GoCardless payment metadata, enabling integration between GoCardless payments and Xero accounting records.
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., "@GoCardless MCP Server show me my recent customers"
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 (MCP) server for GoCardless API integration, enabling AI assistants to interact with GoCardless payment data.
This MCP server provides tools to:
Customers: List, get, and create customers
Payments: List, get, and create payments
Mandates: List and get mandates
Subscriptions: List and get subscriptions (including combined details with customer/mandate)
Payouts: List payouts
Xero Integration: Automatic detection and parsing of Xero contact/invoice/payment IDs from metadata
Related MCP server: Xero MCP Server
Read-only recommended: While customer and payment creation are supported, read-only API tokens are recommended for most use cases
No update operations: Existing records cannot be modified
No cancellation: Subscriptions, mandates, and payments cannot be cancelled through this server
No installation required - uvx will automatically fetch and run the package:
uvx --from git+https://github.com/jmceleney/gocardless-mcp.git gocardless-mcpConfigure in your MCP settings (see configuration examples below).
pipx install git+https://github.com/jmceleney/gocardless-mcp.gitpip install git+https://github.com/jmceleney/gocardless-mcp.git# Clone the repository
git clone https://github.com/jmceleney/gocardless-mcp.git
cd gocardless-mcp
# Install in development mode
pip install -e .You'll need to configure these environment variables:
GOCARDLESS_ACCESS_TOKEN (required): Your GoCardless API access token
GOCARDLESS_ENVIRONMENT (optional): Either sandbox or live (defaults to sandbox)
Get a GoCardless Access Token:
Sign up for a GoCardless sandbox account
Navigate to Developers > API tokens
Create a new access token
Copy the token for use in configuration
Claude Desktop is the easiest way to get started with MCP servers.
Configuration file location:
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
Add this configuration:
{
"mcpServers": {
"gocardless": {
"command": "gocardless-mcp",
"env": {
"GOCARDLESS_ACCESS_TOKEN": "your_access_token_here",
"GOCARDLESS_ENVIRONMENT": "sandbox"
}
}
}
}After configuration:
Restart Claude Desktop
Look for the 🔨 (hammer) icon in the bottom-right corner
Click it to verify the GoCardless server is connected
Start asking questions like "Show me my recent GoCardless customers"
Claude Code works best with uvx for automatic package management.
Method 1: Using uvx (Recommended)
claude mcp add gocardless \
--env GOCARDLESS_ACCESS_TOKEN=your_token_here \
--env GOCARDLESS_ENVIRONMENT=sandbox \
-- uvx --from git+https://github.com/jmceleney/gocardless-mcp.git gocardless-mcpMethod 2: Edit Configuration File Directly
Edit ~/.claude.json:
{
"mcpServers": {
"gocardless": {
"type": "stdio",
"command": "uvx",
"args": ["--from", "git+https://github.com/jmceleney/gocardless-mcp.git", "gocardless-mcp"],
"env": {
"GOCARDLESS_ACCESS_TOKEN": "your_access_token_here",
"GOCARDLESS_ENVIRONMENT": "sandbox"
}
}
}
}After configuration:
Restart Claude Code
Verify with: claude mcp list
The GoCardless server should appear in the list
Cursor works best with uvx for automatic package management.
Project-specific configuration (recommended):
Create .cursor/mcp.json in your project root:
{
"mcpServers": {
"gocardless": {
"command": "uvx",
"args": ["--from", "git+https://github.com/jmceleney/gocardless-mcp.git", "gocardless-mcp"],
"env": {
"GOCARDLESS_ACCESS_TOKEN": "your_access_token_here",
"GOCARDLESS_ENVIRONMENT": "sandbox"
}
}
}
}Global configuration (available in all projects):
Create ~/.cursor/mcp.json:
{
"mcpServers": {
"gocardless": {
"command": "uvx",
"args": ["--from", "git+https://github.com/jmceleney/gocardless-mcp.git", "gocardless-mcp"],
"env": {
"GOCARDLESS_ACCESS_TOKEN": "your_access_token_here",
"GOCARDLESS_ENVIRONMENT": "sandbox"
}
}
}
}After configuration:
Restart Cursor
Open the MCP settings page to verify the server is connected
The Composer Agent will automatically use GoCardless tools when relevant
For any MCP client that supports stdio transport:
# Make sure environment variables are set
export GOCARDLESS_ACCESS_TOKEN="your_token_here"
export GOCARDLESS_ENVIRONMENT="sandbox"
# Run the server
gocardless-mcpThe server communicates via JSON-RPC over stdin/stdout, so it won't produce output when run directly.
GoCardless data follows this hierarchy:
Customer (CU*) → Mandate (MD*) → Subscription (SB*) / Payment (PM*)
Mandates authorize recurring payments. Subscriptions generate recurring payments automatically.
list_customers: List all customers (optional limit parameter)
get_customer: Get a specific customer by ID
create_customer: Create a new customer (requires email, optional given_name, family_name, company_name)
list_payments: List payments (optional limit, status, subscription, mandate filters)
get_payment: Get a specific payment by ID (includes links to mandate/subscription)
create_payment: Create a new payment (requires amount, currency, mandate_id, optional description)
list_mandates: List mandates (optional limit and customer parameters)
get_mandate: Get a specific mandate by ID (includes link to customer)
list_subscriptions: List subscriptions (optional limit and status parameters)
get_subscription: Get a specific subscription by ID (includes link to mandate)
get_subscription_details: Get complete subscription info including mandate and customer in one call
list_payouts: List payouts (optional limit parameter)
Once configured in Claude Desktop, you can ask:
"Show me my recent GoCardless customers"
"Get details for customer CU123"
"Create a new customer with email test@example.com"
"List all pending payments"
"Show me the details of payment PM123"
The MCP Inspector provides an interactive web interface to test your server:
# Run the inspector (requires Node.js)
npx @modelcontextprotocol/inspector gocardless-mcpThis will:
Start the inspector on http://localhost:6274
Open your browser automatically
Allow you to set environment variables in the UI
Interactively test all available tools
In the Inspector:
Set your GOCARDLESS_ACCESS_TOKEN in the environment variables section
Set GOCARDLESS_ENVIRONMENT to sandbox
Browse available tools on the left sidebar
Click any tool to see its schema
Fill in parameters and click "Run" to test
Create a test script to programmatically test the server:
import asyncio
import os
from mcp.client.session import ClientSession
from mcp.client.stdio import StdioServerParameters, stdio_client
async def main():
server_params = StdioServerParameters(
command="gocardless-mcp",
env={
"GOCARDLESS_ACCESS_TOKEN": "your_sandbox_token",
"GOCARDLESS_ENVIRONMENT": "sandbox"
}
)
async with stdio_client(server_params) as (read, write):
async with ClientSession(read, write) as session:
await session.initialize()
# List available tools
tools = await session.list_tools()
print("Available tools:")
for tool in tools.tools:
print(f" - {tool.name}: {tool.description}")
# Test a tool
result = await session.call_tool("list_customers", {"limit": 5})
print("\nResult:", result)
asyncio.run(main())# Install development dependencies
pip install -e ".[dev]"
# Run tests (when implemented)
pytestMIT
Contributions are welcome! Please feel free to submit a Pull Request.
Create a new customer in GoCardless
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Customer email address | ||
| given_name | No | Customer first name | |
| family_name | No | Customer last name | |
| company_name | No | Customer company name (optional) |
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. While 'Create' implies a write/mutation operation, the description doesn't specify whether this requires specific permissions, what happens on duplicate emails, what the response format is, or any rate limits. For a mutation tool with zero annotation coverage, this represents a significant gap in 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 a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a straightforward creation tool and gets directly to the point, making it easy for an agent to parse quickly.
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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address what the tool returns, error conditions, authentication requirements, or how it fits into the broader workflow with sibling tools. For a tool that creates persistent data in a payment system, more contextual information would be helpful.
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 all four parameters clearly documented in the schema itself. The description doesn't add any additional parameter information beyond what's already in the schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the 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 ('Create a new customer') and the target system ('in GoCardless'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'get_customer' or 'list_customers' beyond the obvious creation vs retrieval distinction, 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 requirements), when not to use it (e.g., for updating existing customers), or how it relates to sibling tools like 'list_customers' for verification. This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new payment in GoCardless
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount in minor currency unit (e.g., 1000 for £10.00) | |
| currency | Yes | ISO 4217 currency code (e.g., GBP, EUR) | |
| mandate_id | Yes | ID of the mandate to use for this payment | |
| description | No | Payment 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. It states this is a creation tool, implying a write operation, but doesn't mention critical behaviors like authentication requirements, potential side effects (e.g., charging a customer), error conditions, or what happens on success. For a payment creation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly. Every word earns its place by conveying essential information about the action and target system.
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 payment creation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, what happens after creation (e.g., payment status), error handling, or integration with other tools like mandate management. For a financial transaction tool, more context about behavior and outcomes 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, providing clear documentation for all 4 parameters (amount, currency, mandate_id, description) including formats and examples. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting but doesn't compensate or enhance understanding.
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 in GoCardless'), making the purpose immediately understandable. It distinguishes from siblings like 'get_payment' or 'list_payments' by specifying creation rather than retrieval. However, it doesn't explicitly differentiate from other creation tools like 'create_customer', leaving some ambiguity about when to create a payment versus a customer.
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., needing a mandate first), compare to sibling tools like 'create_customer', or specify contexts where payment creation is appropriate versus other operations. This leaves the agent without explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific customer by ID
| Name | Required | Description | Default |
|---|---|---|---|
| customer_id | Yes | The GoCardless customer ID (e.g., CU123) |
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 the basic action without disclosing behavioral traits. It doesn't mention whether this is a read-only operation, requires authentication, has rate limits, returns error handling for invalid IDs, or what data format to expect. This leaves significant gaps for an agent to understand tool behavior.
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, clear sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loaded with essential information, making it highly 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 (1 parameter, no output schema), the description is incomplete. It lacks details on return values, error conditions, or behavioral context, which are crucial for an agent to use it effectively. Without annotations or output schema, the description should compensate more to provide a complete picture.
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 minimal meaning beyond the input schema, which has 100% coverage and documents the 'customer_id' parameter well. The description implies the ID is used for retrieval but doesn't provide additional context like ID format examples or validation rules. Baseline 3 is appropriate since 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 clearly states the verb ('Get') and resource ('a specific customer by ID'), making the purpose immediately understandable. It distinguishes from siblings like 'list_customers' by specifying retrieval of a single customer. However, it doesn't explicitly mention what 'get' entails (e.g., retrieving full details vs. basic info), keeping it from 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 implies usage when you have a customer ID, suggesting it's for retrieving known customers rather than listing or creating them. However, it lacks explicit guidance on when to use this vs. alternatives like 'list_customers' for browsing or 'get_subscription' for related data, and doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific mandate by ID
| Name | Required | Description | Default |
|---|---|---|---|
| mandate_id | Yes | The GoCardless mandate ID (e.g., MD123) |
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. It states the tool retrieves a mandate but doesn't cover aspects like authentication requirements, rate limits, error handling, or what data is returned (e.g., mandate details, status). For a read operation without annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero waste. It's appropriately sized and front-loaded, making it easy to parse quickly 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 the lack of annotations and output schema, the description is incomplete for a tool that retrieves data. It doesn't explain what information is returned (e.g., mandate attributes, status), potential errors, or usage constraints. For a read operation with no structured output, more context is needed 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%, with the parameter 'mandate_id' documented in the schema as 'The GoCardless mandate ID (e.g., MD123)'. The description adds no additional meaning beyond this, such as format constraints or examples, 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 ('Get') and resource ('a specific mandate by ID'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'list_mandates' or 'get_customer', which would require mentioning it retrieves a single mandate by unique identifier rather than listing multiple mandates or fetching other resource types.
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 using 'list_mandates' for multiple mandates or 'get_customer' for customer data, nor does it specify prerequisites like needing a valid mandate ID. This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific payment by ID
| Name | Required | Description | Default |
|---|---|---|---|
| payment_id | Yes | The GoCardless payment ID (e.g., PM123) |
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. It states the tool retrieves a payment by ID but doesn't describe what happens if the ID is invalid (e.g., error response), whether authentication is required, rate limits, or the format of the returned data. For a read operation with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior.
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: 'Get a specific payment by ID'. It is front-loaded with the core purpose, appropriately sized for a simple retrieval tool, and every word earns its place without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic purpose but lacks context on usage guidelines, behavioral traits (e.g., error handling), and output details. For a simple read tool, this might suffice, but it doesn't provide enough information for optimal agent use without additional assumptions.
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 the 'payment_id' parameter fully documented in the schema (type: string, description: 'The GoCardless payment ID (e.g., PM123)'). The description adds no additional meaning beyond what the schema provides, as it only mentions 'by ID' without elaborating on format or examples. Baseline score of 3 is appropriate since 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 clearly states the verb ('Get') and resource ('a specific payment by ID'), making the purpose immediately understandable. It distinguishes from sibling tools like 'list_payments' by specifying retrieval of a single payment rather than listing multiple. However, it doesn't explicitly differentiate from other get_* tools (e.g., 'get_customer', 'get_mandate') beyond the resource type.
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 when to use 'get_payment' instead of 'list_payments' (e.g., for a known payment ID), nor does it reference other sibling tools like 'get_customer' or 'get_subscription' for related data. There's no discussion of prerequisites, error conditions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get subscription by ID. Returns links.mandate - use get_mandate then get_customer for full details, or use get_subscription_details instead.
| Name | Required | Description | Default |
|---|---|---|---|
| subscription_id | Yes | The GoCardless subscription ID (e.g., SB123) |
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 effectively describes the return format ('Returns links.mandate') and hints at limitations (requiring additional steps for full details), which adds valuable context beyond basic functionality. However, it doesn't cover aspects like error handling 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?
The description is extremely concise and front-loaded, with two sentences that each serve a clear purpose: the first states the core functionality, and the second provides crucial usage guidance. There is zero wasted language, making it highly 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?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is quite complete. It covers purpose, usage alternatives, and behavioral aspects like return data structure. The main gap is the lack of output schema, but the description compensates well by explaining what information is returned and how to obtain further details.
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 the 'subscription_id' parameter. The description doesn't add any additional semantic meaning or context about the parameter beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter documentation.
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 specific action ('Get subscription by ID') and resource ('subscription'), distinguishing it from sibling tools like 'get_subscription_details' by emphasizing the ID-based retrieval. It provides a precise verb+resource combination that leaves no ambiguity about its function.
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 explicitly provides usage guidance by stating when to use alternatives: it mentions that 'links.mandate' is returned and advises using 'get_mandate then get_customer for full details' or 'use get_subscription_details instead.' This clearly defines when this tool is appropriate versus other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get complete subscription info including mandate and customer in one call
| Name | Required | Description | Default |
|---|---|---|---|
| subscription_id | Yes | The GoCardless subscription ID (e.g., SB123) |
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. It states this is a read operation ('Get'), but doesn't mention any behavioral traits such as authentication requirements, rate limits, error conditions, or what 'complete' entails beyond mandate and customer info. This leaves significant gaps for a tool that likely interacts with payment/subscription data.
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 that front-loads the key information ('Get complete subscription info') and adds clarifying details ('including mandate and customer in one call') without any wasted words. It's appropriately sized for a simple tool with one 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 tool's low complexity (1 parameter, no nested objects) and high schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it fails to disclose important behavioral aspects like what data is returned or any operational constraints. This makes it incomplete for safe and effective use by an AI 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?
The input schema has 100% description coverage, with the single parameter 'subscription_id' well-documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or validation rules. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
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's purpose with a specific verb ('Get') and resource ('subscription info'), and it specifies what information is included ('complete subscription info including mandate and customer'). However, it doesn't explicitly differentiate from the sibling 'get_subscription' tool, which appears to be a simpler version.
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 context by mentioning 'in one call,' suggesting this tool should be used when you need comprehensive subscription data. However, it doesn't provide explicit guidance on when to use this versus the simpler 'get_subscription' sibling tool or other related tools like 'get_mandate' or 'get_customer.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all customers from GoCardless
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of customers to retrieve (default: 50) |
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 states it's a list operation but doesn't mention whether it's paginated, sorted, filtered, or has rate limits. For a list tool with zero annotation coverage, this leaves significant behavioral gaps about how the operation actually works.
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. It's appropriately sized for a simple list tool and front-loads the essential information 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 no annotations, no output schema, and a simple parameter with full schema coverage, the description is incomplete. It doesn't explain what the return format looks like (e.g., array of customer objects), pagination behavior, or error conditions, which are important for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single 'limit' parameter with its type and default. The description adds no additional parameter information beyond what's in the schema, 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 clearly states the verb ('List') and resource ('all customers from GoCardless'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_customer' or other list tools, which would require explicit scope clarification to earn a 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?
The description provides no guidance on when to use this tool versus alternatives like 'get_customer' for individual retrieval or other list tools for different resources. There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List mandates from GoCardless
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of mandates to retrieve (default: 50) | |
| customer | No | Filter by customer ID |
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 but offers minimal information. It states it's a list operation but doesn't describe pagination behavior, rate limits, authentication requirements, or what happens when no mandates exist. For a list tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 list operation 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 a list tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what format the mandates are returned in, whether results are paginated, what authentication is required, or how errors are handled. The combination of missing structured data and minimal description leaves the agent with significant uncertainty about tool 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 schema description coverage is 100%, so both parameters are fully documented in the schema itself. The description adds no additional parameter information beyond what's already in the structured fields. This meets the baseline expectation when the schema does the heavy lifting, but doesn't provide extra context about parameter interactions or usage patterns.
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 ('List') and resource ('mandates from GoCardless'), making the tool's purpose immediately understandable. It doesn't differentiate from sibling tools like 'list_customers' or 'list_payments' beyond the resource name, but the verb+resource combination is specific enough for basic understanding.
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_mandate' (for a single mandate) or other list tools. There's no mention of prerequisites, typical use cases, or contextual factors that would help an agent choose between this and sibling list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List payments from GoCardless
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of payments to retrieve (default: 50) | |
| status | No | Filter by payment status (pending_customer_approval, pending_submission, submitted, confirmed, paid_out, cancelled, customer_approval_denied, failed, charged_back) | |
| subscription | No | Filter by subscription ID (e.g., SB123) | |
| mandate | No | Filter by mandate ID (e.g., MD123) |
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. It states the action ('List payments') but doesn't describe how the tool behaves: whether it returns all payments or is paginated (implied by the 'limit' parameter but not explained), what the default ordering is, whether it requires authentication, or what the output format looks like. For a list operation with no annotation coverage, this 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the description earns its place by conveying essential 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?
Given the complexity of a list operation with filtering parameters, no annotations, and no output schema, the description is incomplete. It doesn't address key behavioral aspects like pagination, authentication needs, or output structure, which are critical for an agent to use the tool effectively. The high schema coverage helps with parameters but doesn't compensate for the lack of operational 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 input schema has 100% description coverage, with clear documentation for all four parameters (limit, status, subscription, mandate). The description doesn't add any parameter-specific information beyond what's in the schema, such as explaining how filters combine or providing examples beyond the enum values. Given the high schema coverage, a 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 clearly states the verb 'List' and the resource 'payments from GoCardless', making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'get_payment' or 'list_payouts', which would require specifying this is for retrieving multiple payments with optional filtering rather than a single payment or other resource types.
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 that 'get_payment' is for retrieving a single payment by ID, 'list_payouts' is for a different resource, or that this tool is appropriate for filtered bulk retrieval. Without such context, the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List payouts from GoCardless
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of payouts to retrieve (default: 50) |
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 only states what the tool does without any additional context. It doesn't mention whether this is a read-only operation, if it requires authentication, how results are returned (e.g., pagination), rate limits, or error conditions, which are critical for a list 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 extremely concise—a single sentence that directly states the tool's purpose without any fluff or redundant information. It's front-loaded and wastes no words, making it efficient for an agent 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?
Given the lack of annotations and output schema, the description is incomplete for a list operation. It doesn't explain what a 'payout' entails in GoCardless, the format of returned data, or any behavioral traits like ordering or filtering options, leaving significant gaps for the agent to operate 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?
The input schema has 100% description coverage, with the 'limit' parameter clearly documented in the schema itself. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline score of 3 where 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 clearly states the verb ('List') and resource ('payouts from GoCardless'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its siblings (like 'list_customers', 'list_payments'), which would require specifying what makes payouts unique versus other list 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for listing payouts (e.g., after payments are processed), or how it differs from other list tools on the server, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List subscriptions from GoCardless
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of subscriptions to retrieve (default: 50) | |
| status | No | Filter by subscription status |
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 only states the basic action. It doesn't mention whether this is a read-only operation, if it requires authentication, how results are returned (pagination, format), rate limits, or error conditions. For a listing 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 extremely concise at just 4 words with zero wasted language. It's front-loaded with the essential information (list subscriptions) and doesn't include any unnecessary elaboration or redundant phrasing.
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 listing tool with no annotations and no output schema, the description is incomplete. It doesn't explain what information is returned, how results are structured, whether pagination is supported, or any behavioral aspects. The agent would need to guess about the tool's behavior and output format based solely on the minimal description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter information, but the input schema has 100% description coverage with clear documentation for both 'limit' and 'status' parameters. Since the schema does the heavy lifting, the baseline score of 3 is appropriate even though the description adds no value beyond what's already in the structured 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 the action ('List') and resource ('subscriptions from GoCardless'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'get_subscription' or 'get_subscription_details', which likely retrieve individual subscriptions rather than listing multiple ones.
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_subscription' or 'get_subscription_details'. There's no mention of use cases, prerequisites, or exclusions that would help an agent choose between these related subscription tools.
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.
create_customercreate_paymentget_customerget_mandateget_paymentget_subscriptionget_subscription_detailslist_customerslist_mandateslist_paymentslist_payoutslist_subscriptionsMost tools have distinct purposes targeting specific resources and actions, but there is some ambiguity between get_subscription and get_subscription_details. The descriptions clarify that get_subscription returns limited data requiring follow-up calls, while get_subscription_details provides complete info, but an agent might still be confused about which to use in different scenarios.
All tools follow a consistent verb_noun naming pattern (e.g., create_customer, get_payment, list_subscriptions). The verbs are standardized (create, get, list) and nouns are clear, with no mixing of conventions like camelCase or snake_case deviations.
With 12 tools, the count is well-scoped for a payment processing domain like GoCardless. It covers core resources (customers, payments, mandates, subscriptions, payouts) with appropriate CRUD operations, avoiding bloat while providing essential functionality.
The tool set offers strong coverage for key resources with create, get, and list operations, but lacks update and delete tools for most entities (e.g., no update_customer or delete_payment). This minor gap might require workarounds, but core workflows like creating and retrieving data are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Stripe payments for AI agents. Create links, verify, manage customers.
Connect AI agents to bank accounts, transactions, balances, and investments.
Read-only bank access for your AI agent. Connects Claude, ChatGPT, Cursor, Gemini, Codex.
Let your AI send invoices and take payment — card or ACH. Free.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jmceleney/gocardless-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
