Skip to main content
Glama
Sign In
skylight-mcp

skylight-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

skylight_list_chores

Read-only

Retrieve chores for a Skylight frame within a required date range, including assignee and completion details to review family tasks for a specific period.

Instructions

List chores for a Skylight frame within a required date range. Each chore carries its assignee in category_id (a family-member category — resolve names via skylight_list_categories) and, for a completed up-for-grabs chore, who did it in completed_category_id. Either key is pluralised — category_ids / completed_category_ids — when the API links several members, so an absent singular key means unassigned, never multi-assigned.

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": {
      "after": "<after>",
      "before": "<before>"
    },
    "name": "skylight_list_chores"
  }
}

Input Schema

NameRequiredDescriptionDefault
viewNo"full" (default) returns the flattened chores; "brief" returns one line per chore — title — <date[Ttime], or "no date"> — <status> — inside the untrusted-data envelope, "-- none" when the range is empty.
afterYesYYYY-MM-DD inclusive lower bound (required by the API).
beforeYesYYYY-MM-DD inclusive upper bound (required by the API).
frameIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.0
    • addedInput schema / properties / view
      Added value: +{
+  "description": "\"full\" (default) returns the flattened chores; \"brief\" returns one line per chore — title — <date[Ttime], or \"no date\"> — <status> — inside the untrusted-data envelope, \"-- none\" when the range is empty.",
+  "enum": [
+    "full",
+    "brief"
+  ],
+  "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. First observedv0.4.6

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description goes beyond that by explaining the assignee encoding in the response — singular key means unassigned, pluralised keys mean multiple members — which is real behavioral context an agent would otherwise get wrong.

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-loaded with purpose and scope in the first sentence, then a compact second sentence carrying the non-obvious ID semantics. The second sentence is dense but every clause (singular vs plural, unassigned vs multi-assigned) earns its place.

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?

There is no output schema, so the description correctly spends its budget explaining the returned chore shape and assignee keys. It is nearly complete for a read-list tool; only the absence of pagination/limit behavior and frameId meaning leaves a small gap.

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 75%, with view/after/before already documented in the schema; frameId is undocumented in both. The description's semantic detail concerns response keys (category_id / completed_category_id), not the input parameters, so it adds little input-side meaning beyond the required-range note.

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+resource ('List chores for a Skylight frame') with a scope constraint (required date range), which is unambiguous. It does not differentiate itself from the close sibling skylight_search_chores, so the agent must infer which of the two listing paths to use.

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?

Usage context is implied by the required date-range scope, and it points to skylight_list_categories for resolving assignee names, which is genuinely useful. It never says when to prefer this over skylight_search_chores or whether it paginates/limits results.

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