Skip to main content
Glama

set_archive_rule_active

Idempotent

Activate or deactivate an archive rule. Activation requires confirmation and an active Data Management Policy. [Write]

Instructions

Activate or deactivate an archive rule. Activation requires confirmation and an active Data Management Policy. [Write]

Input Schema

NameRequiredDescriptionDefault
activeYes
sys_idYes
confirmationNoRequired when activating: I_UNDERSTAND

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.15.1

TDQS

A3.7/5.0
Behavior4/5

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

Annotations establish write/idempotent/non-destructive/open-world, so the description doesn't need to re-declare safety. It adds genuine extra context the annotations lack: the confirmation gate and the dependency on an active Data Management Policy, which materially affects whether a call will succeed. It stops short of saying what error surfaces when the policy is inactive.

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?

Two compact sentences plus a write tag; the action is front-loaded and every clause carries information (permission gate, policy prerequisite). Slightly terse for a mutation, but no filler.

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?

For a simple two-state toggle with annotations covering the safety profile and the schema specifying the confirmation value, the description supplies the key prerequisites an agent needs. Missing only failure-mode detail, which is minor given no output schema.

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 coverage is only 33% (only `confirmation` is described, with the 'I_UNDERSTAND' value). The description ties confirmation to the activate case but adds nothing about `sys_id` or the `active` boolean beyond what the parameter names imply, so it does not fully compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb pair (activate/deactivate) and resource (archive rule), which is far better than a generic 'update'. The distinct name and the sibling set (create_archive_rule, set_destroy_rule_active, set_cleanup_rule_active) make the target obvious, though the description never explicitly names those siblings to route away from them.

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

Usage Guidelines3/5

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

It surfaces two real preconditions for the activate path — confirmation and an active Data Management Policy — which is useful context for choosing to call it. However, it gives no guidance on the deactivate path's requirements or on when to pick this over set_destroy_rule_active/set_cleanup_rule_active, leaving usage largely implied by the name.

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

Deploy Server

Other Tools