MCPg - Production-grade PostgreSQL MCP Server

Overview Schema Source Related Servers Discussions Admin

Generate test data

generate_test_data

Read-only

Generate synthetic INSERT statements for a table with typed, constraint-aware values; returns SQL for seeding dev/staging without executing writes.

Instructions

Generate synthetic INSERT statements for a table — typed values respecting column type, NOT NULL, and DEFAULT. Returns the SQL as strings; does NOT execute it. Useful for seeding dev / staging environments. The generator is deterministic when a seed is provided. Foreign keys are NOT resolved — the caller must pre-seed referenced rows or drop the FK before applying. Hard cap of 10000 rows per call. Pure read (the actual writes go through run_write under unrestricted mode).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "schema": "<schema>",
      "table": "<table>"
    },
    "name": "generate_test_data"
  }
}

Input Schema

Name	Required	Description
`rows`	No
`seed`	No
`table`	Yes
`schema`	Yes
`database`	No	Optional: a database id from list_databases, to target a configured secondary (read-only) database; omit for the primary. Database names that are not configured ids are rejected.

Output Schema

Name	Required	Description	Default
`table`	Yes
`schema`	Yes
`statements`	Yes
`rows_generated`	Yes
`skipped_columns`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.8.4Nov 5, 2026

changedInput schema / properties / database / description

Previous value: -"Optional: target a configured secondary (read-only) database by name; omit for the primary. Call list_databases to see the configured ids."New value: +"Optional: a database id from list_databases, to target a configured secondary (read-only) database; omit for the primary. Database names that are not configured ids are rejected."

First observedv0.6.8Jul 6, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the readOnlyHint/openWorldHint annotations: it declares the output is SQL strings that are never executed, that generation is deterministic given a seed, that foreign keys are not resolved and referenced rows must be pre-seeded or the FK dropped, and that there is a hard cap of 10000 rows per call. The 'pure read, writes go through run_write' sentence reinforces rather than contradicts the readOnlyHint.

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?

Five dense sentences, each carrying distinct information, with the core capability and the 'does NOT execute' constraint front-loaded before caveats about FKs and row limits. There is no filler or restatement of the title.

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

Completeness5/5

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

For a generation tool with an output schema already describing the returned SQL strings, the description covers everything an agent needs: what is produced, that it is not executed, determinism controls, FK preconditions, row limits, and the database targeting caveat. No material behavioral question is left open.

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 only 20% (only 'database' is documented in the schema), so the description must carry the load — and it does for the important ones: rows is constrained by the stated 10000-row cap and seed is explained as a determinism switch. Table and schema are only implied by 'for a table', leaving a gap on whether schema accepts a name or a database-qualified path, but overall compensation is strong.

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 verb and resource (generate synthetic INSERT statements for a table) plus the exact content rule (typed values respecting column type, NOT NULL, DEFAULT). It also disambiguates the closely related sibling generate_test_row_for by making clear this is a bulk, per-table operation producing SQL text rather than executing rows.

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 concrete when-to-use context (seeding dev / staging environments) and names the write path it is not (run_write under unrestricted mode). It stops short of an explicit when-not rule, such as preferring generate_test_row_for for a single row, but the surrounding guidance is clear enough to route the agent correctly.

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

Deploy Server