Skip to main content
Glama
stables-money

Stables MCP Server

Official

create_customer_onboarding_link

Create a customer and get a hosted link for them to submit their own KYC/KYB details, reusing an existing customer with the same email.

Instructions

Create a customer and get a hosted verification link for them in one call, so the customer enters their own KYC/KYB details. An existing customer with the same email is reused (customer_created is false) and the fields sent are ignored. Takes the same fields as create_customer; send what you already know.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dobNoDate of birth in YYYY-MM-DD format (e.g., '1990-01-15')
typeNoCompany type (e.g., 'Private Company Limited by Shares')
emailNoCustomer's email address
phoneNoPhone number with country code (e.g., '+14155552671')
taxIdNoTax ID (e.g., '12-3456789')
countryNoCountry code ISO 3166-1 alpha-2 (required for businesses, e.g., 'US')
websiteNoWebsite URL
lastNameNoLast name (required for individuals)
firstNameNoFirst name (required for individuals)
rejectUrlNoWhere to send the customer if verification is rejected
ttlInSecsNoLink lifetime in seconds (default 1800)
middleNameNoMiddle name
successUrlNoWhere to send the customer after verification succeeds
acceptTermsNoAccept Stables' terms of service and privacy policy
addressCityNoCity
companyNameNoCompany name (required for businesses)
nationalityNoTwo-letter country code (e.g., 'US', 'GB')
addressLine1NoStreet address line 1
addressLine2NoStreet address line 2
addressStateNoState or region
customerTypeYesType of customer - 'individual' for personal, 'business' for companies
entitlementsNoList of entitlements to request
sourceOfFundsNoSource of funds
accountPurposeNoWhat will you use Stables for?
addressCountryNoTwo-letter country code (e.g., 'US')
incorporatedOnNoDate of incorporation in YYYY-MM-DD format
describeBusinessNoDescription of the business
legalAddressCityNoLegal address city (for businesses)
verificationTypeNoRun one verification step instead of the full flow
addressPostalCodeNoPostal/ZIP code
legalAddressLine1NoLegal address line 1 (for businesses)
legalAddressLine2NoLegal address line 2 (for businesses)
legalAddressStateNoLegal address state (for businesses)
externalCustomerIdNoYour own reference ID for this customer
registrationNumberNoBusiness registration number
accountPurposeOtherNoExplain purpose (required if accountPurpose is OTHER)
legalAddressCountryNoLegal address country code (for businesses)
conductMoneyServicesNoWhether the company conducts money services
registrationLocationNoRegistration location (e.g., state for USA)
describeMoneyServicesNoDescribe money services (required if conductMoneyServices is true)
expectedAnnualRevenueNoEstimated annual revenue in USD
legalAddressPostalCodeNoLegal address postal code (for businesses)
expectedMonthlyPaymentsNoExpected monthly payments in USD
sourceOfFundsDescriptionNoDescribe where your business funds come from
describeComplianceControlsNoDescription of compliance controls
operateInProhibitedCountryNoDoes your business operate in any prohibited countries?
doesYourBusinessEngageInHighRiskActivitiesNoDoes your business engage in high risk activities?

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.4.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose genuinely non-obvious behavior: an existing customer with the same email is reused, customer_created is false, and the submitted fields are ignored. It still omits permission/auth requirements and what happens to the link on expiry beyond the schema's ttlInSecs default.

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

Conciseness5/5

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

Three short sentences, front-loaded with the outcome, then the reuse caveat, then the field guidance. Every sentence carries distinct information with no filler.

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

Completeness4/5

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

For a 47-parameter, no-output-schema tool with no annotations, the description covers the key decision points (link generation, customer reuse, field delegation) and names the returned customer_created flag. It is somewhat thin on the returned link payload and expiry semantics, but the schema documents ttlInSecs.

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

Parameters4/5

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

Schema description coverage is 100%, so baseline is 3, and the description adds real meaning on top: it delegates the field set to create_customer and advises sending only what is already known, which tells the agent most fields are optional despite the 47-property schema. It does not clarify the interaction between the two APIs' field sets beyond that.

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

Purpose5/5

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

States a specific compound action ('create a customer and get a hosted verification link ... in one call') with the resource and the rationale (customer self-enters KYC/KYB). This clearly distinguishes it from the sibling create_customer, which does not return a link.

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

Usage Guidelines4/5

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

Gives clear usage context ('so the customer enters their own KYC/KYB details') and an explicit relationship to the sibling ('Takes the same fields as create_customer; send what you already know'). It stops short of stating when to prefer plain create_customer or get_verification_link instead, so it is not a full when/when-not rule.

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