dForms

Publish a form

publish_form

DestructiveIdempotent

Make the form's unpublished draft live at its public_url, replacing what respondents see now. The replaced version is kept: revert_form brings it back. With no draft pending this changes nothing and says so (nothing_published true), so a retry after a timeout is safe. Returns the public_url to give the user.

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": "publish_form"
  }
}

Input Schema

Name	Required	Description
`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.
`expected_updated_at`	No	Recommended: the updated_at from your last update_form, so you publish exactly the draft you reviewed.

Output Schema

Name	Required	Description
`form`	Yes
`warnings`	No	What did not go exactly as sent, or what the user needs to know.
`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.
`nothing_published`	No	True when no draft was pending, so nothing changed: what is live stays live (an earlier publish_form may already have gone through).
`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.4/5.0

Behavior5/5

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

The annotations already state destructiveHint=true and idempotentHint=true, and the description corroborates both instead of merely repeating them. It adds the reversibility mechanism ('The replaced version is kept: revert_form brings it back'), the exact no-op signal (nothing_published true), and the returned public_url. That is real behavioral context beyond the structured fields.

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

Conciseness5/5

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

Three sentences, each doing work: the effect is front-loaded, then reversibility, then the safe-retry semantics and the return value. There is no filler and nothing is repeated from the title.

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

Completeness4/5

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

With an output schema present, the description need not detail the response, though it usefully says it returns public_url. Annotations cover the safety profile, and the description covers reversibility and retry safety. It could say more about how this relates to the other draft-related siblings, but it is complete enough to call correctly.

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?

Schema description coverage is 100%, so all three parameters (form_id, workspace_id, expected_updated_at) are already well documented, including the recommendation to pass expected_updated_at for optimistic concurrency. The description adds nothing parameter-specific, so the baseline of 3 applies.

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 concrete verb and effect: it makes the form's unpublished draft live at its public_url, replacing what respondents currently see. It also names the counterpart operation (revert_form) that restores the replaced version, which lets an agent distinguish it from update_form or discard_draft without opening other schemas.

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

Usage Guidelines4/5

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

It gives clear conditions for calling it and for calling the alternative: publish makes the draft live, revert_form brings the previous version back. It also explains the no-op case, 'With no draft pending this changes nothing and says so', which tells the agent the call is safe to retry. It stops short of saying when to discard a draft instead of publishing it.

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?