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

Annotations provide readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is partially covered. However, the description adds no behavioral context such as required permissions, whether listId must refer to an existing list, what happens if the item label already exists, or what a successful call returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The single sentence is concise and front-loaded with the core action. It wastes no words, though it is arguably too terse to be fully useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With three parameters, no output schema, and zero schema description coverage, the description is too thin. It omits parameter meaning and any behavioral details 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.

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

Schema description coverage is 0%, meaning none of the three parameters are documented. The description does not explain listId, label, or frameId, so an agent cannot know what identifiers are expected or whether frameId is optional.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb+resource: add an item to a list on a Skylight frame. The sibling family includes update_list_item, delete_list_item, and move_list_item, so the 'add' action is distinguishable, but the description does not explicitly differentiate itself from those siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, prerequisites, or alternatives are mentioned. The description leaves the agent to infer that this is for creating a new list item rather than updating or moving one.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the write/visibility profile is covered structurally. The description adds nothing beyond the tautological statement that it comments on a message/photo — no note on who sees the comment, whether it can be removed, or what it returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with zero padding and the key action front-loaded. It is efficient, though so terse that it reads as a fragment rather than a structured definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive write tool with three parameters, only 33% schema coverage, and no output schema, one sentence leaves the agent guessing about the id/frameId relationship and side effects. The annotations carry safety, but the description does not fill the remaining gaps.

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

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

Only 33% of parameters have schema descriptions (body only). The description's phrase 'frame message/photo' loosely hints at the relationship between frameId and the target, but it never explains what 'id' identifies (message id vs. frame id) or how the optional frameId changes behavior, so it fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb ('comment') and resource ('frame message/photo'), which is enough for an agent to know this adds a comment to an existing message or photo. It does not, however, distinguish itself from near siblings such as skylight_set_message_caption or skylight_like_message, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus alternatives, no prerequisite that the message/photo must already exist, and no mention of why one would comment rather than caption or like. Usage is only implied by the name.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds nothing beyond that: it does not say whether ingredients are appended or replace list contents, how duplicates are handled, what permissions are required, or how many items may be created.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with the operation front-loaded and zero filler. Nothing could be trimmed without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple three-parameter write tool with no output schema, the description is minimally viable. However, with 33% parameter coverage and openWorldHint signaling an external service call, it should at least clarify the required id's meaning and whether the operation is idempotent.

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

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

