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

No annotations are provided, so the description carries the burden. It clearly states this is a create operation and that it returns the created event details. It also hints at natural-language time parsing. However, it does not disclose side effects, permission requirements, conflict behavior, or whether recurrence is truly supported (the 'every Saturday' example implies recurrence but no parameter exists).

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 well-structured with clear sections: purpose, use cases, parameters, returns, and related tool. It front-loads the main purpose. It is somewhat long and repeats schema info, but that is acceptable given 7 parameters and the added natural-language 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?

The tool has 7 parameters, 3 required, no annotations, and no output schema. The description handles most essentials: purpose, when to use, parameter list, return value, and related tool. However, it omits details about recurrence behavior (despite implying it in an example), allDay interaction with times, timezone handling, and error or conflict scenarios.

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 100%, so baseline is 3. The description goes beyond the schema by noting that startsAt/endsAt accept natural language in addition to ISO format, which is not in the schema. It also gives real-world examples for parameter usage, adding practical semantic value.

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 statement ('Create a new calendar event in Skylight') and is immediately distinguished from sibling tools like update_calendar_event and delete_calendar_event. The use-case bullets reinforce that this is for creating new events, not modifying or removing them.

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 explicitly provides 'Use this when' guidance with concrete examples for scheduling appointments, family activities, and reminders. It also points to get_family_members for category IDs. However, it does not explicitly state when NOT to use this tool (e.g., updating or deleting events), so it misses the exclusion/alternative clause.

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?

With no annotations, the description carries the full disclosure burden and does well by revealing that the chore appears on the Skylight display and that the assignee is mandatory due to an API-version limitation. It adds nuanced context about a real-world constraint ('unassigned chores are rejected outright') that an agent must know. Minor gap: it doesn't mention what happens on success, error handling, or idempotency, but it's still substantially transparent.

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 structure is exemplary: a one-sentence summary, a short bulleted list for when to use, and a final paragraph explaining an important edge case. Every sentence contributes meaningful information, and the format is scannable. No fluff or redundancy.

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 tool with 7 parameters, no output schema, and no annotations, the description covers the key usage scenarios and adds behavioral context (display, assignee constraint). It could be more thorough by mentioning default values, response behavior, or failure modes, but given the schema richness, it's sufficiently complete. The missing pieces are nice-to-have, not 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 description coverage is 100%, so the baseline is 3. The description adds marginal value by explaining the rationale behind 'assignee' (required and why) and implying the 'recurring' parameter, but it doesn't elaborate on the other parameters beyond the schema. It meets the baseline but doesn't elevate it.

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 "Add a new chore to Skylight," a specific verb+resource that clearly defines the operation. The bulleted use cases (e.g., 'Add a new task like "empty the dishwasher"', 'Assign chores to family members', 'Create recurring chores') further disambiguate it from siblings like create_task and update_chore, which could otherwise be confused.

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 explicit 'Use this when the user wants to:' section lists clear contexts for using the tool, such as adding tasks, assigning chores, and creating recurring chores. However, it stops short of naming alternatives (e.g., 'use update_chore for edits' or 'use create_task for...'), so it misses the full 'when-not-to-use' guidance that would earn 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?

With no annotations, the description carries the burden of behavioral disclosure. It states the tool 'creates' a new list, which implies mutation, and discloses the return value ('Returns: The created list details'). However, it does not mention permissions, side effects, or idempotency considerations beyond the basic creation action, which limits transparency.

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 well-structured with clear sections for use cases, parameters, and return value, all front-loaded with the primary action. It is appropriately sized—every sentence contributes useful information without redundancy.

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?

The tool is simple (3 parameters, no nested objects, no output schema), and the description covers purpose, use cases, parameter details, and return value. This makes it complete for an agent to understand when and how to invoke the tool effectively.

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 schema already covers all parameters with descriptions (100% coverage), setting a baseline of 3. The description adds value by providing concrete examples for 'label' (e.g., 'Vacation Packing', 'Weekly Groceries') and explaining the meaning of 'kind' enum values ('shopping' for grocery/shopping lists, 'to_do' for task lists), enhancing the semantic clarity 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?

