Skip to main content
Glama

fofa_schedule_delete

DestructiveIdempotent

Cancel an active scheduled scan and remove it from management while retaining its history and reports in the archive; use only for explicit deletion requests.

Instructions

Delete a schedule from active management; cancel its run and retain history/reports in the index archive.

Only call when the user explicitly requests deletion. Deleted tasks cannot be resumed or edited.

Input Schema

NameRequiredDescriptionDefault
schedule_idYes

Output Schema

NameRequiredDescriptionDefault
dataNo
summaryYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.2

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, so safety is covered. The description adds valuable context beyond that: the run is cancelled, history/reports are retained in the archive, and the task cannot be resumed or edited. It does not mention permissions or auth requirements, but for a low-complexity delete that is a minor gap.

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?

Two short sentences, front-loaded with the action and its effect, followed by the call condition. No wasted words.

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?

An output schema exists, so return values need no explanation, and the behavior around deletion, retention, and irreversibility is well covered. The remaining gap is the undocumented schedule_id, which matters for correct invocation but is the sole omission.

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

Parameters2/5

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

Schema description coverage is 0% and the single parameter (schedule_id) is never mentioned in the description. The agent gets no guidance on where to obtain the id or what format it takes, so the description fails to compensate for the undocumented schema.

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 and resource ('Delete a schedule') plus scope ('from active management') and a distinguishing behavioral note (history/reports retained in the archive). It does not name a sibling to contrast with, but an agent can infer the difference from a mere stop/cancel.

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?

Explicitly says 'Only call when the user explicitly requests deletion,' which is a clear when-to-use guard. It does not mention alternatives such as fofa_schedule_stop or fofa_schedule_set_enabled for non-destructive lifecycle changes, so it falls short of full alternative routing.

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