MIDAS CIVIL NX tools (MIDAS IT Europe)

Undo a patch-load run

point_to_patch_undo

Destructive

Undoes the latest point_to_patch_apply run (or the run named) with the plugin's cleanup: every PRES / BMLD row the run touched is put back as it was, the PATCH_ cases it removed are restored and the ones it created deleted. Previews unless apply: true.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "point_to_patch_undo"
  }
}

Input Schema

Name	Required	Description	Default
`apply`	No
`runId`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 28, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the destructiveHint annotation, it discloses exactly what gets restored and deleted: PRES/BMLD rows are put back, removed PATCH_ cases are restored, and created PATCH_ cases are deleted. It also states that the operation previews unless apply is true.

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

Conciseness5/5

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

The description is compact and front-loaded, leading with the undo action and scope before explaining cleanup details and the apply flag. Every clause adds useful information without repetition.

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 undo tool with annotations covering safety and no output schema, the description provides enough behavioral detail to invoke it correctly. It covers scope, cleanup effects, and preview-versus-execute behavior.

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

Parameters4/5

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

Schema description coverage is 0%, but the description compensates by explaining both parameters semantically: apply controls preview versus execution, and runId selects a specific run instead of the latest. It does not add runId format details, but the core meaning is clear.

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: it undoes the latest point_to_patch_apply run, or a named run, and names the exact cleanup scope. It clearly distinguishes itself from point_to_patch_apply and other siblings.

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 clearly situates usage after point_to_patch_apply and explains the default preview mode versus applying via apply: true. It does not explicitly name exclusions or alternatives, but the context is strong 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.

All MIDAS CIVIL NX tools (MIDAS IT Europe) 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?