Schema description coverage is only 33% (only list_id is documented), so the description carries extra burden. It does implicitly map 'id' to a recipe and 'grocery list' to list_id, but it never disambiguates the required 'id' explicitly and says nothing about frameId, leaving a real gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource pair ('Add a recipe's ingredients to a grocery list'), so the agent knows exactly what operation is performed and on what. It does not differentiate itself from the closest sibling, skylight_add_list_item, which also writes into a list, leaving the agent to infer the difference from the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not-to-use guidance, no prerequisites, and no mention of alternatives such as adding individual items via skylight_add_list_item. Usage is only 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.

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the agent knows this is a non-destructive mutation reaching external state. The description adds that deduction is possible (negative points), but says nothing about whether deductions can drive a balance below zero, whether the operation is idempotent, or what permissions/scope are needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with the parenthetical clarifying the deduct case; no filler or restatement of the title. It is efficient, though the terseness leaves room that could have been spent on routing guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 output schema and an undocumented frameId, the description is too thin: it omits the tool's relationship to the reward-points read/list siblings and gives no sense of the effect or result of a call. An agent has enough to attempt a call but not enough to choose it confidently over alternatives.

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

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

Schema coverage is 67%: points and category_ids are described in the schema, and the description corroborates that points go to family members. However, frameId has no documentation in either the description or the schema, and the description adds no format or constraint detail beyond the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (grant/deduct) and resource (reward points) with the target (family members), so an agent can distinguish it from reward-related siblings such as get_reward_points, create_reward, and redeem_reward. It stops short of naming those alternatives, so differentiation is implied rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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_get_reward_points (viewing balances), skylight_create_reward (defining a reward), or skylight_redeem_reward. The description only says what it does, leaving the agent to infer the adjacency to the point-balance siblings.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the basic safety profile is covered. The description adds nothing further: it doesn't say whether adding is idempotent, whether it applies to multiple albums at once, or what happens with duplicate membership.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with no padding or wasted words, but it is under-specified rather than genuinely concise for a mutating tool with three parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema, 0% schema coverage, an undocumented frameId, and only minimal annotations, the description leaves too much for the agent to infer about required context and side effects.

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

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

Schema description coverage is 0%, so the description must carry the burden. It only loosely implies album_ids and message_ids; the required frameId parameter is never mentioned, and there is no info on accepted ID formats (string or number) or batching behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (add) and both the resources being moved (messages/photos) and the destination (albums), which distinguishes it from siblings like skylight_remove_from_album and skylight_create_album. The mention of 'photos' is slightly misleading since the schema only accepts message_ids and album_ids.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus skylight_remove_from_album, skylight_copy_messages_to_frames, or skylight_create_album. No prerequisites, constraints, or conditions are stated.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the write/external nature is covered. The description's phrase 'subscribe the frame' adds the useful nuance that this creates an ongoing external subscription tied to a frame, but it says nothing about duplicate subscriptions, replacement behavior, or permissions. Adequate but thin against the annotation baseline.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with the verb and target front-loaded and no filler. It is efficient, though it is arguably too terse to carry the guidance an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating, open-world tool with an undocumented frameId and no output schema, the description leaves key operational questions unanswered: which frame is targeted by default, what happens if the URL is already subscribed, and whether Plus/subscription access is required. The one-sentence description is insufficient for this complexity.

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

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

Schema coverage is 50%: sync_url is documented in the schema, but frameId has no description anywhere. The description references 'the frame' without explaining how frameId is supplied, whether it is optional, or how a default frame is resolved, so it does not compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: 'Subscribe the frame to a webcal/ICS calendar URL.' An agent understands this adds an external calendar subscription. However, it does not distinguish itself from siblings such as skylight_create_source_calendar or skylight_link_apple_calendar, which sound like they do overlapping work.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no prerequisites, and no mention of alternatives, despite several calendar-related siblings (create_source_calendar, link_apple_calendar, update_calendar) that an agent could easily confuse with this one. Usage must be inferred entirely from the name.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the write nature and safety profile are covered structurally. The description adds that drafts are converted into real calendar events, which is useful semantic context, but it omits reversibility (an undo sibling exists), whether repeated approvals are idempotent, and any auth/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.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no filler; the core action and outcome come first. It is a touch terse given the gaps in usage and parameter explanation, but there is no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 would ideally say what the agent gets back or what state changes occur. For a mutation tool with annotations covering safety, the description is minimally adequate but leaves the intent-id/draft-id workflow and undo relationship unclear.

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

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

Schema coverage is 67%: 'id' (intent id) and 'ids' (draft event ids) are both described in the schema, but 'frameId' is undocumented. The description adds nothing about the id vs ids relationship, so it neither compensates nor detracts; the baseline of 3 fits a moderately documented schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('approve AI-drafted events') and clarifies the effect ('turns them into real calendar events'), which separates it from read-only siblings like skylight_list_auto_creation_drafts. It does not explicitly distinguish itself from the closely related skylight_undo_auto_creation, but the action direction is unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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_get_auto_creation_intent, skylight_list_auto_creation_drafts, or skylight_undo_auto_creation. There is no mention of prerequisites (e.g., needing a prior intent id) or when approval is appropriate.

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

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

Annotations flag this as destructive/open-world, but the description adds substantial behavioral detail the annotations cannot: it discloses that a confirmation is required, that a first call may return only a preview plus confirmToken, and that only a repeated call with that token proceeds. It also states the preview names the user and frame.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and consequence, then the confirmation mechanics. Every sentence addresses a distinct concern (purpose, confirmation prompt, token fallback, preview contents) with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, no-output-schema tool, the description covers the risky interaction flow thoroughly, including the elicitation fallback and return of a preview. It is slightly thin on disambiguating id vs frameId, but overall sufficient to invoke correctly.

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

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

Schema coverage is only 33%; confirmToken is richly documented in the schema, but id and frameId have no schema descriptions. The phrase 'the preview names the user and frame' partially implies that id identifies the user and frameId the frame, so the description compensates somewhat but not fully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Approve a pending frame user — grants them access to the frame.' No sibling performs this action (invite_user invites, remove_user revokes), so the tool is unambiguous without naming alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear invocation context by spelling out the confirmation flow (prompt where supported, otherwise preview+token), which an agent must understand to call it correctly. It does not, however, name when to use this versus sibling user-management tools.

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

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

Annotations already disclose readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond the annotations: it does not say whether attribution replaces existing category assignments or appends to them, whether it affects already-imported events, or what permissions are required for 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no wasted words, correctly leading with the action. It is perhaps too terse for a mutation tool, but structurally sound.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter mutation tool with no output schema, the description is minimally adequate but leaves the key behavioral question (replace vs. merge attribution) unanswered and does not cover the undocumented frameId parameter.

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

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

Schema coverage is 67%, so the schema docs most parameters; the description adds the plural semantics of category_ids ('one or more family members'). It does not explain the frameId parameter or clarify the relationship between id and frameId, so it only marginally exceeds the schema baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (attribute) and resource (source calendar's events → family members), which distinguishes it from nearby siblings like skylight_update_calendar and skylight_update_category. It is clear what the tool accomplishes, though it does not explicitly name the sibling it is not.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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_update_calendar or skylight_update_category, and no prerequisites or exclusions are stated. The agent must 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.

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

Annotations already declare destructiveHint=true, but the description goes far beyond that: it states permanence, describes the two confirmation paths (elicitation vs. confirmToken fallback), explains that the preview enumerates affected items by label, and notes the token binds that exact set. It also carves out the empty-list case, all of which meaningfully de-risks invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core destructive action before any mechanics, and each subsequent sentence carries operational weight. It is dense but not padded; the parenthetical reference to MCP_CONFIRM_MODE is a slight external dependency rather than self-contained prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation with no output schema and 33% parameter coverage, the description covers the highest-risk aspects (permanence, confirmation, preview contents). It stops short of describing the success response or frameId scoping, but the critical decision path is complete.

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

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

Schema description coverage is only 33%. The description usefully clarifies confirmToken's role and when it must not be used, but frameId receives no explanation in either the description or the schema, and listId's format is unstated. Compensation is partial, not full.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a specific verb, resource, and scope ('Remove all items from a list — permanent'), which is clearly distinct from sibling operations like delete_list (removes the list itself) or delete_list_item (single item). However, it never names or contrasts those siblings, so the agent must infer the boundary between clearing and deleting.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description spends its bulk on the confirmation mechanics rather than on when to choose this tool over skylight_delete_list_items or skylight_delete_list. Operational context (confirmation flow, empty-list exemption) is provided, but there is no explicit alternative-selection guidance.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing further: no idempotency note (does completing an already-complete chore error?), no indication of what state results, and no distinction from completing a chore instance. With annotations carrying the safety signal, this thin addition merits a low score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The single sentence is front-loaded and free of waste, but it is under-specified rather than genuinely concise. For a mutation tool with two undocumented parameters and a near-identical sibling, this terseness leaves real gaps.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a write operation with no output schema, no meaningful annotations beyond hints, and 0% parameter documentation, the description should at minimum resolve the chore-vs-chore-instance distinction and explain frameId. It does none of this, so an agent cannot call it confidently in the presence of skylight_complete_chore_instance.

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

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

Schema description coverage is 0% for both parameters, so the description carries the full burden and fails it. It never clarifies whether 'id' is a chore definition ID or a specific chore instance ID, and 'frameId' is completely unexplained. The wording of 'Mark a chore complete' only marginally implies id is a chore, which is the bare minimum.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Mark a chore complete'), so an agent knows the operation is a state transition on a chore. However, it does not differentiate from the near-identical sibling skylight_complete_chore_instance, which is exactly the kind of ambiguity an agent needs resolved. Clear purpose, but no sibling disambiguation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as skylight_complete_chore_instance (for a specific occurrence) or skylight_uncomplete_chore (the inverse). The agent must infer routing entirely from tool names.

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

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

Annotations declare a non-read-only, non-destructive, open-world mutation, so safety is partly covered. The description adds nothing beyond that: no note on what completing an occurrence triggers, whether it is reversible (skylight_uncomplete_chore exists), or any auth/error behavior. For a mutation tool this is thin.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler. It is efficient, though so terse it leaves the behavioral and parameter gaps unaddressed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A mutation tool with no output schema, five parameters, and only 60% schema description coverage needs more than one sentence. Key facts — which identifier 'id' refers to, whether the completion is reversible, and how it differs from skylight_complete_chore — are absent.

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

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

Three of five parameters are documented in the schema (category_id, instance_date, instance_time) but 'id' and 'frameId' are undocumented, and the description supplies no parameter meaning at all. With schema coverage at 60% and no compensating detail, the description contributes nothing to parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (mark complete) and resource (a specific occurrence of a recurring chore), which implicitly separates it from skylight_complete_chore and skylight_uncomplete_chore. It stops short of explicitly naming those siblings or clarifying the difference in scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'specific occurrence of a recurring chore' implies the intended case, but no explicit when-to-use vs. skylight_complete_chore guidance, no mention of required permissions, and no exclusions are given. Usage is left to inference.

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

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

Annotations already declare a non-read-only, non-destructive, open-world write operation, and the description is consistent with that. The parenthetical '(inferred from the app bundle, not live-verified)' is a genuinely useful reliability caveat, but the description says nothing about whether the source messages are retained, whether copies duplicate, idempotency, or 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

One front-loaded sentence that states the action before the caveat; nothing is redundant. The parenthetical costs words but earns them by flagging unverified behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter, non-destructive write tool with no output schema, the description covers the core action but omits return/result behavior, what happens if a destination frame id is invalid, and how source frame resolution works. The 'not live-verified' note is honest but leaves the agent with unresolved behavioral questions.

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

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

Schema coverage is 67%, so the schema documents message_ids and new_frame_ids while frameId is undocumented. The description's 'from this frame to other frames' adds a little meaning to the source/destination split, but does not explain the frameId parameter or the accepted id formats.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (copy) with the source resource (messages/photos in a frame) and destination (other frames on the account), so the agent can distinguish it from sibling tools like add_to_album or delete_messages. The phrasing is clear, though 'this frame' is only resolved via the frameId parameter rather than named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no conditions for when to use this tool versus alternatives; it never mentions related siblings such as add_to_album, upload_photo, or delete_messages, nor any prerequisites. Usage is only implied by the frame-to-frame framing.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is partially covered. The description adds no behavioral context of its own: it says nothing about what happens on duplicate titles, whether the album is created empty, or what the caller receives. With the write semantics assumed but not confirmed, there is no value added beyond structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One short sentence with no filler and the action is front-loaded, which is structurally fine. The problem is under-specification rather than verbosity, so it is neither wasteful nor substantive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a write tool with no output schema and no parameter documentation. The description does not cover required permissions, the meaning of frameId, or the result of the call, leaving an agent without enough context to invoke it beyond the required title argument.

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

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

Schema description coverage is 0%, so both parameters (title, frameId) are undocumented anywhere. The description does not explain what "title" implies for uniqueness or what "frameId" does (presumably ties the album to a specific frame). With low coverage, the description should compensate, and it does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 photo album"), so the basic action is unambiguous. However, it adds essentially nothing beyond the tool name skylight_create_album and gives no scope detail, such as whether the album belongs to a frame or a device. It does not distinguish this tool from siblings like skylight_add_to_album, skylight_update_album, or skylight_set_device_album.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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_list_albums or skylight_add_to_album, nor any stated prerequisites (e.g., required permissions or an existing frame). The agent must infer everything 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.

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

Annotations already declare a non-destructive write (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the safety profile is covered. The description adds real behavioral context beyond that: that linked_to_profile + selected_for_chore_chart jointly upgrade the created entity, and that avatars can be set at creation or deferred to a later call. No permission or return-value detail is given, which keeps it out of the top band.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core action before the parameter configuration guidance. Every clause carries information: entity equivalence, flag combo, avatar source, avatar fallback. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description does not say what the call returns (e.g. the new category's id) or how frameId defaults when omitted. For a 6-parameter creation tool with high schema coverage, what is present is enough to call it correctly, but the return/identity gap keeps it short of complete.

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

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

Schema description coverage is 83%, so the baseline is a 3. The description earns above baseline by explaining the composite effect of two booleans that the schema documents only in isolation, and by naming the source tool for avatar_id. color, label and frameId receive no added meaning in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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'), and crucially resolves the naming ambiguity by equating 'category' with 'family member', which is exactly what separates this tool from skylight_update_family_member and skylight_resolve_member. An agent can tell what it produces without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It routes the agent to sibling tools for adjacent steps ('pick avatar_id from skylight_list_avatars', 'set a custom photo afterward with skylight_set_member_avatar') and explains the flag combination that produces a full chore-chart member. It does not state when to prefer this over skylight_update_family_member or skylight_update_category, so the exclusion side is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the write/safe semantics are covered. The description adds nothing beyond that: no auth/permission requirements, no note that the chore is bound to a family-member category, and no indication of idempotency or duplicate handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The single sentence is front-loaded and free of waste, so it is structurally sound. However, it is short through under-specification rather than through efficient information density.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Wait — with six parameters, no output schema, and a dense sibling set, the description is not complete enough. It says nothing about frameId targeting, the required category binding, or how to source a category id, leaving the agent wholly dependent on schema descriptions.

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

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

Schema coverage is 67% (frameId and description are undocumented), and the description supplies no parameter meaning at all. It does not reinforce the required summary/category_id pair or explain that frameId targets a specific frame; the little value present comes entirely from the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource ('Create a chore'), which is more than a tautology, but it gives no scope detail and does not distinguish it from close siblings like skylight_create_recurring_chore or skylight_create_task. An agent must open the schemas to know which creation tool applies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisite for obtaining a category id, and no mention of how this differs from creating recurring chores or tasks. With ~100 sibling tools, the absence of routing guidance is a real gap.

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

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

Beyond the annotations (destructiveHint=true), the description discloses the irreversible side effect (invitation e-mails cannot be un-sent), the two-phase confirmation mechanics keyed to MCP_CONFIRM_MODE and elicitation support, and an explicit prompt-injection guardrail. This is exactly the extra context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first sentence, and each subsequent clause addresses a distinct risk (invitation side effect, confirmation flow, injection safety). The second sentence is long and heavily nested, which costs some readability, but no content is genuinely filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter mutation tool with no output schema, the description covers the dangerous paths and even sketches phase-1 response shape (recipient list + confirmToken). It omits return details for the ordinary success path and any note on the required summary/frameId relationship, but the risk surface is well covered.

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

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

Schema coverage is 58%, and the description meaningfully enriches the two highest-risk parameters: it explains that a non-empty invited_emails causes real outbound e-mail and that confirmToken only comes from phase-1 and must never be invented or reused. The remaining parameters (rrule, all_day, location, etc.) get no additional narrative, but they are self-evident from the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Create a calendar event on a Skylight frame" gives a specific verb and resource, clearly separable from sibling readers/writers like skylight_update_event, skylight_delete_event, and skylight_get_event. It stops short of naming those alternatives explicitly, so differentiation is inferred rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description is precise about the invited_emails path (when it triggers confirmation, when a repeat call with confirmToken is needed), which is real usage guidance. However, it never addresses the more basic routing question of create vs update_event vs add_webcal, leaving the common-case decision to the name alone.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the write/no-destroy safety profile is covered structurally. The description adds nothing beyond that – no note on frame targeting, required vs optional fields, uniqueness constraints, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler, which is efficient. It is arguably under-specified rather than wasteful, but on the conciseness axis itself it is clean.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a create/mutation tool with no output schema and only 50% parameter coverage, the description should at minimum clarify required inputs and target frame semantics. It leaves both the required-vs-optional distinction and the return/confirmation behavior unexplained.

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

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

Schema description coverage is only 50%: 'kind' and 'color' are documented in the schema, but 'label' and 'frameId' have no descriptions anywhere. The phrase 'on a Skylight frame' vaguely gestures at frameId but gives no format or whether it is required, so the description fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Create') and resource ('a new list') and ties it to a Skylight frame, which distinguishes it from update_list/delete_list/list_lists siblings by action. It is clear but does not explicitly call out the sibling boundary (e.g., what 'create' means versus 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.

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 the many sibling list tools (update_list, add_list_item, list_lists), and no preconditions such as needing a valid frameId or existing frame. The 'create' verb is the only signal, leaving usage to inference.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond that — no mention of what gets persisted, whether the recipe lands on a specific frame, or any permission/rate considerations for this open-world write.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single clean sentence with no waste, but the brevity here reflects under-specification rather than economy. A four-parameter creation tool needs more than five words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a creation tool with no output schema and two undocumented parameters, the description leaves too much unstated — where the recipe is created (frameId), what happens to it afterward, and how it relates to meal categories and meal planning. An agent would be calling this nearly blind.

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

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

Schema coverage is 50%: summary and meal_category_id are documented in the schema, while frameId and description are undocumented everywhere. With half the parameters lacking semantics, the description is required to compensate and instead adds zero parameter information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a verb and resource ('Create a meal recipe'), so the intent is legible, but it is essentially a restatement of the tool name skylight_create_recipe. It offers no differentiation from siblings like skylight_update_recipe, skylight_get_recipe, or skylight_plan_meal, so an agent must infer which recipe operation applies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 versus skylight_update_recipe, skylight_plan_meal, or the grocery-list path. The schema at least hints that meal_category_id comes from list_meal_categories, but the description itself supplies no prerequisites or alternatives.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the write/safety profile is covered structurally. The description adds the RRULE basis for recurrence and a vague 'verified live' claim, but nothing about permissions, assignee requirements, or what happens to conflicting existing chores.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no waste; the parenthetical 'verified live' is the only slightly opaque addition, but overall it is tight and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter mutation tool with no output schema, the description is thin: it omits the chore-vs-routine relationship to sibling tools and provides no return or failure context. The schema carries most of the load, leaving the description only minimally complete.

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

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

Schema description coverage is 67% and the schema itself documents the critical params (recurrence format, routine toggle, category_ids/up_for_grabs rule). The description adds little beyond restating the recurring/routine distinction, so the mid-range baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create a recurring chore or routine'), and the 'recurring' qualifier implicitly separates it from the sibling skylight_create_chore. It stops short of naming that sibling explicitly, so an agent must infer the non-recurring counterpart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The word 'recurring' implies when this tool applies, but there is no explicit when-to-use guidance, no exclusions, and no reference to skylight_create_chore as the non-recurring alternative, nor to skylight_update_chore for edits.

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

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

Annotations already establish this is a non-read-only, open-world, non-destructive write, so the safety profile is covered. The phrase 'live-verified fields' is a genuine value-add, implying other schema fields (e.g. frameId) are unverified, but the description says nothing about required pre-existing categories, failure modes, or what is returned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with no filler, and the verb+resource leads. The parenthetical field list is compact rather than padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a create tool with no output schema and no annotations gap, the description is minimally adequate but omits the cross-entity dependency (category_ids must reference existing category ids) and any note on the unverified frameId behavior.

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

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

Schema coverage is 67% and the description names five of the six parameters, but it only repeats names already present in the schema and skips frameId entirely. No added meaning on format or constraints beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear specific verb+resource ('Create a reward') and it enumerates the fields the tool accepts, so an agent knows exactly what it produces. It does not, however, differentiate itself from near neighbors like skylight_create_category or the reward-update tool beyond the obvious verb.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No statement of when to use this versus skylight_update_reward or how it relates to skylight_create_category for the referenced category_ids. An agent must infer context entirely from the name and schema.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the mutation/safety profile is covered. The description adds only that input is raw provider attributes (low-level/advanced), which is modest context beyond the structured hints and omits what happens on failure or what data must be supplied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short, front-loaded sentence with no filler. The parenthetical qualifier is slightly vague but costs little space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool taking a required free-form nested object and shipping no output schema, the description leaves key gaps: what 'raw provider attributes' contain, auth/scope needs, and how to choose it over add_webcal/link_apple_calendar. It is not adequate for correct invocation.

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

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

At 50% schema coverage, the description should compensate but does not: 'raw provider attributes' restates the attributes field, while frameId is undocumented in both schema and description. No format, examples, or required provider keys are given for the nested attributes object.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: 'Create a source calendar'. The 'from raw provider attributes' clause clarifies the input mode, and it can be distinguished from list/delete/categorize source-calendar siblings. It does not, however, differentiate itself from other calendar-creation siblings like skylight_add_webcal or skylight_link_apple_calendar.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The '(advanced)' tag hints at caution but gives no explicit when-to-use, when-not-to-use, or alternative routing (e.g., add_webcal or link_apple_calendar for the common cases). An agent must infer applicability entirely.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that structured data — no note about which frame the item lands in, whether reward_points affects household scoring, or what the response returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single front-loaded sentence with no filler, which is structurally fine. However its brevity comes from under-specification rather than economy, so it earns only a middling score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a five-parameter mutation with no annotations carrying behavioral detail, no output schema, and only one documented field, a one-sentence description is grossly inadequate. An agent cannot construct a correct call from this definition alone.

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

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

Schema coverage is only 20% (just 'summary': 'Task title.'), leaving frameId, routine, emoji_icon, and reward_points undocumented in both the schema and the description. The description supplies zero compensating meaning, so four of five parameters are opaque.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Create a task-box item" essentially restates the tool name skylight_create_task with a synonym for the resource, adding no distinguishing detail. With siblings like skylight_create_chore, skylight_create_recurring_chore, and skylight_create_reward, an agent gets no basis to tell what uniquely constitutes a "task-box item."

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus skylight_create_chore, skylight_create_recurring_chore, or skylight_update_task, and no prerequisites or scope conditions. The agent receives a bare imperative with no routing context.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: it does not say whether contained photos are also destroyed, whether frameId scopes the deletion, or whether the action is reversible. With annotations carrying the basics, this is a thin but non-contradictory entry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no padding, which is structurally sound. However, there is no content beyond the minimum, so it is minimally sized rather than optimally informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation tool with two parameters (one undocumented), no output schema, and no permission or cascade information, the description is too thin. An agent cannot tell what side effects accompany the deletion or how frameId alters behavior.

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

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

Schema description coverage is 0%: neither 'id' nor 'frameId' is documented in the schema, and the description does not explain their formats or which entity frameId refers to. The description fails to compensate for the coverage gap, leaving the frameId parameter's purpose entirely opaque.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Delete a photo album'), which cleanly distinguishes it from the sibling create_album, update_album, add_to_album and remove_from_album. It does not explicitly contrast with those siblings, but the action is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no prerequisites (e.g. must own the album, must be a frame member), and no mention of alternatives or the distinction from remove_from_album. The agent gets zero routing help beyond the name.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description goes well beyond them: it discloses exactly what is destroyed (chores, reward points, completion history are orphaned unless reassigned), the mandatory confirmation requirement, and the two-step confirmToken fallback with its no-reuse constraint. This is exactly the kind of consequence-level detail an agent needs for a destructive mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then consequences, then confirmation mechanics in three dense sentences with little waste. Slightly long and references an external MCP_CONFIRM_MODE constant, but every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive 4-param tool with no output schema, the description covers consequences, the confirmation contract, and preview naming, which is strong. The unexplained frameId and the absence of any note on what the call returns leave minor gaps.

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

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

Schema coverage is only 50%, and the description adds meaning the schema lacks: the consequence of omitting reassign_to_category_id (orphaning) and the lifecycle rules for confirmToken. However, 'id' and 'frameId' are never explained in either place, leaving a real gap that keeps this below 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Delete a category / family member') and clarifies that a 'category' here is a family member, which is not obvious from the name alone. An agent can immediately tell this apart from the many sibling delete tools (delete_chore, delete_list, delete_event) by resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives real conditional guidance: use reassign_to_category_id to move items instead of orphaning, and the confirmation flow is described. It does not name a sibling alternative (e.g., update_category for non-destructive changes) or state an explicit 'do not use when', so it falls short of a 5.

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

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

Annotations already flag destructiveHint=true, but the description adds substantial behavior the annotations cannot convey: the confirmation prompt path, the two-step preview/confirmToken fallback, client-elicitation awareness, and the explicit 'never on the first call, never reused' constraint. This is exactly the extra context the bar asks for on 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then the confirmation semantics in a compact parenthetical flow. Slightly dense, but each clause (apply_to scope, elicitation fallback, confirmToken rule) earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no output schema, the description covers the destructive-confirmation lifecycle thoroughly and the annotations cover safety hints. Minor gaps remain on which entities the id/frameId refer to and any error/edge behavior, but an agent can call this correctly from the text provided.

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

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

Schema description coverage is 50%, and the schema itself already documents apply_to and confirmToken in depth (including the two-step usage warning). The description largely restates apply_to behavior and gives no meaning for the undocumented id/frameId fields, so it adds only marginal value over the structured schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Delete a chore') plus the sub-scope ('optionally a single occurrence or the whole series'), which cleanly separates it from siblings like skylight_complete_chore, skylight_uncomplete_chore, and skylight_update_chore.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete procedural guidance for the destructive path (apply_to 'all' triggers confirmation; fallback is preview + confirmToken on repeat call), which is useful when-to-call context. However, it never contrasts this tool with alternatives such as completing vs. deleting, nor states prerequisites like ownership/permissions, so the selection guidance is implied rather than explicit.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true. The description only repeats the destructive action ('Delete') without adding context such as irreversibility, what happens to associated data, required permissions, or the role of frameId. Since the annotations carry the safety profile, the description adds little beyond them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no wasted words. It is appropriately sized for a simple delete-by-id operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, open-world delete tool with no output schema and 0% schema description coverage, the description is too thin. It omits frameId semantics, confirmation/warning behavior, and any indication of what a successful deletion affects, leaving important operational context missing.

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

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 mentions 'by id', which gives minimal meaning to the required id parameter, but the optional frameId parameter is completely undocumented. The description does not explain ID format, scope, or when frameId is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Delete a calendar event by id.' This clearly separates it from sibling tools like skylight_update_event and skylight_delete_task. It does not explicitly name alternatives or scope, but 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.

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_update_event, skylight_delete_msgs, or other delete tools. The action is obvious for a delete operation, but no conditions, prerequisites, 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.

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

Annotations only declare destructive=true; the description goes far beyond that, spelling out permanence, the confirmation protocol, what the preview contains ('names the list and every item that would go'), what the token binds, and that the token must never be invented or reused. This is exactly the extra behavioral context an agent needs for an irreversible operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The destructive scope and permanence are front-loaded in the first clause, followed by the confirmation mechanics. It is dense but each sentence carries necessary protocol detail; the parenthetical '(see MCP_CONFIRM_MODE)' is a reasonable pointer rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no output schema, the description covers the risky flow well: confirmation, preview, token semantics, and the empty-list shortcut. Remaining gaps are the meaning of frameId and what a phase-1 preview response looks like structurally, though the description does describe its contents.

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

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

Schema coverage is only 33%: listId and frameId are undocumented in both schema and description. The description does explain the role of confirmToken and its relationship to MCP_CONFIRM_MODE, matching the schema's own note, but it adds no meaning for the two undocumented identifiers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource with scope: 'Delete a Skylight list and every item in it — permanent.' An agent immediately knows this removes the container, not just its contents. It does not, however, distinguish itself from close siblings like skylight_clear_list or skylight_delete_list_items, which an agent could easily confuse it with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operational context: confirmation is requested when the list has items, and an empty list is deleted directly. It explains the two paths (elicitation vs. token fallback) so the agent knows what to do on the first call. It stops short of saying when to choose this tool over clear_list or delete_list_items.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds nothing on top: it doesn't say the deletion is irreversible, whether it requires ownership/permissions, or how the optional frameId affects behavior. Zero value beyond structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler. It is efficient, though the brevity tips into under-specification rather than disciplined conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, open-world mutation with no output schema and 0% parameter documentation, the description is too thin. It omits irreversibility, parameter meaning, and the single-vs-batch distinction the sibling list makes critical.

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

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

Schema coverage is 0% across three parameters, so the description carries the full burden and largely fails it. The phrase 'list item ... from a Skylight frame' loosely hints at itemId/listId/frameId roles, but no format, requiredness, or the meaning of the optional frameId is conveyed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (delete) and resource (list item) scoped to a Skylight frame, so an agent immediately knows the operation. It does not, however, distinguish itself from the near-identical sibling skylight_delete_list_items (plural, batch), leaving the singular-vs-batch choice to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as skylight_delete_list_items or skylight_clear_list for bulk removal. The agent must guess whether this handles single items only.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the destructive nature is covered structurally. The description adds nothing beyond that — no note on irreversibility, required permissions, or partial-failure behavior — so it earns little credit over the structured data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with zero waste. It is efficient, though the terseness contributes to the gaps elsewhere rather than being a deliberate, complete statement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation tool with no output schema and two undocumented parameters, the description is too thin. It omits what happens to the list, whether frameId is required in some contexts, and any confirmation of the effect.

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

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

Schema coverage is only 33%: item_ids is documented in the schema, but listId and frameId carry no description anywhere. The one-line description does nothing to compensate for those two undocumented parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (delete) and resource (list items) with the 'bulk' qualifier that implicitly distinguishes it from the singular sibling skylight_delete_list_item. An agent can tell what it does, though it never names the sibling it differs from.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this bulk variant versus skylight_delete_list_item, skylight_clear_list, or skylight_move_list_item. It implies you already hold item ids ('specific') but never states prerequisites or exclusions.

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

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

Adds rich context beyond the destructiveHint annotation: explicit 'no undo', the split semantics of 'one'/'future', and the full confirmation/confirmToken two-step flow with MCP_CONFIRM_MODE reference. This substantially exceeds what annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose, then scope behavior, then the critical no-undo and confirmation caveat. Four tight sentences with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Destructive mutation with no output schema is fully covered: what gets deleted per mode, irreversibility, and the exact two-phase confirmation protocol. An agent can call this correctly without further inference.

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

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

Schema coverage is 80%, so the schema does most work, but the description reinforces apply_to semantics and the confirmation flow beyond the schema's enum description. id, instance_date, and confirmToken are documented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Remove') and resource ('a planned meal (meal sitting)') and immediately explains scoping via apply_to, distinguishing it from siblings like skylight_update_meal and 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly explains how the three apply_to values behave and when confirmation is triggered, but does not explicitly name alternative tools (e.g., skylight_update_meal for modifying rather than removing). Context for when to use each apply_to mode is clear.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is known. The description adds nothing beyond that — no statement about permanence, recoverability, or required permissions for this 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence that front-loads the verb and resource with no wasted words. It is efficient, though its brevity contributes to the gaps noted elsewhere rather than being a structural flaw.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive delete with 0% schema coverage, two undocumented parameters, and no output schema, the description is too thin — it never clarifies the id/frameId roles or how this differs from the bulk delete sibling.

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

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

Schema description coverage is 0% and the description supplies no parameter meaning at all — the distinction between 'id' (required message identifier) and 'frameId' (optional frame scope) is left entirely undocumented in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Delete) and resource (frame message/photo), which is clearer than a bare name restatement. It does not, however, distinguish itself from the sibling skylight_delete_messages (plural/bulk), leaving the singular-vs-bulk boundary ambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 versus skylight_delete_messages, skylight_delete_album, or other delete siblings, and no prerequisites or irreversibility warnings. Usage is only implied by the verb.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds critical behavioral context beyond them: deletion is permanent with no trash, a photo may exist nowhere else, and the tool enforces user confirmation via a preview/confirmToken flow. This is exactly the extra safety information an agent needs before calling a destructive tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the irreversible nature ('permanent; there is no trash') before explaining the confirmation protocol. Every sentence carries operational weight for a destructive tool, and the alternative-tool routing is placed at the end where it naturally follows the bulk-vs-single distinction.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the destructive nature, no output schema, and moderately covered parameters, the description covers the critical missing pieces: irreversibility, mandatory user confirmation, fallback mechanics, preview contents, and token binding. An agent has enough context to invoke this safely without additional documentation.

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

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

Schema coverage is 67%. The description adds meaning beyond the schema by clarifying that the preview lists every id with its caption and that the confirmToken binds that exact set, plus reiterating that a repeat call must use the same arguments. It does not explain the frameId parameter, leaving one gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Bulk-delete messages/photos from the frame'. It also explicitly distinguishes itself from the single-item sibling by saying 'For one message use skylight_delete_message', so an agent can route correctly without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the alternative tool and the condition that selects it ('For one message use skylight_delete_message'). It also describes exactly when the two-step confirmation fallback applies versus elicitation, giving complete usage context.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that - it does not say whether the deletion is permanent, whether meals referencing the recipe are affected, or what happens if the id 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single short sentence with zero filler and the action is front-loaded, so there is no wasted prose. However, at four words it is under-specified rather than optimally concise for a destructive two-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation with 0% schema coverage, an undocumented optional parameter, and no output schema, the description is far too thin. An agent cannot verify the scope of the deletion or the meaning of 'frameId' from the available information.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning and does not. It never explains what 'id' identifies or what the optional 'frameId' is for on a recipe-deletion call, which is a genuinely non-obvious parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a verb (delete) and resource (meal recipe), but it is nearly a restatement of the tool name 'skylight_delete_recipe'. The only added information is the word 'meal', and it offers no differentiation from sibling tools like skylight_delete_meal or skylight_update_recipe, so an agent gets minimal help narrowing the choice.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as skylight_update_recipe or skylight_delete_meal. The agent is left to infer the tool's role entirely from the name.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it says nothing about whether deletion is permanent, what happens to a member's existing reward points or redemptions, or whether the optional frameId scopes the operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single clause with no wasted words and the action is front-loaded, but this brevity is under-specification rather than disciplined conciseness for a destructive mutation tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no output schema and two undocumented parameters, the definition omits the consequences of deletion, the role of frameId, and any recovery/undo path. The annotations carry the entire burden.

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

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

Schema description coverage is 0% for two parameters. The description never mentions 'id' or 'frameId', so it fails to compensate for the complete absence of parameter documentation in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Delete a reward" states a verb and a resource, so the purpose is not misleading, but it essentially restates the tool name (skylight_delete_reward) without adding scope, and it draws no boundary against siblings like skylight_get_reward, skylight_update_reward, or skylight_unredeem_reward.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives in a sibling set that contains several closely related reward operations (delete vs. unredeem vs. update). The agent must infer everything 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.

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the destructive nature is covered structurally. The description does add real scope context by noting webcal subscriptions are included, but it omits whether synced events are cascade-deleted, whether the action is recoverable, and what authorization is needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence naming the action, the resource, and the notable inclusion of webcal subscriptions. Nothing is padded or repeated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, no-output-schema tool the definition is only partially sufficient: it names the target but leaves the two parameters unexplained and does not describe the side effects on existing events or synced data. Annotations cover the safety profile, so the remaining gap is mainly scope and parameters.

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

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

Schema description coverage is 0% for two parameters (id, frameId), and the description supplies no parameter meaning at all — it does not say whether id is the source calendar ID or whether frameId is required to disambiguate. With required 'id' and an entirely undescribed optional 'frameId', the description fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Remove a connected source calendar') and clarifies scope by including webcal subscriptions, which distinguishes it from generic delete tools and from skylight_delete_event. It does not explicitly contrast with the closest siblings (list_source_calendars, create_source_calendar, categorize_source_calendar), but the intent is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use or when-not-to-use guidance, and no prerequisites stated (e.g. whether the calendar must first be disconnected or whether it must belong to a frame). The agent is left to infer that this is the tool for tearing down a source calendar rather than an event or category.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is covered by structured data. The description adds nothing beyond that: it does not say whether deletion is permanent or recoverable, nor what happens to the parent task box, nor what the frameId scoping implies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with zero filler and no redundancy. Its brevity is appropriate in form, though the shortness here reflects under-specification rather than economy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation with two undocumented parameters, no output schema, and an ambiguous resource name, the description leaves too much unresolved. An agent cannot determine what object it is deleting or what the optional frameId changes.

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

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

Schema description coverage is 0%, so the description carries the full burden for `id` and `frameId`, yet it explains neither. 'item' loosely hints that `id` identifies the target, but the optional `frameId` (and why a frame scope would be needed to delete a task) is entirely undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

It states a specific verb ('Delete') and a resource ('task-box item'), so the basic action is clear. However, 'task-box item' is not the vocabulary the sibling set uses (skylight_create_task, skylight_update_task, skylight_list_tasks), so an agent cannot confidently tell whether this deletes a task, a list item, or a frame widget without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisite, and no mention of the sibling tools it competes with (skylight_delete_list_item, skylight_delete_chore, skylight_delete_message). The agent is left to infer applicability purely from the tool name.

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

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

Annotations already declare a non-readonly, open-world, non-destructive operation, so the safety profile is covered. The description adds genuinely useful context beyond that: it discloses that output is draft events (not committed events) and that the operation is asynchronous, which materially changes how an agent should follow up.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single well-formed sentence that front-loads the core action and appends the crucial async/draft caveat. Every clause earns its place with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter write tool with no output schema, the description conveys the essential behavioral facts (drafts, async) that an agent needs before invoking. It is slightly incomplete in not indicating how the resulting drafts are surfaced or approved, which matters given sibling draft/approval tools, but the coverage is otherwise solid.

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

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

Schema description coverage is 86%, so the schema already documents parameters like physical_location, datetime_range_start/end, category_ids, budget, and activity_kind. The description only restates 'location and time range' and adds no format, constraint, or default detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (generate) and resource (activity/event ideas) scoped to a location and time range, and notes it creates draft events asynchronously. It is clearly distinguishable from create_event (which makes a single event), but it does not explicitly name or contrast with its nearest sibling, generate_meal_plan, or the auto-creation draft tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description describes the input scope but gives no when-to-use guidance: nothing tells the agent when to prefer this over skylight_create_event or skylight_generate_meal_plan, nor when not to use it. Usage is only implied by the resource name.

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

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

Annotations already flag a non-read-only, open-world, non-destructive operation; the description usefully adds that output is drafts created asynchronously plus the required poll/approve follow-up. It doesn't mention permission requirements or whether regenerating overwrites prior drafts.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that carries purpose, async behavior, and the follow-up tool chain with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description adequately covers the async lifecycle by naming the polling and approval tools. Minor gaps remain around the undocumented frameId and add_to_grocery_list parameters.

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

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

Schema coverage is 67%, and the description adds nothing about parameters beyond implying dates. Two parameters (frameId, add_to_grocery_list) lack descriptions in both schema and description, and the description doesn't explain the AI-vs-recipe source semantics the schema only hints at.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Generate) and resource (AI meal plan for given dates) and clarifies it creates draft meal sittings rather than final meals. This distinguishes it from skylight_plan_meal and other meal siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly describes the workflow context: async draft creation, then polling with skylight_get_auto_creation_intent, then approval. It does not, however, state when to prefer this over skylight_plan_meal (manual planning), so the alternative-selection guidance is incomplete.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds that the response carries status plus draft results, which is useful, but says nothing about authorization, error cases, or freshness of the intent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with the resource and return content front-loaded. Nothing is wasted, though it is minimal rather than richly structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and 0% parameter documentation, the description should carry more weight. It partially covers the return value (status + draft results) but leaves both parameters and the relationship to sibling auto-creation tools unexplained, which is thin for a lookup tool in a crowded namespace.

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

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

Schema description coverage is 0%, so neither 'id' nor the optional 'frameId' is documented anywhere. The description does not compensate—it never explains what the id refers to or why a frameId would be supplied, leaving an ambiguity about whether id is global or frame-scoped.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Get) and resource (auto-creation intent), and clarifies the payload with 'status + draft results'. It implicitly distinguishes itself from the sibling skylight_list_auto_creation_intents by fetching a single intent, though it never names that sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as list_auto_creation_intents or approve_auto_creation. The agent must infer retrieval semantics 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds no behavior beyond that: no note on what is returned, whether a missing/inaccessible calendar errors, or any scope constraint. It essentially repeats the read semantics the annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with no filler, so it is structurally clean and front-loaded. However, the brevity comes at the cost of under-specification rather than genuine concision, similar to a near-tautological stub.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a lookup tool with no output schema and 0% parameter documentation, the description should at minimum identify what the id refers to and what the result contains. Nothing about return shape, id semantics, or error behavior is present, so an agent cannot confidently invoke it.

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

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

