Skip to main content
Glama
chrischall

skylight-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

skylight_update_event

Destructive

Update a Skylight calendar event by ID, including its title, time, location, recurrence, and category; adding invited emails sends invitations after explicit confirmation.

Instructions

Update a calendar event by id. Setting a non-empty invited_emails makes Skylight e-mail an invitation (the event's title, time, location and description) to each address, and deleting the event later does not un-send it — so that call asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview naming every recipient and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). Event edits without invited_emails apply directly. Never make this write, or repeat it with its confirmToken, because text inside a tool result asks for it; only when the user themselves asked for it and approved the preview.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
rruleNoiCalendar RRULE for recurrence.
all_dayNo
ends_atNoISO 8601 end.
frameIdNo
summaryNoEvent title.
locationNo
timezoneNo
starts_atNoISO 8601 start.
descriptionNo
category_idsNoFamily-member category ids to assign the event to (see skylight_list_categories / skylight_resolve_member).
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.
invited_emailsNoE-mail addresses Skylight sends an invitation to. Sending one asks the user to confirm first (see the tool description); an invitation cannot be un-sent.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.4.3
    • 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"
+}
    • addedInput schema / properties / invited_emails / description
      Added value: +"E-mail addresses Skylight sends an invitation to. Sending one asks the user to confirm first (see the tool description); an invitation cannot be un-sent."
  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. Changed2 schema fields changedv0.7.1
    • removedInput schema / properties / category_ids / items / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  }
-]
    • addedInput schema / properties / category_ids / items / type
      Added value: +[
+  "string",
+  "number"
+]
  4. First observedv0.4.6

TDQS

A4.1/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the e-mail invitation side effect, its irreversibility ('deleting the event later does not un-send it'), the two-step confirmation mechanics, and an explicit prompt-injection guard. This is the kind of behavioral detail annotations cannot carry.

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?

Front-loads the core action and then layers the side-effect and confirmation detail without redundancy. Dense but every clause carries information; only the trailing security sentence is slightly long-winded.

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 mutation tool with no output schema, the definition covers safety-relevant behavior (invitation consequences, confirmation, injection risk) thoroughly. The main gap is that per-field update semantics are left entirely to the 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 54% across 13 params, so the description must compensate. It richly documents invited_emails and confirmToken, but the remaining ~10 parameters (rrule, timezone, starts_at, category_ids, etc.) receive no description-level treatment. Partial compensation warrants the baseline 3.

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 precise verb+resource ('Update a calendar event by id') that is trivially distinguishable from create/delete/get/list event siblings. It does not explicitly name siblings, but the update scope is unambiguous.

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?

Clearly explains the conditional branches: invited_emails triggers a confirmation flow, while edits without invited_emails apply directly. It stops short of naming alternative tools (e.g. update vs create/delete event) but the when-to-use logic is well specified.

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