MCP server that wraps the JsonFabrica REST API to generate synthetic JSON test data, manage templates, sequences, batches, usage, and admin billing.
Health & identity: jsonfabrica_health checks gateway reachability; jsonfabrica_whoami returns the configured tenant ID and role.
Template management: create saved templates (with optional immediate generation), list/filter templates by name and active/archived status with pagination, fetch a template by ID, partially update a template (no undo), and archive/delete templates (no restore; archived templates remain usable by get/generate).
Document generation: jsonfabrica_generate_from_template generates from a saved template ID; jsonfabrica_generate_adhoc generates from a raw body without persisting. Both support deterministic seed, params, context, and sequenceNamespace, returning data and meta.
Batch generation: generate multiple documents across saved templates in one batch with per-document alias/count, a common seed, and optional sequence namespace; returns batchId and status.
Sequence management: list/get sequences, bump/update a sequence with a step or set value, and delete a sequence; sequence namespaces isolate test/debug runs from real tenant state.
Usage monitoring: jsonfabrica_get_usage returns { tenantId, usageTotal, asOf }.
Admin billing controls: admin role required; list generator functions and reweight a generator function with a new billing weight (otherwise gateway returns 403).
A local Model Context Protocol (MCP) server that lets an AI coding agent — Claude Desktop, Cursor, or anything else that speaks MCP — generate realistic, schema-conformant JSON test data mid-session by calling JsonFabrica's REST API as MCP tools.
It runs over stdio transport only: your AI client launches it as a subprocess, so there's no network service to host and no port to open. It never talks to anything except the JsonFabrica gateway you configure.
New to JsonFabrica? It's an API-first service for generating synthetic JSON test data from reusable templates — deterministic, seed-reproducible, with referential integrity across related records. See jsonfabrica.com and the API docs.
Add it to your MCP client's config so the client launches it via npx:
{
"mcpServers": {
"jsonfabrica": {
"command": "npx",
"args": ["-y", "@jsonfabrica/mcp-server"],
"env": {
"JSONFABRICA_API_KEY": "sk_live_...",
"JSONFABRICA_API_URL": "https://api.jsonfabrica.com"
}
}
}
}Claude Desktop — add the block above to claude_desktop_config.json
(Settings → Developer → Edit Config), then restart.
Cursor — Settings → MCP → Add new MCP server, or add the block to
~/.cursor/mcp.json.
Get an API key by signing up at jsonfabrica.com — Settings → API Keys.
Or run it directly for local testing:
npm install
npm run build
JSONFABRICA_API_KEY=sk_live_... node dist/index.jsRelated MCP server: model-gateway
Once connected, an agent can do things like:
You: Generate 20 realistic customer records and 60 orders linked to them, and drop them into
fixtures/seed.json.Agent: calls
jsonfabrica_create_templatefor the customer and order shapes, thenjsonfabrica_create_batchwith arelationsmap so each order references a generated customer id, then writes the result to the file.
No tab-switching to a dashboard, no hand-written fixtures.
Env var | Required | Default | Notes |
| Yes | — | If missing, the server still starts and answers tool discovery, but every tool call fails with "check JSONFABRICA_API_KEY". Never logged or echoed back in tool output. |
| No |
| Base URL of the JsonFabrica gateway. Override this if you're self-hosting the gateway (e.g. |
Every tool's description states, verbatim, which REST endpoint it calls. Tool
names are prefixed jsonfabrica_ to avoid collisions with other MCP servers
your client may have loaded.
Tool | Endpoint | Notes |
|
| No auth. Connectivity check. |
|
| Returns |
Tool | Endpoint |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Template body strings use JsonFabrica's function-call placeholder syntax with
angle brackets, e.g. <getRandomFullName()>, <getRandomEmail()>,
<createSeq('orderNo')>. The full catalogue of built-in functions is documented
at jsonfabrica.com/docs/functions —
it's authoring reference, not something this server exposes as tools.
Tool | Endpoint |
|
|
|
|
|
|
|
|
|
|
|
|
Tool | Endpoint |
|
|
|
|
Tool | Endpoint |
|
|
POST /v1/signup and PATCH /v1/billing/tier — unauthenticated
account-creation / billing-tier-change endpoints. Wrapping these would let a
model create real paid subscriptions or change billing tiers on the user's
behalf; excluded by design (generation API surface only).
POST /v1/webhooks/stripe — Stripe-only webhook ingestion, not a
developer-facing capability.
Every tool catches errors internally and returns an MCP isError: true result
with a readable message — it never throws out of the handler or crashes the host
process. Common cases:
401 → "Invalid or missing API key — check JSONFABRICA_API_KEY."
403 → the API key's tenant is not allowed to perform the call.
402 (blocked account) → the upstream blockReason is passed through.
Network failure (gateway unreachable) → a message naming the configured
JSONFABRICA_API_URL.
Anything else → JsonFabrica API error [CODE] (HTTP status): message.
401 / "Invalid or missing API key" → check JSONFABRICA_API_KEY is set
and valid.
Connection refused / UPSTREAM_UNREACHABLE → check JSONFABRICA_API_URL and
that the gateway is actually running and reachable from wherever this process
runs.
403 / FORBIDDEN → your API key's tenant is not permitted to perform that call.
npm install
npm run build # tsc -p tsconfig.json
npm test # build + node --test dist/
npm start # node dist/index.js (requires JSONFABRICA_API_KEY)Source layout mirrors the OpenAPI spec's tags: one file per tag under
src/tools/. src/client.ts is the only place that knows about fetch, the
base URL, and the Authorization header.
MIT — see LICENSE.
Calls POST /v1/sequences/{name}/bump. Atomically advances the sequence by its configured step (a permanent, irreversible change to the stored currentValue) and returns the updated record — this is the same advance a template's createSeq()/getSeq() calls trigger during generation. Use jsonfabrica_update_sequence instead if you need to set an explicit currentValue/step rather than advancing by the existing step.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact name of the sequence to bump (advance by its configured step). Required. |
| Name | Required | Description |
|---|---|---|
| name | Yes | Sequence name. |
| step | No | Increment applied per bump (ignored for "uuid"). |
| type | Yes | Value kind produced on each bump. |
| start | No | Initial value the sequence was created with. |
| tenantId | Yes | Owning tenant id. |
| createdAt | Yes | ISO-8601 creation timestamp. |
| updatedAt | Yes | ISO-8601 last-update timestamp. |
| currentValue | Yes | Current stored counter value (unused by "uuid" sequences). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, idempotentHint=false), the description discloses atomicity ('Atomically advances'), irreversibility ('permanent, irreversible change'), and the return behavior ('returns the updated record'). It also connects to template generation behavior, adding valuable operational context not present in annotations.
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 two sentences, front-loaded with the core action and endpoint, then the alternative. No wasted words; every clause adds value. The structure is exemplary for a tool definition.
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 simple one-parameter tool with an output schema, the description fully covers purpose, when to use, behavior, and alternative. It omits return format (handled by output schema) and prerequisites (implied by sequence existence). Nothing an agent needs to call it correctly is missing.
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 already provides 100% coverage, describing 'name' as the exact sequence name and marking it required. The description adds only that the name is used in the URL path, which is a minor clarification. With full schema coverage, 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 clearly states the tool advances a sequence by its configured step, specifies the HTTP endpoint (POST /v1/sequences/{name}/bump), and explicitly differentiates it from the sibling jsonfabrica_update_sequence which sets explicit values. This is specific verb+resource and distinguishes from alternatives.
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 explicitly tells when to use this tool vs the alternative: 'Use jsonfabrica_update_sequence instead if you need to set an explicit currentValue/step rather than advancing by the existing step.' It also adds context that this matches what createSeq()/getSeq() trigger, giving a clear decision heuristic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calls POST /v1/batches. Generates multiple documents from one or more persisted templates in one call, optionally cross-referencing documents via relations — use this instead of looping jsonfabrica_generate_from_template yourself when you need many documents or cross-document relations in a single request. Small batches run synchronously and the response is 200 with results; larger batches are queued and the response is 202 with just { batchId, status, seed } — poll jsonfabrica_get_batch for the final results in that case. Like a single generate call, this is metered/billed per document produced and, unless namespaced, can advance real durable sequences and mutate durable variables referenced by the templates.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Deterministic PRNG seed applied across the whole batch — the same seed reproduces byte-identical random values for every document. Optional; if omitted the server picks a random seed and returns it in the response (`seed` in both sync and async cases). | |
| documents | Yes | One entry per group of documents to generate, each naming a `templateId`, a unique `alias`, how many (`count`) to generate, and optionally `relations`/`params`. Required; at least one entry. Entries are executed in dependency order (documents with `relations` are generated after the aliases they depend on). | |
| sequenceNamespace | No | Isolates createSeq()/getSeq() durable-sequence side effects for this whole batch under this namespace, so test/debug runs don't advance real tenant sequences. Optional; omitted means the default (unnamespaced) sequence scope is used. | |
| variableNamespace | No | Isolates durable-variable side effects for this whole batch under this namespace, analogous to `sequenceNamespace`. Optional; omitted means the default (unnamespaced) variable scope is used. |
| Name | Required | Description |
|---|---|---|
| seed | No | PRNG seed used/assigned for the whole batch. |
| error | No | Present if the whole batch failed. |
| status | No | Batch status at response time. |
| batchId | No | Id of the created batch. |
| results | No | Present only for synchronous (200) responses. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations (which only set readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) by detailing side effects: it can 'advance real durable sequences and mutate durable variables' unless namespaced, and notes per-document billing. It also discloses the async behavior with 200 vs 202 responses and polling, which is critical for correct invocation. No contradictions with annotations.
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 two well-structured sentences that pack essential information: the first states the endpoint and core function, the second covers sync/async behavior and side effects. It is front-loaded with the purpose and avoids redundancy, making it efficient for an agent to parse quickly.
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's complexity, the description provides comprehensive context: it covers when to use it, how it behaves synchronously vs asynchronously, billing implications, and side-effect risks with namespace mitigation. Since an output schema exists, return value details are not required in the description. Everything an agent needs to correctly call and interpret the result is present.
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 schema has 100% coverage with detailed descriptions for all parameters, so the baseline is 3. The description adds minimal parameter-specific meaning beyond the schema—it mentions the relations cross-referencing concept and namespacing side effects, but these are already explained in the schema properties. The description does not introduce new parameter semantics not covered by the schema.
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 tool's function: 'Generates multiple documents from one or more persisted templates in one call' and explicitly distinguishes it from the sibling jsonfabrica_generate_from_template by recommending this tool 'instead of looping' when many documents or cross-document relations are needed. This makes the purpose unambiguous and differentiates it from alternatives.
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?
Provides explicit when-to-use guidance: 'use this instead of looping jsonfabrica_generate_from_template yourself when you need many documents or cross-document relations in a single request.' It also explains the sync vs async behavior and directs the agent to poll jsonfabrica_get_batch for async results, giving clear context on when to expect different response types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calls POST /v1/sequences. Creates a durable named sequence (number/string/uuid), referenced from template bodies via createSeq()/getSeq()-style functions. Fails with a 409-style conflict error if a sequence with this name already exists for the tenant — use jsonfabrica_update_sequence to change an existing one's currentValue/step instead of retrying create with the same name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Unique identifier for the sequence within the tenant, referenced from template bodies via createSeq("name")/getSeq("name") placeholders. Required; creation fails if a sequence with this name already exists. | |
| step | No | Amount `currentValue` is incremented by on each bump, for "number"/"string" sequences (ignored for "uuid"). Optional; defaults to 1 when omitted. May be negative to count down. | |
| type | Yes | Value kind the sequence produces on each bump: "number" increments `currentValue` by `step` and returns a numeric value; "string" behaves like "number" but the returned value is stringified; "uuid" does not use `start`/`step` to derive values (but `start` must still be provided — see its description); each bump returns a fresh UUID. Required. | |
| start | No | Initial value of `currentValue` for "number"/"string" sequences. Marked optional in this schema, but the gateway validates it as a required finite number for every sequence type — omitting it always causes a 400 validation error, even for type "uuid". For "uuid" sequences the value is stored but not used to derive the generated UUIDs. |
| Name | Required | Description |
|---|---|---|
| name | Yes | Sequence name. |
| step | No | Increment applied per bump (ignored for "uuid"). |
| type | Yes | Value kind produced on each bump. |
| start | No | Initial value the sequence was created with. |
| tenantId | Yes | Owning tenant id. |
| createdAt | Yes | ISO-8601 creation timestamp. |
| updatedAt | Yes | ISO-8601 last-update timestamp. |
| currentValue | Yes | Current stored counter value (unused by "uuid" sequences). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses persistence, conflict failure, and the surprising gateway validation that start is required despite being marked optional in the schema. It does not contradict the annotations and reasonably conveys the non-idempotent, non-destructive nature of the 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 top-level description is concise and focused, while the detailed schema descriptions are appropriately placed in the parameter definitions. There is no redundant or irrelevant text.
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 description includes important operational context such as template placeholder usage, conflict behavior, and the alternative update path. Since an output schema exists, the lack of an explicit return-value explanation is not a gap.
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 property descriptions fully cover every parameter, including type-specific behavior for number/string/uuid, step defaults, and the start edge case. This leaves no ambiguity about parameter meaning or validation requirements.
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 that it calls POST /v1/sequences to create a durable named sequence for number/string/uuid kinds. It also distinguishes itself from the update tool by explicitly advising use of jsonfabrica_update_sequence when a sequence already exists.
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?
It gives explicit guidance on when to use the tool and what happens on conflict, including the alternative update operation. It does not enumerate every possible use case, but the provided context is sufficient for correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calls POST /v1/templates. Creates a persisted, reusable template that can be generated from repeatedly with jsonfabrica_generate_from_template — use this instead of jsonfabrica_generate_adhoc when you want the body saved and shareable rather than a one-off, unsaved evaluation. body uses JsonFabrica's function-call placeholder syntax, e.g. "Hello {{getRandomFullName()}}" or "<getRandomNumber(1,100)>" — see the data-generation-functions reference for the full catalog. The optional generate field is a convenience that also runs a generation in the same call (response includes generation or generationError alongside template) so you avoid a separate jsonfabrica_generate_from_template round-trip; that generation is metered/billed and can advance durable sequences/variables just like a normal generate call. If generate is omitted, the response is just the created template with no generation side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Template body containing at least one function-call placeholder. Required. | |
| name | Yes | Template name. Required; not required to be unique per tenant. | |
| tags | No | Labels for later filtering via jsonfabrica_list_templates' `tags` parameter (AND-match: a template must contain every requested tag). Optional; omitted or empty means no tags stored. | |
| generate | No | When present, immediately generates one document from the just-created template using these options; the response then includes `generation`/`generationError` alongside `template`. Optional — omit to only create the template record with no generation side effects. | |
| description | No | Free-text human-readable description of the template's purpose. Optional; omitted means none stored. |
| Name | Required | Description |
|---|---|---|
| body | No | Template body containing function-call placeholders. |
| name | No | Template name. |
| tags | No | Tags stored on the template. |
| status | No | "active" unless soft-deleted via jsonfabrica_delete_template. |
| astCache | No | Server-internal parsed-body cache; opaque to callers. |
| template | No | Present when `generate` was passed; the created template record. |
| tenantId | No | Owning tenant id. |
| warnings | No | Non-fatal validation warnings, if any. |
| createdAt | No | ISO-8601 creation timestamp. |
| updatedAt | No | ISO-8601 last-update timestamp. |
| validated | No | Whether the body passed static template validation. |
| generation | No | Present when `generate` was passed and the immediate generation succeeded. |
| templateId | No | Server-assigned template id. |
| description | No | Free-text description, if any was stored. |
| generationError | No | Present when `generate` was passed but the immediate generation failed at runtime (template was still created). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the minimal annotations, the description discloses persistence, optional generation side effects, metering/billing, durable sequence/variable advancement, and the absence of side effects when generate is omitted. It does not enumerate every possible side effect, but it provides sufficient 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?
The description is well organized and free of fluff, though the optional-generate section is long and contains several nested clauses. Overall, every sentence adds useful guidance.
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?
Combined with full schema descriptions and the output schema indication, the description covers when to use the tool, what side effects to expect, and what response shape to anticipate when generate is present or omitted.
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 descriptions cover all parameters, and the tool description adds meaningful behavioral detail: tags use AND-match, unresolved params remain empty, params are unrelated to sequence/variable namespacing, and context is implementation-specific auxiliary data.
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 explicitly says the tool 'Creates a persisted, reusable template' and contrasts it with jsonfabrica_generate_adhoc and jsonfabrica_generate_from_template, making the purpose and resource type clear.
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?
It gives direct selection guidance: use this instead of jsonfabrica_generate_adhoc when the body should be saved and shareable, and explains the optional generate field as a convenience to avoid a separate round-trip.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calls DELETE /v1/sequences/{name}. This is a hard, permanent delete — unlike jsonfabrica_delete_template's soft-delete/archive behavior, the sequence record is removed entirely and cannot be recovered; there is no status: "archived" equivalent for sequences. Returns no content on success. Any template body still calling createSeq()/getSeq() with this name afterwards will no longer see the deleted history/state.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact name of the sequence to delete. Required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructive hint), the description details that deletion is irreversible, returns no content, and affects subsequent operations on the same name, providing strong transparency about 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 slightly verbose with three sentences, but each adds value: the action, the comparison, and the side effects. It is not overly long for the information conveyed.
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 there is no output schema, the description clarifies the return (no content) and explains the impacts of deletion on subsequent calls. It provides sufficient context for safe 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?
The sole parameter 'name' is described as 'Exact name of the sequence to delete', which is clear and covers the required semantics. Schema coverage is 100%.
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 tool deletes a sequence permanently, using the specific verb 'delete' and the resource 'sequence'. It also contrasts with the soft-delete behavior of a sibling tool, making the purpose unambiguous.
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 implicitly guides usage by contrasting with the soft-delete alternative, indicating this tool is for hard, permanent deletion. However, it does not explicitly state conditions for when to choose this over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calls DELETE /v1/templates/{templateId}. This is a soft delete: the template's status is set to "archived" (it is not erased from storage), and the call returns the resulting archived template record. Archived templates are excluded from jsonfabrica_list_templates by default — pass status: "archived" there to find them again — and both jsonfabrica_get_template and jsonfabrica_generate_from_template still work against the id afterwards, since archiving does not block reads or generation. Use this when a template should stop showing up in normal listings; there is currently no tool to restore an archived template back to active.
| Name | Required | Description | Default |
|---|---|---|---|
| templateId | Yes | ID of the template to delete. Required. |
| Name | Required | Description |
|---|---|---|
| body | Yes | Template body containing function-call placeholders. |
| name | Yes | Template name. |
| tags | No | Tags stored on the template. |
| status | Yes | "active" unless soft-deleted via jsonfabrica_delete_template. |
| astCache | No | Server-internal parsed-body cache; opaque to callers. |
| tenantId | Yes | Owning tenant id. |
| warnings | No | Non-fatal validation warnings, if any. |
| createdAt | Yes | ISO-8601 creation timestamp. |
| updatedAt | Yes | ISO-8601 last-update timestamp. |
| validated | No | Whether the body passed static template validation. |
| templateId | Yes | Server-assigned template id. |
| description | No | Free-text description, if any was stored. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description transparently explains the soft-delete behavior, that get and generate still work, that list excludes archived templates by default, and that the call returns the archived record. This is fully consistent with destructiveHint and idempotentHint.
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 detailed but every sentence contributes meaningful behavior, use-case guidance, and caveats. It is well-structured and avoids redundant filler.
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 description fully covers the operation's side effects, return value, effect on sibling operations, intended use case, and the lack of a restore path. This gives an agent enough context to decide when and how to invoke the 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?
The single parameter templateId is described in both the schema and the description as the ID of the template to delete and required. Since schema coverage is 100% and the description adds no additional parameter-level detail, the baseline score applies.
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 tool calls DELETE /v1/templates/{templateId} and defines the operation as a soft delete that sets status to 'archived'. It distinguishes this from a hard deletion and explicitly differentiates it from related template tools.
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?
It provides explicit guidance on when to use the tool: when a template should stop appearing in normal listings. It also warns that no tool currently restores an archived template to active, preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| data | Yes | The generated document; shape is entirely determined by the template body. |
| meta | Yes | Generation metadata. |
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.
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.
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.
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.
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.
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.
Calls POST /v1/templates/{templateId}/generate. Generates a document from a persisted, saved template referenced by templateId — use this (not jsonfabrica_generate_adhoc) when the template is meant to be reused or shared across calls/tenants; use jsonfabrica_generate_adhoc instead when you are still iterating on raw template syntax and don't want to persist anything yet. This call is metered/billed like any generation and, unless namespaced, can advance real durable sequences and mutate durable variables referenced by the template body. Set sequenceNamespace/variableNamespace to isolate those side effects between environments (e.g. test vs. production).
| Name | Required | Description | Default |
|---|---|---|---|
| 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 the template body. Optional; omitted keys leave the corresponding getParam() calls unresolved/empty. | |
| context | No | Arbitrary auxiliary key/value data made available to the template body alongside `params`. Optional; omitted keys are simply absent during generation. | |
| templateId | Yes | ID of the persisted template to generate a document from. Required. | |
| sequenceNamespace | No | Isolates createSeq()/getSeq() durable-sequence side effects under this namespace so repeated test/debug 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. |
| Name | Required | Description |
|---|---|---|
| data | Yes | The generated document; shape is entirely determined by the template body. |
| meta | Yes | Generation metadata. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses side effects on sequences/variables, the ability to isolate them via namespaces, and the metered/billed nature of the call.
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?
Focused and mostly efficient, though 'persisted, saved' is mildly redundant and the side-effect explanation could be tightened.
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?
Covers usage, side effects, and namespace semantics; the output schema handles return details, so no critical missing context.
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 schema already covers 100% of parameters with detailed descriptions; the prose adds context but no significant parameter-level meaning beyond that.
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?
States a specific action (generate a document from a persisted template) and explicitly contrasts with jsonfabrica_generate_adhoc, making the tool's purpose unmistakable.
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?
Explicitly says when to use this tool versus the adhoc alternative, and warns about metering/billing plus durable side effects with namespace guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calls GET /v1/batches/{batchId}. Returns batch status and, once complete, the generated documents. Use this to poll a batch that was accepted asynchronously (202).
| Name | Required | Description | Default |
|---|---|---|---|
| batchId | Yes | ID of the batch job to fetch, as returned by jsonfabrica_create_batch. Required. |
| Name | Required | Description |
|---|---|---|
| seed | No | PRNG seed used for the whole batch. |
| spec | No | The original BatchSpec request body this batch was created from. |
| error | No | Present if the whole batch failed. |
| status | Yes | Current batch status. |
| batchId | Yes | Id of the fetched batch. |
| tenantId | No | Owning tenant id. |
| documents | No | Generated documents, once available. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Read-only, idempotent, and non-destructive behavior is fully disclosed via annotations, and the description accurately reflects that no side effects occur beyond retrieving batch state and documents.
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 and information-dense, using two sentences to convey endpoint, result, and usage context without unnecessary detail.
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?
With a complete output schema and clear parameter documentation, the description provides all necessary context for correct invocation and interpretation of results.
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 single required parameter batchId is fully described in the schema and the description adds useful provenance by noting it comes from jsonfabrica_create_batch.
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 states the exact HTTP method and resource (GET /v1/batches/{batchId}) and clarifies that it returns batch status and generated documents. It clearly distinguishes this from batch creation and other sibling operations.
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?
Explicitly instructs to use this tool for polling a batch that was accepted asynchronously (202), making the intended invocation context unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calls GET /v1/sequences/{name}. Returns the sequence record for a known name; use jsonfabrica_list_sequences instead if you need to discover names. Read-only — does not advance the sequence (use jsonfabrica_bump_sequence for that).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact name of the sequence to fetch, as given at creation. Required. |
| Name | Required | Description |
|---|---|---|
| name | Yes | Sequence name. |
| step | No | Increment applied per bump (ignored for "uuid"). |
| type | Yes | Value kind produced on each bump. |
| start | No | Initial value the sequence was created with. |
| tenantId | Yes | Owning tenant id. |
| createdAt | Yes | ISO-8601 creation timestamp. |
| updatedAt | Yes | ISO-8601 last-update timestamp. |
| currentValue | Yes | Current stored counter value (unused by "uuid" sequences). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reinforces the annotation hints by explicitly noting the operation is read-only and does not advance the sequence. No side effects are hidden.
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 two concise sentences with no redundant wording. It states the endpoint, resource, and key differentiators efficiently.
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 description provides enough context for correct invocation, including endpoint, parameter semantics, and side-effect behavior. The presence of an output schema covers return details.
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 single parameter `name` is fully described in the schema, and the description adds that it must be a known sequence name, directing discovery to the list tool. This gives complete parameter context.
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 tool calls GET /v1/sequences/{name} and returns the sequence record for a known name. It explicitly distinguishes this from list_sequences and bump_sequence, making the purpose unambiguous.
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 gives explicit guidance: use list_sequences when discovering names and bump_sequence when advancing is needed. This makes the appropriate usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calls GET /v1/templates/{templateId}. Returns the full template record for a known id. Use this instead of jsonfabrica_list_templates when you already have the templateId (e.g. from a prior create/list call); it is also the recommended way to inspect current body/tags/description before calling jsonfabrica_update_template, since update only shows you the fields you send, not the result of merging them with what already exists. Read-only, no side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| templateId | Yes | ID of the template to fetch, as returned by create/list. Required. |
| Name | Required | Description |
|---|---|---|
| body | Yes | Template body containing function-call placeholders. |
| name | Yes | Template name. |
| tags | No | Tags stored on the template. |
| status | Yes | "active" unless soft-deleted via jsonfabrica_delete_template. |
| astCache | No | Server-internal parsed-body cache; opaque to callers. |
| tenantId | Yes | Owning tenant id. |
| warnings | No | Non-fatal validation warnings, if any. |
| createdAt | Yes | ISO-8601 creation timestamp. |
| updatedAt | Yes | ISO-8601 last-update timestamp. |
| validated | No | Whether the body passed static template validation. |
| templateId | Yes | Server-assigned template id. |
| description | No | Free-text description, if any was stored. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly states 'Read-only, no side effects' and is consistent with readOnlyHint, idempotentHint, and destructiveHint annotations.
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?
Concise yet informative, with no wasted words; the extra context about update_template is valuable and well-integrated.
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?
Explains what is returned (full template record, including body/tags/description) and how it relates to sibling tools, making the tool's role clear.
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 single parameter templateId is clearly described as the ID of the template to fetch, matching the schema description fully.
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?
Clearly states it fetches a full template record by ID, and distinguishes itself from list and update operations.
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?
Provides explicit guidance on when to use this tool instead of list_templates and before update_template, including the rationale about merge behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calls GET /v1/usage. Returns { tenantId, usageTotal, asOf } for the configured API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| asOf | Yes | ISO-8601 timestamp the usage total was computed as of. |
| tenantId | Yes | Tenant id the usage totals belong to. |
| usageTotal | Yes | Cumulative metered usage units consumed by this tenant. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly notes a read-only GET operation and indicates it returns data, which aligns with the readOnlyHint and idempotentHint annotations. It does not describe side effects, but none are expected for a usage retrieval endpoint.
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 concise sentence that includes the endpoint, return fields, and API key context, with no unnecessary wording.
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 no parameters and the description includes the return shape, endpoint, and auth context, it provides all necessary information for an agent to call it successfully.
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 tool has no parameters, so parameter semantics are trivially satisfied. The description does not need to explain any inputs, and the schema confirms an empty properties object.
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 HTTP method and endpoint ('Calls GET /v1/usage') and identifies the resource as tenant usage. The title and sibling context make it distinct from health, whoami, and template management tools.
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 intended use is implied by the title and description: to retrieve tenant usage for the configured API key. It does not explicitly contrast with sibling tools, but the resource and endpoint are unambiguous enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calls GET /health on the JsonFabrica gateway. No authentication required. Use this to verify JSONFABRICA_API_URL points at a reachable gateway.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| status | Yes | Liveness indicator, e.g. "ok". |
| service | No | Name of the responding service, e.g. "svc-gateway". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds useful context by specifying the HTTP method and that no authentication is required.
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 fully cover purpose, method, authentication, and intended use with no filler or redundancy.
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 description is complete for a health-check tool with no parameters, and since an output schema exists, return values need not be described.
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?
With zero parameters, the baseline is 4. There are no parameter semantics to add beyond what the empty input schema already conveys.
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?
Clearly states it calls GET /health on the JsonFabrica gateway, distinguishing it from all other sibling tools that perform CRUD, generation, or usage operations.
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?
Explicitly says to use this tool to verify JSONFABRICA_API_URL points at a reachable gateway, giving a specific when-to-use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calls GET /v1/sequences. Returns a page of sequences ({ items, nextCursor }). Use this to discover sequence names when you don't already know one; if you know the exact name, call jsonfabrica_get_sequence directly instead. Read-only, no side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of sequences to return in this page. Optional; defaults to 20 when omitted. Values <= 0 or > 100 are not clamped — the request is rejected with a 400 validation error. | |
| cursor | No | Opaque pagination cursor from a previous response's `nextCursor`. Optional; omit to fetch the first page. Not a page number or offset you construct yourself. |
| Name | Required | Description |
|---|---|---|
| items | Yes | Page of matching sequences. |
| nextCursor | No | Pass to `cursor` on the next call; absent on the last page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the return shape `{ items, nextCursor }` and repeats 'Read-only, no side effects,' but adds little beyond what annotations and schema already convey. It does not introduce any contradiction.
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 three sentences, front-loaded with the HTTP call and return shape, followed by concise usage guidance and a safety note. No filler or redundant details—every sentence 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?
Given an output schema exists (noted in context), the description need not detail the full return structure. It covers the discovery use case, pagination behavior, and explicitly states the alternative tool. For a simple read-only list operation, nothing essential is missing.
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 100%, with both limit and cursor having detailed descriptions. The description's mention of cursor from a previous response's nextCursor is already covered in the schema, so it adds no new meaning beyond what the schema provides. Baseline of 3 applies.
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 states the specific HTTP call (GET /v1/sequences) and the return shape (a page of sequences with items and nextCursor). It also differentiates from the sibling jsonfabrica_get_sequence by clarifying when to use each, so the purpose is unambiguous.
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?
Explicitly instructs to use this tool for discovery when the sequence name is unknown, and directs to jsonfabrica_get_sequence when the exact name is known. This leaves no ambiguity about when to choose this over the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calls GET /v1/templates. Returns a page of templates matching optional name/tags/status filters ({ items, nextCursor }). Use this to discover or search templates when you don't already know the templateId; if you already have the id, call jsonfabrica_get_template directly instead — it is cheaper and returns the full record. This is read-only and has no side effects. Pass status: "archived" to see templates previously removed with jsonfabrica_delete_template, since the default active filter excludes them.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filters to templates whose `name` contains this text — a case-insensitive substring match, not an exact match. Optional; omit to match templates of any name. | |
| tags | No | Comma-separated list of tags, e.g. "orders,email". AND-match: a template must contain every listed tag to be included (not "any of"). Optional; omit to ignore tags entirely. | |
| limit | No | Maximum number of templates to return in this page. Optional; defaults to 20 when omitted. Values <= 0 or > 100 are not clamped — the request is rejected with a 400 validation error. | |
| cursor | No | Opaque pagination cursor taken verbatim from a previous response's `nextCursor`. Optional; omit to fetch the first page. | |
| status | No | `active` returns only non-deleted templates, `archived` returns only soft-deleted ones. Optional; defaults to `active` when omitted (archived templates are excluded unless requested). |
| Name | Required | Description |
|---|---|---|
| items | Yes | Page of matching templates. |
| nextCursor | No | Pass to `cursor` on the next call to fetch the following page; absent on the last page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description reaffirms 'read-only and has no side effects' (consistent, not contradictory). It adds valuable behavior beyond annotations: default active filter, pagination via nextCursor, and that archived templates are excluded unless requested. This context enriches the agent's understanding without relying solely on structured hints.
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 compact and front-loaded: endpoint, return shape, then usage guidance. Every sentence earns its place, covering filters, alternative, read-only nature, and archived use case without redundancy. Well-structured and efficient.
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 list tool with 5 parameters and an output schema, the description covers discovery, pagination, filter semantics, the read-only nature, and the alternative tool. Nothing an agent needs to call it correctly is missing. The presence of an output schema means return values need not be explained further.
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 100%—every parameter has a detailed description, so the schema already carries the heavy lifting. The description adds a usage example (pass status archived) but does not introduce new parameter meaning beyond what the schema provides. Baseline 3 is appropriate given full 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?
States a specific HTTP verb, resource, and return shape, and explicitly differentiates from jsonfabrica_get_template by saying it is for discovery when you don't know the templateId. The purpose is unambiguous and distinguishable from 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?
Explicitly instructs when to use this tool (discover/search when templateId unknown) and when to use the alternative (jsonfabrica_get_template if you already have the id), noting it is cheaper. Also gives a concrete use case for the archived status filter. Provides clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calls PATCH /v1/sequences/{name}. Only the provided fields (currentValue, step) are changed; fields you omit are left as-is. Use this when you need to set an explicit currentValue (e.g. resetting a counter) or change the step amount — use jsonfabrica_bump_sequence instead when you just want to advance the sequence by its existing configured step. This overwrites the sequence's stored state in place immediately; there is no undo.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact name of the sequence to update. Required. | |
| step | No | Changes the increment applied by future jsonfabrica_bump_sequence calls; must be a non-zero finite number (negative allowed, to count down). Optional; if omitted, the existing step is left unchanged. | |
| currentValue | No | Resets the sequence's current counter value to this number, without changing `step`. Optional; if omitted, the current value is left unchanged (unless `step` is also provided, in which case only `step` changes). |
| Name | Required | Description |
|---|---|---|
| name | Yes | Sequence name. |
| step | No | Increment applied per bump (ignored for "uuid"). |
| type | Yes | Value kind produced on each bump. |
| start | No | Initial value the sequence was created with. |
| tenantId | Yes | Owning tenant id. |
| createdAt | Yes | ISO-8601 creation timestamp. |
| updatedAt | Yes | ISO-8601 last-update timestamp. |
| currentValue | Yes | Current stored counter value (unused by "uuid" sequences). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: it states that only provided fields are changed, that the operation overwrites stored state in place, and that there is no undo. These details are not present in the annotations (which only indicate readOnlyHint=false and destructiveHint=false) and are crucial for an agent to understand side effects. No contradiction with annotations.
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 four concise sentences with zero fluff. It front-loads the endpoint and core behavior, then provides usage guidance and a warning. Every sentence earns its place, and the structure is logical and scannable.
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 mutation tool with a rich schema and an output schema, the description is complete: it covers the operation, partial-update semantics, when to use it vs. the sibling, and the irreversible nature. Nothing essential for an agent to call it correctly is missing. The output schema handles return values, so no need to describe them.
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 100% and each parameter has a detailed description (e.g., step explains non-zero finite requirement and negative allowed; currentValue explains resetting without changing step). The description adds a general partial-update behavior but does not add per-parameter meaning beyond the schema. Baseline 3 is appropriate since the schema carries the burden.
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 identifies the operation (calls PATCH on a sequence), specifies the fields it modifies (currentValue, step), and explicitly distinguishes it from the sibling tool jsonfabrica_bump_sequence. The verb+resource+scope is precise, making it unambiguous which tool to select.
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 gives explicit when-to-use guidance: use this tool to set an explicit currentValue (e.g., resetting a counter) or change the step amount, and directs the agent to use jsonfabrica_bump_sequence instead when only advancing by the existing step. It also clarifies partial-update semantics (omitted fields left as-is), providing clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calls PUT /v1/templates/{templateId}. Partially updates an existing template in place: only the fields you include in the call are changed, and every field you omit is left exactly as it was — call jsonfabrica_get_template first if you need to see current values before deciding what to send. Use this only for an existing templateId; to make a new template use jsonfabrica_create_template instead (it does not modify or version the original). The change is applied immediately and in-place with no version history — there is no undo, so if you need to keep the old body/tags around, read and save them first.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | New template body (function-call placeholder syntax), replacing the existing one entirely. Optional; omit to leave the current body unchanged. | |
| name | No | New template name. Optional; omit to leave the current name unchanged. | |
| tags | No | New full set of tags, replacing (not merging with) the existing tags. Optional; omit to leave the current tags unchanged; pass an empty array to clear all tags. | |
| templateId | Yes | ID of the template to update. Required. | |
| description | No | New free-text description, replacing the existing one. Optional; omit to leave it unchanged. |
| Name | Required | Description |
|---|---|---|
| body | Yes | Template body containing function-call placeholders. |
| name | Yes | Template name. |
| tags | No | Tags stored on the template. |
| status | Yes | "active" unless soft-deleted via jsonfabrica_delete_template. |
| astCache | No | Server-internal parsed-body cache; opaque to callers. |
| tenantId | Yes | Owning tenant id. |
| warnings | No | Non-fatal validation warnings, if any. |
| createdAt | Yes | ISO-8601 creation timestamp. |
| updatedAt | Yes | ISO-8601 last-update timestamp. |
| validated | No | Whether the body passed static template validation. |
| templateId | Yes | Server-assigned template id. |
| description | No | Free-text description, if any was stored. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write operation (readOnlyHint=false) and idempotentHint=true. The description adds crucial behavior beyond annotations: the partial-update semantics, immediate in-place application, no version history, and no undo. It also warns to save old values if needed. No contradiction.
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 longer than necessary but each sentence carries meaningful information: method, partial update semantics, guidance to read first, sibling routing, and behavioral warnings. It is front-loaded with the key behavior and remains focused.
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?
With an output schema present, return values are covered. The description covers usage context, behavioral nuances, alternatives, and prerequisites. Nothing essential is missing for an agent to call 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 100%, so every parameter is already documented in the schema. The description adds slight context about partial update semantics (omit to leave unchanged) but this is also largely captured in the schema descriptions. Baseline 3 is appropriate since the schema does the heavy lifting.
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 a specific verb ('Partially updates'), a resource ('an existing template'), and the scope ('only the fields you include are changed'). It clearly distinguishes from the sibling create_template by noting it modifies an existing template rather than creating a new one.
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?
Explicitly instructs to use only for an existing templateId, names the alternative jsonfabrica_create_template for creation, and recommends calling jsonfabrica_get_template first to see current values. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calls GET /v1/whoami on the JsonFabrica gateway using the configured API key. Returns { tenantId, role } for the configured JSONFABRICA_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| role | Yes | Role associated with the configured API key. |
| tenantId | Yes | Tenant id resolved from the configured API key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the endpoint, the auth mechanism (configured API key), and the exact return fields, which are useful beyond the annotations. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero fluff. The endpoint and return shape are front-loaded, and 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?
With an output schema present, the return values are already documented. The description covers the endpoint and auth context, and annotations handle safety. Nothing essential is missing 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?
There are zero parameters, so the schema is trivially covered. The description adds no param info, but none is needed. Baseline 4 for a zero-parameter tool 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 states the exact HTTP verb and resource (GET /v1/whoami), names the configured API key as the auth context, and specifies the exact response shape ({ tenantId, role }). It is unambiguous and clearly distinct from siblings like jsonfabrica_health.
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: to retrieve the current tenant and role associated with the configured API key. There is no explicit alternative named, but given the tool is unique and self-explanatory, the context is clear. A brief 'use when you need to verify the API key' would push it to 5.
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.
v0.3.0jsonfabrica_list_function_weightsjsonfabrica_update_function_weightjsonfabrica_bump_sequence2 fields changedInput schema / properties / name / descriptionAdded value: +"Exact name of the sequence to bump (advance by its configured step). Required."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "createdAt": {
+ "description": "ISO-8601 creation timestamp.",
+ "type": "string"
+ },
+ "currentValue": {
+ "description": "Current stored counter value (unused by \"uuid\" sequences).",
+ "type": "number"
+ },
+ "name": {
+ "description": "Sequence name.",
+ "type": "string"
+ },
+ "start": {
+ "description": "Initial value the sequence was created with.",
+ "type": "number"
+ },
+ "step": {
+ "description": "Increment applied per bump (ignored for \"uuid\").",
+ "type": "number"
+ },
+ "tenantId": {
+ "description": "Owning tenant id.",
+ "type": "string"
+ },
+ "type": {
+ "description": "Value kind produced on each bump.",
+ "enum": [
+ "number",
+ "string",
+ "uuid"
+ ],
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "ISO-8601 last-update timestamp.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "tenantId",
+ "name",
+ "type",
+ "currentValue",
+ "createdAt",
+ "updatedAt"
+ ],
+ "type": "object"
+}jsonfabrica_create_batch11 fields changedInput schema / properties / documents / descriptionAdded value: +"One entry per group of documents to generate, each naming a `templateId`, a unique `alias`, how many (`count`) to generate, and optionally `relations`/`params`. Required; at least one entry. Entries are executed in dependency order (documents with `relations` are generated after the aliases they depend on)."Input schema / properties / documents / items / properties / alias / descriptionAdded value: +"Short name identifying this `documents[]` entry within the batch, used to reference it from other entries' `relations` (and duplicated aliases across entries are rejected with a 400 error). Required."Input schema / properties / documents / items / properties / count / descriptionAdded value: +"How many documents to generate from this template within the batch. Required; must be an integer."Input schema / properties / documents / items / properties / params / descriptionAdded value: +"Key/value map supplying values for getParam(\"key\") placeholders in this template's body, applied to every document generated for this alias. Optional; omitted keys leave the corresponding getParam() calls unresolved/empty."Input schema / properties / documents / items / properties / relations / additionalProperties / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "properties": {
- "from": {
- "type": "string"
- },
- "strategy": {
- "enum": [
- "by-index",
- "round-robin"
- ],
- "type": "string"
- }
- },
- "type": "object"
- }
-]New value: +[
+ {
+ "description": "Shorthand relation reference in the form \"parentAlias\" or \"parentAlias.field.nested\", pointing at a document from another `documents[]` entry (by its `alias`). Only valid when the referenced parent has `count === 1` — with `count > 1` the reference is ambiguous and the request is rejected with a 400 error; use the object form with `strategy` instead.",
+ "type": "string"
+ },
+ {
+ "properties": {
+ "from": {
+ "description": "Same \"parentAlias\" or \"parentAlias.field.nested\" reference as the string form, but required here so a `strategy` can be attached — used when the referenced parent has `count > 1`.",
+ "type": "string"
+ },
+ "strategy": {
+ "description": "How to pick one of several parent documents when the referenced alias has `count > 1`. Only \"round-robin\" is currently supported (cycles through the parent's generated documents in order, wrapping around); any other value is rejected with a 400 UNSUPPORTED_STRATEGY error. Optional, but effectively required whenever the parent alias has `count > 1`.",
+ "enum": [
+ "round-robin"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+]Input schema / properties / documents / items / properties / relations / descriptionAdded value: +"Map of field name (as it appears in this template's generated output) to a reference into another alias in the same batch, letting generated documents cross-reference each other (e.g. an \"orders\" entry referencing a \"customers\" entry's id). Optional; omit for documents with no cross-references. Unknown aliases or dependency cycles across `documents[]` are rejected with a 400 error."Input schema / properties / documents / items / properties / templateId / descriptionAdded value: +"ID of the persisted template used to generate this document group. Required."Input schema / properties / seed / descriptionAdded value: +"Deterministic PRNG seed applied across the whole batch — the same seed reproduces byte-identical random values for every document. Optional; if omitted the server picks a random seed and returns it in the response (`seed` in both sync and async cases)."Input schema / properties / sequenceNamespace / descriptionAdded value: +"Isolates createSeq()/getSeq() durable-sequence side effects for this whole batch under this namespace, so test/debug runs don't advance real tenant sequences. Optional; omitted means the default (unnamespaced) sequence scope is used."Input schema / properties / variableNamespace / descriptionAdded value: +"Isolates durable-variable side effects for this whole batch under this namespace, analogous to `sequenceNamespace`. Optional; omitted means the default (unnamespaced) variable scope is used."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "batchId": {
+ "description": "Id of the created batch.",
+ "type": "string"
+ },
+ "error": {
+ "additionalProperties": false,
+ "description": "Present if the whole batch failed.",
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "results": {
+ "description": "Present only for synchronous (200) responses.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "alias": {
+ "description": "The `documents[]` alias this document was generated for.",
+ "type": "string"
+ },
+ "batchId": {
+ "description": "Id of the batch this document belongs to.",
+ "type": "string"
+ },
+ "documentSeed": {
+ "description": "Per-document PRNG seed actually used.",
+ "type": "number"
+ },
+ "result": {
+ "description": "The generated document; shape depends on the template body. Absent while pending/failed."
+ },
+ "seqNo": {
+ "description": "0-based index of this document within its alias group.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "status": {
+ "description": "Per-document generation status.",
+ "enum": [
+ "pending",
+ "completed",
+ "failed"
+ ],
+ "type": "string"
+ },
+ "templateId": {
+ "description": "Template used to generate this document.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "batchId",
+ "alias",
+ "seqNo",
+ "templateId",
+ "status"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "seed": {
+ "description": "PRNG seed used/assigned for the whole batch.",
+ "type": "number"
+ },
+ "status": {
+ "description": "Batch status at response time.",
+ "enum": [
+ "queued",
+ "running",
+ "completed",
+ "failed"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+}jsonfabrica_create_sequence5 fields changedInput schema / properties / name / descriptionAdded value: +"Unique identifier for the sequence within the tenant, referenced from template bodies via createSeq(\"name\")/getSeq(\"name\") placeholders. Required; creation fails if a sequence with this name already exists."Input schema / properties / start / descriptionAdded value: +"Initial value of `currentValue` for \"number\"/\"string\" sequences. Marked optional in this schema, but the gateway validates it as a required finite number for every sequence type — omitting it always causes a 400 validation error, even for type \"uuid\". For \"uuid\" sequences the value is stored but not used to derive the generated UUIDs."Input schema / properties / step / descriptionAdded value: +"Amount `currentValue` is incremented by on each bump, for \"number\"/\"string\" sequences (ignored for \"uuid\"). Optional; defaults to 1 when omitted. May be negative to count down."Input schema / properties / type / descriptionAdded value: +"Value kind the sequence produces on each bump: \"number\" increments `currentValue` by `step` and returns a numeric value; \"string\" behaves like \"number\" but the returned value is stringified; \"uuid\" does not use `start`/`step` to derive values (but `start` must still be provided — see its description); each bump returns a fresh UUID. Required."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "createdAt": {
+ "description": "ISO-8601 creation timestamp.",
+ "type": "string"
+ },
+ "currentValue": {
+ "description": "Current stored counter value (unused by \"uuid\" sequences).",
+ "type": "number"
+ },
+ "name": {
+ "description": "Sequence name.",
+ "type": "string"
+ },
+ "start": {
+ "description": "Initial value the sequence was created with.",
+ "type": "number"
+ },
+ "step": {
+ "description": "Increment applied per bump (ignored for \"uuid\").",
+ "type": "number"
+ },
+ "tenantId": {
+ "description": "Owning tenant id.",
+ "type": "string"
+ },
+ "type": {
+ "description": "Value kind produced on each bump.",
+ "enum": [
+ "number",
+ "string",
+ "uuid"
+ ],
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "ISO-8601 last-update timestamp.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "tenantId",
+ "name",
+ "type",
+ "currentValue",
+ "createdAt",
+ "updatedAt"
+ ],
+ "type": "object"
+}jsonfabrica_create_template9 fields changedInput schema / properties / body / descriptionPrevious value: -"Template body containing at least one function-call placeholder."New value: +"Template body containing at least one function-call placeholder. Required."Input schema / properties / description / descriptionAdded value: +"Free-text human-readable description of the template's purpose. Optional; omitted means none stored."Input schema / properties / generate / descriptionAdded value: +"When present, immediately generates one document from the just-created template using these options; the response then includes `generation`/`generationError` alongside `template`. Optional — omit to only create the template record with no generation side effects."Input schema / properties / generate / properties / context / descriptionAdded value: +"Arbitrary key/value data made available to the template body alongside `params` (implementation- specific auxiliary context, e.g. for conditional logic). Optional; omitted keys are simply absent during generation."Input schema / properties / generate / properties / params / descriptionPrevious value: -"Values for getParam() references in the body."New value: +"Key/value map supplying values for getParam(\"key\") placeholders referenced in the template body. Optional; omitted keys leave the corresponding getParam() calls unresolved/empty. Not related to sequence or variable namespacing."Input schema / properties / generate / properties / seed / descriptionPrevious value: -"Deterministic seed for the generated document."New value: +"Deterministic PRNG seed for this generation — the same seed plus the same template body/params reproduces byte-identical random values. Optional; if omitted the server picks a random seed and returns it in the response so the result can be reproduced later."Input schema / properties / name / descriptionPrevious value: -"Template name."New value: +"Template name. Required; not required to be unique per tenant."Input schema / properties / tags / descriptionAdded value: +"Labels for later filtering via jsonfabrica_list_templates' `tags` parameter (AND-match: a template must contain every requested tag). Optional; omitted or empty means no tags stored."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "astCache": {
+ "anyOf": [
+ {
+ "items": {},
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Server-internal parsed-body cache; opaque to callers."
+ },
+ "body": {
+ "description": "Template body containing function-call placeholders.",
+ "type": "string"
+ },
+ "createdAt": {
+ "description": "ISO-8601 creation timestamp.",
+ "type": "string"
+ },
+ "description": {
+ "description": "Free-text description, if any was stored.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "generation": {
+ "additionalProperties": false,
+ "description": "Present when `generate` was passed and the immediate generation succeeded.",
+ "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"
+ },
+ "generationError": {
+ "additionalProperties": false,
+ "description": "Present when `generate` was passed but the immediate generation failed at runtime (template was still created).",
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "name": {
+ "description": "Template name.",
+ "type": "string"
+ },
+ "status": {
+ "description": "\"active\" unless soft-deleted via jsonfabrica_delete_template.",
+ "enum": [
+ "active",
+ "archived"
+ ],
+ "type": "string"
+ },
+ "tags": {
+ "description": "Tags stored on the template.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "template": {
+ "additionalProperties": false,
+ "description": "Present when `generate` was passed; the created template record.",
+ "properties": {
+ "astCache": {
+ "anyOf": [
+ {
+ "items": {},
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Server-internal parsed-body cache; opaque to callers."
+ },
+ "body": {
+ "description": "Template body containing function-call placeholders.",
+ "type": "string"
+ },
+ "createdAt": {
+ "description": "ISO-8601 creation timestamp.",
+ "type": "string"
+ },
+ "description": {
+ "description": "Free-text description, if any was stored.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "description": "Template name.",
+ "type": "string"
+ },
+ "status": {
+ "description": "\"active\" unless soft-deleted via jsonfabrica_delete_template.",
+ "enum": [
+ "active",
+ "archived"
+ ],
+ "type": "string"
+ },
+ "tags": {
+ "description": "Tags stored on the template.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "templateId": {
+ "description": "Server-assigned template id.",
+ "type": "string"
+ },
+ "tenantId": {
+ "description": "Owning tenant id.",
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "ISO-8601 last-update timestamp.",
+ "type": "string"
+ },
+ "validated": {
+ "description": "Whether the body passed static template validation.",
+ "type": "boolean"
+ },
+ "warnings": {
+ "description": "Non-fatal validation warnings, if any.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "templateId",
+ "tenantId",
+ "name",
+ "body",
+ "status",
+ "createdAt",
+ "updatedAt"
+ ],
+ "type": "object"
+ },
+ "templateId": {
+ "description": "Server-assigned template id.",
+ "type": "string"
+ },
+ "tenantId": {
+ "description": "Owning tenant id.",
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "ISO-8601 last-update timestamp.",
+ "type": "string"
+ },
+ "validated": {
+ "description": "Whether the body passed static template validation.",
+ "type": "boolean"
+ },
+ "warnings": {
+ "description": "Non-fatal validation warnings, if any.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}jsonfabrica_delete_sequence1 field changedInput schema / properties / name / descriptionAdded value: +"Exact name of the sequence to delete. Required."jsonfabrica_delete_template2 fields changedInput schema / properties / templateId / descriptionAdded value: +"ID of the template to delete. Required."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "astCache": {
+ "anyOf": [
+ {
+ "items": {},
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Server-internal parsed-body cache; opaque to callers."
+ },
+ "body": {
+ "description": "Template body containing function-call placeholders.",
+ "type": "string"
+ },
+ "createdAt": {
+ "description": "ISO-8601 creation timestamp.",
+ "type": "string"
+ },
+ "description": {
+ "description": "Free-text description, if any was stored.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "description": "Template name.",
+ "type": "string"
+ },
+ "status": {
+ "description": "\"active\" unless soft-deleted via jsonfabrica_delete_template.",
+ "enum": [
+ "active",
+ "archived"
+ ],
+ "type": "string"
+ },
+ "tags": {
+ "description": "Tags stored on the template.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "templateId": {
+ "description": "Server-assigned template id.",
+ "type": "string"
+ },
+ "tenantId": {
+ "description": "Owning tenant id.",
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "ISO-8601 last-update timestamp.",
+ "type": "string"
+ },
+ "validated": {
+ "description": "Whether the body passed static template validation.",
+ "type": "boolean"
+ },
+ "warnings": {
+ "description": "Non-fatal validation warnings, if any.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "templateId",
+ "tenantId",
+ "name",
+ "body",
+ "status",
+ "createdAt",
+ "updatedAt"
+ ],
+ "type": "object"
+}jsonfabrica_generate_adhoc7 fields changedInput schema / properties / body / descriptionAdded value: +"Raw template body containing at least one function-call placeholder, e.g. \"Hello {{getRandomFullName()}}\" — evaluated directly without persisting a template record. Required."Input schema / properties / context / descriptionAdded value: +"Arbitrary auxiliary key/value data made available to `body` alongside `params`. Optional; omitted keys are simply absent during generation."Input schema / properties / params / descriptionAdded value: +"Key/value map supplying values for getParam(\"key\") placeholders in `body`. Optional; omitted keys leave the corresponding getParam() calls unresolved/empty."Input schema / properties / seed / descriptionAdded 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."Input schema / properties / sequenceNamespace / descriptionAdded 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."Input schema / properties / variableNamespace / descriptionAdded value: +"Isolates durable-variable side effects under this namespace, analogous to `sequenceNamespace`. Optional; omitted means the default (unnamespaced) variable scope is used."Output 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"
+}jsonfabrica_generate_from_template7 fields changedInput schema / properties / context / descriptionAdded value: +"Arbitrary auxiliary key/value data made available to the template body alongside `params`. Optional; omitted keys are simply absent during generation."Input schema / properties / params / descriptionAdded value: +"Key/value map supplying values for getParam(\"key\") placeholders in the template body. Optional; omitted keys leave the corresponding getParam() calls unresolved/empty."Input schema / properties / seed / descriptionAdded 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."Input schema / properties / sequenceNamespace / descriptionAdded value: +"Isolates createSeq()/getSeq() durable-sequence side effects under this namespace so repeated test/debug runs don't advance real tenant sequences. Optional; omitted means the default (unnamespaced) sequence scope is used."Input schema / properties / templateId / descriptionAdded value: +"ID of the persisted template to generate a document from. Required."Input schema / properties / variableNamespace / descriptionAdded value: +"Isolates durable-variable side effects under this namespace, analogous to `sequenceNamespace`. Optional; omitted means the default (unnamespaced) variable scope is used."Output 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"
+}jsonfabrica_get_batch2 fields changedInput schema / properties / batchId / descriptionAdded value: +"ID of the batch job to fetch, as returned by jsonfabrica_create_batch. Required."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "batchId": {
+ "description": "Id of the fetched batch.",
+ "type": "string"
+ },
+ "documents": {
+ "description": "Generated documents, once available.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "alias": {
+ "description": "The `documents[]` alias this document was generated for.",
+ "type": "string"
+ },
+ "batchId": {
+ "description": "Id of the batch this document belongs to.",
+ "type": "string"
+ },
+ "documentSeed": {
+ "description": "Per-document PRNG seed actually used.",
+ "type": "number"
+ },
+ "result": {
+ "description": "The generated document; shape depends on the template body. Absent while pending/failed."
+ },
+ "seqNo": {
+ "description": "0-based index of this document within its alias group.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "status": {
+ "description": "Per-document generation status.",
+ "enum": [
+ "pending",
+ "completed",
+ "failed"
+ ],
+ "type": "string"
+ },
+ "templateId": {
+ "description": "Template used to generate this document.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "batchId",
+ "alias",
+ "seqNo",
+ "templateId",
+ "status"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "error": {
+ "additionalProperties": false,
+ "description": "Present if the whole batch failed.",
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "seed": {
+ "description": "PRNG seed used for the whole batch.",
+ "type": "number"
+ },
+ "spec": {
+ "description": "The original BatchSpec request body this batch was created from."
+ },
+ "status": {
+ "description": "Current batch status.",
+ "enum": [
+ "queued",
+ "running",
+ "completed",
+ "failed"
+ ],
+ "type": "string"
+ },
+ "tenantId": {
+ "description": "Owning tenant id.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "batchId",
+ "status"
+ ],
+ "type": "object"
+}jsonfabrica_get_sequence2 fields changedInput schema / properties / name / descriptionAdded value: +"Exact name of the sequence to fetch, as given at creation. Required."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "createdAt": {
+ "description": "ISO-8601 creation timestamp.",
+ "type": "string"
+ },
+ "currentValue": {
+ "description": "Current stored counter value (unused by \"uuid\" sequences).",
+ "type": "number"
+ },
+ "name": {
+ "description": "Sequence name.",
+ "type": "string"
+ },
+ "start": {
+ "description": "Initial value the sequence was created with.",
+ "type": "number"
+ },
+ "step": {
+ "description": "Increment applied per bump (ignored for \"uuid\").",
+ "type": "number"
+ },
+ "tenantId": {
+ "description": "Owning tenant id.",
+ "type": "string"
+ },
+ "type": {
+ "description": "Value kind produced on each bump.",
+ "enum": [
+ "number",
+ "string",
+ "uuid"
+ ],
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "ISO-8601 last-update timestamp.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "tenantId",
+ "name",
+ "type",
+ "currentValue",
+ "createdAt",
+ "updatedAt"
+ ],
+ "type": "object"
+}jsonfabrica_get_template2 fields changedInput schema / properties / templateId / descriptionAdded value: +"ID of the template to fetch, as returned by create/list. Required."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "astCache": {
+ "anyOf": [
+ {
+ "items": {},
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Server-internal parsed-body cache; opaque to callers."
+ },
+ "body": {
+ "description": "Template body containing function-call placeholders.",
+ "type": "string"
+ },
+ "createdAt": {
+ "description": "ISO-8601 creation timestamp.",
+ "type": "string"
+ },
+ "description": {
+ "description": "Free-text description, if any was stored.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "description": "Template name.",
+ "type": "string"
+ },
+ "status": {
+ "description": "\"active\" unless soft-deleted via jsonfabrica_delete_template.",
+ "enum": [
+ "active",
+ "archived"
+ ],
+ "type": "string"
+ },
+ "tags": {
+ "description": "Tags stored on the template.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "templateId": {
+ "description": "Server-assigned template id.",
+ "type": "string"
+ },
+ "tenantId": {
+ "description": "Owning tenant id.",
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "ISO-8601 last-update timestamp.",
+ "type": "string"
+ },
+ "validated": {
+ "description": "Whether the body passed static template validation.",
+ "type": "boolean"
+ },
+ "warnings": {
+ "description": "Non-fatal validation warnings, if any.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "templateId",
+ "tenantId",
+ "name",
+ "body",
+ "status",
+ "createdAt",
+ "updatedAt"
+ ],
+ "type": "object"
+}jsonfabrica_get_usage1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "asOf": {
+ "description": "ISO-8601 timestamp the usage total was computed as of.",
+ "type": "string"
+ },
+ "tenantId": {
+ "description": "Tenant id the usage totals belong to.",
+ "type": "string"
+ },
+ "usageTotal": {
+ "description": "Cumulative metered usage units consumed by this tenant.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "tenantId",
+ "usageTotal",
+ "asOf"
+ ],
+ "type": "object"
+}jsonfabrica_health1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "service": {
+ "description": "Name of the responding service, e.g. \"svc-gateway\".",
+ "type": "string"
+ },
+ "status": {
+ "description": "Liveness indicator, e.g. \"ok\".",
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}jsonfabrica_list_function_weights1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "items": {
+ "description": "All configured function weights. The gateway itself returns a bare JSON array; it is wrapped under `items` here for `structuredContent` (the raw array is still what `content[0].text` shows).",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "functionName": {
+ "description": "Name of the generator function, e.g. \"getRandomFullName\".",
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "ISO-8601 timestamp of the last weight change.",
+ "type": "string"
+ },
+ "updatedBy": {
+ "description": "Tenant id that last changed the weight, if any.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "weight": {
+ "description": "Usage units consumed each time the function is invoked during generation.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "functionName",
+ "weight",
+ "updatedAt"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "items"
+ ],
+ "type": "object"
+}jsonfabrica_list_sequences3 fields changedInput schema / properties / cursor / descriptionAdded value: +"Opaque pagination cursor from a previous response's `nextCursor`. Optional; omit to fetch the first page. Not a page number or offset you construct yourself."Input schema / properties / limit / descriptionAdded value: +"Maximum number of sequences to return in this page. Optional; defaults to 20 when omitted. Values <= 0 or > 100 are not clamped — the request is rejected with a 400 validation error."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "items": {
+ "description": "Page of matching sequences.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "createdAt": {
+ "description": "ISO-8601 creation timestamp.",
+ "type": "string"
+ },
+ "currentValue": {
+ "description": "Current stored counter value (unused by \"uuid\" sequences).",
+ "type": "number"
+ },
+ "name": {
+ "description": "Sequence name.",
+ "type": "string"
+ },
+ "start": {
+ "description": "Initial value the sequence was created with.",
+ "type": "number"
+ },
+ "step": {
+ "description": "Increment applied per bump (ignored for \"uuid\").",
+ "type": "number"
+ },
+ "tenantId": {
+ "description": "Owning tenant id.",
+ "type": "string"
+ },
+ "type": {
+ "description": "Value kind produced on each bump.",
+ "enum": [
+ "number",
+ "string",
+ "uuid"
+ ],
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "ISO-8601 last-update timestamp.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "tenantId",
+ "name",
+ "type",
+ "currentValue",
+ "createdAt",
+ "updatedAt"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "nextCursor": {
+ "description": "Pass to `cursor` on the next call; absent on the last page.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "items"
+ ],
+ "type": "object"
+}jsonfabrica_list_templates6 fields changedInput schema / properties / cursor / descriptionAdded value: +"Opaque pagination cursor taken verbatim from a previous response's `nextCursor`. Optional; omit to fetch the first page."Input schema / properties / limit / descriptionAdded value: +"Maximum number of templates to return in this page. Optional; defaults to 20 when omitted. Values <= 0 or > 100 are not clamped — the request is rejected with a 400 validation error."Input schema / properties / name / descriptionAdded value: +"Filters to templates whose `name` contains this text — a case-insensitive substring match, not an exact match. Optional; omit to match templates of any name."Input schema / properties / status / descriptionAdded value: +"`active` returns only non-deleted templates, `archived` returns only soft-deleted ones. Optional; defaults to `active` when omitted (archived templates are excluded unless requested)."Input schema / properties / tags / descriptionPrevious value: -"Comma-separated list of tags, e.g. \"orders,email\"."New value: +"Comma-separated list of tags, e.g. \"orders,email\". AND-match: a template must contain every listed tag to be included (not \"any of\"). Optional; omit to ignore tags entirely."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "items": {
+ "description": "Page of matching templates.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "astCache": {
+ "anyOf": [
+ {
+ "items": {},
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Server-internal parsed-body cache; opaque to callers."
+ },
+ "body": {
+ "description": "Template body containing function-call placeholders.",
+ "type": "string"
+ },
+ "createdAt": {
+ "description": "ISO-8601 creation timestamp.",
+ "type": "string"
+ },
+ "description": {
+ "description": "Free-text description, if any was stored.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "description": "Template name.",
+ "type": "string"
+ },
+ "status": {
+ "description": "\"active\" unless soft-deleted via jsonfabrica_delete_template.",
+ "enum": [
+ "active",
+ "archived"
+ ],
+ "type": "string"
+ },
+ "tags": {
+ "description": "Tags stored on the template.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "templateId": {
+ "description": "Server-assigned template id.",
+ "type": "string"
+ },
+ "tenantId": {
+ "description": "Owning tenant id.",
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "ISO-8601 last-update timestamp.",
+ "type": "string"
+ },
+ "validated": {
+ "description": "Whether the body passed static template validation.",
+ "type": "boolean"
+ },
+ "warnings": {
+ "description": "Non-fatal validation warnings, if any.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "templateId",
+ "tenantId",
+ "name",
+ "body",
+ "status",
+ "createdAt",
+ "updatedAt"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "nextCursor": {
+ "description": "Pass to `cursor` on the next call to fetch the following page; absent on the last page.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "items"
+ ],
+ "type": "object"
+}jsonfabrica_update_function_weight3 fields changedInput schema / properties / functionName / descriptionAdded value: +"Exact name of the generator function to reweight, e.g. \"getRandomFullName\" or \"getRandomNumber\" (must match a name already returned by jsonfabrica_list_function_weights — unknown names return 404). Required."Input schema / properties / weight / descriptionAdded value: +"New billing weight for this function: the number of usage units consumed each time the function is invoked during generation (metered to Stripe as \"weight-units-consumed\", additive across a document's generated calls — it is not a percentage or ratio relative to other functions). Platform defaults are 10 for most generator functions, except createSeq, getSeq, and getContext, which default to 1000. Must be a positive finite number (<= 0, NaN, or Infinity are rejected with a 400 validation error). Required — this call always replaces the current weight, there is no partial/omitted-field behaviour."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "functionName": {
+ "description": "Name of the generator function, e.g. \"getRandomFullName\".",
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "ISO-8601 timestamp of the last weight change.",
+ "type": "string"
+ },
+ "updatedBy": {
+ "description": "Tenant id that last changed the weight, if any.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "weight": {
+ "description": "Usage units consumed each time the function is invoked during generation.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "functionName",
+ "weight",
+ "updatedAt"
+ ],
+ "type": "object"
+}jsonfabrica_update_sequence4 fields changedInput schema / properties / currentValue / descriptionAdded value: +"Resets the sequence's current counter value to this number, without changing `step`. Optional; if omitted, the current value is left unchanged (unless `step` is also provided, in which case only `step` changes)."Input schema / properties / name / descriptionAdded value: +"Exact name of the sequence to update. Required."Input schema / properties / step / descriptionAdded value: +"Changes the increment applied by future jsonfabrica_bump_sequence calls; must be a non-zero finite number (negative allowed, to count down). Optional; if omitted, the existing step is left unchanged."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "createdAt": {
+ "description": "ISO-8601 creation timestamp.",
+ "type": "string"
+ },
+ "currentValue": {
+ "description": "Current stored counter value (unused by \"uuid\" sequences).",
+ "type": "number"
+ },
+ "name": {
+ "description": "Sequence name.",
+ "type": "string"
+ },
+ "start": {
+ "description": "Initial value the sequence was created with.",
+ "type": "number"
+ },
+ "step": {
+ "description": "Increment applied per bump (ignored for \"uuid\").",
+ "type": "number"
+ },
+ "tenantId": {
+ "description": "Owning tenant id.",
+ "type": "string"
+ },
+ "type": {
+ "description": "Value kind produced on each bump.",
+ "enum": [
+ "number",
+ "string",
+ "uuid"
+ ],
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "ISO-8601 last-update timestamp.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "tenantId",
+ "name",
+ "type",
+ "currentValue",
+ "createdAt",
+ "updatedAt"
+ ],
+ "type": "object"
+}jsonfabrica_update_template6 fields changedInput schema / properties / body / descriptionAdded value: +"New template body (function-call placeholder syntax), replacing the existing one entirely. Optional; omit to leave the current body unchanged."Input schema / properties / description / descriptionAdded value: +"New free-text description, replacing the existing one. Optional; omit to leave it unchanged."Input schema / properties / name / descriptionAdded value: +"New template name. Optional; omit to leave the current name unchanged."Input schema / properties / tags / descriptionAdded value: +"New full set of tags, replacing (not merging with) the existing tags. Optional; omit to leave the current tags unchanged; pass an empty array to clear all tags."Input schema / properties / templateId / descriptionAdded value: +"ID of the template to update. Required."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "astCache": {
+ "anyOf": [
+ {
+ "items": {},
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Server-internal parsed-body cache; opaque to callers."
+ },
+ "body": {
+ "description": "Template body containing function-call placeholders.",
+ "type": "string"
+ },
+ "createdAt": {
+ "description": "ISO-8601 creation timestamp.",
+ "type": "string"
+ },
+ "description": {
+ "description": "Free-text description, if any was stored.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "description": "Template name.",
+ "type": "string"
+ },
+ "status": {
+ "description": "\"active\" unless soft-deleted via jsonfabrica_delete_template.",
+ "enum": [
+ "active",
+ "archived"
+ ],
+ "type": "string"
+ },
+ "tags": {
+ "description": "Tags stored on the template.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "templateId": {
+ "description": "Server-assigned template id.",
+ "type": "string"
+ },
+ "tenantId": {
+ "description": "Owning tenant id.",
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "ISO-8601 last-update timestamp.",
+ "type": "string"
+ },
+ "validated": {
+ "description": "Whether the body passed static template validation.",
+ "type": "boolean"
+ },
+ "warnings": {
+ "description": "Non-fatal validation warnings, if any.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "templateId",
+ "tenantId",
+ "name",
+ "body",
+ "status",
+ "createdAt",
+ "updatedAt"
+ ],
+ "type": "object"
+}jsonfabrica_whoami1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "role": {
+ "description": "Role associated with the configured API key.",
+ "enum": [
+ "admin",
+ "user"
+ ],
+ "type": "string"
+ },
+ "tenantId": {
+ "description": "Tenant id resolved from the configured API key.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "tenantId",
+ "role"
+ ],
+ "type": "object"
+}v0.1.4jsonfabrica_bump_sequencejsonfabrica_create_batchjsonfabrica_create_sequencejsonfabrica_create_templatejsonfabrica_delete_sequencejsonfabrica_delete_templatejsonfabrica_generate_adhocjsonfabrica_generate_from_templatejsonfabrica_get_batchjsonfabrica_get_sequencejsonfabrica_get_templatejsonfabrica_get_usagejsonfabrica_healthjsonfabrica_list_function_weightsjsonfabrica_list_sequencesjsonfabrica_list_templatesjsonfabrica_update_function_weightjsonfabrica_update_sequencejsonfabrica_update_templatejsonfabrica_whoamiScored across 18 tools
Each tool maps cleanly to a distinct resource and action: template CRUD, sequence CRUD/bump, adhoc vs persisted generation, batch create/poll, and service introspection. The few close pairs like generate_adhoc vs generate_from_template are explicitly differentiated by whether the template is persisted.
Tools consistently use the jsonfabrica_ prefix and mostly follow a verb_noun pattern (create_template, list_templates, get_sequence, delete_template). Minor exceptions are jsonfabrica_health and jsonfabrica_whoami, which are noun/command style rather than get_health/get_identity.
Eighteen tools is slightly above the typical ideal range, but each tool maps to a meaningful operation and there is no obvious redundancy. The size is justified by the multiple resource domains: templates, sequences, batches, and account introspection.
Template and sequence lifecycles are well covered with CRUD plus generation and bump operations, and batch create/poll coverage exists. However, the descriptions repeatedly mention durable variables with namespaces but provide no variable management tools, and archived templates cannot be restored to active.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server (stdio): validate JSON against JSON Schema (draft-07 / 2020-12) via the AgentForge API
Hosted MCP endpoint with realistic fake data for prototyping agents. 12 tools, no setup.
