Stables MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

create_customer

Create individual or business customers in Stables for KYC verification and transactions. Set entitlements such as base_payout to enable payouts and transfers.

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.

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.

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.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It implies a write operation ('Create'), but discloses nothing about idempotency, required permissions, the subsequent KYC state, or what happens to fields not supplied. For a 43-parameter mutation tool this is a substantial gap.

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 short sentences, front-loaded with the core action and with the type guidance close behind. No filler, though the entitlements sentence is slightly loose ('like').

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?

Given 43 parameters, a single required field, several conditional field groups (business legal address, money-services descriptions), no annotations and no output schema, the description is too thin. It omits any guidance on the field dependencies an agent must satisfy to get a valid creation through.

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 coverage is 100%, so the schema already documents every parameter including enums and conditional requirements. The description's mention of customerType values and entitlements largely restates what the schema provides, meriting the baseline 3.

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?

States a specific verb and resource ('Create a new customer') plus the downstream purpose (KYC verification and transfers). It does not, however, distinguish this from closely-named siblings such as create_customer_onboarding_link or update_customer, so the agent must infer which creation path applies.

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 conditional guidance on customerType ('individual' for personal, 'business' for company) and hints that entitlements like 'base_payout' enable transactions, but offers no when-to-use versus alternatives like create_customer_onboarding_link, and no prerequisites such as accepting terms.

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

Deploy Server

create_customer

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools