Stables MCP Server

Official

by stables-money

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Create customer

create_customer

Destructive

Create individual or business customers in Stables to enable KYC verification and transfers; specify customer type and entitlements such as base_payout to activate transaction capabilities.

Instructions

Create a new customer in Stables for KYC verification and transfers. Use 'individual' for personal accounts or 'business' for company accounts. Include entitlements like 'base_payout' to enable transactions.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "customerType": "<customerType>"
    },
    "name": "create_customer"
  }
}

Input Schema

Name	Required	Description
`dob`	No	Date of birth in YYYY-MM-DD format (e.g., '1990-01-15')
`type`	No	Company type (e.g., 'Private Company Limited by Shares')
`email`	No	Customer's email address
`phone`	No	Phone number with country code (e.g., '+14155552671')
`taxId`	No	Tax ID (e.g., '12-3456789')
`country`	No	Country code ISO 3166-1 alpha-2 (required for businesses, e.g., 'US')
`website`	No	Website URL
`lastName`	No	Last name (required for individuals)
`firstName`	No	First name (required for individuals)
`middleName`	No	Middle name
`acceptTerms`	No	Accept Stables' terms of service and privacy policy
`addressCity`	No	City
`companyName`	No	Company name (required for businesses)
`nationality`	No	Two-letter country code (e.g., 'US', 'GB')
`addressLine1`	No	Street address line 1
`addressLine2`	No	Street address line 2
`addressState`	No	State or region
`customerType`	Yes	Type of customer - 'individual' for personal, 'business' for companies
`entitlements`	No	List of entitlements to request
`sourceOfFunds`	No	Source of funds
`accountPurpose`	No	What will you use Stables for?
`addressCountry`	No	Two-letter country code (e.g., 'US')
`incorporatedOn`	No	Date of incorporation in YYYY-MM-DD format
`describeBusiness`	No	Description of the business
`legalAddressCity`	No	Legal address city (for businesses)
`addressPostalCode`	No	Postal/ZIP code
`legalAddressLine1`	No	Legal address line 1 (for businesses)
`legalAddressLine2`	No	Legal address line 2 (for businesses)
`legalAddressState`	No	Legal address state (for businesses)
`externalCustomerId`	No	Your own reference ID for this customer
`registrationNumber`	No	Business registration number
`accountPurposeOther`	No	Explain purpose (required if accountPurpose is OTHER)
`legalAddressCountry`	No	Legal address country code (for businesses)
`conductMoneyServices`	No	Whether the company conducts money services
`registrationLocation`	No	Registration location (e.g., state for USA)
`describeMoneyServices`	No	Describe money services (required if conductMoneyServices is true)
`expectedAnnualRevenue`	No	Estimated annual revenue in USD
`legalAddressPostalCode`	No	Legal address postal code (for businesses)
`expectedMonthlyPayments`	No	Expected monthly payments in USD
`sourceOfFundsDescription`	No	Describe where your business funds come from
`describeComplianceControls`	No	Description of compliance controls
`operateInProhibitedCountry`	No	Does your business operate in any prohibited countries?
`doesYourBusinessEngageInHighRiskActivities`	No	Does your business engage in high risk activities?

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv2.6.11Oct 26, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / email / pattern

Added value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"

Changed5 schema fields changedv2.4.0Oct 23, 2026

changedInput schema / properties / entitlements / items / enum

Previous value: -[
-  "base_payout",
-  "virtual_account"
-]New value: +[
+  "base_payout",
+  "virtual_account",
+  "eur_virtual_account",
+  "gbp_virtual_account",
+  "usd_virtual_account",
+  "aed_local"
+]

removedInput schema / properties / howDidYouComeAcrossStables

Removed value: -{
-  "description": "How did you come across Stables?",
-  "type": "string"
-}

removedInput schema / properties / industrySelection

Removed value: -{
-  "description": "NAICS industry code (e.g., '5415')",
-  "type": "string"
-}

removedInput schema / properties / isYourBusinessADao

Removed value: -{
-  "description": "Is your business a DAO?",
-  "type": "boolean"
-}

removedInput schema / properties / mainSourceOfFunds

Removed value: -{
-  "description": "Main source of funds",
-  "enum": [
-    "BUSINESS_LOANS",
-    "GRANTS",
-    "INTER_COMPANY_FUNDS",
-    "INVESTMENT_PROCEEDS",
-    "LEGAL_SETTLEMENT",
-    "OWNERS_CAPITAL",
-    "PENSION_RETIREMENT",
-    "SALE_OF_ASSETS",
-    "SALES_OF_GOODS_AND_SERVICES",
-    "THIRD_PARTY_FUNDS",
-    "TREASURY_RESERVES"
-  ],
-  "type": "string"
-}

First observedv1.4.0Jul 13, 2026

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this is a non-idempotent, destructive write, so the safety profile is carried structurally. The description adds only that the record feeds KYC verification and that entitlements gate transactions; it never warns about duplicate-customer risk, irreversible creation, or that verification is kicked off as a side effect. With annotations covering the basics, this is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no filler, and the core action is front-loaded ahead of the two narrowing rules. It is efficiently written, though for a 43-parameter destructive operation the same length could have carried more decision-relevant content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent creation tool with 43 parameters and no output schema, the description omits the things an agent most needs: that only customerType is required yet most fields are conditionally required by type, that acceptTerms is effectively mandatory, and what identifier the response yields for use with get_customer or create_customer_onboarding_link.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every one of the 43 fields is already documented, which sets the baseline at 3. The description adds one genuine piece of meaning beyond the schema — that 'base_payout' is what enables transactions — but says nothing about which fields become conditionally required (firstName/lastName for individuals, country/companyName for businesses, describeMoneyServices when conductMoneyServices is true).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ('Create a new customer in Stables') and adds the downstream purpose (KYC verification and transfers), which distinguishes it from read/update siblings like get_customer and update_customer. It does not explicitly contrast with create_customer_onboarding_link, the nearest ambiguous sibling, but the create-a-customer-record intent is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a decision rule for the main discriminator ('individual' vs 'business') and hints at entitlements, which is more than nothing. However it says nothing about when to use this versus create_customer_onboarding_link, what prerequisites exist (acceptTerms, terms of service), or whether the customer must exist before requesting entitlements via request_entitlements.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server