Setup and testing
Connect your agent to the Lumx docs MCP
A copy-paste prompt that wires the Lumx documentation MCP server into your coding agent so it reads real schemas instead of inventing field names.
// PROMPT
{ "type": "INDIVIDUAL", "name": "William Default", "taxId": "100.100.100-01", "birthDate": "1990-01-01" }
You are configuring your own tooling. Connect yourself to the Lumx documentation MCP server, verify it works, and then use it instead of your memory for every Lumx schema question.
The server gives you documentation, not API access. It cannot create a customer, quote a rate or move money — that needs the REST API and a server-side key, which this does not give you. Do not assume it is strictly read-only either: check the tool list for anything that writes, and do not call such a tool on my behalf without asking.
Ground truth for the setup itself:
1. https://docs.lumx.io/developer/mcp-server — the server URL and the install line for each host. Also read https://docs.lumx.io/llms.txt for the documentation index.
2. https://lumx-docs-public-prod.s3.us-east-1.amazonaws.com/api-production.yaml — the OpenAPI 3.1 spec, which is also reachable through the server once connected.
1. Install the server for this host. The transport is HTTP and there is no authentication and no API key. On Claude Code the whole setup is: claude mcp add --transport http lumx-docs https://docs.lumx.io/mcp — for Cursor, VS Code, Codex or Claude Web, take the exact config block for your host from the docs page and do not improvise a stdio wrapper.
2. Verify the connection by listing the tools. Report the names you actually get back rather than the names you expected — the docs page describes two and the server may expose more.
3. Learn what each tool is for: semantic search across the docs for "where do I find X", and shell-style access over the raw doc and OpenAPI files, with rg, head, cat and tree, for "what exactly are the required fields of X".
4. Find the spec through the server rather than downloading it: list the tree and locate the OpenAPI files, then read the production one from there — a staging spec sits beside it, so name the file you read and never mix the two in one answer. Confirm you can grep an enum out of it.
5. Prove it changes an answer. Pick any Lumx request body, write down the field names from memory first, then read them from the spec through the server, and diff the two lists out loud.
6. Adopt the rule for the rest of this session: any Lumx field name, enum value or endpoint path you are about to write, you read first. If the server is unreachable, say so and fall back to the two URLs above rather than to memory.
Constraints:
- Do not describe this server as API access. It reads published documentation.
- Do not configure discovery through any .well-known path; use the published server URL directly.
- Do not send any credential to this server. It does not take one, and anything you send it leaves your machine.
Deliverables:
- The working config for this host, in the right file.
- The tool list you actually received.
- The memory-versus-spec diff from step 5, which is the evidence this was worth doing.
Run the install line yourself if your host needs a restart to pick up a new server — most do.
Do step 5 with a schema you think you know. The diff is the whole point, and it is usually not empty.
If your host has no MCP support, skip this and keep the two URLs in your project instructions instead.
Discover how our infrastructure can seamlessly integrate stablecoins into your financial operations quickly, securely, and efficiently.