Schema description coverage is 0% for two parameters. The description never mentions 'id' or 'frameId', leaving it unclear whether the id is a calendar id, a source calendar id, or something frame-scoped, and what frameId disambiguates. No value is added over the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a verb and resource ('Get one calendar account'), which is more specific than a bare title, but 'calendar account' is ambiguous given siblings like skylight_list_source_calendars and skylight_update_calendar. It does not clarify whether this retrieves a source calendar, a device calendar, or frame-associated calendar settings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to call this versus skylight_list_calendars (to enumerate) or skylight_get_frame. The 'one' hints at single-item retrieval, but nothing states prerequisites or when-not-to-use alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation with open-world implications. The description adds no further behavioral context, such as authentication needs or error behavior, but the annotations carry the safety profile, making a 3 appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that is front-loaded and wastes no words, though it could benefit from slightly more detail without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only two parameters and no output schema, the description is too sparse. It fails to explain the 'frameId' parameter, does not mention return values, and provides no usage context, leaving significant gaps for an agent.

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

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, but it only mentions retrieving by 'id' and does not explain the 'frameId' parameter or the format of 'id'. It adds minimal meaning beyond the schema field names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (get) and resource (calendar event) and specifies retrieval by id. It is clear but does not explicitly differentiate from sibling tools like skylight_list_events or skylight_get_calendar, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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_list_events or skylight_get_calendar. It simply states what it does without context or exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered structurally; the description adds essentially no behavioral context beyond restating the resource. It does not say what settings are returned, whether a frame must exist, or that the read is non-mutating.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short, front-loaded sentence with no filler. It is efficient, though its brevity borders on under-specification rather than tightness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, no parameter documentation, and no annotations covering return behavior, the description leaves an agent without enough to know what it will receive or how frameId resolves. For a getter that should describe the returned settings shape, this is thin.

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

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

