Skip to main content
Glama
dwooods
by dwooods

create_list

Create a new shopping or to-do list in Skylight with a required name and list type, plus an optional color. Use it to organize groceries or tasks.

Instructions

Create a new list in Skylight.

Use this when:

  • Creating a new shopping/grocery list

  • Creating a new to-do list

Parameters:

  • label (required): Name of the list (e.g., "Vacation Packing", "Weekly Groceries")

  • kind (required): "shopping" for grocery/shopping lists, "to_do" for task lists

  • color: Optional color for the list

Returns: The created list details.

Input Schema

NameRequiredDescriptionDefault
kindYesType of list: 'shopping' or 'to_do'
colorNoOptional color for the list
labelYesName of the list (e.g., 'Vacation Packing')

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.4.1

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare the write, non-destructive, closed-world profile, so the safety bar is lower. The description adds a returns line and the kind semantics, but says nothing about permissions, duplicate-list behavior, or whether the list is shared with family members — meaningful gaps for a creation tool.

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 verb+resource sentence, then scannable bullets and a parameter list — well structured and short. Some content duplicates the schema descriptions verbatim, which costs a little efficiency but not comprehension.

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?

With no output schema, the 'Returns: The created list details' line usefully closes the loop, and all three parameters are covered. What's missing is context about where the created list appears (Skylight device/family scope), which an agent might need to confirm success.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description goes slightly beyond by spelling out what 'shopping' versus 'to_do' means in practice and giving realistic label examples. The color parameter is only restated, not elaborated.

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?

States a specific verb and resource ('Create a new list in Skylight') and immediately narrows scope to the two supported list types. The create verb cleanly separates it from sibling tools get_lists, update_list, and delete_list.

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 'Use this when' bullets give concrete trigger conditions (shopping/grocery list, to-do list) that map directly to the two kind values. It does not name alternatives or exclusions (e.g., how this differs from update_list), but the context is clear enough to act on.

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