The description clearly states the action ('Create a new list in Skylight') with a specific resource (list) and differentiates from sibling tools like create_chore or create_list_item by specifying 'shopping/grocery list' or 'to-do list'. The verb+resource combination is unambiguous and distinct.

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 explicit 'Use this when' scenarios (creating shopping/grocery lists or to-do lists), giving clear context for when the tool is appropriate. However, it does not explicitly state when not to use this tool or mention alternatives like update_list for modifying existing lists, so it stops short of full 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?

No annotations are provided, so the description carries the full burden. It mentions returning a confirmation but does not discuss potential side effects, error conditions, or how listId and listName interact (e.g., precedence). For a create operation, this is acceptable but not fully transparent.

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 well-structured with clear sections (purpose, when to use, parameters, default behavior, returns, related tools). Every sentence is informative and necessary, with no redundancy or fluff.

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?

The description explains the return value and default behavior, which is sufficient for a simple create operation. It could mention edge cases like what happens if a list with the given name doesn't exist, but overall it provides adequate context for a straightforward tool.

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 schema already provides a description for every parameter (100% coverage), and the tool description adds examples but does not significantly enhance the meaning beyond the schema. The baseline for high schema coverage is 3, and the description meets but does not exceed that.

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 clearly states the tool's purpose ('Add an item to a Skylight list') and provides specific examples (grocery list, to-do list) that distinguish it from sibling tools like create_list or update_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?

The 'Use this when' section gives concrete scenarios and mentions default behavior when no list is specified. It could be improved by explicitly stating when not to use it (e.g., for updating existing items), but the examples provide adequate 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?

With no annotations provided, the description takes on the responsibility of disclosing behavior. It does state what happens after creation ('The task will appear on the Skylight display in the task box') and the context of the task box. However, it does not discuss side effects, idempotency, or permissions, which would have provided a fuller picture of the tool's behavior.

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 concise and well-structured: a one-sentence purpose, a brief explanation of the task box, a list of example triggers, and a concluding note on the outcome. Every sentence adds value, with no redundancy or fluff.

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 tool with 4 simple parameters and no output schema, the description is complete. It covers the component's purpose, the domain concept (task box), when to invoke it, and the expected outcome. This is sufficient for an agent to use the tool effectively in context.

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 schema description coverage is 100%, so the baseline is 3 as per the rubric. The description does not add significant parameter-specific details beyond the schema. It provides example user inputs that implicitly map to the summary field, but it does not clarify formats, defaults, or interactions beyond what the schema already documents.

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 clearly states the verb ('Add'), the resource ('a task to the Skylight task box'), and distinguishes this from scheduled tasks by clarifying these are 'unscheduled tasks' that can be assigned to dates later. This effectively differentiates it from siblings like create_calendar_event, which handle dated entries.

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 explicit 'when to use' examples (e.g., 'Add XYZ to my task list', 'Remind me to do ABC' with the qualifier 'without a specific date') which clearly implies when not to use it (i.e., when a date is involved). However, it does not explicitly name alternative tools, so it falls short of full 5 on the 'alternatives' criterion.

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?

No annotations are provided, so the description must carry the burden of behavioral disclosure. It explicitly states that the event is 'permanently removed' and clarifies that recurring events 'may only delete one instance,' which are important destructive and edge-case behaviors. It does not describe return values or error behavior, but the core safety traits are covered.

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 compact and well-structured, with a front-loaded purpose, helpful use-case bullets, a parameter note, and a behavioral warning. Every sentence serves a purpose and there is no filler or unnecessary repetition.

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 one-parameter destructive tool with no annotations and no output schema, this description covers the essential aspects: what it does, when to use it, how to provide the parameter, permanence, and recurring-event behavior. The only notable omission is the return/confirmation behavior, but this is a minor gap given the tool's simplicity.

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 schema already documents eventId at 100% coverage, so the description's parameter section is somewhat redundant. However, it adds useful provenance by saying the ID comes 'from get_calendar_events,' helping the agent understand how to obtain a valid value. This goes slightly 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?

The description opens with a specific verb+resource pair: 'Delete a calendar event from Skylight.' This clearly distinguishes the tool from siblings like create_calendar_event, update_calendar_event, and get_calendar_events. The scope and action are 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?

The 'Use this when:' section provides explicit, concrete contexts (canceling an event and deleting old events) with natural-language example phrases. It does not explicitly state when not to use the tool or name alternatives, but the context is clear enough for an agent to select it correctly.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly states the operation is permanent, that applyTo is required for recurring chores and ignored for one-offs, that single-occurrence deletion is impossible, and that missing applyTo results in an error.

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 well-organized with a one-sentence purpose, clear use-case bullets, a parameter breakdown, and a warning note. Every sentence contributes necessary information without filler or redundancy.

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?

