This server provides an agent-friendly interface to Generate-Data.com, allowing you to:
Generate synthetic datasets: Create fake data rows from a field list, specifying output format (CSV, JSON, XML, Parquet, ZIP) and row count. Binary formats are base64-encoded. Limits depend on your tier (e.g., Free: 100 rows/10 cols; Premium: 100k rows/50 cols).
Design schemas with natural language: Propose a new dataset schema from a text description, or refine an existing one through a conversation (providing prior messages and the current schema).
List and configure field types: Browse all available data types grouped by category, and get detailed configuration options for any specific field type.
Manage projects (Premium tier): List your saved projects and generate all tables in a project, downloading the result in your chosen format.
Check API usage: View your current tier, daily call counts, and remaining limits.
All tools return a consistent success/error envelope for easy handling.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@generate-data-mcp Propose a schema for an e-commerce product catalog."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for Generate-Data.com — generate synthetic datasets, design schemas from natural language, and manage Projects, straight from your agent.
Thin HTTP wrapper over the Generate-Data.com API. No generation logic lives in this repo — it's a curated, agent-friendly interface onto the real thing: 7 tools, one consistent response shape, binary-safe output, and server-side validation on every input.
You need a Generate-Data.com API key first — create one in Settings → API Access on generate-data.com.
Add this to your MCP client config (Claude Desktop: claude_desktop_config.json; Cursor: .cursor/mcp.json):
{
"mcpServers": {
"generate-data": {
"command": "uvx",
"args": ["generate-data-mcp"],
"env": {
"GENERATE_DATA_API_KEY": "your-uuid-key-here"
}
}
}
}uvx fetches and runs the latest published version on demand — no separate install step, nothing to update by hand. Restart your client and the 7 gd_* tools are available.
Do not commit a config file containing your real API key.
# run once, ad hoc:
uvx generate-data-mcp
# or install it as a persistent CLI tool:
uv tool install generate-data-mcppip install generate-data-mcpFor local development against this repo directly:
git clone https://github.com/ns-3e/generate-data-mcp.git
cd generate-data-mcp
pip install -e ".[dev]"export GENERATE_DATA_API_KEY=your-key
generate-data-mcpFrom your MCP client, invoke gd_get_usage — it should return your tier and call counts. Then invoke gd_list_field_types — it should return the category map.
Ask your agent something like "generate 50 rows of fake e-commerce customers as CSV" and it will call gd_design_schema then gd_generate_dataset on its own.
Related MCP server: JustOneAPI MCP Server
A typical session looks like this — the agent chains tools on its own, you just describe the outcome:
Discover what's possible. gd_list_field_types — see every field type, grouped by category.
Design a schema. gd_design_schema(prompt="E-commerce customers with name, email, and signup date") — proposes a fields array from plain English.
Generate the data. gd_generate_dataset(fields=..., num_rows=10, format="csv") — returns the rows.
Refine if needed. Call gd_design_schema again, this time passing messages (the running conversation) + current_schema (the prior result) together — it refines instead of proposing fresh.
Every tool returns the same envelope: {"ok": true, "summary": "...", "data": {...}} on success, or {"ok": false, "error": {"code": ..., "message": ...}} on failure — errors always tell you what to do next, never a raw stack trace.
{
"env": { "GENERATE_DATA_API_BASE_URL": "http://localhost:8000" }
}Point at a locally running Django backend instead of the hosted API.
v2.0.0 renames every tool (breaking change). Old name → new name:
generate_data → gd_generate_dataset
list_field_types → gd_list_field_types
get_field_options → gd_get_field_type_options
propose_schema → gd_design_schema (first call, no messages/current_schema)
refine_schema → gd_design_schema (pass messages + current_schema together)
get_api_usage → gd_get_usage
list_projects → gd_list_projects (now paginated: limit/offset)
generate_project → gd_generate_project (binary formats now returned base64-encoded, not corrupted utf-8)
All 7 tools, split by tier.
gd_generate_dataset — Generate synthetic dataset rows from a field list. format: csv, json, xml, parquet, or zip (binary formats return base64-encoded).
gd_list_field_types — List all available field types grouped by category. Takes no arguments.
gd_get_field_type_options — Get the configuration option schema for one field type. field_type must match ^[a-z0-9_]+$.
gd_design_schema — Design a dataset schema from natural language, or refine an existing one — one tool for both the first proposal and follow-up conversation turns.
gd_get_usage — Get current API key usage stats: calls today, tier, limits. Takes no arguments.
Requires a Premium API key — Free-tier keys get a tier_forbidden error.
gd_list_projects — List the user's Projects, paginated (limit/offset, default 20/0).
gd_generate_project — Generate all tables in a Project and download the result. Same format/binary rules as gd_generate_dataset.
Capability | Free | Premium |
Max rows / request | 100 | 100,000 |
Max columns | 10 | 50 |
Formats | CSV | CSV, JSON, XML, Parquet |
Daily API calls | 10 | 1,000 |
Limits are enforced by the Django API, not this MCP server.
Variable | Required | Default |
| Yes | — |
| No |
|
Symptom | Fix |
| Set env var before starting the server |
HTTP 401 / | Invalid or deactivated key |
HTTP 429 / | Per-minute or daily cap hit; wait or upgrade tier |
HTTP 403 / | Free tier lacks access; upgrade plan |
|
|
| Value failed server-side validation before any request was sent — check spelling/type |
git clone https://github.com/ns-3e/generate-data-mcp.git
cd generate-data-mcp
pip install -e ".[dev]"
pytest tests/ -vDocs live on generate-data.com. See this repo's tool docstrings (generate_data_mcp/server.py) for the authoritative request/response shapes.
Generate synthetic data rows. Returns CSV/text content or error message.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | ||
| format | No | csv | |
| num_rows | No | ||
| settings | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions return type (CSV/text or error) but lacks details on side effects, safety, or operational constraints like memory or API limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose. Could be more structured with separate sections for return value and parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no schema descriptions, no annotations, but an output schema exists (not shown). Description fails to explain parameter usage or provide sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions). Description only hints at format via 'CSV/text' but does not explain fields, num_rows, or settings, leaving agents uninformed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('generate') and resource ('synthetic data rows'). Distinguishable from siblings like generate_project and data retrieval tools. However, could be more specific about the type of synthetic data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate all tables in a Project. Returns ZIP bytes as text or JSON error.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | zip | |
| project_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return format (ZIP bytes as text or JSON error) but does not mention if the operation is destructive, requires permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence for purpose and one for output. However, it could include more detail without excessive length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that generates tables, the description lacks information on what 'generate' entails (creates new? overwrites?), limits, and output schema specifics. The presence of an output schema is noted but not leveraged.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description adds no detail about parameters. The 'format' parameter defaults to 'zip' but possible values are unexplained; 'project_id' is not contextualized beyond being required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Generate all tables in a Project' which is a specific verb and resource, distinguishing it from sibling 'generate_data' which likely operates on individual tables. However, it does not explicitly contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'generate_data' or 'list_projects'. The description only states what it does, not the context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current API key usage stats.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only states 'current' implying real-time, but omits details like read-only nature, error conditions, or data freshness. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no extraneous words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema exists and explains return values, the description lacks behavioral details such as whether the key must be active or how historical usage is handled. Adequate for a simple tool but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is 100%. The description adds nothing parameter-specific, but baseline for 0 params is 4. No additional meaning needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'API key usage stats', making the purpose obvious. However, it does not differentiate from sibling tools like 'generate_data' or 'list_projects', which are distinct but not contrasted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For a simple read operation, this may not be critical, but the absence of context about usage scenarios lowers the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get configuration schema for a field type.
| Name | Required | Description | Default |
|---|---|---|---|
| field_type | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It does not disclose any behavioral traits such as read-only nature, authentication needs, or side effects. The description is too minimal to be informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is appropriately short, though it could benefit from slight expansion without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one simple parameter and an output schema exists, so the description does not need to explain return values. However, it provides no additional context about field types, usage patterns, or integration with sibling tools, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, and the tool description adds no parameter-specific information. The 'field_type' parameter is unexplained, leaving the agent without knowledge of valid values or where to obtain them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get configuration schema for a field type', specifying a concrete verb and resource. It distinguishes from siblings like 'list_field_types' which lists types rather than their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'list_field_types' or 'propose_schema'. The agent is left to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available field types grouped by category.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description solely conveys the behavior: listing field types grouped by category. It is accurate but does not disclose possible side effects, auth needs, or rate limits. The description is sufficient for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the action verb 'List'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and an output schema exists, so the description's mention of grouping by category suffices. However, it could note that it is read-only or provide example categories for better completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
As there are no parameters and schema coverage is 100%, the description adds value by explaining the output grouping, but it doesn't add parameter-specific detail. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clearly identifies the resource as 'field types' with the additional detail of grouping by category. It distinguishes the tool from siblings like get_field_options which likely gets options for a specific field, not a general list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (need to see available field types), but provides no explicit when-not-to-use or alternatives. It is adequate but lacks depth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List user's Projects (Premium).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks behavioral details like read-only nature, pagination, limits, or authentication needs. The description carries full burden but is too minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no wasted words. Efficiently conveys purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and existence of output schema, the description sufficiently states what the tool does. However, it lacks mention of any implicit behavioral aspects like project scope or limitations, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Description adds minimal context ('Premium') beyond the schema. Baseline 4 is appropriate as there is nothing to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List user's Projects (Premium)' with specific verb and resource, and adds context about the feature tier. It is unambiguous and distinct from sibling tools which focus on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Does not mention prerequisites, such as authentication or project access, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Propose a schema from natural language.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | en_US | |
| prompt | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states the action but omits any side effects, permissions, idempotency, rate limits, or return behavior beyond what output schema might cover. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core action. It is concise with no wasted words, though it may be too brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a sibling 'refine_schema' and two parameters (one required), the description lacks necessary context such as how the tool differs from alternatives, the expected input style, and any limitations. The presence of an output schema partially compensates for return value explanation, but overall completeness is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema properties lack any descriptions. The tool description does not explain the purpose or format of the 'prompt' and 'locale' parameters, failing to compensate for the missing schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (propose) and resource (schema) and the source (natural language). However, it does not distinguish the tool from its sibling 'refine_schema', which could cause confusion. Thus, purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The single sentence offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refine an existing schema via conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| messages | Yes | ||
| current_schema | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It mentions 'conversation' but does not explain iterative behavior, side effects, authentication requirements, or any constraints. The single sentence is insufficient for a tool with two complex parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (5 words) but at the cost of essential detail. Given the tool's complexity (two required nested objects), the description should be longer and front-load critical information. The brevity is more under-specification than efficient conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema but the description ignores it. With 0% schema parameter coverage, no usage guidelines, and minimal behavioral context, the description is grossly incomplete for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for the 'messages' or 'current_schema' parameters. The agent receives no guidance on format, purpose, or constraints beyond the schema's structural definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Refine an existing schema via conversation,' which identifies a specific verb and resource. However, it does not differentiate from the sibling tool 'propose_schema' and lacks detail on what 'refine' entails (e.g., field additions, type changes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like 'propose_schema' or 'generate_data.' The phrase 'via conversation' implies interactivity but provides no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0generate_datagenerate_projectget_api_usageget_field_optionslist_field_typeslist_projectspropose_schemarefine_schemaEach tool serves a distinct function: generating data, generating full projects, checking API usage, retrieving field options, listing fields, listing projects, proposing schemas, and refining schemas. No overlapping purposes.
All tool names follow a consistent verb_noun pattern with lowercase and underscores (e.g., generate_data, list_field_types). No mixing of styles.
With 8 tools, the set is well-scoped for the domain of synthetic data generation and schema management. It covers both creation and configuration without being overwhelming.
The tool set covers core workflows: generating data and projects, schema proposal/refinement, and listing field types and projects. Minor gaps exist (e.g., no delete or update for projects), but agents can still accomplish main tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Decodo MCP — wraps the Decodo Web Scraping API (decodo.com, formerly
Data.gov MCP — wraps Data.gov CKAN API (catalog.data.gov/api/3)
API Ninjas MCP — wraps the multi-endpoint API Ninjas data API (api-ninjas.com)
JSONPlaceholder MCP — wraps JSONPlaceholder fake REST API (free, no auth)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ns-3e/generate-data-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server