Connect a local test-data engine through MCP

Source access and license

The source repository is currently private. The checkout instructions below are for authorized collaborators with repository access. The browser tools remain available without source access. The CLI package declares UNLICENSED; no public source-code license or npm publication is implied. See the maintainer profile for the project identity, or use the browser tools.

Prepare the source checkout first

Follow the CLI checkout instructions and confirm that node cli/bin/fundata.js --help works. The package is marked UNLICENSED; the checkout instructions do not assert open-source permission or an npm release. The maintainer is reachable through the azmiyuksel GitHub profile.

The server runs over standard input/output, not a hosted HTTP endpoint. Starting it in a terminal leaves it waiting for protocol messages; a waiting process alone does not prove a successful client connection.

Configure a client with an absolute script path

For a client that accepts the common mcpServers configuration shape, replace the example script path with the absolute path to your checkout:

{
  "mcpServers": {
    "fundata": {
      "command": "node",
      "args": ["/absolute/path/to/fundata/cli/bin/fundata.js", "mcp"]
    }
  }
}

On Windows, a JSON path can use forward slashes, such as C:/projects/fundata/cli/bin/fundata.js. If the client cannot find Node.js, replace node with the absolute path to its executable. Client settings formats and configuration locations vary; use the client's current documentation and confirm the four tools appear after reconnecting.

Discover tools before asking for data

• list_field_types: discover accepted field IDs and options.
• list_templates: inspect available schema templates.
• generate_test_data: generate at most 1,000 rows in one tool call.
• schema_to_code: produce TypeScript, Zod, Pydantic, JSON Schema or SQL DDL from the native field schema.

First ask your client to list the field types, then ask it to call generate_test_data with this argument object:

{
  "schema": [
    {"name": "id", "type": "row_number"},
    {"name": "email", "type": "email_address"}
  ],
  "rows": 3,
  "format": "json",
  "seed": "mcp-demo-v1"
}

Check that the response contains three records and the expected properties. A natural-language assistant reply is not proof that the MCP tool ran; inspect the tool invocation shown by your client. Use the CLI for larger files instead of returning thousands of rows to the assistant.

Local generation and assistant privacy are different boundaries

The server generates locally and returns data through stdio. Its output enters the MCP client's conversation; a cloud-backed assistant may then process those returned rows under that service's settings. Local generation does not mean that all subsequent assistant processing stays on your machine.

Use synthetic schemas and example values. Do not place secrets or production records in prompts, custom lists or tool arguments. Keep the source revision, seed and fixed date bounds when reproducibility matters. For a browser-only alternative, use the generator; for a complete testing example, follow the QA fixture workflow.

Last updated 16 October 2026