Skip to main content
Glama
chrischall

skylight-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

skylight_delete_meal

Destructive

Remove a scheduled meal from your meal plan by deleting a single occurrence, this and future occurrences, or the entire series. Future and all deletions require confirmation to prevent accidental changes.

Instructions

Remove a planned meal (meal sitting) from the meal plan. Deletes one occurrence, this-and-future occurrences, or the whole series depending on apply_to. There is no undo. apply_to 'future' or 'all' asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview of exactly what would be deleted and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). apply_to 'one' deletes directly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesMeal sitting id (from skylight_list_meals).
frameIdNo
apply_toYesRecurrence scope: 'one' = just this occurrence (splits it out of the series), 'future' = this and all later occurrences (splits the tail into a new sitting), 'all' = the whole series.
confirmTokenNoONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 "confirmation-required" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.
instance_dateYesYYYY-MM-DD of the occurrence to act on — must be one of that sitting's `instances`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.3.0
    • removedInput schema / properties / confirm
      Removed value: -{
-  "description": "Must be true to proceed. Without this, the tool returns a preview.",
-  "type": "boolean"
-}
    • addedInput schema / properties / confirmToken
      Added value: +{
+  "description": "ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 \"confirmation-required\" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.",
+  "type": "string"
+}
  2. Changed1 schema field changedv1.0.1
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. Addedv0.8.1

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only flag destructiveHint=true and readOnlyHint=false; the description adds critical un-annotated behavior: 'There is no undo.' It fully discloses the two-step confirmation protocol — first call returns a preview plus confirmToken, only a repeat call with that token proceeds, token never invented/reused — and states that 'one' bypasses confirmation. This is exactly the kind of behavioral context an agent needs beyond the annotations.

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?

Four dense sentences with zero filler: what it deletes, the scope options, the no-undo warning, and the confirmation behavior. The operation is front-loaded in the first clause, and every subsequent sentence earns its place by covering a distinct, decision-relevant fact.

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 destructive, multi-mode tool with no output schema, the description covers the essentials: irreversibility, per-mode scope semantics, and the full confirmation/fallback protocol including the preview response. The only gap is that a successful direct-delete ('one') response shape is never hinted at, which is minor relative to the correctness-critical information already provided.

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 high (80%) and the schema already documents each parameter thoroughly, including the confirmToken's phase-1/phase-2 rules and apply_to's enum meanings. The description reinforces these by narrating how the modes map to the confirmation flow, but it adds little parameter-level meaning beyond what the schema already states, so the high-coverage baseline of 3 is appropriate.

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 and resource — 'Remove a planned meal (meal sitting) from the meal plan' — then immediately narrows the operation into its three recurrence scopes (one/future/all). This pins the tool to a distinct resource (meal sittings) versus siblings like skylight_delete_recipe, skylight_delete_event, or skylight_update_meal, with no ambiguity about what is being acted on.

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?

Provides clear, actionable context: apply_to 'one' deletes directly while 'future'/'all' require confirmation, and it explains the two distinct confirmation paths (client-supported elicitation vs. the preview+confirmToken fallback). It stops short of explicitly naming non-destructive alternatives (e.g., when to choose skylight_update_meal instead of deleting), so there is no explicit when-not-to-use guidance.

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