jsonfabrica-mcp-server

Overview Schema Source Related Servers Discussions Admin

Generate a document from a raw template body (no persistence)

jsonfabrica_generate_adhoc

Generates a document directly from a raw template body string for ad-hoc synthetic data creation. Use when you need a quick one-off JSON sample without saving a reusable template.

Instructions

Calls POST /v1/templates/generate. Generates a document directly from a raw body string without creating a template record — prefer this over jsonfabrica_generate_from_template while still iterating on template syntax; switch to jsonfabrica_create_template once the body is ready to be reused or shared. Goes through the same billing/usage metering as persisted-template generation (not a free bypass). createSeq()/durable sequence side effects still apply; set sequenceNamespace/variableNamespace to e.g. "debug" to avoid colliding with real tenant sequences and variables.

Input Schema

TableJSON Schema

Name	Required	Description
`body`	Yes	Raw template body containing at least one function-call placeholder, e.g. "Hello {{getRandomFullName()}}" — evaluated directly without persisting a template record. Required.
`seed`	No	Deterministic PRNG seed for this generation — the same seed reproduces byte-identical random values. Optional; if omitted the server picks a random seed and returns it in the response.
`params`	No	Key/value map supplying values for getParam("key") placeholders in `body`. Optional; omitted keys leave the corresponding getParam() calls unresolved/empty.
`context`	No	Arbitrary auxiliary key/value data made available to `body` alongside `params`. Optional; omitted keys are simply absent during generation.
`sequenceNamespace`	No	Isolates createSeq()/getSeq() durable-sequence side effects under this namespace, e.g. "debug", so ad-hoc runs don't advance real tenant sequences. Optional; omitted means the default (unnamespaced) sequence scope is used.
`variableNamespace`	No	Isolates durable-variable side effects under this namespace, analogous to `sequenceNamespace`. Optional; omitted means the default (unnamespaced) variable scope is used.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes	The generated document; shape is entirely determined by the template body.
`meta`	Yes	Generation metadata.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedSep 9, 2026

addedInput schema / properties / body / description

Added value: +"Raw template body containing at least one function-call placeholder, e.g. \"Hello {{getRandomFullName()}}\" — evaluated directly without persisting a template record. Required."

addedInput schema / properties / context / description

Added value: +"Arbitrary auxiliary key/value data made available to `body` alongside `params`. Optional; omitted keys are simply absent during generation."

addedInput schema / properties / params / description

Added value: +"Key/value map supplying values for getParam(\"key\") placeholders in `body`. Optional; omitted keys leave the corresponding getParam() calls unresolved/empty."

addedInput schema / properties / seed / description

Added value: +"Deterministic PRNG seed for this generation — the same seed reproduces byte-identical random values. Optional; if omitted the server picks a random seed and returns it in the response."

addedInput schema / properties / sequenceNamespace / description

Added value: +"Isolates createSeq()/getSeq() durable-sequence side effects under this namespace, e.g. \"debug\", so ad-hoc runs don't advance real tenant sequences. Optional; omitted means the default (unnamespaced) sequence scope is used."

addedInput schema / properties / variableNamespace / description

Added value: +"Isolates durable-variable side effects under this namespace, analogous to `sequenceNamespace`. Optional; omitted means the default (unnamespaced) variable scope is used."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "data": {
+      "description": "The generated document; shape is entirely determined by the template body."
+    },
+    "meta": {
+      "additionalProperties": false,
+      "description": "Generation metadata.",
+      "properties": {
+        "documentSeed": {
+          "description": "Per-document seed, present for some generation paths.",
+          "type": "number"
+        },
+        "generatedAt": {
+          "description": "ISO-8601 timestamp of generation.",
+          "type": "string"
+        },
+        "seed": {
+          "description": "PRNG seed actually used for this generation.",
+          "type": "number"
+        },
+        "templateId": {
+          "description": "Present when generated from a persisted template.",
+          "type": "string"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "data",
+    "meta"
+  ],
+  "type": "object"
+}

First observedv0.1.4Sep 5, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description reveals billing/usage metering, durable sequence side effects, and the recommended use of namespaces to avoid collisions. This adds valuable context that annotations do not convey, with no contradictions.

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?

The description is three sentences: core purpose, usage guidance, and side-effect warning. Information is front-loaded and every sentence earns its place; no redundancy.

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?

With an output schema present, return values are covered. The description covers purpose, usage alternatives, side effects, billing, and namespace guidance. Nothing needed to invoke correctly is missing.

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 coverage is 100%, so the schema already documents all parameters. The description adds extra guidance on sequenceNamespace/variableNamespace (e.g., using 'debug' to avoid collisions) and clarifies the billing behavior tied to parameters. This goes beyond the schema, so a 4 is appropriate.

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?

The description clearly states the tool's purpose: it generates a document from a raw body string without persisting a template record. It explicitly contrasts itself with jsonfabrica_generate_from_template and jsonfabrica_create_template, making sibling differentiation unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance: prefer this during template syntax iteration, switch to jsonfabrica_create_template for reuse/sharing. It also mentions billing and side-effect namespaces, leaving no ambiguity about when to select this tool over siblings.

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

Deploy Server