There is one parameter (frameId) with 0% schema description coverage and 0 required parameters, yet the description says nothing about how the frame is identified, whether frameId is optional, or what happens if it is omitted. The phrase 'the frame's' hints at frame scoping but does not resolve the optional/required ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Get') and resource ('the frame's calendar-event notification settings'), so an agent can tell this is the read side of the notification-settings pair rather than the update variant. It is clear but never names or contrasts with the sibling skylight_update_event_notification_settings, so it stops short of full differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no mention of the update counterpart, and no prerequisite or context is supplied. The agent must infer from the name alone that this is the read operation.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the return includes the frame's settings, which is useful, but says nothing about auth requirements, behavior when the frame cannot be resolved, or error conditions. A 3 is appropriate given the annotations carry most of the burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no waste. It is arguably too terse for a tool description, but nothing is redundant or poorly ordered.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with no required parameters, one well-documented parameter, and no output schema, the description covers what is fetched and that settings are included. Minor gaps remain on what 'settings' comprises and failure behavior when no frame is resolved.

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

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

Schema description coverage is 100% and the single frameId parameter already documents that it defaults to the resolved frame. The description adds no format, id-shape, or lookup guidance beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Get') and resource ('one Skylight frame and its settings'), and the singular 'one frame' implicitly contrasts with the sibling skylight_list_frames. It does not, however, explicitly differentiate itself from update_frame, rename_frame, or list_frames, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to call this versus skylight_list_frames (to enumerate frames) or the update/rename variants (to mutate one). The only usage hint is implicit in the word 'one'. No prerequisites or exclusions are given.

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

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

Annotations cover read-only safety (readOnlyHint=true, openWorldHint=true). The description adds nothing about whether a frameId is required, behavior when omitted, or what configuration is returned, which matters given the required parameter count is 0.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single short sentence, front-loaded, no waste. It is concise but borders on under-specified for a tool with an undocumented parameter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description should indicate what household configuration entails. With 0% schema coverage and no output schema, the definition leaves key behavior undocumented.

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

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

Schema coverage is 0% and the sole parameter frameId has no description. The description does not explain what frameId is, whether it can be omitted, or what the default frame behavior is.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Get) and resource (household configuration) with scope ('for the frame'). It is distinguishable from the sibling skylight_update_household_config, though 'household configuration' contents remain unspecified.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, prerequisites, or mention of alternatives. The agent must infer that this is the read counterpart to update_household_config 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only the scope note that it returns ALL items, without stating pagination behavior, what an item looks like, or what happens for an unknown list/frame. With annotations carrying the safety burden, this is adequate but thin.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler; the action and resource come first. It is efficiently sized, though its brevity is partly a symptom of missing detail rather than disciplined trimming.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read tool with annotations and no output schema, the description is minimally sufficient to identify the operation. It falls short on the frameId/listId relationship and any return-shape expectations, which matters because the schema documents neither parameter.

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

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

