Samuelz® Policy

Unternehmensregeln · Inaktiv

deactivate_policy

Read-onlyIdempotent

Preview deactivation of an automation policy without saving or applying it. Use this only for an explicit stop; use prepare_policy_change for other replacements.

Read get_policy_write_options first. Choose canDeactivate=true and copy moduleKey, policyKey and expectedRevision from that same option. The revision identifies the complete current state, not a proposed value. Only standing-send permissions and public-post plans support deactivation.

The existing Owner card consumes the preview's exact nextAction.arguments. Only a human can confirm; models never call confirmation. Confirmation preserves other settings and history and keeps the disabled state current, preventing older permissions from resuming. Already inactive produces no card or new version; running or sent work is not cancelled.

Requires policy:read/write and current Owner/module authority. Invalid, stale, unsupported, unconfigured or inaccessible selections fail without persistence. After confirmation or uncertainty, read get_policy and get_policy_history; do not retry confirmation.

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": {
      "moduleKey": "<moduleKey>",
      "policyKey": "<policyKey>",
      "expectedRevision": "<expectedRevision>"
    },
    "name": "deactivate_policy"
  }
}

Input Schema

Name	Required	Description
`moduleKey`	Yes	Policy module key from the same supported get_policy_write_options result as policyKey and expectedRevision; never a tenant selector.
`policyKey`	Yes	Exact editable policy key from the same get_policy_write_options element as moduleKey and expectedRevision, with canDeactivate=true. Other policies and templates are unsupported.
`expectedRevision`	Yes	Opaque hash of the current complete state from that result, not a proposed-value hash or numeric history version. Stale state requires a fresh read and renewed intent.

Output Schema

Name	Required	Description
`after`	Yes	Validated explicit replacement during a preview; null during discovery. This value has not been saved.
`title`	Yes
`before`	Yes	Native current value, null when unconfigured. Read failures are errors, not empty configuration.
`effect`	Yes
`status`	Yes	Unpersisted human preview, or an attested current disabled value with no card or new version.
`proposed`	No	Optional native adapter guidance, possibly null; never requested intent or approval.
`tenantId`	Yes	Workspace already bound by the current grant, never a selectable destination.
`moduleKey`	Yes	Policy module key from the same supported get_policy_write_options result as policyKey and expectedRevision; never a tenant selector.
`policyKey`	Yes	Existing editable policy identifier from that same result; arbitrary new identities and templates are unsupported.
`nextAction`	No	Existing private human-card continuation. Does not itself apply the value.
`displayAfter`	No
`settingsPath`	Yes
`writesPolicy`	Yes
`canDeactivate`	Yes	True only when this native settings contract defines a safe disabled value. Use deactivate_policy for an explicitly requested stop; unconfigured policies still have nothing to deactivate. Other policy values and templates have no generic delete or enabled-field fallback.
`displayBefore`	No
`currentVersion`	Yes	Current verified numeric policy version, or null when unconfigured; not the write revision.
`activatesPolicy`	Yes
`expectedRevision`	Yes	Opaque hash of the current complete state from that result, not a proposed-value hash or numeric history version. Stale state requires a fresh read and renewed intent.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, and the description is fully consistent with a non-persisting preview. It adds substantial context beyond them: the Owner card consumes nextAction.arguments, models never call confirmation, confirmation preserves other settings and history, already-inactive produces no card, and running/sent work is not cancelled. It also discloses auth requirements (policy:read/write, Owner/module authority) and the full failure taxonomy without persistence.

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?

Purpose and the sibling exclusion are front-loaded, then prerequisites, constraints, confirmation semantics, and post-call behavior in a logical order. Dense but nearly every sentence carries a distinct constraint; a few clauses (e.g. the permissions/history preservation rationale) are more verbose than strictly needed.

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?

With an output schema present, return values need not be explained, and everything else an agent needs is covered: prerequisites, credential requirements, supported policy types, failure conditions, confirmation handoff to humans, and the correct follow-up reads on uncertainty.

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 the baseline is 3; the description earns above that by explaining that the three values must come from the same get_policy_write_options element, that canDeactivate=true selects it, and that expectedRevision is a hash of the complete current state rather than a proposed-value hash.

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?

Opens with a specific verb+resource+scope: 'Preview deactivation of an automation policy without saving or applying it.' It immediately distinguishes itself from prepare_policy_change, which handles 'other replacements', so an agent can route correctly without opening either 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?

Explicit when-to-use ('only for an explicit stop'), when-not (prepare_policy_change for other replacements), prerequisite ordering ('Read get_policy_write_options first'), the selection condition (canDeactivate=true), supported cases, and follow-up reads (get_policy, get_policy_history) with a 'do not retry confirmation' exclusion.

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

All Samuelz® Policy 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?