Skip to main content
Glama
Sign In
Archiware MCP

Archiware MCP

by mnott
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

plan_event

Adds a scheduled backup event to a backup plan by defining pool, level, frequency, and first run; requires confirm:true to apply.

Instructions

Adds an event (schedule entry: pool + level + frequency + first run) to a backup plan. Level 1 full, 0 incremental, -1 synthetic. Frequency tokens: "D n" | "W n days..." | "M n week day". firstrun is ISO local time the local time zone, e.g. 2026-11-07T02:00. Requires confirm:true.

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": {
      "plan": "<plan>",
      "pool": "<pool>",
      "level": "<level>",
      "frequency": "<frequency>",
      "firstrun": "<firstrun>"
    },
    "name": "plan_event"
  }
}

Input Schema

NameRequiredDescriptionDefault
planYesPlan id
poolYesPool name the event writes into
levelYes1 full, 0 incremental, -1 synthetic
confirmNoMust be true to actually run
firstrunYesISO local time, e.g. 2026-11-07T02:00
exceptionNoOptional exception tokens, same format as frequency
frequencyYesTokens, e.g. ["M","1","1","6"]

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the disclosure burden. It makes clear this is a mutating add operation and flags the confirm:true requirement, but it does not state permission needs, whether existing events are affected, or what happens on duplicate or overlapping schedules.

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?

The description is dense but front-loaded: it identifies the action first, then the event fields, then the token syntax and confirmation requirement. Minor redundancy exists because level values and firstrun format are also present in the schema.

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

Completeness3/5

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

Given seven parameters, five required, and no annotations, the description covers the core event semantics and mutation prerequisite reasonably well. It does not describe permissions, side effects, or the result of the operation, and with no output schema those behavioral gaps remain relevant.

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 already 100%, so the baseline is 3. The description adds value beyond the schema by explaining the frequency token grammar (D/W/M forms) and the firstrun local-time format, which the schema only illustrates with a bare example.

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?

The description states a specific verb and resource: it adds a schedule event to a backup plan, and it enumerates the event fields (pool, level, frequency, first run). This distinguishes it from plan-level tools, but it does not explicitly contrast with siblings such as dryrun_plan or create_plan.

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 gives a key prerequisite, confirm:true, which tells the agent the call only takes effect under that condition. However, it does not say when to prefer this over dryrun_plan, or when an event should be added to an existing plan versus creating a new one.

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