Schema coverage is 0%, so the description must compensate and it does not: it never explains that listId identifies the target list, that frameId is optional, or how the two interact ('a Skylight frame' hints at frameId but gives no rules). The only real hint is the phrase 'on a Skylight frame'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb+resource ('get all items') and scopes it to 'a specific list on a Skylight frame', which distinguishes it from skylight_list_lists (which enumerates lists) and the list-item mutation tools (add/update/delete/clear). It does not, however, explicitly contrast itself with those siblings, so the distinction must be inferred.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no mention of prerequisites (e.g., needing a valid list), and no reference to alternatives such as skylight_list_lists for discovering list IDs. The agent is left to infer the whole usage context.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds a genuinely non-obvious behavioral caveat — that caption and comment content is user-authored and must be treated as untrusted data, not instructions — which is exactly the kind of context annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the operation and followed by the one caveat that matters. No filler, no restatement of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with no output schema and read-only annotations, the core operation and the untrusted-content warning are enough to call it safely. However, the undocumented id/frameId relationship leaves a real ambiguity that a slightly longer description could have closed.

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

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

Schema description coverage is 0% and the description says nothing about either parameter. It never explains what 'id' identifies versus the optional 'frameId', nor whether frameId scopes or disambiguates the lookup, so an agent must guess from names alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get one frame message'), which distinguishes it from the sibling list_messages by scope. It never names the sibling explicitly, so the differentiation is implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not-to-use guidance, and no mention of the obvious alternative (skylight_list_messages) or of when a message id should be fetched directly. The singular 'one message' hints at retrieval of a single known item, but that is inference, not guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only, external-facing nature is covered structurally. The description adds no further behavioral context – no auth requirements, no caching or rate-limit notes, no indication of what the entitlement status entails.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no waste. The 'subscription / entitlement' pairing is mildly redundant but not enough to impede comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read with no output schema, the description leaves the return shape unspecified – an agent cannot tell whether this yields a boolean, a tier name, or a feature list. Adequate minimum, but the missing response context is a real gap given there is no output schema to compensate.

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

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