The tool involves a destructive action and recurring-chore edge cases. The description covers permanence, applyTo behavior, error conditions, and how to source choreId. With no output schema, return details are less critical, and nothing important is left unaddressed.

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 100%, but the description adds significant meaning beyond the schema: it explains that applyTo is ignored for one-off chores, that 'future' preserves past occurrences, and that the API supports no single-occurrence option. This goes well beyond the bare enum descriptions.

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 opening line 'Delete a chore from Skylight' clearly identifies the specific verb and resource. The use-case bullets further define the scope, and the sibling list includes other delete tools, making it unambiguous that this tool is for chore deletion only.

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 explicit 'Use this when' scenarios: removing old/irrelevant chores, mistaken additions, and recurring series with applyTo semantics. It does not explicitly state when not to use it or contrast with update_chore, but the guidance is clear and actionable.

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?

No annotations are present, so the description carries full responsibility. It explicitly states 'This permanently deletes the list and all its items,' which discloses the destructive, irreversible, and cascading nature of the operation—critical behavioral information.

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?

Well-structured and efficiently sized: one-line purpose, bulleted usage scenarios, parameter explanations, and a crucial note. Every sentence adds necessary information without redundancy.

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?

Covers purpose, usage, parameter guidance, and destructive consequences despite lacking annotations and output schema. It does not address edge cases like providing both listId and listName or neither, but given the tool's simplicity, it is mostly 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 coverage is 100%, so baseline is 3. The description adds value by directing users to get_lists for finding list IDs and clarifying that listName is an alternative to listId.

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 verb+resource: 'Delete a list from Skylight.' The description also distinguishes this from sibling delete_list_item by emphasizing it deletes the list and all its items.

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?

Provides an explicit 'Use this when' section with two concrete scenarios. It also implies a workflow by suggesting get_lists to find IDs. However, it does not explicitly state when not to use it, such as using delete_list_item for individual 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?

With no annotations, the description carries the full burden of behavioral disclosure. It clearly warns that the action permanently removes the item, which is critical destructive-behavior information. It also contrasts with checking off to clarify the effect. Slight room remains for additional details (e.g., reversibility, side effects), but for this simple tool it is adequately transparent.

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 well-structured with a clear topic sentence, a 'Use this when' list, a parameter list, and a note for an alternative. Every sentence earns its place, and the layout makes key information easy to scan.

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 low-complexity tool with two simple parameters and no output schema. The description provides the core purpose, usage conditions, parameter meanings, and permanent/deletion behavior. It is complete enough for an agent to decide when and how to invoke it 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?

The input schema already documents both parameters with descriptions at 100% coverage. The description essentially repeats the parameter names and their purpose, adding no extra meaning beyond what the schema provides. The baseline of 3 applies here.

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 and resource: 'Remove an item from a list.' It clearly identifies the tool's function and distinguishes it from siblings by explicitly noting that checking off an item should use update_list_item instead.

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 'Use this when' section provides concrete scenarios (removing an item added by mistake, deleting instead of completing). It also explicitly names the alternative tool and usage pattern (update_list_item with status='completed'), making when-to-use and when-not-to-use unambiguous.

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?

