skylight-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.8.1
Disambiguation2/5
Several tool clusters blur together: list_tasks vs list_lists/get_list_items, list_calendars vs list_source_calendars, delete_list_items/delete_list_item/clear_list, and list_auto_creation_drafts vs list_auto_creation_items require reading descriptions closely to avoid misselection. update_family_member vs update_category and add_webcal/link_apple_calendar/create_source_calendar add further boundary ambiguity. Despite some clarifying text, the overlap is pervasive enough that agents will frequently pick the wrong tool.
Naming Consistency4/5
Nearly all tools follow skylight_verb_noun snake_case, and most CRUD operations use a consistent list/get/create/update/delete pattern. Minor inconsistencies exist (list vs get, set vs update, singular vs plural variants like delete_list_item vs delete_list_items, plan_meal vs create_meal), but overall the naming is predictable and readable.
Tool Count1/5
At 113 tools this is an extreme count for an MCP server, even though Skylight is a broad product. Most agent-facing servers this size overwhelm prompt context and make selection harder. It falls clearly in the 50+ category and should be split into focused domain servers (calendar, chores, lists, meals, etc.).
Completeness4/5
The tool surface is remarkably broad and covers most lifecycle operations for calendars, events, chores, rewards, lists, meals, photos/albums, and AI auto-creation. Minor gaps exist (no get_album/get_chore/get_category, no generic text-message posting, no device removal), but agents can generally work around them with list/search and update tools.
Average 3/5 across 113 of 113 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 17 of 17 community issues answered or closed in the last 6 months
- 88 commits in the last 12 weeks
- Last stable release on September 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Redeem a reward' implies a state-changing action, but it does not explain side effects such as point deduction, reversibility, idempotency, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but under-specification is not effective conciseness. The single sentence restates the tool name and earns no place by adding operational or selection context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, no output schema, no annotations, and no usage guidance, a three-word description is completely inadequate. An agent cannot determine required inputs, expected effects, return values, or when this tool is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter-level meaning, and schema description coverage is only 33%. The required 'id' and optional 'frameId' are left undefined, and the description does nothing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description, 'Redeem a reward,' verbatim restates the tool name and adds no resource-specific meaning. It does not help an agent distinguish this tool from related siblings like skylight_unreedeem_reward or skylight_get_reward beyond the bare verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as unredeem_reward, get_reward, or add_reward_points. An agent is left to infer the appropriate context without any stated prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only says 'update' with no disclosure of side effects, permissions, or reversibility. Fails to describe mutation behavior beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but empty of useful content. Under-specification is not valuable conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 undocumented parameters, no output schema, and no annotations, the description is completely inadequate for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0%; description adds no meaning to the three parameters (frameId, disney_screensaver, disney_profile_pictures). Agent cannot infer their purpose or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description repeats tool name ('Update household configuration') without specifying what aspects of configuration can be updated. Fails to differentiate from siblings like skylight_update_frame or skylight_update_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to update household config vs other update tools. No context on prerequisites or alternatives among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and 'Update a reward' provides none. It does not disclose whether this is a partial or full update, whether omitted fields are left unchanged, what happens to existing redemptions or point values, or whether any permissions are required. This is effectively a restatement of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short at two words, which is concise but is under-specification rather than earned conciseness. It contains no substantive information that helps an agent select or invoke the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is an update/mutation tool with no annotations, no output schema, and no parameter documentation. The description gives no information about required id semantics, return values, error behavior, or update behavior, making it inadequate for correct invocation among many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the five parameters. The schema shows fields like id, name, frameId, point_value, and category_ids, but the description does not explain what each field represents, how they interact, or which are required beyond the schema's own constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Update a reward.' This distinguishes it at a basic level from create/delete/list/get reward tools, but it does not specify what fields or aspects of a reward are updated, and it does not differentiate it from reward lifecycle siblings like add_reward_points or redeem_reward.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as add_reward_points, redeem_reward, or update_chore. No context, prerequisites, or exclusions are provided, leaving the agent to infer usage entirely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only states 'update' without details on side effects, return values, or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but lacks necessary substance; it is underspecified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description provides almost no contextual information needed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no meaning to any of the 6 parameters; parameter names alone are insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'update a task-box item' which is a clear verb+resource, but it does not distinguish from sibling tools like skylight_create_task or skylight_delete_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; no prerequisites, exclusions, or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks any disclosure of behavioral traits like read-only nature, side effects, or permission requirements. Since no annotations are provided, the description carries the full burden, but it only states the action and resource without any behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 words) but at the cost of omitting essential information. It fails to earn its place by not providing enough context for an agent to use the tool effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and parameter descriptions, the description is highly incomplete. For a simple getter tool, at least the expected output or identifier usage should be mentioned. The current description minimally fulfills the basic function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not explain the meaning or usage of the 'id' or 'frameId' parameters. The description adds no value beyond the schema's structural definition.
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?
The description 'Get one meal recipe' clearly indicates the action (get) and the resource (meal recipe), distinguishing it from sibling tools like skylight_list_recipes (list all) and skylight_create_recipe (create). However, it does not explicitly state that the retrieval is by ID, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when to use a list or create tool. No context about prerequisites or typical use cases is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. It only states the basic action without revealing any behavioral traits such as side effects (e.g., notifications, frame assignment) or permissions required. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but it sacrifices necessary detail. It is not front-loaded with critical information; instead, it merely restates the tool's name. Conciseness should not come at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, two unannotated parameters, and a simple operation, the description is incomplete. It does not explain return values, error cases, or any side effects. For a tool that modifies state, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the purpose or constraints of the two parameters (title, frameId). It adds no meaning beyond the raw schema, leaving agents unaware of what values are acceptable or how they affect the album.
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?
The description 'Create a photo album' clearly states the verb and resource, indicating that this tool creates an album. However, it does not differentiate from sibling tools like skylight_add_to_album or skylight_update_album, which involve albums but serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., skylight_add_to_album for adding photos to an existing album). No context about prerequisites or usage scenarios is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It only states that deletion occurs, without disclosing consequences like whether it's permanent, if items are deleted, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is front-loaded but overly terse given the tool's complexity and lack of schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 2 parameters, no output schema, and many siblings, the description is incomplete. It doesn't mention return values, prerequisites, or what 'list' refers to.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, and the description provides no additional meaning, leaving parameters like listId and frameId unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete a Skylight list,' which provides a clear verb and resource. However, it does not differentiate from sibling tools like skylight_clear_list or skylight_delete_list_items, leaving ambiguity in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as skylight_clear_list or skylight_remove_from_album. No context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It fails to mention whether the tool is read-only, requires authentication, has pagination, or returns all albums globally or per frame. This is a critical omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) but lacks structure and essential details. It is under-specified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter and no output schema, the description should clarify the return format and relationship to frames. It does not, leaving significant gaps for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the frameId parameter at all. The agent is left to guess its purpose and whether it is required or optional.
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?
The description clearly states the action ('List') and resource ('photo albums'), making the purpose understandable. However, it does not differentiate this tool from sibling tools that also deal with albums (e.g., skylight_create_album), but since listing is a distinct operation, the purpose is reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or context. For example, it doesn't mention that listing albums may require a frame or that the optional frameId parameter can filter results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint annotation signals that this is a destructive operation, and the description does not contradict that. However, the description itself adds no behavioral context: it does not mention that changes may be previewed until confirm is true, that recurrence edits can affect an entire series, or what the destructive consequences are. The description relies entirely on the annotation and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It conveys no information beyond what the tool name already states, so the single sentence does not earn its place by adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 parameters, a required confirmation gate, a destructive annotation, recurrence semantics, and no output schema, a one-sentence description is completely inadequate. An agent cannot safely or correctly invoke this tool without additional external knowledge about how updates apply to recurring chores, what confirm controls, and what inputs are valid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 31% schema description coverage and 13 parameters, the description should compensate by highlighting key parameters or update targets, but it says nothing. It does not even mention confirm, apply_to, recurrence, or id. The parameter names are somewhat self-explanatory, but the description adds no semantic value for the many undocumented fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a clear verb and resource: 'Update a chore.' However, it does not indicate what aspects of a chore can be updated, how this differs from sibling operations like skylight_complete_chore, skylight_uncomplete_chore, or skylight_update_task, or what effect the update has. It is minimally clear but largely generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as skylight_create_chore, skylight_create_recurring_chore, skylight_complete_chore, or skylight_delete_chore. It does not mention that this edits existing chores, handles recurring occurrences, or requires confirmation before applying changes. The agent must infer all usage context from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It fails to mention whether the action is idempotent, reversible, or requires specific permissions, leaving critical gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it sacrifices essential information for brevity. While concise, it is underspecified and does not earn its place as a complete description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter documentation, the description is entirely incomplete. The agent cannot determine preconditions, effects, or return values from this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the two parameters ('id' and 'frameId'). The agent receives no guidance on their meaning or usage, which is severely inadequate.
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?
The description 'Mark a chore complete' uses a clear verb and resource, effectively stating the tool's core action. However, it does not differentiate from the sibling tool 'skylight_complete_chore_instance', which may have a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'skylight_complete_chore_instance' or 'skylight_uncomplete_chore'. Usage context is entirely implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose operation traits like irreversibility, permission requirements, or side effects. It only states 'Delete a reward', adding no behavioral context beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (three words) but fails to convey necessary details. It is under-specified rather than efficiently structured, lacking definition of parameters or usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (delete operation, two parameters, no output schema, no annotations), the description is severely incomplete. It omits critical information about parameter semantics, return values, and operational behavior, rendering it inadequate for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (id, frameId) with no descriptions, and schema coverage is 0%. The description does not explain what these parameters mean, how they relate, or which is required. The agent cannot determine how to correctly populate them.
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?
The description 'Delete a reward' clearly states the action and resource, matching the name. However, it does not differentiate from sibling delete tools like skylight_delete_chore or skylight_delete_event, which perform analogous operations on different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or conditions for use, leaving the agent to infer purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description lacks any behavioral context such as whether deletion is permanent, permission requirements, or impact on related data. The agent gets no insight beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but is under-specified rather than concise. It sacrifices essential detail for brevity, reducing utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and incomplete parameter information, the description fails to adequately prepare the agent. It does not explain what a 'task-box item' is, how to obtain an id, or what happens after deletion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter (id and frameId). The agent must guess their roles, leading to likely invocation errors.
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?
The description states the verb 'delete' and the resource 'task-box item', clearly indicating the tool's purpose. It distinguishes it from other delete tools like skylight_delete_event, as 'task-box item' is a specific entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like skylight_delete_chore or skylight_delete_list. There are no conditions, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks any behavioral details. It does not disclose whether the rename is destructive, requires specific permissions, or has side effects like breaking references.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is too brief for a tool with two parameters and no schema descriptions. It could be expanded slightly without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and the minimal description, the tool's behavior is incomplete. It does not explain what the function returns after renaming, nor does it mention any related operations or constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the purpose or constraints of the two parameters (name and frameId). For example, it does not specify that frameId identifies the frame or that name must be non-empty.
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?
The description clearly states the verb 'Rename' and the resource 'Skylight frame', making the purpose unambiguous. However, it does not differentiate from sibling tools like skylight_update_frame, which could also involve renaming as part of updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as skylight_update_frame or skylight_get_frame. There are no prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'Update' and does not explain whether fields are partially or fully replaced, whether the operation is reversible, what permissions are needed, or what the response contains. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and contains no filler, but it is under-specified rather than appropriately concise. A single clause that restates the tool's name does not provide meaningful structure or front-loaded decision information for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter mutation tool with no output schema, no annotations, and 0% schema coverage, a one-sentence description is completely inadequate. An agent cannot determine which fields are updatable, what the identifiers refer to, or what the call will return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions none of the five parameters. While names like id, summary, and meal_category_id are somewhat suggestive, nothing clarifies what frameId means or how the fields are applied during an update.
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?
The description uses a specific verb ('Update') and names the resource ('meal recipe'), which clearly distinguishes it from sibling create/delete/list recipe tools. It doesn't explicitly contrast with those siblings, but the core operation 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus skylight_create_recipe or skylight_delete_recipe, and no mention of prerequisites such as the recipe already existing or id identifying the target recipe. The schema's required id hints at existing-resource semantics, but the description does not state this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like mutation, idempotency, or authorization needs. It only states the basic action, leaving out critical details such as whether duplicates are allowed or the response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a single sentence, but it lacks structure and is overly minimal, missing opportunities to add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (3 params, no output schema, no annotations), the description is incomplete. It does not explain optional parameters, success indicators, or integration with other list tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It fails to describe any of the three properties (label, listId, frameId) despite them not being self-explanatory in context.
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?
The description clearly states the verb 'add' and the resource 'item to a list', which is specific and distinguishes from siblings like update or delete. However, it does not explicitly differentiate from other list item operations, missing a chance to clarify uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as skylight_update_list_item or skylight_delete_list_item. No prerequisites or scenarios provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It only states the basic action but omits details like whether deletion is permanent, permissions required, or effects on recurring events.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it sacrifices completeness for brevity. It could add value without significant length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 2 unexplained parameters, the description is severely incomplete. The agent lacks critical information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters (id, frameId). The agent gets no help understanding what 'frameId' means or how to use the parameters correctly.
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?
The description 'Delete a calendar event by id' clearly states the action (delete) and the resource (calendar event), distinguishing it from sibling tools like skylight_create_event or skylight_delete_task. However, it could be more explicit about scope or irreversibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool, prerequisites (e.g., needing the event id), or alternatives. The agent receives no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, and the description only says 'Delete'. It does not disclose that the operation is destructive, irreversible, or requires specific permissions. For a mutation tool with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but at the expense of necessary detail. It is not overly verbose, yet it fails to provide sufficient information beyond the basic action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no output schema, many sibling tools), the description is incomplete. It lacks parameter explanations, usage context, and behavioral details, making it insufficient for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the three parameters (itemId, listId, frameId). It does not explain their roles or relationships, leaving the agent without essential context.
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?
Description states 'Delete a list item from a Skylight frame' with a specific verb and resource. However, sibling tools like 'skylight_delete_list_items' (batch delete) and 'skylight_delete_list' are not differentiated, so it misses the top score for distinguishing from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no mention of when to use this tool over similar siblings (e.g., skylight_delete_list_items, skylight_move_list_item). The description implicitly assumes delete individual item but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Get one calendar account' without disclosing behavioral traits such as read-only nature, return format, side effects, permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no superfluous words. However, it sacrifices necessary detail for brevity, making it adequate but not well-structured for agent comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 2 parameters, no output schema, and no annotations. The description fails to explain return values, usage context, parameter formats, or any constraints. It is severely incomplete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds no meaning to the parameters ('id' and 'frameId') beyond their names. The agent receives no guidance on what values to provide or how they affect the tool's behavior.
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?
The description 'Get one calendar account.' clearly specifies the action (get) and the resource (one calendar account). It is distinct from sibling tools like 'skylight_list_calendars' which lists all calendars, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'skylight_list_calendars' or 'skylight_create_source_calendar'. The description does not mention prerequisites, context, or exclusivity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral traits. It does not state read-only nature, return format, error handling, or side effects. The minimal description adds no transparency beyond the obvious retrieval action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks essential details. It is not well-structured to convey critical information, and the brevity leads to under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters with no schema descriptions, no annotations, and no output schema, the description fails to provide adequate context. The agent cannot determine how to invoke the tool correctly or what to expect in response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the parameters 'id' and 'frameId'. The name 'id' is vague; the description should clarify that 'id' is the message identifier and 'frameId' is optional context. The description adds no value to the schema.
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?
The description 'Get one frame message' clearly indicates the tool retrieves a single message. The verb 'Get' and resource 'message' are specific, and it distinguishes from sibling tools like skylight_list_messages (list) and skylight_delete_message (delete). However, 'frame message' could be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like skylight_list_messages or skylight_get_frame. There is no mention of required parameters, prerequisites, or typical use cases, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description fails to disclose any behavioral traits. It does not mention whether the operation is read-only, has side effects, requires authentication, or has rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (3 words). While brevity is positive, it lacks structure and comes at the cost of missing essential information. For a simple tool, this is moderately adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and unknown return type, the description is incomplete. It does not explain what the tool returns or any context about the reward object. The agent would need prior knowledge of the API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and no parameter explanations in the description, the semantics of 'id' and 'frameId' are entirely unclear. The agent cannot determine what the parameters represent or how to use them.
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?
The description 'Get one reward' clearly states the action (get) and resource (reward), indicating retrieval of a single item. It differentiates from the sibling tool 'skylight_list_rewards' which lists multiple rewards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to use this tool over alternatives like 'skylight_list_rewards' or scenarios where fetching a single reward is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only states 'reorder,' implying mutation but lacking details on safety, permissions, or side effects. The agent cannot assess if the operation is destructive or requires special conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse (3 words), which under-specifies the tool's functionality. While short, it fails to convey necessary usage details, making it more 'underspecified' than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, low schema coverage, and a single-sentence description, the tool definition is highly incomplete. The agent cannot determine return values, error conditions, or proper invocation context for a tool with 4 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'afterItemId' has a description). The tool's description does not clarify any parameter meanings, such as what 'itemId' or 'listId' represent, nor how to use 'frameId'. The agent must rely solely on the sparse schema.
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?
The description says 'Reorder a list item,' which is a specific verb and resource. It clearly indicates the action of changing order, but does not specify the scope (e.g., within a list) or distinguish from similar actions like setting item sections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus siblings, such as 'skylight_set_list_item_section' or 'skylight_update_list_item'. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits. It states only the action, not effects, permissions, error conditions, or idempotency. This is risky for an agent invoking a mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a brief 5-word sentence, achieving conciseness but at the expense of providing any additional guidance. It is not front-loaded with any extra information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers only the basic action without the necessary context for an AI agent to correctly invoke this tool. It lacks parameter details, return value info, and behavioral expectations, making it inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the three parameters. With 0% schema coverage, the agent must guess the meaning of 'id', 'caption', and 'frameId' from names alone. This inadequately guides parameter selection and formatting.
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?
The description uses a specific verb ('Set') and identifies the resource ('message/photo caption'), clarifying that it can set captions on both messages and photos. While somewhat brief, it adequately distinguishes from sibling tools like skylight_add_message_comment (which adds a comment) or skylight_get_message (which retrieves). It could be more specific about context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The agent is left to infer usage context from the tool name alone, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the action. It does not mention idempotency, side effects, or whether the update is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is appropriately short, but it lacks structure and fails to convey crucial information. It is under-specified for the task.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and minimal description, the agent lacks context about the effects of the tool and the meaning of its parameters. The sibling get tool might help, but that is not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema parameter descriptions have 0% coverage, yet the description adds no explanation of parameters like 'early', 'on_time', 'early_minutes_before', or 'frameId'. This leaves the agent without necessary context.
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?
The description clearly states the verb 'Update' and the resource 'calendar-event notification settings', distinguishing it from the sibling get tool. However, it does not clarify that the settings apply to a specific frame (via frameId), which may cause slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it specify any prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description is too brief to disclose behavioral traits. It implies mutation but does not specify side effects, required permissions, idempotency, or whether omitted fields are preserved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence is concise but lacks necessary detail. It is front-loaded and readable, but the brevity limits its usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 5 parameters with minimal description coverage, the tool definition is incomplete. It does not explain required parameters, return values, or provide enough context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should add meaning, but it only names three fields (name, color, type), missing listId and frameId. The field name 'name' does not match schema 'label', and 'type' maps to 'kind' enum, adding some but incomplete context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update a Skylight list's name, color, or type', identifying the resource and updatable fields. However, it uses 'name' and 'type' instead of the schema's 'label' and 'kind', causing potential confusion. It does distinguish from siblings like create/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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., skylight_update_list_item, skylight_delete_list). No prerequisites or conditions for use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It does not disclose behavioral traits such as whether the comment is appended, any permission requirements, or side effects. The description adds minimal value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (5 words), but it sacrifices necessary detail. While it is front-loaded, it is too brief to be fully useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 3 parameters with low schema coverage, the description is incomplete. It fails to explain return values, constraints, or typical usage patterns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (body has a description). The description does not explain the id or frameId parameters, nor does it clarify how they relate to the comment action.
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?
The description clearly states the action (comment) and the resource (frame message/photo). It distinguishes from sibling tools like like_message and set_message_caption, though it could be more explicit about 'adding' a comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., skylight_like_message). No prerequisites or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the obvious mutation (creating a chore) that the tool name already implies. It does not disclose whether frameId is required, what happens when a chore is created without a start date, or how category_id maps to a family member.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single zero-waste sentence with no fluff, which is structurally fine. However, it adds almost nothing beyond the tool name itself ('Create a chore' vs 'skylight_create_chore'), bordering on under-specification rather than genuine conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, two of which are required, no annotations, no output schema, and a large sibling set including a recurring-chore variant, a single sentence is insufficient. An agent cannot determine key invocation details like whether frameId is needed, what the response contains, or what distinguishes a one-time chore from a recurring one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds zero parameter-level information; the schema already does the work for 67% of parameters (summary, category_id, start, reward_points), including a helpful pointer to skylight_list_categories. However, frameId and description remain undocumented in both the schema and the description, and the description does not compensate for that gap.
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?
The description uses a specific verb ('create') and a named resource ('a chore on a Skylight frame'), so an agent can tell this performs a chore-creation action. It is clear, but it does not explicitly distinguish itself from the sibling skylight_create_recurring_chore, relying on the tool name alone to carry that differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as skylight_create_recurring_chore, skylight_update_chore, or skylight_complete_chore. The one-sentence description provides no context about prerequisites, such as whether a frame must already exist or how chores relate to categories/members.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states 'create' with no disclosure about side effects, idempotency, required permissions, or post-creation behavior. A simple creation tool should note if duplicates are allowed or what the response includes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks necessary detail. It could incorporate parameter summaries or usage notes without becoming verbose, so it is under-sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 parameters with moderate complexity, the description is incomplete. It omits required parameters, return values, and constraints like whether frameId is required or optional. A creation tool needs more context for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only kind and color have descriptions). The description does not explain any parameter meanings or relationships. It misses the chance to clarify 'label' or 'frameId' beyond the schema, leaving gaps for the agent.
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?
The description clearly states the tool creates a new list on a Skylight frame, using a specific verb and resource. It distinguishes from siblings like update or delete, but could be more specific by mentioning the list types ('shopping' or 'to_do') which are in the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like skylight_create_event or skylight_create_chore. The description does not provide context for selection from the many sibling create tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, yet 'Create a meal recipe' merely restates the operation implied by the tool name. It does not disclose the return value, whether a duplicate summary is rejected, whether meal_category_id must reference an existing category, or any other side effects — a significant gap for a mutating tool with no annotation safety signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally short with the verb front-loaded and no filler, which is structurally clean. But at five words it crosses from conciseness into under-specification for a 4-parameter creation tool, providing no information beyond a restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, four parameters, and a cluster of related siblings (plan_meal, add_recipe_to_grocery_list, list_meal_categories, update_recipe), the description covers none of the gaps an agent needs to invoke the tool correctly. The return behavior and the meaning of half the parameters remain unknown, so this is incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the tool description adds nothing about parameters. summary ('Recipe title') and meal_category_id ('from list_meal_categories, required') are documented in the schema, but frameId and description are entirely opaque — an agent cannot tell what frameId refers to or what the description field should contain.
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?
The description names a specific verb ('create') and resource ('meal recipe'), so an agent can identify the core operation and distinguish it from recipe siblings like get/update/delete_recipe. However, it does not differentiate from closely related meal tools such as skylight_plan_meal or skylight_add_recipe_to_grocery_list, leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided whatsoever — no indication of when to create a recipe versus planning a meal or adding to a grocery list, and no prerequisite mentioned (e.g., calling list_meal_categories first, despite the schema hint). The description does not mislead, but it gives an agent zero guidance on selecting this tool among the many meal/recipe siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states 'create' without explaining side effects, authentication needs, or what happens upon successful creation (e.g., return value).
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?
The description is a single sentence with no wasted words. However, it is so brief that it sacrifices helpful detail, but it is still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5 parameters and no output schema, the description is incomplete. It does not explain what a 'task-box item' is, how parameters relate, or what the tool returns. Sibling tools show many task operations, so context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% (summary has a description). The description adds no extra meaning to any parameter; it does not explain frameId, routine, emoji_icon, or reward_points.
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?
The description clearly states the action 'Create' and the resource 'task-box item', which aligns with the tool name and distinguishes it from other create tools like create_chore or create_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as skylight_create_chore or skylight_create_event. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states that deletion happens. It does not disclose irreversibility, what happens to the member's items if reassign_to_category_id is not provided, auth requirements, or cascading effects. The schema description of reassign_to_category_id hints that items would otherwise be orphaned, but the main description offers no such transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, which is structurally clean. However, it is under-specified: it contains almost no behavioral or parameter context, so the brevity is not fully appropriate for a destructive operation with three parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete tool with no annotations, no output schema, and three parameters, one sentence is insufficient. It does not cover deletion consequences, reassignment behavior, or how this tool relates to the many sibling member/category tools. The schema's reassign_to_category_id description provides one useful detail, but the tool definition as a whole leaves important context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description needed to compensate for undocumented 'id' and 'frameId' parameters, but it does not explain either. The phrase 'category / family member' indirectly suggests that 'id' identifies a member/category, providing a little semantic value beyond the bare schema, but most parameter meaning is still left to inference.
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?
The description names the action ('Delete') and the resource ('category / family member'), so an agent knows what the tool does. It is slightly ambiguous whether category and family member are synonyms or two resource types, but the tool name and sibling set make the intent reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool instead of related operations such as skylight_update_category, skylight_remove_user, or skylight_update_family_member, and no mention of prerequisites or exclusions. The only hint is the verb 'Delete', which is implied usage at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It only states the basic operation without mentioning side effects, permissions, error conditions, or what happens if the list or frame does not exist.
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?
The description is a single clear sentence with no redundancy. It is concise, though it could benefit from additional context for usability without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 parameters, no output schema), the description is insufficient. It lacks parameter explanations, behavioral details, and output information, making it incomplete for an agent to invoke correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage for its parameters. The description does not add any meaning about what listId or frameId represent, how they are used, or any constraints.
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?
The description clearly states the action ('Get all items') and the target ('a specific list on a Skylight frame'). It effectively communicates the resource and scope, but does not explicitly differentiate from sibling tools like skylight_list_lists or skylight_add_list_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives (e.g., skylight_list_lists to get all lists, or skylight_get_list_items vs. skylight_get_frame). No prerequisites or context for use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the basic action. Since no annotations are provided, the description should cover aspects like whether liking is reversible, permissions needed, or side effects. It does not.
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?
The description is a single sentence with no wasted words. It is front-loaded but may be too brief given the lack of other documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation, no output schema, and no annotations, the description is insufficient. It does not cover what happens after liking, such as a response or toggle behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameter meanings. It does not mention 'id' or 'frameId', leaving their roles entirely unspecified.
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?
The description 'Like a frame message/photo' clearly specifies the action and resource. It distinguishes from sibling tools like skylight_unlike_message, but could be more precise about what constitutes a 'frame message/photo'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., unlike or get). There is no mention of prerequisites or context, such as whether the message must already be viewed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether this operation is read-only, what ordering or filtering (if any) applies, pagination behavior, or the effect of calling it. The phrase 'on the frame' is vague and doesn't clarify scoping for the optional frameId parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, which is concise but lacks structure. It front-loads the verb and resource, but the brevity sacrifices clarity on key details like parameters and sibling differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, one optional parameter, and related sibling tools (list drafts, list items, get intent), the description is incomplete. It does not explain the differences between intents, drafts, and items, nor does it describe the output format or whether the list is scoped to a specific frame. The agent lacks sufficient context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and there is one optional parameter frameId. The description mentions 'on the frame' but does not explain the parameter's role or behavior when omitted. It fails to specify whether frameId filters results or returns all intents across frames, which is necessary for the agent to use the parameter correctly.
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?
The description clearly states the verb 'list' and the resource 'AI auto-creation intents', and adds context about finding pending/completed drafting jobs and their IDs. However, it does not differentiate this tool from sibling tools like skylight_list_auto_creation_drafts or skylight_list_auto_creation_items, leaving room for confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as skylight_get_auto_creation_intent or skylight_list_auto_creation_drafts. It only implies usage for discovering intents but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description offers no behavioral details beyond listing. No annotations exist, so it fails to disclose read-only nature, error handling, or side effects. The minimal text adds no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one sentence, which is good for clarity, but it sacrifices necessary detail. It is not overly verbose, but underspecification reduces its effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description is incomplete. It does not explain what meal categories are, how to obtain a frameId, or what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the undocumented frameId parameter. It implies the parameter via 'for the frame' but provides no specifics on format, requiredness, or default behavior.
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?
The description clearly states the verb 'List' and the resource 'meal categories', indicating it retrieves meal categories. However, it does not differentiate from the sibling tool 'skylight_list_categories' which likely lists all categories, missing a chance to clarify the specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'skylight_list_categories'. There are no prerequisites or context about required frameId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It only states 'list' without mentioning read-only nature, return format, pagination, or side effects. The minimal description fails to inform agent about expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but lacks structure or front-loading of critical details. It could be expanded with minimal overhead.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a single under-described parameter, the description is too brief. An agent needs more context on response structure, optional parameter effects, and potential error states.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only vaguely implies that frameId identifies a frame. No details on format, default, or required status, leaving the agent with insufficient information to use the parameter correctly.
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?
The description clearly states the tool lists 'task-box items' from a frame's task list, specifying the resource (tasks within a frame). It distinguishes from sibling tools like skylight_list_chores and skylight_list_list_items by focusing on tasks, though it does not explicitly differentiate from other list operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like skylight_list_frames, skylight_list_chores, or skylight_list_list_items. No mention of required frameId or default behavior if omitted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Reverse a reward redemption' states the action but says nothing about side effects such as whether points are refunded, whether the redemption must be in a certain state, or whether the reversal is idempotent.
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?
The description is a single, direct sentence with no wasted words. However, it is minimal to the point of near-tautology, so while structurally clean, it provides little substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no annotations, and no output schema, the description is under-equipped to let an agent call the tool correctly. It does not explain how to identify the redemption to reverse, what a successful reversal returns, or what failure conditions exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the tool description adds no parameter information at all. The required 'id' parameter and 'frameId' are unexplained in the description, and it does not clarify when 'category_id' is needed despite its partial schema description.
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?
The description uses a specific verb ('Reverse') and resource ('a reward redemption'), making the tool's core action unmistakable and clearly distinct from the sibling skylight_redeem_reward. It is slightly tautological with the tool name but does convey an understandable operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives, prerequisites, or situations where reversing a redemption is appropriate. The presence of siblings like skylight_redeem_reward implies the inverse relationship, but the description leaves the decision entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Update' implies mutation, but it does not reveal whether the update is a full replacement or partial patch, how recurrence is handled, whether an existing event is required, or what happens on failure.
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?
The description is one short, front-loaded sentence with no unnecessary words. It is concise, but the brevity borders on under-specification for a tool with 12 parameters and no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 12 parameters, no annotations, no output schema, and low schema description coverage, this description is far too thin. It omits update semantics, required prerequisites, return behavior, and the meaning of most parameters. An agent would struggle to call this tool correctly in non-trivial cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 42%, so the description should compensate for the many undocumented parameters. It only clarifies that 'id' identifies the event to update; it adds no meaning for frameId, invited_emails, timezone, all_day, location, description, or other fields. Several property descriptions exist in the schema, but the overall parameter semantics are incompletely conveyed.
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?
The description names a specific verb ('Update'), resource ('calendar event'), and the key identifier ('by id'). This clearly differentiates it from create/delete/get/list event siblings, though it does not explicitly distinguish it from the similarly named skylight_update_event_notification_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool instead of create_event, delete_event, get_event, or list_events. There are no conditions, prerequisites, or exclusions, so an agent must infer that this is for modifying an already-created event.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states 'Update', implying mutation, but no annotations are provided. It fails to disclose behavioral traits such as required permissions, idempotency, side effects (e.g., changes take effect immediately?), or rate limits. The description carries the full burden and does not meet it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence (6 words), which is efficient but insufficient for an 11-parameter tool. It is not verbose, but the lack of detail makes it merely adequate rather than well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, no output schema, no annotations), the description is grossly incomplete. It does not explain return values, constraints, or the effect of missing parameters, making it insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 9% schema description coverage (one out of 11 parameters has a description in the schema), the tool description adds no parameter information. It does not compensate for the low coverage, providing no additional meaning beyond the raw schema.
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 uses a specific verb ('Update') and resource ('Skylight frame'), and clearly distinguishes from sibling tools like skylight_list_frames or skylight_get_frame by indicating it modifies settings. While 'display/sleep' is slightly vague relative to the full parameter set, the overall purpose 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., skylight_rename_frame). There is no mention of prerequisites, contexts, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only restates the mutation ('update') without indicating whether updates are partial or full, whether unspecified fields are preserved, or what side effects occur. The schema's checked and section descriptions hint at behavior, but the description itself adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence with the action front-loaded and no filler, which is structurally clean. However, it is undersized for a six-parameter operation and misses opportunities to add field semantics or usage guidance without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters, no output schema, no annotations, and a large set of closely related sibling tools, a one-sentence description is inadequate. It leaves unclear how updates behave, which fields are relevant, how IDs relate, and when to pick this tool over similar list-item operations. The low schema coverage amplifies these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description does not compensate for the undocumented parameters. It does not explain label, listId, itemId, or frameId, nor does it clarify which fields are optional and updatable. Only checked and section carry schema-level descriptions, so four of six parameters remain semantically bare.
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?
The description uses a specific verb ('update') and resource ('list item') and locates the operation on a Skylight frame, making the core action clear and distinguishing it from higher-level tools like skylight_update_list. However, it does not say which attributes are updatable or what distinguishes it from item-level siblings like move or set-section operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus closely related siblings such as skylight_set_list_item_section, skylight_move_list_item, or skylight_add_list_item. The description provides no context, exclusions, or alternatives, leaving the agent to infer selection from names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It only states the basic action and does not mention side effects, duplicate handling, whether recipe ingredients are added as separate items, idempotency, or required permissions. For a mutating operation, this is a meaningful gap.
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?
The description is a single efficient sentence with no wasted words and the core action front-loaded. It could include slightly more context, but as a concise high-level summary it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no annotations, and no output schema, the description leaves important context unspecified: what 'id' refers to, what 'frameId' does, how ingredients are added, and what a successful result looks like. An agent can make a plausible guess but not call it with full confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description adds no parameter details. The required 'id' is undocumented and can only be inferred as the recipe id from the tool name and description. 'frameId' is completely unexplained, and 'list_id' is documented only in the schema.
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?
The description gives a specific verb ('Add'), a clear resource ('a recipe's ingredients'), and a target ('a grocery list'). It is clear enough to identify the operation, but it does not explicitly differentiate from the similar sibling add_list_item, so it falls short of a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as add_list_item or create_list. The use case is inferable from the description, but there are no exclusions, prerequisites, or explicit routing to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but fails to disclose any behavioral traits such as required permissions, side effects (e.g., irreversible action), or response behavior. It only states the action without explaining what 'approve' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. However, it is too brief and lacks necessary details, making it minimally acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no output schema, and no annotations, the description is incomplete. It fails to explain the context of 'approve', what a 'pending frame user' is, or how the parameters are used, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not explain what the 'id' and 'frameId' parameters mean. The description adds no value beyond the parameter names, leaving the agent to guess their purpose.
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 'Approve a pending frame user' uses a specific verb ('Approve') and resource ('pending frame user'), clearly distinguishing it from sibling tools like skylight_invite_user, skylight_remove_user, or skylight_resolve_member.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or how it relates to other tools like skylight_list_frame_members or skylight_invite_user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the delete action, without disclosing whether deletion is permanent, whether it affects associated data, whether authorization is required, or whether the operation can be undone. For a destructive action, this is a significant transparency gap.
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?
The description is very short and front-loaded, using a single efficient sentence that adds the resource context 'frame message/photo.' It earns its place, though the awkward slash in 'message/photo' creates mild ambiguity about whether these are two distinct resource types or one combined type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and no parameter documentation, yet the description provides only a minimal action statement. It does not specify which identifiers are required, what happens after deletion, or how this relates to other message-based tools. The description is insufficient for an agent to invoke the tool with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain either parameter. The 'id' property is understandable as the identifier of the message, but 'frameId' is left unexplained, and the description does not clarify whether both are needed, what formats are expected, or how they relate to the 'frame message/photo' concept.
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?
The description 'Delete a frame message/photo' gives a clear verb ('delete') and a specific resource type ('frame message/photo'), which is more precise than the bare tool name. It is clear enough to be distinguished from the sibling tool skylight_delete_messages, though it does not explicitly call out that difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. In particular, the sibling skylight_delete_messages exists, but the description does not say whether this singular tool is for a single message/photo while the plural is for bulk deletion, nor does it state any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description must disclose behavioral traits. It only states the action but does not mention side effects (e.g., cascading deletion of events), irreversibility, or permissions needed. This is insufficient for safe selection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loads the action. However, it sacrifices necessary detail, making it borderline under-specified. Conciseness is adequate but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and zero parameter coverage, the description should provide more context about the tool's behavior, return value, and error conditions. It is incomplete for a delete operation that may have significant effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema adds no meaning to parameters. The description does not elaborate on the purpose of 'id' or 'frameId', leaving the agent to guess. It adds no value beyond the schema.
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 clearly states the action ('Remove') and the resource ('a connected source calendar'), explicitly including webcal subscriptions. This distinguishes it well from sibling tools like skylight_list_source_calendars or skylight_create_source_calendar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, disclaimers, or what to check before deletion. A user must infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only, non-destructive operation ('Get'), which is appropriate. With no annotations, it would benefit from explicitly stating that it does not modify any state. However, for a simple GET, this is minimally acceptable. No mention of authentication or rate limits, but those are not critical here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short at 8 words, which is concise but at the expense of necessary detail. It is front-loaded but lacks additional information that could be added without losing brevity. It earns a medium score because undue brevity reduces utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and only one parameter, the description fails to explain the return format, what 'household configuration' includes, or how the parameter affects the response. The tool is relatively simple, but the description is insufficient for an agent to fully understand its behavior without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('frameId') with no description, and the description does not explain its meaning or usage. With 0% schema description coverage and no parameter context in the description, the agent has no guidance on how to populate 'frameId' or what values are valid.
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?
The description clearly states the verb 'Get' and the resource 'household configuration' with context 'for the frame'. It effectively distinguishes from sibling 'skylight_update_household_config' as a read operation. However, it doesn't elaborate on what 'household configuration' entails, which could be more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use versus alternatives. While the sibling list includes an update counterpart, the description provides no context on prerequisites, typical use cases, or when to prefer this tool over other 'get' tools. The implied usage is simply when you need configuration data, but that is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose side effects (e.g., whether existing linked calendar is replaced), required permissions, or error behavior. The mention of 'app-specific password' is helpful but insufficient for safety.
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?
The description is a single concise sentence with no extraneous words. It is front-loaded with the core action. However, it could be slightly expanded for completeness without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description does not explain the return value or success/error indicators. It lacks details on what happens after linking (e.g., calendar appears in list, duplicate handling), making it incomplete for an operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, but the tool description only rephrases the app-specific password parameter. The 'frameId' parameter is undocumented in both schema and description, leaving its purpose unclear.
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?
The description clearly states the action ('link') and the resource ('Apple/iCloud calendar') and specifies the method ('using an app-specific password'). It distinguishes from sibling tools like skylight_add_webcal that link via webcal, providing a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. It does not specify when to use this tool versus alternatives (e.g., other calendar linking tools), nor does it mention prerequisites like having an Apple ID or generating an app-specific password.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It only states the action (list categories) without disclosing behavioral traits like authentication requirements, rate limits, error handling on invalid frameId, or whether omitting frameId returns categories for all frames.
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?
Single sentence front-loads the verb and resource, no fluff. Could benefit from a brief clarification of what categories are, but remains appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given many sibling tools with similar purposes, the description is too sparse. No output schema, no mention of return format, no differentiation from skylight_list_calendars or skylight_list_chores. Leaves agent guessing about behavior and scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description only indirectly explains frameId by mentioning 'for a Skylight frame'. It adds minimal context beyond the parameter name, failing to clarify what values are valid or how to obtain a frameId.
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?
Description uses specific verb 'list' and resource 'calendar/chore categories', clearly indicating what the tool does. It distinguishes from sibling tools like create, update, delete categories, but doesn't explicitly differentiate from similar list tools like skylight_list_calendars or skylight_list_chores.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not explain the optional frameId parameter, prerequisites (e.g., frame must exist), or when to prefer skylight_list_calendars over this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the basic purpose. It does not state whether the operation is read-only, destructive, or requires authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it omits important details about the parameter. While concise, it lacks completeness to earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 1 parameter and no output schema, the description is insufficient. It does not explain the frameId parameter or what the output looks like, leaving the agent with incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description adds no meaning to the frameId parameter. Users are left to infer its purpose from the name alone.
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 clearly states the action (list), resource (lists), and scope (on a Skylight frame). It effectively distinguishes from siblings like skylight_list_frames and skylight_create_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., skylight_get_list_items). Does not mention prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates that the device is renamed. It does not mention permissions, reversibility, side effects, uniqueness constraints, or error behavior, which are important for a mutation operation.
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?
The description is a single, front-loaded sentence with no filler or redundancy. It is efficient and easy to parse, though it is concise at the expense of substantive guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, this one-liner is too sparse to fully support reliable invocation. It omits expected return behavior, side effects, prerequisites, and any clarification of the optional frameId parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents id and name, but the description adds no parameter-level meaning and does not compensate for the undocumented frameId parameter. With only 67% schema coverage, the missing frameId semantics remain unexplained.
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?
The description clearly states the action ('Rename') and the resource ('a Skylight device'), which distinguishes it from the close sibling skylight_rename_frame. It is specific enough to identify the core operation, though it does not elaborate on what a 'device' means or how it relates to frames.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like skylight_rename_frame or skylight_update_frame. It also omits prerequisites, intended workflow steps, or exclusions, leaving the agent to infer the correct usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It communicates that the tool changes which album a device displays, but it does not mention side effects, prerequisites, permissions, reversibility, or what the response looks like.
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?
The description is a single clear sentence with no wasted words, and the core action is front-loaded. It is concise, though it sacrifices valuable behavioral detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and an unexplained optional frameId parameter, this description is too thin for confident invocation. An agent would not know how to source album IDs, whether frameId is required for a particular device type, or what success or failure looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes id and current_album_id, but the description adds no parameter-level meaning beyond that. The optional frameId parameter has no schema description and is not explained anywhere, so 67% schema coverage is insufficient to make this parameter usable.
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?
The description states a specific verb and resource: it sets which photo album a device displays. This is clear and distinguishable from most sibling tools, but it does not explicitly call out how it differs from related device or album tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of alternatives like skylight_update_album, skylight_list_albums, or other device-related tools. The intended context must be inferred entirely from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It states the action (remove all items) but fails to disclose important behavioral traits such as irreversibility, required permissions, or whether the list itself is affected. The description is too sparse for a destructive operation.
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?
The description is very concise at one sentence. It states the core purpose without extraneous words. However, it sacrifices necessary detail for brevity, making it borderline under-specified. Still, the sentence earns its place by clarifying the function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and sparse description, the tool definition is incomplete. It lacks information about return values, edge cases (e.g., empty list), parameter dependencies, and side effects. The agent would need to infer or test extensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the JSON schema provides no descriptions for the two parameters (listId, frameId). The tool description does not explain their meaning or usage. The agent receives no guidance on what values to provide or how parameters affect the operation.
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 is clear and specific: 'Remove all items from a list.' It uses a strong verb ('Remove') and a specific resource ('all items from a list'). This distinguishes it from sibling tools like skylight_delete_list (which deletes the list itself) and skylight_delete_list_items (which deletes specific items, not all).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For instance, it does not clarify when to use skylight_clear_list instead of iterating over skylight_delete_list_items or other methods. No context about prerequisites or conditions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Delete', implying a destructive action, but lacks details on reversibility, side effects (e.g., removal from meal plans), whether the recipe must exist, or any required permissions. No annotations are present to compensate.
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 a single, front-loaded sentence with no wasted words. It conveys the core action efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature of the tool, lack of output schema, and two underdocumented parameters, the description is far too sparse. It does not explain what the ID represents, the effect of the optional frameId, nor what happens after deletion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters ('id', 'frameId') with 0% description coverage. The description does not explain their meanings, roles, or relationships, leaving the agent unsure which ID to provide.
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 'Delete a meal recipe.' uses a specific verb ('Delete') and clearly identifies the resource ('meal recipe'), distinguishing it from sibling tools like create, update, or list recipes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., skylight_update_recipe for deactivation), nor are there prerequisites or conditions for deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether frameId is required or optional, error conditions, authentication needs, or data freshness. The tool is likely read-only but this is not stated.
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?
A single sentence that fronts the verb and resource. It is concise and to the point, but could include more detail without significant expansion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description covers the basic purpose but lacks detail on return structure or behavior without frameId. It is minimally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the frameId parameter—its purpose, format, or behavior when omitted. The description says 'the frame's' but does not clarify the parameter's role.
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?
The description uses the specific verb 'List' and clearly identifies the resource as 'calendar accounts (Google/Apple/etc.) and their active calendars' for a frame. It is clear and distinguishes from tools like skylight_get_calendar, but does not explicitly differentiate from other list tools like skylight_list_source_calendars.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as skylight_list_source_calendars or skylight_get_calendar. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only states a basic list operation without revealing any behavioral traits like read-only, auth requirements, or response format.
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?
The description is a single concise sentence with no wasted words, though it could benefit from additional structural elements like parameter explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a single undocumented optional parameter, the description lacks completeness. It does not explain output format or how the optional frameId affects results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter frameId is not described beyond its name. Schema description coverage is 0%, and the description adds no clarification about its meaning or required status.
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 clearly states the verb 'List' and the resource 'physical devices attached to a Skylight frame,' distinguishing it from siblings like skylight_list_frames.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives or prerequisites. Siblings exist for listing frames and other entities, but no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. Only mentions date-range scope; lacks disclosure of return format, pagination, authentication needs, or any side effects. Minimal transparency beyond the basic listing operation.
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?
A single, clear sentence with no unnecessary words. All information is front-loaded. Highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacking output schema and annotations, the description is too sparse. Does not explain what a nudge is, what the response contains, or how results are ordered. For a listing tool with multiple parameters, more context is needed for complete agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (2 of 3 params have descriptions). Tool description adds no extra meaning; merely reiterates the date range. The optional 'frameId' parameter is not mentioned at all, leaving its semantics unclear.
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?
Clearly states the verb 'list' and resource 'nudges (reminders)' with a scope 'in a date range'. The resource name is distinct from siblings, though no explicit sibling differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. With many sibling list tools for different resources, the description offers no context about when to choose this over skylight_list_tasks or others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states that the tool lists recipes for the frame, with no mention of pagination, ordering, filtering, side effects, or required permissions. This is insufficient for behavioral transparency.
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?
Single sentence, front-loaded with the key action and resource. No extraneous words. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, single parameter with no description, and no annotations, the description is incomplete. It does not explain what a frame or recipe is, expected output format, or any constraints. A list tool should provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'frameId' has no description in the schema (0% coverage). The description adds 'for the frame,' implying frameId is the frame identifier, but does not explain its format or whether it's truly optional (since not required). Minimal added value over the schema.
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?
The description clearly states the verb 'List' and the resource 'meal recipes,' with scope 'for the frame.' This distinguishes it from siblings like get_recipe (single) and create_recipe. However, the term 'frame' is not explained, which may cause slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There are many list tools, but no context on when listing recipes is appropriate or when to use other recipe tools (e.g., get_recipe, create_recipe).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden, but it only restates the core action. It does not disclose side effects, reversibility, whether the user's account is deleted, or what happens when frameId is omitted.
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?
A single clear sentence with no filler; the action and object are front-loaded. It is appropriately sized for a simple two-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too thin for an agent to invoke this safely: it leaves unclear whether frameId is required in multi-frame setups, what return or error behavior to expect given no output schema, and what 'removed' means for the user's existing data and access. Given absent annotations and 0% parameter coverage, this is a substantial gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only loosely maps 'a user' to id and 'the frame' to frameId. It does not explain that id is the user/member identifier, how frameId behaves when optional, or why id can be a string or number.
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?
The description states a specific action ('Remove') with a resource and scope ('a user from the frame'), and is clearly distinct from sibling tools like invite_user or approve_user. It is somewhat ambiguous whether 'remove' means revoking frame access versus deleting a user account, but the frame context narrows it enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of alternatives such as skylight_resolve_member, skylight_list_frame_members, or user-management actions. There is no stated prerequisite, such as finding the user id first, and no exclusion, such as not for deleting an account.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of disclosing behavior. It indicates a mutating operation and the ability to clear a section, but it does not disclose side effects, authorization requirements, reversibility, or what happens to unspecified list items. This is comparable to a generic mutation description that leaves important behavioral context implicit.
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?
A single, front-loaded sentence that states the primary action and the notable null-clear behavior with no filler. It is as concise as possible while conveying the essential function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with four parameters, no annotations, and no output schema, the description should provide more context to support correct invocation. It omits when to use the tool, what frameId means, and what the operational effects are beyond the basic move/clear action, leaving an agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description does not compensate for the undocumented listId and frameId parameters. It loosely maps to 'section' and 'list items,' but adds little meaning beyond what the schema already states for section and item_ids. The required listId parameter has no semantic explanation in either the schema or the description.
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?
The description uses a clear verb and resource: 'Move list items into a named section,' which conveys the core operation. It also adds the 'clear it' alternative, but it does not explicitly distinguish itself from the sibling tool skylight_move_list_item, leaving a potential ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like skylight_move_list_item or skylight_update_list_item. The description states what it does but not the conditions or intent that should lead an agent to select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. 'Set' indicates mutation, but it does not disclose whether active_calendars replaces the full active set, what an empty array means, or any side effects on the connected account/source calendars.
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?
One short sentence with front-loaded action and object, no redundant wording or filler. It communicates the core operation efficiently without repeating schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter mutation with no annotations or output schema, this definition is incomplete. The agent is left without enough context about what id and frameId refer to, whether the operation is a full replacement, or how this relates to connected/source calendars.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, covering active_calendars, while id and frameId are undocumented. The description adds 'sub-calendars' and 'connected account' but never maps these concepts to the parameters, so it does not compensate for the schema coverage gap.
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?
The description states a specific verb and resource: 'Set which sub-calendars of a connected account are active.' This makes the tool's purpose clear and distinguishes it from list/default-calendar siblings, though it does not explicitly name any sibling or contrast with skylight_set_default_calendar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like skylight_set_default_calendar or skylight_list_calendars. The description implies connected-account calendar management but does not state prerequisites, exclusions, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'update' without elaborating on idempotency, required permissions, side effects, or return values. This leaves significant gaps for an agent.
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 a single, direct sentence with no unnecessary words. It is optimally concise for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, low schema coverage, and absence of output schema, the description is insufficient. It does not explain what a 'frame profile' is or how the parameters relate, leaving an agent with incomplete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (birthday described as YYYY-MM-DD). The description merely lists the parameter names without adding meaning or constraints for 'name' or 'frameId'. It fails to compensate for the low coverage.
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?
The description clearly states the action (update) and the resource (frame profile) along with the fields (name, birthday). However, it does not differentiate from similar sibling tools like skylight_update_family_member or skylight_update_frame, leaving ambiguity about what constitutes a 'frame profile'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like skylight_update_frame or skylight_rename_frame, nor does it mention prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only says 'subscribe', which implies a state change, but does not disclose whether it overwrites existing subscriptions, if the frame must exist, or if the operation is reversible. Key behavioral context is missing.
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?
The description is a single sentence, achieving conciseness. It could be slightly more informative (e.g., note that frameId is optional) without losing brevity, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no annotations, and no output schema, the description is too sparse. It does not explain what happens after subscription (e.g., events appear), error conditions, or limits. For a simple operation, this is still incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (sync_url has a description). The description adds no additional meaning to the parameters. The 'frameId' parameter lacks any description in both the schema and the tool description, leaving its purpose unclear despite being optional.
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 clearly states the action ('Subscribe the frame to a webcal/ICS calendar URL'), using a specific verb and resource. It distinguishes itself from siblings like skylight_create_source_calendar and skylight_link_apple_calendar by focusing on webcal subscriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., skylight_create_source_calendar or skylight_update_calendar). There is no mention of prerequisites, when not to use it, or expected outcomes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. 'Attribute' implies a mutating operation, but the description does not state whether prior attribution is replaced or supplemented, whether the change is reversible, or what side effects occur. This leaves the agent unable to predict the consequences of invoking the tool.
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 a single, front-loaded sentence with no filler. Every word contributes to the core purpose, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotation safety profile, yet the description omits return behavior, side effects, and the role of frameId. For a mutating tool, the agent needs more context to understand what happens after the call and whether prior categorizations are overwritten.
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?
The schema already documents id and category_ids, and the description adds the conceptual meaning that category_ids refer to family members whose calendars receive these events. However, frameId remains undocumented, and with only 67% schema coverage the description does not fully compensate for that missing parameter.
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?
The description uses a specific verb ('attribute') with a specific resource ('a source calendar's events') and names the outcome ('to one or more family members'). It clearly states the tool's purpose, though it doesn't explicitly contrast it with related calendar tools like skylight_update_calendar or skylight_set_default_calendar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, such as skylight_create_source_calendar, skylight_update_calendar, or skylight_delete_source_calendar. There are no exclusions, prerequisites, or contextual hints beyond the fact that it operates on an existing source calendar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Create a calendar event.' It does not explain side effects, whether events are immediately visible on the frame, permissions needed, or behavior around recurrence/category assignment. This is a minimal mutating-action statement with no additional behavioral depth.
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?
The description is a single sentence with no filler or redundancy, and the key scoping detail 'on a Skylight frame' is front-loaded. It is appropriately concise, though the short length reflects a larger gap in substance that is penalized elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, no annotations, and no output schema, this description is far too incomplete. It does not explain how to specify the frame, what the event lifecycle is, or how required parameters beyond summary should be handled. The agent cannot correctly and confidently use the tool across realistic scenarios based on this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 45%, and the description does not compensate for the remaining undocumented parameters. It hints at frame targeting via 'on a Skylight frame,' but does not explain all_day, timezone, location, invited_emails, or frameId semantics. The schema itself documents only a few fields, so the agent is left without sufficient meaning for most parameters.
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 states a specific verb and resource: 'Create a calendar event on a Skylight frame.' This clearly distinguishes it from sibling tools like skylight_create_source_calendar, skylight_update_event, and skylight_delete_event. The purpose 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, and no exclusions or prerequisites. It does not mention that it should be used for creating new events as opposed to updating or deleting, aside from the implicit verb 'Create.' This leaves the agent without explicit routing context among the many calendar-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral consequences, but it only says 'Delete a photo album.' It does not mention irreversibility, whether photos inside the album are also deleted, ownership/permission requirements, or any side effects.
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 a single, direct sentence with no wasted words. It is appropriately front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, no annotations, and no output schema, the description is too sparse. It fails to clarify the meaning of required parameters or the consequences of deleting an album, leaving important context for the agent missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the 'id' or 'frameId' parameters. An agent cannot determine what ID is expected or why frameId might be needed.
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 'Delete a photo album.' clearly states the specific action (delete) and resource (photo album). It is easily distinguished from sibling tools that delete other resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as skylight_remove_from_album or skylight_update_album. It does not state exclusions, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. 'Get' implies read-only, but the description does not explicitly state idempotency, lack of side effects, authentication needs, or response characteristics (e.g., what fields are returned).
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?
Single sentence, no redundancy, perfectly concise. Every word is necessary and contributes to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, no output schema, and no annotations, the description is too sparse. Missing details on parameter usage, return value structure, and any prerequisites for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the 'frameId' parameter—its meaning, format, or how to obtain it. The agent must rely solely on the parameter name, which is insufficient.
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?
Description uses specific verb 'Get' and resource 'frame's calendar-event notification settings', clearly distinguishing from sibling 'skylight_update_event_notification_settings'. The purpose is immediately understood.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives or prerequisites (e.g., how to obtain frameId). The description only states the basic function without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description only says 'list members', implying a read-only operation. It does not disclose authentication needs, error handling, or pagination, but for a simple list tool this is minimally acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks structure and could benefit from additional context. It is not verbose but also not optimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no output schema or annotations, the description is very minimal. It does not explain return values, error conditions, or any edge cases, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation of the frameId parameter beyond its name. No information about format, required status, or default behavior is provided.
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 'List members (frame_users) of a Skylight frame' clearly states the action (list) and resource (members of a frame), distinguishing it from siblings like skylight_get_frame and skylight_list_frames.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites or exclusion criteria. The description only implies usage but does not explicitly help the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. However, it only states the basic function without mentioning read-only nature, authentication needs, or error behaviors (e.g., what if frameId is invalid).
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?
The description is a single sentence that is concise and front-loaded. However, it may be overly terse, lacking necessary details that would warrant a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It does not explain what source calendars are, typical use cases, or what the output contains. More context is needed for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the frameId parameter. It fails to clarify that frameId is the identifier of the frame, nor does it specify any constraints or format.
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 clearly identifies the action (List), the resource (linked source calendars), and the scope (for a frame). It distinguishes from sibling tools like skylight_list_calendars by specifying 'source' and 'linked'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as skylight_list_calendars or skylight_get_calendar. There is no mention of prerequisites or context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies side effects like scheduling a meal and optionally mutating the grocery list, but it does not state whether this creates a new record, whether existing meals are overwritten, what permissions are required, or what the response contains.
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 a single concise, front-loaded sentence with no filler. It communicates the core action and the three optional capabilities in a compact form that is easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter creation tool with no annotations and no output schema, this description is too thin. It does not mention return values, the requirement that summary must be blank when meal_recipe_id is set, how category IDs are obtained, or the purpose of several parameters. The schema helps, but the overall tool context remains incomplete.
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 60%, and the description adds some parameter-level meaning by clarifying that repeating maps to rrule, linking a recipe maps to meal_recipe_id, and grocery list mapping to add_to_grocery_list. However, it does not compensate for undocumented parameters such as note, frameId, saveToRecipeBox, and add_to_grocery_list, and the schema already documents the most complex parameter (summary).
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?
The description uses a specific verb 'Plan a meal on a date' and identifies the resource and core optional behaviors (repeating, linking a recipe, adding to grocery list). It is clear enough to distinguish from meal-related siblings like skylight_update_meal or skylight_list_meals, though it does not explicitly differentiate itself from skylight_generate_meal_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to choose this tool over alternatives. It states what the tool can do but gives no exclusions, no recommended contexts, and no comparisons to related tools such as skylight_generate_meal_plan or skylight_create_recipe.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions the inclusion of unscheduled/template chores, but does not disclose whether the tool is read-only, any authentication needs, rate limits, or other behavioral traits. This leaves significant gaps for an AI agent.
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?
The description is a single sentence that front-loads the key differentiator (including unscheduled/template chores). It is concise and avoids unnecessary words, though it could benefit from slight restructuring for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description is too brief. It does not explain return format, pagination via limit, filtering by frameId, or the role of include_up_for_grabs. The tool requires richer context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 40% (only search_query and ended_chore_lookback_days have descriptions). The description adds no additional meaning beyond the schema; it does not explain the purpose of any parameters (e.g., limit, frameId, include_up_for_grabs), failing to compensate for the low coverage.
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?
The description clearly identifies the tool as a search for chores, specifically including unscheduled/template chores that the date-range list cannot return. This differentiates it from sibling tool skylight_list_chores, providing a specific verb and resource.
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?
The description implies usage when needing unscheduled/template chores not available via the date-range list, providing some context. However, it does not explicitly state when to avoid this tool or mention alternatives like skylight_list_chores.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It reveals the operation is destructive (delete) but does not mention permanence, side effects, or the role of the optional frameId parameter. For a mutation tool this is a meaningful gap.
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 a single front-loaded sentence with zero filler. Every word contributes meaning, and it is appropriately brief for a simple bulk-delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description is too sparse to fully specify invocation. It omits the meaning of listId and frameId, provides no usage boundaries relative to sibling tools, and does not describe the result of a successful bulk delete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only item_ids has a description). The description adds no clarification for listId or frameId and only weakly corresponds to item_ids via 'list items'. It does not compensate for the low schema coverage.
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?
The description states a specific verb ('Bulk-delete') and resource ('list items'), clearly identifying a batch deletion operation. 'Bulk' and 'specific' implicitly distinguish it from the singular sibling skylight_delete_list_item and the clear-all sibling skylight_clear_list, though it does not name them explicitly.
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?
The term 'Bulk' implies this tool should be used when deleting multiple specific list items, but there is no explicit guidance on when to choose it over skylight_delete_list_item for a single item or skylight_clear_list for all items. The usage context is only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. It discloses that points can be granted or deducted, but it does not describe side effects such as balance updates, whether negative balances are allowed, authorization requirements, or what the tool returns after execution.
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 a single compact sentence with no filler. It communicates the core operation immediately and every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too sparse. It leaves out the meaning of frameId, any behavioral consequences, return value expectations, and guidance relative to reward-related sibling tools, so it is not complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents 'points' and 'category_ids', and the description essentially restates that information without adding new meaning. The frameId parameter remains completely undocumented, and the description does not clarify its role or relationship to the other parameters.
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 uses a specific verb ('Grant or deduct'), a clear resource ('reward points'), and a target ('family members'). It is distinct from siblings like skylight_get_reward_points, skylight_create_reward, and skylight_redeem_reward, so an agent can tell what operation this performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the operation but gives no guidance on when to choose this tool over alternatives such as skylight_redeem_reward or skylight_get_reward_points. It also does not mention prerequisites like having an existing reward category or whether points can go negative beyond the schema note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Create a reward' and lists fields; it does not explain side effects, required permissions, validation behavior, idempotency, or what happens on success/failure. The phrase 'live-verified fields' is vague and does not meaningfully disclose behavior.
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?
The description is a single, action-first sentence with a compact parenthetical field list. It is concise and efficient, though 'live-verified fields' is an unclear phrase that slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, no annotations, and no output schema, this description is too thin. It does not explain return values, side effects, prerequisites, or the meaning of frameId, leaving important gaps for an agent deciding how to call the tool correctly.
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 descriptions already cover 4 of 6 parameters, and the description enumerates five field names, which partially helps identify relevant inputs. However, it adds little semantic meaning beyond the schema and does not clarify the purpose of frameId or the 'description' parameter.
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 states a specific verb and resource: 'Create a reward.' It also enumerates the main fields involved, making the tool's purpose unmistakable and distinguishable from update_reward, delete_reward, list_rewards, and get_reward siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus update_reward, or about prerequisites for creating a reward. The imperative 'Create' only restates the tool's name and does not provide context, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral details, but it only mentions 'raw provider attributes' without explaining side effects, required permissions, or error states. Leaves significant ambiguity.
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?
Extremely concise—single sentence with no fluff—but risks underspecification. The word 'advanced' is informative but could be expanded without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, nested object parameter, and two parameters, the description lacks essential details like how to obtain frameId, return value, or failure behavior. Incomplete for reliable use.
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 covers 50% (attributes only). Description adds context ('raw provider-specific') to attributes, but frameId remains undocumented. Does not fully compensate for the missing parameter description.
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 clearly states the action ('Create') and the resource ('source calendar'), with the qualifier 'from raw provider attributes (advanced)' specifying the method and intended audience, distinguishing it from other calendar-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like skylight_add_webcal or skylight_link_apple_calendar. The 'advanced' hint implies non-default use, but lacks explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states the action without disclosing behavioral details such as whether the invitation requires acceptance, any limits, or the role of frameId. For a mutation tool, this lacks depth.
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?
Single sentence, front-loaded with verb and resource, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and only 2 parameters with one undocumented. The description fails to provide enough context for an agent to understand the full workflow, such as what happens after inviting or what a 'frame' is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: email has description, frameId has none. Description adds 'by email' but does not explain frameId. With moderate coverage, the description should compensate but does not clarify the optional parameter's purpose.
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?
Description clearly states 'Invite a user to the frame by email', providing specific verb, resource, and method. It distinguishes from siblings like skylight_list_frame_members, skylight_approve_user, and skylight_remove_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites, when not to use, or suggest sibling tools for related actions like approving or listing members.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states that the tool lists chores with a date range, but reveals nothing about return format, pagination, ordering, or side effects. Agents cannot assess safety or completeness of results.
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?
The description is a single, clear sentence with no unnecessary words. It conveys the essential purpose and constraint, though it could be slightly more structured without loss of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is insufficient. It omits details about response format, whether the list is paginated, how frameId affects results, and potential limitations like timezone handling.
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 67% (after and before have descriptions), and the description reiterates the required date range. It adds no meaning beyond the schema for after/before and does not describe the frameId parameter at all.
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 clearly states the tool lists chores for a Skylight frame with a required date range, using a specific verb and resource. It distinguishes from siblings like skylight_search_chores (search vs list) and skylight_complete_chore (action vs listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like skylight_search_chores. It does not mention prerequisites, exclusions, or contexts where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. It indicates a state change ('Set'), but does not disclose whether this affects only future events, whether existing defaults are overwritten, what permissions are required, or whether the change is scoped to a household, frame, or user.
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 a single clear sentence with no filler or redundancy. It front-loads the core action and target resource efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, a missing description for 'frameId', and no output schema, the description is too sparse. It establishes the basic purpose but leaves important context about parameter meaning, side effects, and result behavior unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents only 'id' (50% coverage) and leaves 'frameId' completely undescribed. The description does not compensate by explaining how the parameters relate or what 'frameId' means, so an agent cannot confidently populate both parameters.
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 names a specific verb ('Set'), a specific resource ('default source calendar'), and the scope ('for new events'). This clearly distinguishes it from sibling operations like creating, listing, or categorizing source calendars.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as skylight_update_calendar or skylight_create_source_calendar. The description implies a configuration purpose but does not state when the default should be changed or what alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the operation discards the intent and its drafts, which is meaningful behavioral information. However, it does not state whether the action is reversible, whether it requires any confirmation, or whether it affects related items beyond drafts, such as generated events or photos.
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?
The description is a single concise sentence with no filler. It is front-loaded with the action and object. It could add a bit more scoping detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is thin. It does not explain return behavior, side effects on related entities, prerequisites (e.g., intent must exist and be in draft state), or the relationship between the two parameters. The sibling set shows this is part of a larger auto-creation workflow, and the description leaves the workflow context underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It does not explain what 'id' refers to (an auto-creation intent ID vs. a draft ID) or what 'frameId' is for. The agent must infer from the tool name and sibling tools, which is risky.
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?
The description uses a clear verb-resource pair ('Undo/discard an AI auto-creation intent and its drafts') and identifies the exact object being acted on. It is distinguishable from the sibling auto-creation tools (approve, list, get), though the phrasing 'and its drafts' could imply broader side effects than just the intent.
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?
The description implies this is used to discard an AI auto-creation intent before approval, but it does not explicitly state when to use it versus approving or listing intents. The sibling context provides enough signal, but the description itself gives no when-to-use or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It adds 'verified live' but that phrase is vague and unexplained; it does not state whether creation is immediate, whether permissions are required, what side effects occur, or what the response contains.
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?
The description is a single efficient sentence that front-loads the verb and the core object. The parenthetical is useful, though 'verified live' is vague and slightly wasteful; overall it is appropriately compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 12-parameter creation tool with no annotations and no output schema, yet the description provides only a one-line purpose and no guidance on required inputs, optional modifiers, return behavior, or constraint interplay. The schema does some work, but the description is not complete enough for a tool this complex.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, so the schema documents most parameters, but the tool description adds essentially no parameter-level meaning beyond the RRULE hint. The description does not compensate for the four undocumented parameters (frameId, emoji_icon, description, reward_points) or clarify the relationship between category_ids and up_for_grabs.
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 uses a specific verb-resource pair: 'Create a recurring chore or routine,' and it adds recurrence semantics via 'repeats per an RRULE.' The word 'recurring' clearly separates this tool from the sibling skylight_create_chore without requiring the agent to inspect that tool.
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 'recurring' qualifier and RRULE mention: this is the tool for repeating chores/routines. However, it never explicitly states when to use this versus create_chore, create_task, or create_event, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It communicates that the action is a deletion, but does not disclose whether deletion is permanent, whether it affects albums or shared copies, what happens to photos, or whether specific permissions are required.
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?
The description is a single front-loaded sentence with no filler words. It is efficient and easy to parse, though its brevity comes at the expense of behavioral guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive bulk operation with no annotations, no output schema, and an undocumented optional frameId parameter. The description does not explain return behavior, scope constraints, or consequences of deletion, leaving an agent under-informed for a potentially irreversible action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents message_ids as 'Message/photo ids to delete', but frameId has no description. The tool description's reference to 'the frame' is not explicitly tied to frameId, and it does not clarify ID formats, whether frameId is optional, or how it scopes deletion.
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 states a specific verb ('Bulk-delete'), a specific resource ('messages/photos'), and a location ('from the frame'). It distinguishes this tool from the sibling skylight_delete_message by emphasizing bulk deletion.
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?
The word 'Bulk-delete' implies this is intended for deleting multiple messages/photos at once, and the singular sibling skylight_delete_message plausibly covers single deletions. However, there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only states what data is returned, not behavioral traits like idempotency, authentication needs, or error handling. For a read operation, it should at least indicate it is read-only.
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 a single concise sentence that directly states the function and output. No unnecessary words or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter descriptions, the description provides minimal context. It adequately states the core purpose but leaves gaps about the parameter, idempotency, and return format. It is minimally viable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'frameId' has no description in the schema (0% coverage) and the tool description does not explain its meaning or role. The phrase 'per family member' does not clarify what frameId represents, leaving the agent to guess.
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 clearly states the verb 'Get', the resource 'reward-point balances', and the scope 'per family member' including both 'lifetime earned + current balance'. It effectively distinguishes from sibling tools like skylight_list_rewards or skylight_get_reward.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context. The description lacks information about typical use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not specify what 'recently' means, how many emails are returned, or any other behavior like filtering or authentication needs.
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?
The description is a single concise sentence with a clear subject and purpose. It could benefit from a bit more structure, but it is not overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and only one optional parameter, the description lacks completeness. It does not describe the output format or limitations of the list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the sole parameter 'frameId' at all. The description adds no meaning beyond the schema.
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 clearly states the tool lists recently-invited email addresses and explicitly connects it to filling the invited_emails field of create_event. This distinguishes it from siblings like skylight_list_events or skylight_invite_user.
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 says 'handy for filling create_event invited_emails,' which gives a concrete use case. It does not explicitly mention when not to use it or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the mutation action and does not mention validation failures, idempotency, reversibility via uncomplete_chore, or side effects.
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 a single front-loaded sentence with no filler. Every word contributes to identifying the tool's function, and the scoping qualifier 'specific occurrence of a recurring chore' earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, no annotations, and no output schema, one sentence is insufficient for confident invocation. The description omits how to identify the recurring chore via id/frameId, the conditional category_id semantics, and what a successful call returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 60% of parameters and includes useful conditional notes for category_id, instance_time, and instance_date, but id and frameId remain unexplained. The description adds no parameter-level meaning beyond 'specific occurrence,' leaving key identifiers ambiguous.
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 states a specific verb ('Mark...complete') and a precise resource ('a specific occurrence of a recurring chore'). The phrase 'specific occurrence' distinguishes it from sibling skylight_complete_chore without requiring the agent to inspect schemas.
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?
The description implies this tool is for recurring chore occurrences, but it does not explicitly name alternatives or state when not to use it. The agent must infer the boundary against skylight_complete_chore from the word 'recurring' and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. 'Get' implies a read-only operation, and the parenthetical '(its status + draft results)' explains what the tool returns. However, it does not disclose output structure, error behavior, or any side effects, though for a simple read tool this is acceptable.
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 a single, front-loaded sentence with no fluff. The parenthetical adds useful detail about return contents, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and two undocumented parameters, the description is too thin. It summarizes the return value but omits parameter semantics and usage guidance, leaving an agent to infer too much from sibling names and the bare schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter. The name 'id' is partially clarified by the tool purpose as the intent id, but 'frameId' is left completely unexplained. The description fails to compensate for the schema's lack of descriptions.
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 states a specific verb ('Get') and a specific resource ('an AI auto-creation intent'), and further clarifies that it returns both status and draft results. This distinguishes it from sibling tools like list_auto_creation_intents, approve_auto_creation, and undo_auto_creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance about when to use this tool versus alternatives. An agent can infer that 'get' means retrieving a single intent by id, but the description does not state conditions, prerequisites, or mention sibling tools such as list_auto_creation_intents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the basic action, with no details on return format, permissions, prerequisites, or side effects. The description is too minimal to inform the agent about behavior beyond the surface.
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?
The description is a single, front-loaded sentence with no fluff. It efficiently conveys the core purpose, though it could include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with 2 parameters and no output schema, the description is adequate but not complete. It covers the primary action but misses parameter explanations and usage context that would help an agent invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should add meaning to the parameters. It mentions 'by id' but does not explain the 'frameId' parameter or clarify the format of 'id'. The description adds minimal value beyond the schema.
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 clearly states the verb 'Get', the resource 'calendar event', and the method 'by id'. It is specific and distinguishes this tool from siblings like skylight_list_events (list multiple) and skylight_create_event (create).
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?
The description implies usage when you have a specific event ID, but it does not provide explicit guidance on when to use this tool vs alternatives (e.g., list_events first) or any exclusions. Context is clear but lacks depth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states it 'gets' a frame, offering no information about authorization, rate limits, or other behavioral traits. The description does not contradict any annotations as none exist.
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 a single, front-loaded sentence with no unnecessary words, making it highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, and the description implies a response containing the frame and its settings. However, without an output schema, the description could be more explicit about the structure or scope of the response.
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?
The input schema has 100% coverage for the single parameter 'frameId' with its description already explaining it defaults to the resolved frame. The tool description adds no additional meaning beyond what the schema provides.
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 clearly states the verb 'Get' and the resource 'one Skylight frame and its settings', distinguishing it from sibling tools like skylight_list_frames (list all frames) and skylight_update_frame (update a frame).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as skylight_list_frames for listing all frames or skylight_update_frame for modifying a frame.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states that it lists messages, omitting details like pagination, ordering, filtering, or authentication requirements.
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?
A single, front-loaded sentence contains all necessary information without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description is adequate but lacks details on output format, pagination, or filtering nuances.
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 0% and frameId has no description. The description adds meaning by implying messages are associated with a 'frame', but does not explain the parameter's purpose, format, or default behavior.
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 'List messages posted to the Skylight frame' uses a specific verb ('List') and resource ('messages'), clearly distinguishing it from siblings like skylight_get_message (single message) and skylight_delete_messages (delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as skylight_get_message or other list tools. There are no when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions listing and default time range. Fails to disclose read-only nature, authentication needs, rate limits, pagination, or empty result behavior.
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?
Single sentence, 12 words, front-loaded with key action. Efficient but omits parameter detail; could expand slightly without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple list tool: states resource, context, default filter. However, no result description (output schema absent), no parameter details, and no mention of required permissions. Leaves gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0% and description adds no parameter explanations. 'defaulting to last 30 days' hints at date parameters but doesn't specify format or that redeemed_at_min/max set range. Parameter names are self-explanatory but lack validation guidance.
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?
Description clearly states verb 'List', resource 'redeemed rewards', and scope 'for a Skylight frame' with default time range. Distinguishes from siblings like skylight_get_reward (single) and skylight_create_reward.
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?
Implies usage for recent redeemed rewards via default 30 days, but no explicit when-not or alternatives. Missing prerequisites like requiring frameId, and no contrast with skylight_get_reward or skylight_redeem_reward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It only restates the operation without disclosing that the underlying messages are not deleted, whether removal is reversible, what permissions are needed, or what happens to messages already on frames. The phrase 'from albums' hints at non-destructive removal but does not make it explicit.
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 a single front-loaded sentence with no filler or repetition. It earns its place by stating the action and scope clearly, without boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 0% schema description coverage, this minimal description leaves important context missing: the role of frameId, the side effects of removal, and error/disambiguation behavior. It is insufficient for reliable invocation in ambiguous situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It maps album_ids and message_ids to the operation, but frameId is entirely unexplained and no parameter-level detail is provided. An agent cannot tell what frameId does or how the arrays are interpreted beyond their names.
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 uses a specific verb ('Remove'), names the resource ('messages/photos'), and names the container ('albums'), which makes the operation unambiguous. It also distinguishes itself from sibling tools like skylight_delete_messages and skylight_delete_album by scoping the action to album membership rather than deletion.
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?
The usage is implied by the direct statement 'Remove messages/photos from albums' — an agent can infer it is the tool to call when messages should leave an album. However, it gives no explicit conditions, prerequisites, or alternatives such as when to prefer skylight_delete_messages over this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'Set the global reminder cadence' without explaining if it overwrites, affects existing reminders, or any side effects. Missing details on range, defaults, or authorization.
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 a single, front-loaded sentence that directly states the tool's purpose with no extraneous words. It is appropriately sized for a simple setter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description is adequate but incomplete. It lacks information about default cadence, valid range, or consequences, which could lead to incorrect use by an AI agent.
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 100% and already describes interval_weeks as 'How many weeks between reminder nudges.' The description adds only the vague phrase 'global reminder cadence', which provides no meaningful additional insight beyond the schema.
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 clearly states the tool sets the global reminder cadence, using specific verb 'Set' and resource 'global reminder cadence', and explains what it does ('how often Skylight nudges about reminders'). It is distinct from sibling tools like skylight_list_nudges which only reads nudges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or any context for when settings should be modified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the behavioral burden; it discloses the core effect of removing a like but not edge behavior such as whether removing a non-existent like is an error, whether it affects only the current user, or what the response is.
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?
Eight words with no filler; the verb and object are front-loaded and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity mutation with two parameters and no output schema, the description covers the core call intent but remains thin: no parameter semantics, no return/error behavior, and no guidance around the like_message counterpart. It is minimally viable with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description only hints that id identifies a message/photo. It does not explain the relationship between id and frameId, nor why frameId is optional, so the description only partially compensates for the undocumented schema.
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?
The description states a specific action and resource: 'Remove a like from a message/photo.' It is clear and naturally contrasts with the sibling skylight_like_message, but it never explicitly names that alternative.
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?
The action verb 'remove' implies this tool is used to undo a like on a message/photo, so usage is inferable. However, there is no explicit statement of when to choose this over skylight_like_message or any preconditions such as an existing like.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the add action and omits whether additions are idempotent, whether messages are moved or copied, what happens on invalid IDs, or any permission requirements.
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 a single sentence with no wasted words and the core verb/object is front-loaded. It is concise, though it sacrifices richness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no parameter descriptions, a one-line description leaves frameId, return behavior, error cases, and add semantics undefined. This is acceptable for a very simple tool but not fully sufficient for robust agent invocation.
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?
With 0% schema description coverage, the description's mention of 'messages/photos' and 'albums' provides the only meaning for message_ids and album_ids. However, the optional frameId parameter is completely unexplained, and the relationship between the two required arrays is left implicit.
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 states a specific action ('Add') and exact targets ('messages/photos to albums'). This clearly separates it from siblings like skylight_remove_from_album and skylight_create_album, so an agent can distinguish the tool without opening its schema.
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?
The usage context is only implied by the verb 'Add'. It does not explicitly state when to prefer this tool over alternatives or mention any exclusions, though the intended use case is reasonably inferable from the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals the core behavioral consequence — draft events become real calendar events. However, with no annotations, it leaves important operational traits undisclosed, such as whether approval is reversible, whether drafts are removed afterward, or what permissions are required.
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?
A single, front-loaded sentence that conveys the action and the state change with no filler. It earns its place and is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutating approval action with no annotations and no output schema, so the definition should do more to support safe invocation. Missing pieces include when to use it in the auto-creation workflow, whether it is reversible, and the purpose of frameId.
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?
The schema already documents id and ids, so the description adds little parameter-level meaning. The relationship between the required id and ids is unexplained, and frameId has no schema or description-level documentation.
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 states a precise verb ('Approve') and resource ('AI-drafted events') and specifies the outcome: turning drafts into real calendar events. This clearly distinguishes it from generic create_event and from companion tools like skylight_undo_auto_creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool rather than list_auto_creation_drafts, undo_auto_creation, or create_event. The only usage signal is the verb itself, with no workflow context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only states the basic function without disclosing behavioral traits such as read-only nature, pagination behavior, required permissions, rate limits, or any side effects. For a read tool, this is minimal transparency.
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?
The description is a single sentence of 10 words, which is concise and front-loaded with the key action. However, it lacks structural elements like bullet points or headings that could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (2 required) and no output schema, the description covers the basic purpose but does not explain the return format, pagination, or how results are ordered. It is adequate but not complete.
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 75%, and the tool description adds no additional meaning beyond what the schema provides (e.g., date ranges, timezone). Baseline 3 is appropriate since the schema already explains the parameters.
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 clearly states the verb 'list', the resource 'calendar events', and constraints 'in a date range for a Skylight frame', which distinguishes it from sibling tools like skylight_get_event or skylight_create_event.
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?
The description implies usage when listing events in a date range but does not explicitly state when to use this tool versus alternatives (e.g., skylight_get_event for a single event, skylight_search_chores for other resources). No 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a notable behavioral trait: converting a label into a family-member profile via linked_to_profile. However, it does not explain side effects, reversibility, required permissions, or what happens to existing category data. With no annotations, the description carries the burden, and this is only partially met.
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?
Single, well-structured sentence with the primary action front-loaded and specific use cases in a dash-delimited list. Every word earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and partial parameter documentation, the description is too thin. It does not explain return values, failure conditions, prerequisites, or the implications of converting a category to a family-member profile.
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?
The description adds semantic grouping by mapping 'rename/recolor' to label/color and the conversion to linked_to_profile. But schema coverage is only 57%, and frameId, avatar_id, and selected_for_chore_chart have no descriptions or contextual explanation, leaving meaningful gaps.
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 states a specific verb and resource — 'Update a category' — and then details concrete actions: rename, recolor, or convert a label into a family-member profile. This clearly differentiates it from sibling tools like create_category, delete_category, and list_categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives such as update_family_member or create_category. The only usage signal is the word 'Update,' which implies an existing category but does not state prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It does add one useful behavioral trait: the source frame is 'inferred from the app bundle, not live-verified.' However, it omits other material behaviors like whether copying is non-destructive to the originals, whether duplicates are created, or any required permissions. Partial transparency is present, but significant gaps remain.
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 a single efficient sentence with the core action front-loaded and the caveat tucked into parentheses. Every word earns its place; there is no filler or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is fairly simple, but with no output schema and no annotations, the description should clarify more. It fails to state what the source frame parameter is for when not inferred, and it says nothing about the return value or failure behavior. The existing caveat is helpful, but an agent could not fully anticipate how to specify a source frame or what a successful copy returns.
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 67%, so the description should compensate for the undocumented frameId. It partially does by referring to 'this frame' and explaining the app-bundle inference, but it never explicitly maps frameId to the source frame. The descriptions for message_ids and new_frame_ids are already in the schema, though the schema's note to list frames adds value.
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 states a specific action ('Copy'), the resource ('messages/photos'), and the destination ('other frames on the account'). It clearly distinguishes the tool from related siblings like skylight_delete_messages or skylight_like_message, since copying is a unique operation. The phrasing 'from this frame' is understandable in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, such as moving or deleting messages, or how it relates to skylight_add_to_album. The caveat about app-bundle inference is a behavioral note, not usage direction. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. 'List' makes the read-only nature clear, and the description adds useful scope context (general vs event-only drafts). However, it does not disclose pagination, response format, or any requirements beyond the implied id relationship.
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?
A single sentence delivers the core purpose, examples, and a useful contrast with the sibling tool. There is no wasted wording or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, and the description fails to clarify the key parameters needed to call it correctly. An agent would need to inspect sibling tools or infer the id semantics from the tool name and context, so the description is not self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain what the required 'id' refers to (presumably an AI intent id) or what 'frameId' does. An agent has to guess at the meaning of both parameters from context alone, which is insufficient.
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 uses a specific verb ('List') and resource ('draft items an AI intent created'), gives concrete examples (meal sittings, activities, list items), and explicitly distinguishes itself from the event-only draft list. This makes the tool's purpose unmistakable and differentiates it from its siblings.
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?
It clearly conveys that this is the general draft reader and that the event-only draft list does not surface these items, so the agent knows when this tool is the right choice. However, it stops short of explicitly naming the alternative tool or stating a when-not-to-use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states this is a list operation on the account, implying read-only behavior, but provides no details on authentication, rate limits, or output format. With no annotations, more transparency would be beneficial.
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 a single 10-word sentence with no unnecessary words. It is perfectly concise and front-loaded with the key action and resource.
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 tool has no parameters and no output schema, the description adequately states what it does (list frames) and the scope (on this account). It could mention result format but is sufficient for a simple listing.
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?
The input schema has no parameters, and schema description coverage is 100%, so the description does not need to add param details. Baseline score of 3 is appropriate as it adds no extra meaning beyond the schema.
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 uses a specific verb 'List' with resource 'Skylight frames (family hubs)', clearly distinguishing from sibling tools like skylight_get_frame (retrieve a single frame) and skylight_update_frame (modify). The inclusion of '(family hubs)' adds clarifying context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, such as skylight_get_frame for a specific frame. No when-not or usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It states 'Get' (a read operation) but fails to mention authentication requirements, error states (e.g., not a Plus member), or any side effects. Minimal value beyond the verb.
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 a single, clear sentence that front-loads the action and resource. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with zero parameters and no output schema, the description is adequately complete in terms of purpose. However, it lacks behavioral context (e.g., what if not entitled). A bit more detail would be helpful.
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?
No parameters exist, and schema coverage is 100% trivially. With 0 parameters, the baseline is 4. The description adds no additional parameter info, but none is needed.
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?
Description uses specific verb 'Get' and clearly identifies the resource 'Skylight Plus subscription / entitlement status'. This distinguishes it from many sibling tools that get other entities.
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?
No explicit when or when-not guidance is provided. Usage is implied by the tool's name and description, but alternatives are not discussed. Acceptable for a simple retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool 'reopens' a chore, indicating status change, but does not mention side effects, permissions, error states, or behavior for non-recurring chores when instance_date is omitted. Some behavioral context but not comprehensive.
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?
Single sentence that front-loads the action and parameters. No redundancy or extra information; every part is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the core functionality and optional parameters for recurring chores. However, it lacks explanation of frameId, behavior for recurring chores without instance_date, and error/success outcomes. Adequate but with clear gaps.
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 50%, with descriptions for instance_date and instance_time. The description adds meaning by explaining that instance_date is for reopening a single recurring occurrence. However, id and frameId lack descriptions both in schema and description. Overall, adds some value beyond schema but doesn't fully compensate for gaps.
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?
Description clearly uses verb 'Reopen' and resource 'chore', and distinguishes between a single chore and an occurrence of a recurring chore by mentioning instance_date. It is distinct from sibling tools like skylight_complete_chore and skylight_complete_chore_instance.
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?
Description implies usage for reverting a completed chore, but does not explicitly state when to use this over alternatives such as skylight_complete_chore or skylight_complete_chore_instance. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With destructiveHint=true already present, the description adds meaningful behavioral context by clarifying that deletion can target a single occurrence or the whole series. It is consistent with the annotation and adds nuance beyond it.
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?
A single short sentence with no wasted words. The core action is front-loaded and the optional scope is expressed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a basic destructive tool but leaves gaps: it does not mention the confirm/preview behavior, frameId semantics, or how non-recurring chores behave. The schema fills some of this, but the description alone is lean for a 4-parameter destructive operation with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, leaving id and frameId undocumented. The description restates the occurrence-vs-series choice already present in apply_to's schema description, but it does not add meaning for the undocumented params, and with low coverage the description needed to compensate.
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 states the exact operation ('Delete') and resource ('a chore'), and adds a scope nuance ('optionally a single occurrence or the whole series'). This clearly distinguishes it from sibling delete tools for other resources.
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 is implied by the verb and resource name, but the description gives no explicit guidance on when to choose this over alternatives such as completing, updating, or uncompleting a chore. There are no exclusions or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose the core mutating effects: renaming and hiding from slideshow. However, it omits behavior around frameId, whether updates are partial or full, permissions, and response/error behavior.
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?
A single front-loaded sentence with no filler: it states the action, the resource, and the specific supported behaviors. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter mutation tool with no annotations and no output schema, this one-liner is not complete enough. It leaves frameId semantics undefined and gives no indication of return values or error behavior, even though it covers the most common rename and hide use cases.
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 only 25%, so the description must compensate. It helps by mapping 'rename' to title and 'hide from slideshow' to exclude_from_slideshow, but frameId remains completely unexplained in both the schema and the description, making the compensation incomplete.
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 the verb 'Update' and resource 'photo album', then concretely lists the supported operations ('rename, hide from slideshow'). This clearly distinguishes it from sibling album tools like create_album, delete_album, add_to_album, and remove_from_album.
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 parenthetical provides clear intended usage contexts: renaming an album or hiding it from slideshow. It does not explicitly mention alternatives or exclusions, but the stated operations give an agent enough context to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It usefully discloses that the tool is asynchronous and that it creates draft events rather than returning finalized events immediately. It does not explain what happens after drafts are created or how results are surfaced, but the side-effect and async traits are meaningfully stated.
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?
A single concise sentence front-loads the core purpose and adds two critical behavioral qualifiers—draft creation and asynchronicity—without any filler. Every phrase contributes information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generation tool with no output schema and no annotations, the description is adequate but leaves gaps. It does not say how the agent should discover the resulting drafts or whether approval is required, and it does not mention the sibling auto-creation draft tools that are likely relevant.
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 high at 86%, so the schema already documents the parameters well. The description adds little beyond mapping to 'location' and 'time range', which are already represented by physical_location and datetime_range_start/end. Baseline 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 names a specific action (generate AI activity/event ideas), a resource scope (location and time range), and a concrete side effect (creates draft events, async). This clearly distinguishes it from event CRUD tools and the sibling skylight_generate_meal_plan.
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?
The description implies when to use the tool: when AI-generated activity ideas are needed for a given location and time range. However, it gives no explicit guidance about when not to use it or which sibling tools cover related but different cases, such as generating meal plans or managing existing drafts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. 'List' conveys a read-only operation, and the description usefully explains that drafts are events for some engines but items for meal/activity engines. It doesn't mention pagination or return details, but the core behavioral context is present.
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?
Two concise sentences, front-loaded with the operation and resource, followed by a necessary sibling-tool redirection. No filler or redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The purpose and sibling distinction are clear, but the tool has no annotations, no output schema, and completely undocumented parameters. An agent cannot reliably construct a valid call because the required 'id' is undefined in both the schema and the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description gives no meaning for the required 'id' or optional 'frameId' parameters. The required 'id' is typed as both string and number, so an agent cannot determine whether to pass an intent ID, draft ID, or frame ID.
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 uses a specific verb ('List') and a specific resource ('events an AI intent drafted'), and clarifies the purpose is review before approving. It also explicitly distinguishes this tool from skylight_list_auto_creation_items, so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the intended workflow ('for review before approving') and gives an explicit alternative for meal/activity engines: 'use skylight_list_auto_creation_items instead.' This is direct when-to-use vs. alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It clearly reveals that the tool is asynchronous, that it only creates drafts rather than final meals, and that polling and approval are required. This is valuable transparency, though it does not cover side effects such as whether grocery list items are created immediately.
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 a single sentence with a parenthetical that packs in the key workflow information. Every part earns its place, and the main action is front-loaded.
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 no output schema and no annotations, the description still provides enough for an agent to understand the async draft/approval flow and the next tool to call. It is slightly incomplete in not describing what the immediate response will contain, but the polling step mitigates that 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 description coverage is 67%, and the description adds no parameter-specific meaning beyond what the schema already provides. The required parameters are documented in the schema, but the description does not compensate for undocumented parameters like frameId or add_to_grocery_list.
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?
The description states a specific verb ('Generate'), a resource ('AI meal plan for the given dates'), and a concrete result ('creates draft meal sittings'). It is clear about what the tool does, though it does not explicitly differentiate from the closely related sibling skylight_plan_meal.
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 gives an explicit follow-up workflow: the operation is async, the agent should poll skylight_get_auto_creation_intent, and then approve. This is strong context, but it does not state when to prefer this tool over alternatives like skylight_plan_meal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that linked_to_profile and selected_for_chore_chart must be combined to create a full chore-chart member and explains the avatar workflow, but it does not state success results, failure modes (e.g., duplicate label), or side effects of linked_to_profile such as user creation.
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?
Two compact, front-loaded sentences. The first states the primary action, and the second delivers the two most important workflow caveats (flag combination and avatar sourcing) with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-param create tool with no output schema and no annotations, the description covers purpose, flag semantics, and avatar flow, but leaves frameId's role unexplained and never states what the call returns or whether duplicate labels are rejected.
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 83%, so baseline is 3, and the description adds real value beyond it: it instructs agents to set linked_to_profile and selected_for_chore_chart together for a full member and tells them exactly where to source avatar_id. Only frameId remains unexplained in both schema and description.
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 category / family member on the frame') with location scoping. The wording clarifies that category and family member are the same entity, and the name contrasts clearly with sibling create/update/delete category tools.
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?
Names skylight_list_avatars as the source for avatar_id and skylight_set_member_avatar as the route for custom photos, giving concrete workflow guidance. It does not explicitly exclude this tool for updating existing members (skylight_update_category), but the create/update split is implied by naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the shape of the listing by explaining that each sitting carries `instances`, `meal_category`, `meal_recipe`, and `profiles`, and it implies a read-only operation via 'List'. It does not cover pagination or ordering, but the core behavior is clear.
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?
Two dense sentences with no filler. The first sentence states purpose and scope; the second explains what the returned sittings contain. Every sentence 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 should compensate by explaining return values, and it does: it enumerates `instances`, `meal_category`, `meal_recipe`, and `profiles`, including the breakfast/lunch/dinner domain. The optional `frameId` behavior is absent, but the core date-range listing scenario is sufficiently documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents `date_min` and `date_max` with format and inclusivity, so the description adds little beyond echoing the date-range concept. The optional `frameId` parameter has no schema description and is not explained in the tool description either, leaving a real gap for agents.
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?
Description uses a specific verb ('List') plus a concrete resource ('planned meals / meal sittings') and clearly scopes it to a date range. It also distinguishes the tool from siblings like `skylight_plan_meal`, `skylight_generate_meal_plan`, and `skylight_list_meal_categories` by describing what actually gets returned.
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 establishes a clear usage context: query the meal plan for a date range and see what is assigned to each day. It does not explicitly name alternatives or state when not to use it, but the read-only listing purpose is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add useful behavioral context by revealing that the member's name is actually a category label and not a field updated here. However, it does not disclose whether the update is a merge or a full replacement, what happens to unmentioned fields, any permission requirements, or the success/error response shape. Some meaningful context is present, but significant behavioral details are missing.
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?
Two sentences, front-loaded with the primary purpose and then a focused routing note. There is no filler, repetition, or tangential information. Every sentence earns its place: the first defines the core operation, and the second prevents a likely misuse by directing name updates to the correct sibling tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is concise but not fully complete. It clearly covers the main purpose and the name/category relationship, but it leaves frameId unexplained and gives no guidance on when or whether it should be provided. An agent might still call this tool correctly for a simple birthday or dietary preference update, but it lacks enough context to confidently handle edge cases or understand the role of all four parameters.
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 50%; only id and birthday have descriptions. The description helps by explicitly naming birthday and dietary_preferences as the updatable profile fields, adding meaning to dietary_preferences which is otherwise undocumented in the schema. However, frameId remains entirely unexplained in both the schema and the description, and no detail is given about how the parameters interact or which are required for a valid update.
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 clearly states the action: 'Update a family member's profile' and names the specific fields (birthday, dietary preferences). It also distinguishes itself from the sibling tool skylight_update_category by explaining that the member's name is a category label and must be set through that tool. This gives an agent a precise, non-tautological understanding of what this tool does and how it fits among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly routes name changes to skylight_update_category: 'The member's name is the category label — set it via skylight_update_category.' This tells the agent when not to use this tool for a common related request and names the correct alternative. The first sentence implies this tool is for profile fields like birthday and dietary preferences, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns a specific object structure on success/failure, and that on mismatch it lists all members. No side effects or auth requirements are mentioned, but for a read-only resolve operation this is acceptable.
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?
Two sentences, front-loaded with purpose, then return format. No redundant information. Every sentence 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?
Despite no output schema, the description includes the return object fields. It covers the essential behavior for a resolve tool. However, it does not explain the 'members' array structure or the 'note' field, and the 'frameId' parameter is unexplained.
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?
The schema describes only 'name' (50% coverage). The description adds context for 'name' by explaining its purpose and the return behavior, but 'frameId' is left undocumented. The description partially compensates but leaves a gap.
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 clearly states the tool resolves a family-member name to a category ID, used by chores/rewards. It distinguishes from sibling tools like list_frame_members by focusing on resolution to an ID. The verb 'resolve' and resource 'member name' are specific.
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 explains the behavior on match and mismatch, including return values. However, it does not explicitly state when to use vs alternatives, though it is implied as a lookup tool. No when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already flags destructiveHint=true, but the description adds crucial behavior beyond that: 'There is no undo', 'without confirm:true this returns a dry-run preview... and makes NO network call', and 'with confirm:true it deletes'. This is valuable safety guidance that the annotation alone does not convey, fully disclosing the tool's side effects and safety mechanism.
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?
Two sentences deliver the core purpose, the three recurrence modes, and the critical safety behavior without wasted words. The most important information (destructive + confirm mechanism) is front-loaded, and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with a safety dry-run, the description covers the key aspects: what it deletes, the three scopes, the confirm requirement, the no-undo caveat, and the network-call behavior. With no output schema, the description adequately explains the preview output. Nothing essential for an agent to call it correctly is missing.
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% — four of five parameters have descriptions (frameId lacks one). The description repeats the apply_to semantics already present in the schema and reiterates the confirm requirement, but does not add new meaning beyond what the schema provides. With high schema coverage, the description carries no additional parameter insight, so the baseline 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 — 'Remove a planned meal (meal sitting) from the meal plan' — and goes on to explain the three recurrence modes via apply_to. This clearly differentiates it from siblings like skylight_update_meal or skylight_delete_recipe, and leaves no ambiguity about the tool's 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 explains when to use each apply_to mode and the confirm/dry-run safety flow, giving the agent concrete behavioral context. It doesn't explicitly contrast with alternative tools, but no sibling performs this exact action, so the guidance is sufficient. A 5 would require explicit 'use this instead of X' statements, which are unnecessary here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only include destructiveHint: true, so the description carries the burden of explaining the mutation's side effects. It does this well by warning that apply_to:'one' and 'future' SPLIT the series into additional sittings rather than editing in place. It does not mention the preview/confirm flow or other side effects, but the key surprising behavior is disclosed.
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?
Three sentences with no waste: the first states what the tool does, the second explains targeting mechanism, and the third warns about the most important behavioral nuance. The critical splitting warning is placed where it is likely to be read before invocation, and the follow-up tool reference is concise and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with recurrence complexity and no output schema, the description is complete enough: it covers the editable fields, the occurrence targeting, the apply_to semantics including the split behavior, and points to the right follow-up tool. The only missing piece, the confirm/preview flow, is already documented in the schema, so the description doesn't need to repeat it.
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 description coverage is 83%, so the schema already documents most parameters. The description adds value by explaining the meaning of apply_to in the context of recurrence ('SPLIT the series into additional sittings') and by emphasizing that the tool targets a specific occurrence via its date. This goes beyond what the parameter list alone states, though some parameters like confirm and frameId are not addressed in the description.
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 states a specific verb ('Update') and resource ('planned meal (meal sitting)'), lists the editable fields (name, recipe, category/slot, notes, date, repeat rule), and clarifies that it targets one occurrence by date. This clearly differentiates it from siblings like skylight_plan_meal or skylight_delete_meal, which create or remove meals rather than modify an existing sitting.
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 gives clear context: use this to update an existing meal sitting, and it even advises re-running skylight_list_meals to inspect the resulting series shape after recurrence changes. It does not explicitly state when not to use it or name alternative tools such as skylight_plan_meal, but the context is sufficient for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation by stating 'List the preset avatar library.' No annotations are provided, but the description clearly indicates no side effects. It could further state 'read-only' explicitly, but the intent is transparent.
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 concise: two sentences with no wasted words. The purpose is front-loaded, and every sentence adds value.
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?
The description adequately explains the tool's purpose and how to use its output. Although there is no output schema, the description hints that avatar IDs are returned. It does not mention pagination or limits, but for a simple list tool, the information is sufficient.
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?
The input schema has no parameters (0 params), so the baseline score is 4. No additional parameter information is needed as the tool requires no inputs.
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 clearly states the tool's function: 'List the preset avatar library (emoji/icon images).' The verb 'list' and resource 'preset avatar library' are specific. It distinguishes itself from sibling tools like skylight_set_member_avatar which sets avatars, not lists them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides when and how to use the tool: 'Use an avatar id with skylight_create_category / skylight_update_category to set a member's avatar without uploading a custom photo.' It provides context for using the output and contrasts with an alternative (uploading a custom photo).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses the two-step S3 signing and registration workflow, and explicitly states that without confirm:true no S3/network call is made. This is valuable behavioral context that helps an agent avoid unintended side effects.
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?
Three sentences, each carrying distinct information: what the tool does, how it works, and the confirm gating behavior. The most important operational detail is front-loaded.
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 no output schema, the description is close to complete: it covers inputs, the confirm flag, the dry-run preview output, and side-effect behavior. Missing explicit return value details for confirm:true uploads and failure modes, but the essential call semantics are present.
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 80%, and the description adds important semantics: image_path must be an absolute resolved path, mime type is detected, and confirm gates the network call. It clarifies the dry-run output structure, though frameId/frame_ids semantics remain mostly schema-only.
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 states a specific verb and resource: upload a photo or video from a local file to the Skylight frame slideshow. It clearly distinguishes the tool from album/message-related siblings by naming the target as the frame slideshow.
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 explains when the tool performs a real upload versus a dry run, and that confirm:true is required for the actual network operation. It does not explicitly name sibling alternatives or conditions for choosing them, but the dry-run/confirm contrast provides strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behaviors beyond the destructiveHint annotation: it uploads to S3, the photo↔intent link is inferred from captured traffic rather than confirmed, the result is best-effort/unverified, and confirm:true is required to trigger side effects. This is far more than the annotation alone provides.
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 clause earns its place: purpose, safety gate, side-effect behavior, verification caveat, and follow-up workflow. It front-loads the core action and critical warning before procedural details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and complex async side effects, the description is unusually complete. It states what the preview returns, when network calls occur, and exactly how to complete the import via sibling tools. Nothing essential for correct invocation is missing.
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?
With 75% schema coverage, the description still adds meaning by clarifying confirm's gating behavior, image_path's role as the absolute path used for the upload, and the dry-run preview. frameId is not addressed in the description, but the overall parameter semantics are substantially enriched by the behavior details.
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 precise verb and resource: 'Import calendar events from a photo of a flyer/invite/schedule using Skylight's AI'. It clearly distinguishes this from sibling tools like skylight_upload_photo and the auto-creation polling/approval tools by naming the event_importer mechanism and the follow-up workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is explicit: without confirm:true it is a dry-run with no S3/network call; with confirm:true it uploads. It also names the exact polling and approval tools to use afterward, making the intended sequence unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the destructiveHint annotation by disclosing that without confirm:true it makes no network call and returns a dry-run preview, and that with confirm:true it uploads. It also mentions multipart/form-data and detected MIME type, providing valuable behavioral context an agent needs to avoid unintended changes.
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?
Three dense sentences with no filler. The core action is front-loaded, the alternative is clearly named, and the critical confirm behavior is placed last but clearly explained. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description tells the agent exactly what to expect: a dry-run preview with resolved image_path and detected MIME, or an actual upload with confirm. It covers the safety-critical behavior, the target resource, and the alternative workflow, making it complete for correct invocation.
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?
The schema already documents id, confirm, and image_path, covering 75% of parameters. The description adds meaning to image_path by specifying 'absolute path to a local image file' and explains confirm's gatekeeping role. The frameId parameter remains undocumented in both schema and description, which prevents a full 5.
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 states a specific verb and resource: 'Set a family member's avatar to a custom photo from a local image file.' It clearly differentiates this tool from the emoji avatar alternative and from related sibling tools by specifying the custom-photo use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool versus the alternative: use skylight_list_avatars + avatar_id on create/update for emoji avatars, and use this tool for custom photo uploads. It also explains the confirm:true requirement and the dry-run behavior without it, giving clear invocation guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

skylight-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![skylight-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/chrischall/skylight-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chrischall/skylight-mcp)

Score Badge

Copy to your README.md:

[![skylight-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/chrischall/skylight-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chrischall/skylight-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chrischall/skylight-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server