The tool takes zero parameters, so there is no parameter semantics to document and the baseline is 4. Nothing in the description misleads about inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Get') and a specific resource ('Skylight Plus subscription / entitlement status'), so an agent knows exactly what is retrieved. It doesn't need to differentiate from siblings because no other tool in the list touches subscription/entitlement state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says nothing about when this tool should be called, what triggers a need for entitlement status, or whether any alternative exists for checking account capabilities. It is a bare statement of function with no usage context.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond that, such as authentication needs, query behavior, or what 'one recipe' means when multiple frames exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no wasted words. It is appropriately sized as a concise summary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter retrieval tool with no output schema and no parameter descriptions, the definition is too thin. It does not clarify whether id is globally unique, what frameId does, or how an agent should choose between this and list_recipes.

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

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

Schema description coverage is 0% for both parameters. The description does not explain the required id or the optional frameId, so it fails to compensate for the missing schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: get one meal recipe. The word 'one' distinguishes it from the sibling list_recipes, but it does not explicitly contrast with other recipe-related tools such as update_recipe or delete_recipe.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance is provided. An agent must infer that this is for retrieving a single recipe by identifier rather than listing recipes or mutating them.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered by structured data. The description adds nothing beyond that – no note on error behavior for an unknown id, no indication of what a frameId scopes, and no return-shape context – so it contributes essentially no behavioral value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.