rowsmith-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ROWSMITH_URL | No | Optional. Override the base URL for calls (default is https://testdata-api.re-jam620.workers.dev). | |
| ROWSMITH_OUT_DIR | No | Optional. Without it, files can only be written inside the directory the server runs in; set it to choose a specific folder, such as your project's fixtures directory. It moves or narrows the write root. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| generate_test_dataA | Generate realistic fake test data (CSV, JSON or SQL INSERTs) from a table schema. Use it first, when you need rows for fixtures, seed data or tests (list_column_types gives each type's options). Or pass schema (JSON Schema, e.g. a Pydantic or Zod export, or an OpenAPI component) instead of columns; unmappable fields are named. Next: invalid_values for values your code should reject, then sandbox_create and sandbox_payments to test a payment flow. Free and rate-limited: up to 500 rows and 50 columns per call. No real person's data is used as input and no record is derived from a real person; emails, phones, card numbers, SSN-shaped and IBAN-shaped values come only from reserved or invalid ranges. The same schema and seed give byte-identical output for the same generator version (sent as x-generator-version). For more than about 50 rows, pass output_path to write a file instead of returning the data. The result gives the output's sha256 and ends with a curl that regenerates the same bytes. Send schemas only, never real data. |
| list_column_typesA | List the supported column types and the options each accepts. Use it before generate_test_data when you need a type's options. |
| invalid_valuesA | Deliberately invalid TEST DATA values (malformed emails, declining or Luhn-invalid card numbers, malformed addresses, Unicode edge cases, invalid IBAN and SSN shapes), each with the reason it is invalid. Same seed, same output for the same catalogue version. Use it after generate_test_data, to test that your validation rejects bad input. Next: sandbox_create, then sandbox_payments, to test a payment flow. |
| sandbox_createA | Create a fake card-processor sandbox (TEST DATA, no money, no payment provider). Returns its sbx_ id. Deleted 1 hour after creation. Use it to start a payment test; next, call sandbox_payments with the returned id. |
| sandbox_paymentsA | Charge, refund, list, get or reset in a payment sandbox. Accepts only card numbers from Stripe's published testing list; any other card-like number is refused. Declines return code and decline_code. Same seed and call order, same objects for the same sandbox version. Use it after sandbox_create, with that sandbox's id. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool occupies a distinct stage of the workflow: introspection (list_column_types), valid data generation (generate_test_data), invalid-case generation (invalid_values), sandbox provisioning (sandbox_create), and payment operations (sandbox_payments). The only mild overlap is between generate_test_data and invalid_values, since both emit fabricated records, but the names and descriptions make the valid/invalid split clear. sandbox_payments bundles five actions (charge, refund, list, get, reset) into one tool, which is a slight boundary blur but not a cross-tool ambiguity.
All names use snake_case, but the ordering convention is mixed: most tools lead with a verb (list_column_types, generate_test_data), while the sandbox pair leads with a noun (sandbox_create, sandbox_payments) and invalid_values has no verb at all. It remains readable, but the pattern is not predictable enough to guess a tool name from its action.
Five tools is a tight, well-scoped surface for a test-data and payment-sandbox server, and each tool corresponds to a genuine step in the described workflow. Nothing feels padded or redundant.
The chain from schema inspection through data generation, invalid-value testing, sandbox creation, and payment simulation is essentially covered, including the documented 'next' hints. Minor gaps exist around sandbox lifecycle management (no explicit delete or list-sandboxes tool; cleanup is only implicit via the 1-hour expiry) and there is no standalone way to validate an arbitrary schema.