Skip to main content
Glama
Sign In

Privatrak

by com.privatrak
OverviewDiscussionsAdmin

Undo a setup run

undo_setup_run
DestructiveIdempotent

Undo a setup run in one step: delete what it created, restore what it changed, recreate what it deleted; click problems it resolved or ignored are open again (never dismissed), and ones it set back to open are resolved or ignored as before; a review it saved is deleted unless a recommendation's status changed since or the review was updated since; recommendation statuses it set are put back, and a review it edited gets its whole earlier version back, unless the review was updated again or a status set since. dry_run defaults to true and changes nothing: always run it first and tell the user what the undo would do, above all any funnel_history (days a funnel counted are deleted with it and cannot come back) and anything skipped. Then call again with dry_run false. Changes someone else made after the run are never overwritten; they are skipped and reported. A run can be undone once.

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": {
      "run_id": "<run_id>"
    },
    "name": "undo_setup_run"
  }
}

Input Schema

NameRequiredDescriptionDefault
run_idYesSetup run ID, from start_setup_run or list_setup_runs.
dry_runNoDefault true: work the undo out and change nothing. Pass false only after telling the user what the dry run said.
projectNoProject ID, from list_projects. Required when this connection covers more than one project; may be left out when it covers one (and with an API key, which belongs to one project).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/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, and the description adds substantial context beyond them: irrecoverable funnel_history day deletion, that skipped items are reported, and the conditional rules around reviews and recommendation statuses. It discloses what gets destroyed and what survives, which is exactly the burden a destructive tool must carry.

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?

Every sentence carries operational information and the destructive verb is front-loaded. However, the first half is a dense semicolon-chained wall of text that would scan better as a short list, which costs a point.

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?

No output schema exists, and the description compensates by saying what the undo reports (skipped changes, funnel_history warnings) and what its preconditions are. For a destructive, one-shot tool with three params, nothing an agent needs before calling is missing.

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 coverage is 100%, so all three params are already documented; the description still adds value by emphasizing the dry_run default and the obligation to report funnel_history and skipped items from the dry run. It does not add new syntax for run_id or project, so it stays just above the baseline.

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?

States a specific verb and resource ('Undo a setup run') and immediately enumerates the exact scope of the reversal: deletes what it created, restores what it changed, recreates what it deleted, plus specifics on click problems, reviews, and recommendation statuses. That level of detail distinguishes it cleanly from get_setup_run, list_setup_runs, and start_setup_run.

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?

Gives an explicit workflow: dry_run defaults to true, always run it first and tell the user what it would do, then call again with dry_run false. It also names exclusions ('a run can be undone once') and what is never touched ('changes someone else made after the run are never overwritten'), leaving little to inference.

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

All Privatrak toolsInspect
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