No annotations are provided, so the description carries the full burden. It states the tool returns a list of avatars with IDs and details, which is a basic description of the output. However, it does not disclose any side effects (likely none since it's a read-only operation), authentication requirements, or any limitations or errors. It does not contradict the absence of annotations, but could add more behavioral context.

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

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

The description is concise, well-structured, and front-loaded with the purpose. It uses bullet points for usage scenarios and a separate 'Returns' line for output, making it easy to scan. Every sentence adds value without redundancy.

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 tool's simplicity (no parameters, no output schema), the description is fairly complete. It explains what the tool returns and when to use it. However, it could be more complete by mentioning any potential limitations (e.g., if avatars are predefined vs. user-uploaded) or availability conditions, but for a simple lookup tool this is adequate.

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 has zero parameters, and the schema is empty with 100% coverage (since there are no parameters to describe). The description adds context by explaining the purpose and return value, which is helpful given the empty schema. A baseline of 4 is appropriate as the description provides sufficient meaning 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?

The description clearly states the tool's purpose: to get available avatar options for Skylight profiles. It specifies the resource (avatars) and the context (Skylight profiles), effectively distinguishing it from sibling tools that handle other entities like calendar events, chores, or lists. The verb 'Get' is explicit and matches the tool name.

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 clear usage scenarios: setting up a new family member profile, changing a profile picture, or exploring avatar options. It gives context on when to use the tool, but does not explicitly state when not to use it or mention alternatives, which would have been beneficial given the sibling tools include get_family_members (which might also be relevant).

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?

With no annotations, the description carries the burden of behavioral disclosure. It does state that the tool 'Returns a list of events with their titles, times, and details', which is useful. However, it does not explicitly mention read-only behavior, permissions, timezone handling, or behavior for empty results, leaving some ambiguity for a tool with no annotation support.

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 concise and well-structured: a clear one-line purpose, a short bulleted list of example queries, and a one-sentence return summary. Every part earns its place and there is no redundant or filler content.

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-only tool with two optional parameters and no output schema, the description is reasonably complete: it explains what the tool does, when to use it, and what it returns. It does not cover edge cases or timezone details, but these are not critical for the described functionality.

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%, so the input schema already fully documents the 'date' and 'dateEnd' parameters. The description adds no additional parameter-specific semantics beyond example queries, so it does not exceed the 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?

The description opens with 'Get calendar events from Skylight', a specific verb+resource statement that clearly distinguishes this tool from siblings like create_calendar_event, update_calendar_event, and delete_calendar_event. The example questions further reinforce that this is for reading/querying events, not managing them.

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 concrete usage examples ('What's on my calendar today?', 'What do we have scheduled this weekend?') which clearly indicate when to use this tool. It does not explicitly mention when not to use it or name alternatives like get_source_calendars, but the examples sufficiently convey the intended use case.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns chores with IDs, assignees, due dates, and completion status, and implies it is a read-only operation by discussing retrieval and filtering. It does not explicitly mention permissions or side effects, but for a list-getting tool, this is adequate.

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 well-structured with a brief definition, followed by clear example use cases, and a sentence. The description effectively uses the schema to document parameters, avoiding repetition and keeping the description concise without unnecessary detail.

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?

The tool has 5 optional parameters, no output schema, and no annotations, but the schema is fully described. The description provides example queries and highlights the need for IDs for subsequent mutations, covering key context. It doesn't detail return structure but the examples and schema suffice for agent 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?

The schema covers all 5 parameters with descriptions, so the baseline is 3. The description adds value by mentioning the need for IDs for update/delete and gives example usage contexts, but does not explain parameter syntax beyond what the schema provides. The schema has good coverage, so the added value is somewhat limited.

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 clearly states the tool retrieves chores and provides concrete example queries for its use. It distinguishes itself from siblings like get_calendar_events and get_lists by specifying the domain (chores) and the output includes IDs needed for update/delete operations.

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 clear context on when to use this tool, including example user intents, but does not explicitly exclude situations where other tools might be more appropriate. It implies usage for chore-related queries without explicit 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?

With no annotations provided, the description carries the burden of disclosing behavior. It mentions the return format ('List of available colors with IDs and hex values') but does not explicitly state that the operation is read-only or safe. This is adequate for a simple getter but lacks explicit disclosure of side effects or implications.

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 concise and well-structured: a clear one-line purpose, a 'Use this when' list, and a return format note. Every sentence adds value without fluff, making it efficient and front-loaded.

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 parameterless getter with no output schema, the description fully covers purpose, usage scenarios, and return format. No additional context is needed given the tool's trivial nature and the absence of 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?

The input schema has zero parameters, so there is nothing for the description to clarify. The schema coverage is trivially 100%, and the description adds no parameter-level detail because none exist. Per rubric, baseline is 4 since no compensation 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 clearly states the tool returns available color options for Skylight profiles and lists, using a specific verb ('Get') and resource ('color options'). This distinctly separates it from sibling tools like get_lists or get_family_members, which serve different purposes.

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

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

Provides explicit 'Use this when' scenarios (choosing colors, setting list colors, exploring options) that give clear context for invocation. However, it does not mention alternatives or exclusions, which is acceptable given no close siblings, but stops short of a perfect 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?

No annotations are provided, so the description carries the burden for behavioral disclosure. While 'List' implies a read-only operation, the description does not state whether it returns all devices regardless of status, whether any authentication or permissions are needed, or any other behavioral details (e.g., does it include offline devices, sorting, pagination). For a zero-parameter tool, there is little risk, but the description adds minimal behavioral context beyond a straightforward list 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 description is extremely concise, with a single action sentence and two example questions that add value by illustrating common use cases. There is no wasted text; it is front-loaded with the core purpose and then gives concrete guidance. Everything 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 zero-parameter, no-output-schema tool, the description is fairly complete: it specifies the subject (Skylight devices), the context (household), and gives example queries. However, it could mention what fields are returned (e.g., device names, connection status) or any constraints (e.g., only for the current household). Given the simplicity, the description is adequate but would benefit from a hint about the return format to be fully 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?

The tool has zero parameters, and schema description coverage is 100% (since there is nothing to describe). The description adds clarity by explaining that the output is a list of Skylight devices, which helps the agent understand the scope of the call without any parameters. A baseline of 4 is appropriate because no parameters exist and the description adequately communicates the action's return nature.

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 clearly states the verb ('List') and resource ('Skylight devices in the household'), and includes concrete example queries that distinguish it from sibling tools like get_frame_info (which likely targets a single frame) and other tools focused on calendar, chores, lists, etc. The scope is explicit (household devices), making it 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?

The description implicitly guides usage by showing example questions it answers, but it does not explicitly specify when not to use this tool or contrast with alternatives like get_frame_info or get_family_members. Context is clear for listing devices, but no exclusions or alternative directions are given, so it lacks full usage 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?

No annotations are provided, so the description carries the full burden. It implies a read-only operation with 'Get' and 'Shows', but does not explicitly state that it is read-only or describe any side effects, return format, or potential limitations. The additional context about 'who can be assigned chores' adds some value, but not enough to fully compensate for missing safety disclosures.

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 concise, efficient, and well-structured. It opens with a clear one-liner, adds a clarifying sentence, and then provides concrete example queries. No unnecessary information or repetition.

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 tool with no parameters, no output schema, and no annotations, the description is reasonably complete. It tells the user what the tool returns ('family members/profiles' and 'profile details') and gives usage examples. Slightly more detail about the output format would improve it, but it is adequate for the tool's simplicity.

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 has zero parameters, and the schema confirms this. According to the rubric, 0 parameters merit a baseline score of 4. The description does not need to explain non-existent parameters, and it appropriately focuses on the output behavior instead.

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 clearly states the tool retrieves family members/profiles from Skylight, specifically identifying those who can be assigned chores. It uses the verb 'Get' and the resource 'family members/profiles', distinguishing it from sibling tools like get_chores or calendar 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 provides explicit example questions that the tool should answer, giving clear context for when to use it. It does not explicitly mention alternatives or exclusion cases, but the examples effectively scope the tool's intended usage.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The "get" verb implies a non-destructive read, and the setup/debugging framing adds light context, but the description does not disclose return format, failure behavior, or auth requirements. Adequate for a simple info lookup but adds little beyond what the name already 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?

The description is compact and well-structured: a one-sentence purpose, a usage framing sentence, and a bulleted list of example queries. Every sentence earns its place, and the examples are genuinely actionable for an agent. No wasted words or vague 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 0-parameter, no-output-schema tool, the description covers the essentials: what it retrieves and when to invoke it, reinforced by concrete example questions. It could marginally mention what the response contains (e.g., frame ID, household settings), but the provided examples already name the key output (frame ID), making the description reasonably complete for this simple tool.

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 has zero parameters, so the baseline is 4 per the rubric. There is nothing for the description to explain regarding parameters; the schema trivially covers 100% and the description correctly does not invent any. No deduction is warranted since there is no parameter surface requiring elaboration.

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+resource: "Get Skylight household/frame information." This clearly distinguishes the tool from siblings like get_devices and get_family_members — it retrieves the household/frame identity-level data, not device or member lists. It is not a tautology of the name and is unambiguous about 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 description gives concrete usage context: "Useful for setup verification and debugging," plus two literal example user utterances ("Show Skylight household info", "What's my frame ID?"). This helps an agent match intents to the tool. It doesn't explicitly state when NOT to use it or name alternatives, but for a 0-param info tool the guidance is sufficiently 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?

With no annotations, the description carries the burden of behavioral disclosure. It states that the tool returns items 'organized by section with their completion status,' which communicates the read-only nature and the return shape beyond what the schema provides. It does not cover edge cases like missing lists, but for a straightforward retrieval tool this is adequate.

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 tightly structured: a one-sentence summary, a short bulleted list of example queries, and a one-sentence return behavior note. Every part earns its place without redundancy or 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 read-only list-item retrieval tool with no output schema and no annotations, the description explains the core purpose, common phrasing, and return organization. It could mention behavior when both listName and listType are supplied or when the list is not found, but the schema and simple tool scope make the description reasonably 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 coverage is 100% and every parameter already has a clear description, including the enum for listType and the default for includeCompleted. The description's example queries add modest real-world context but no new semantic detail beyond what the schema already communicates.

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: 'Get items from a specific Skylight list,' which clearly identifies the operation and distinguishes it from sibling list management tools like get_lists. Example user questions further reinforce that this tool retrieves the contents of a list, not list metadata or aggregation.

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 'Use this to answer' section provides clear, concrete use cases such as 'What's on the grocery list?' and 'Show me my to-do list,' making it easy for an agent to know when to invoke the tool. However, it does not explicitly name alternatives or state when not to use it relative to sibling tools like create_list_item or get_lists.

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?

With no annotations provided, the description carries the full burden and mostly delivers: it explicitly states the return shape ('list names, types (shopping/to_do), and item counts'), which compensates for the absence of annotations. It could be slightly more explicit about it being a non-mutating read, though this is heavily implied by 'Get' and the return-value emphasis.

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?

Three sentences, each carrying distinct weight: purpose+examples, when to use, and return shape. Zero filler words, perfectly front-loaded with the verb+subject.

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 parameterless read-only tool with no output schema, the description is fully self-sufficient: it explains what it does, when to use it, and what data comes back. Nothing more is needed given the tool's simplicity.

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?

Zero parameters means the schema needs no elaboration, so the baseline 4 applies. Nothing in the description contradicts or confuses this — no parameter documentation 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?

Clear verb+resource construction ('Get all lists from Skylight') with concrete examples ('grocery lists, to-do lists') that delimit scope. The examples naturally differentiate it from sibling get_list_items by focusing on the list-level granularity.

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?

'Use this to see what lists are available before adding items' provides explicit workflow context and implies when not to use it (when you already have the list ID). The only shortfall is not naming get_list_items directly as an alternative for item-level operations.

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?

With no annotations, the description carries the burden. It explicitly states it returns a list of connected sources and mentions examples (Google, iCloud), making the behavior transparent. It does not discuss side effects or errors, but for a simple read-only get, this is adequate.

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 highly concise, front-loaded with the primary action, and includes bulleted example queries for clarity. Every sentence earns its place without redundancy.

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-only list tool with no annotations or output schema, the description fully covers its purpose, usage context, and return type. No additional context is needed for an agent to use it 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?

The tool has zero parameters, so the baseline is 4. The description correctly avoids adding irrelevant parameter details, and the schema is trivial.

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 clearly states it gets connected calendar sources, a specific verb and resource, and distinguishes it from siblings like get_calendar_events by focusing on sources rather than events. The inclusion of example questions further reinforces its purpose.

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 explicitly provides example questions to use for, giving clear context on when to use it. However, it does not mention when not to use it or list alternative tools, though the sibling differentiation is implied.

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?

With no annotations, the description must disclose side effects. It states the input and return value but does not mention that updating is destructive (overwrites previous data), any permission requirements, or implications for recurrence. It also omits that partial updates might be allowed (only specified fields are changed). This leaves room for assumptions about mutability and safety.

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 well-structured with a clear summary, bulleted use cases, a parameter list, and return statement. It is appropriately sized for 8 parameters—each parameter gets a brief line but no long prose. Front-loaded with the core purpose, so the key information is immediately visible.

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 tool's complexity (8 optional params) and lack of annotations/output schema, the description covers the basics but misses important context: whether allDay interacts with startsAt/endsAt, any behavioral quirks (e.g., event recurrence), and what happens if a field is omitted (partial update or reset). Not incomplete but leaves gaps that could lead to misuse.

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 schema coverage is 100% with detailed descriptions for each parameter. The tool description repeats parameter names and adds small examples but does not add substantial meaning beyond the schema. However, it clarifies that startsAt/endsAt are ISO format and categoryIds map to family members, which is redundant. Meets baseline for high coverage.

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 clearly states the tool updates an existing calendar event, with specific examples (changing time, details, renaming) and distinguishes it from siblings like create_calendar_event and delete_calendar_event. The purpose is unambiguous and well-scoped.

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 provides clear 'Use this when' examples covering common scenarios, which helps the agent decide when to invoke it. It does not explicitly mention when NOT to use it (e.g., creating vs updating), but the context of 'existing event' and sibling names implies the distinction. Slight gap in explicit exclusions, but adequate.

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?

With no annotations, the description fully carries the transparency burden. It reveals critical behaviors: that changing date alone does not shift recurrence, that missing applyTo causes silent 200 responses with no change, and that unassigning is not supported. These details prevent user confusion.

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 thorough but slightly repetitive, repeating warnings about applyTo and recurrencePattern multiple times. However, each repetition reinforces critical constraints, and overall the structure is logical and easy to follow.

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?

Despite lacking an output schema, the description explains what the return value is and covers error scenarios (e.g., fields not changing). It also addresses edge cases for recurring chores, making the tool's behavior fully predictable.

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 descriptions cover 100% of parameters, but the description adds extra nuance beyond the schema, such as explaining the relationship between date and recurrencePattern and clarifying that assignee cannot be cleared. This adds value without being redundant.

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 clearly states the tool's function ('Update an existing chore in Skylight') and provides concrete examples of its use cases, distinguishing it from sibling tools like create_chore and delete_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?

It explicitly explains when to use the tool (marking complete, reassigning, etc.) and includes important caveats about recurring chores, such as needing applyTo and recurrencePattern. This goes beyond basic usage to guide correct invocation.

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?

With no annotations, the description carries the full transparency burden. It accurately states 'Update' (implying mutation) and specifies the return value ('Returns: The updated list details'). However, it does not disclose potential side effects (e.g., partial overwrites, whether changes are reversible), permission requirements, or behavior when multiple identifiers are supplied. It is not misleading, but gaps remain.

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

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

The description is well-structured with a clear purpose, usage bullets, parameter list, and return statement. It is front-loaded and reasonably compact. Slight redundancy exists because parameter details are repeated from the schema, but the added alternative-ID note justifies the length. No waste sentences.

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 annotations and no output schema, the description is fairly complete: it defines the action, usage cases, parameter semantics, and return format. It does not address edge cases like required fields (all optional) or conflicts if both listId and listName are provided, but these are not critical for basic usage. Given the relative simplicity of the tool, this is adequate.

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 schema covers all 5 parameters with basic descriptions, but the description adds extra value: it notes listName as an alternative to listId, suggests using get_lists to find IDs, and clarifies the meaning of 'label' as the new name. This compensates for the schema's minimal descriptions and provides operational guidance beyond the structured data.

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 clearly states the action: 'Update an existing list's name or settings.' It names the resource (list) and the specific operations (rename, change type/color), which distinguishes it from sibling tools like update_chore or update_calendar_event. The scope is explicit and 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?

The description provides a dedicated 'Use this when' section with three concrete scenarios: renaming, changing type, or changing color. This is clear contextual guidance. However, it does not mention when not to use the tool or explicitly name alternatives (e.g., create_list for new lists), so it misses the 'when-not' aspect for a top score.

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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It accurately implies mutation and states that the tool returns updated item details, but it does not discuss permissions, error handling, reversibility, or side effects beyond the basic 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 description is well-structured with a clear summary, use cases, parameter list, and return statement. It is slightly redundant with the schema's parameter descriptions, but the bullets and examples keep it efficient and scannable.

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 moderately simple update tool with five parameters and two required ones, the description covers the operation, use cases, all parameters, and return value. The absence of an output schema and annotations is partially compensated by the clear parameter descriptions and return statement.

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%, so the baseline is 3. The description's parameter list largely repeats the schema's existing descriptions without adding significant new meaning, though the use-case examples do provide some contextual framing.

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 clearly states the action: 'Update a list item (mark complete, rename, move to section).' This uses a specific verb and resource, and the parenthetical scope differentiates it from sibling tools like update_list or 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?

The 'Use this when' section provides explicit use cases with concrete examples, such as checking off milk or renaming an item. It does not explicitly mention alternatives or when not to use it, but the context is clear enough for selection.

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