dForms

Reset a notification email

reset_notification

DestructiveIdempotent

Put the default subject and body back on one workspace email. Whether it is sent, and its recipients, stay as they are. The custom copy is lost. Destructive: it deletes or replaces data, so it is best confirmed with the user first, naming exactly what will change. After an error or a timeout, a read shows whether the change went through, so a blind retry is not needed. Owners and admins only.

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": {
      "email_key": "<email_key>"
    },
    "name": "reset_notification"
  }
}

Input Schema

Name	Required	Description	Default
`email_key`	Yes	submission_received: the notice to the team. submission_confirmed: the receipt to the person who answered.
`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	Default
`setting`	Yes
`workspace`	Yes	The workspace this call acted in, to compare with the one the user means.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description goes well beyond them: it states exactly what is lost (custom copy), what is preserved (send status and recipients), that confirmation naming the exact change is advisable, and that a follow-up read resolves post-error ambiguity rather than a blind retry. It also discloses the authorization restriction (owners and admins only), which annotations do not cover.

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

Conciseness5/5

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

Five short sentences, each front-loaded with the most consequential fact first (the reset action, then what is preserved, then what is lost, then confirmation and recovery guidance, then permissions). No sentence is redundant or restates the title.

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

Completeness5/5

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

For a destructive mutation with only two parameters, the description covers the action, preserved versus lost state, confirmation practice, error/timeout recovery, and authorization. Return values are covered by the output schema, and safety traits are reinforced rather than duplicated from annotations.

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%, with the enum values and the workspace_id conditional requirement fully documented inline, so the schema carries the parameter burden. The description adds no meaning about email_key or workspace_id beyond what the schema already states, 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 opens with a specific verb and resource ('Put the default subject and body back on one workspace email') and immediately bounds the scope by stating what does not change (sent status, recipients). This makes it clearly distinguishable from the update-oriented siblings like update_notification without needing to name them.

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 use: resetting custom copy back to the default, restricted to owners and admins, and it advises confirming with the user beforehand. It stops short of explicitly naming the alternative tools (e.g. update_notification) an agent should use when it wants to change copy rather than restore defaults.

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?