dForms

Revert to the previous version

revert_form

Destructive

Roll back a publish: put the previously published version of a form back live, changing what respondents see now; the version it replaces becomes the previous one, so calling it twice undoes the revert. It is not the way to undo edits that were saved but not published (the user says "undo my changes" while has_unpublished_draft is true): it leaves that draft as it is and takes the current live version down, while discard_draft drops the draft. A pending draft and the destinations are left as they are. Works only when get_form shows previous_published_at; otherwise it answers NOTHING_TO_REVERT. It changes the live form, so it is best confirmed with the user first.

Tool call template

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

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "form_id": "<form_id>"
    },
    "name": "revert_form"
  }
}

Input Schema

Name	Required	Description	Default
`form_id`	Yes	The form id, from list_forms or get_form.
`workspace_id`	No	The workspace this call acts in: an id from list_my_workspaces. Required for a person signed in with several workspaces and for staff of this deployment; optional with an API key or with only one workspace.

Output Schema

Name	Required	Description
`form`	Yes
`workspace`	Yes	The workspace this call acted in, to compare with the one the user means.
`last_published_at`	Yes	When publish_form last made a draft live. Null when publish_form never ran: the form serves what it was created with, which is an empty form when is_live is false.
`previous_published_at`	Yes	When the version revert_form would bring back went live. Null when there is nothing to revert to.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations, the description explains exactly what changes: the live form is replaced with the previous published version, the replaced version becomes the previous one, and calling twice undoes the revert. It also discloses that a pending draft and destinations remain untouched, that failure returns NOTHING_TO_REVERT, and that user confirmation is advisable because the live form changes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core action is front-loaded in the first clause, and nearly every sentence adds necessary scope, sibling disambiguation, or precondition information. The middle sentence about unpublished drafts is slightly dense and could be clearer, but overall the description is appropriately sized for a destructive tool with non-obvious semantics.

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

Completeness5/5

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

Given the destructive mutation, the existing output schema, and rich annotations, the description covers the remaining essentials: side effects, precondition, error response, unaffected artifacts, reversal semantics, and confirmation advice. An agent has enough context to invoke the tool correctly and safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% description coverage, including form_id and workspace_id, so the structured input already carries parameter meaning. The description adds no additional parameter-level detail such as format or sourcing beyond what the schema provides, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: roll back a publish by putting the previously published form version live. It explicitly distinguishes this action from undoing unpublished edits and names discard_draft as the alternative for draft removal, so an agent can identify it without opening another schema.

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

Usage Guidelines5/5

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

It gives explicit when-to-use guidance, including the precondition that get_form must show previous_published_at. It also states when not to use it, specifically for undoing saved-but-unpublished edits, and names discard_draft as the correct tool in that case.

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

All dForms tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?