Skip to main content
Glama
chrischall

skylight-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

skylight_upload_photo

Destructive

Upload a local photo or video to your Skylight frame so it appears in the slideshow. Confirms before uploading to ensure only approved files are sent.

Instructions

Upload a photo or video from a local file to the Skylight frame (it appears in the slideshow). Two-step: signs an S3 upload with temporary credentials, then registers it as a frame message. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). The preview echoes the resolved absolute image_path, detected mime, size and caption, and nothing is read or uploaded until it is confirmed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
captionNoCaption shown with the photo.
frameIdNo
frame_idsNoFrame ids to post to; defaults to the resolved frame.
image_pathYesAbsolute path to a local image/video file (jpg, jpeg, png, heic, gif, webp, mp4, mov; max 200 MiB). Anything else — or a symlink, or a file whose contents do not match its extension — is refused.
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.

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.1.3
    • changedInput schema / properties / image_path / description
      Previous value: -"Absolute path to a local image/video file (jpg, png, heic, mp4, …)."New value: +"Absolute path to a local image/video file (jpg, jpeg, png, heic, gif, webp, mp4, mov; max 200 MiB). Anything else — or a symlink, or a file whose contents do not match its extension — is refused."
  3. 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"
  4. Changed2 schema fields changedv0.7.1
    • removedInput schema / properties / frame_ids / items / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  }
-]
    • addedInput schema / properties / frame_ids / items / type
      Added value: +[
+  "string",
+  "number"
+]
  5. First observedv0.4.6

TDQS

A4.4/5.0
Behavior5/5

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

The description goes well beyond the annotations by disclosing the full two-step confirmation flow: S3 upload with temporary credentials first, then registration as a frame message, and 'nothing is read or uploaded until it is confirmed.' It also explains the preview-and-confirmToken fallback. This is rich, helpful behavioral disclosure that the annotations alone do not provide.

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?

The description is dense but every sentence earns its place: the core action, the two-step mechanism, the confirmation behavior, and the preview contents. It is front-loaded with the primary purpose and uses a clear progression. Despite the complexity of the flow, the description remains compact and well-organized.

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?

Given the lack of an output schema, the description does a good job explaining what the first call returns ('a preview and a confirmToken') and the overall confirmation flow. The only notable gap is that the final success response after the confirmed call is not described, which an agent might need to know without an output schema. Overall, it is still a complete and actionable definition.

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 description coverage is 80%, and the schema already documents image_path, caption, frame_ids, and confirmToken in detail. The description adds some context about the preview echoing the resolved image_path and caption, but mostly restates or summarizes the schema. It does not materially clarify frameId vs. frame_ids, so the 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?

The description opens with a specific verb and resource: 'Upload a photo or video from a local file to the Skylight frame (it appears in the slideshow).' This unambiguously states what the tool does and differentiates it from siblings like skylight_import_events_from_photo or skylight_add_to_album. No ambiguity remains about the tool's core function.

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?

The description clearly establishes when to use the tool: when a local photo/video should be pushed to a Skylight frame's slideshow. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5. The context is still concrete enough for an agent to select this tool over the many siblings.

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