Whenna

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

Annotations declare readOnlyHint=true, and the description confirms read-only behavior by describing output. It adds specific behavioral context (contiguous blocks, participant listing) beyond the annotation.

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 sentence conveys core functionality and output details efficiently. Slightly dense but well front-loaded with the primary outcome.

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, so description must compensate. It explains return content (blocks and free participants) but omits ordering details, block duration, or whether plan context is included. Adequate but not thorough.

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 are absent (0% coverage), and the description does not explain parameters. 'id' and 'top' roles are not clarified; 'top' is only defined by schema constraints (min, max, default), not its effect on results.

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 provides 'ranked best meeting times for a plan' with specific output details (contiguous blocks, who is free). It distinguishes from sibling tools like whenna_mark_availability or whenna_lock_time by focusing on optimization.

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 implies usage after availability data is collected, but does not explicitly state when to use or when to prefer siblings. No guidelines on prerequisites (e.g., plan must exist) 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?

No annotations are provided, so the description must cover behavioral traits. It mentions that the plan returns a shareable link and a creator_key for locking, and that recurring plans have no dates and repeat weekly. It does not disclose potential side effects, authorization needs, or rate limits, which is a gap for a creation tool.

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

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

The description is three sentences and is highly efficient. It front-loads the core purpose, then provides immediate usage context (timezone, recurring pattern). No superfluous 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?

Given 11 parameters, full schema coverage, and no output schema, the description covers return values (link and creator_key), timezone handling, and recurring behavior. It is complete enough for an agent to use the tool correctly, though it could mention error handling or limits.

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 100% description coverage, so each parameter is documented. The description adds value by explaining the 'days' parameter in detail (candidate dates, weekday names, monthly rules) and the 'frequency' parameter, which goes beyond the schema's short descriptions. This context helps the agent understand complex parameter combinations.

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 creates a Whenna plan, a shareable link that finds free times. It distinguishes from sibling tools like whenna_best_times (which likely finds best times for existing plans) and whenna_get_plan (retrieving plans). The verb 'create' and resource 'plan' are specific.

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 explains that times are wall-clock in a given timezone and how to make recurring plans (using weekday names). It mentions the returned link is for sharing and the creator_key authorizes locking, implying when to use the tool. However, it does not explicitly state when not to use it or compare to 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?

The description details the full return structure, including state (awaiting_answers, collecting, etc.) and suggested_next_step, adding behavioral context beyond the readOnlyHint annotation. It does not contradict annotations and clearly implies a read-only fetch 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 a single sentence but well-structured, front-loading the action and listing key returned fields. It is concise with no wasted words, though it could be split for readability. Still effective.

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 must explain return values. It comprehensively covers all relevant information: plan metadata, participant availability, ranked times, negotiation state, and a suggested next action. This gives an agent everything needed to understand the tool's output.

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% for the single parameter 'id', with a clear description ('Plan id (the part after /o/ in the link)'). The tool description adds no further parameter context, so baseline 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?

The description uses a specific verb 'Fetch' and resource 'Whenna plan', then enumerates all returned fields (title, window, availability, ranked best times, locked time, negotiation brief, state, suggested_next_step). This clearly distinguishes the tool from siblings like whenna_best_times or whenna_lock_time, which are about different 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?

It explicitly suggests polling 'between actions when coordinating', giving a clear usage context. It also mentions 'suggested_next_step telling an agent the best next move', which guides when to use this tool to decide subsequent actions. However, it does not explicitly state when not to use it or provide 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?

No annotations provided, so description carries full burden. Discloses that the lock makes the time visible to all viewers with calendar buttons and returns links. Doesn't mention irreversibility or error conditions, but overall transparent for a lock action.

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 concise sentences: purpose+prerequisite, usage modes, outcome. No extra words, front-loaded with critical info.

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 key aspects: prerequisite, two usage paths, effect on viewers, return type. No output schema, so describing calendar links is sufficient. Could mention error scenarios but not required for basic completeness.

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 description adds meaning beyond the schema by linking creator_key to its origin and explaining the two-tier usage (use_best vs explicit). It clarifies that day/start are optional when use_best is true. Schema covers 67% of params with descriptions, but the tool description fills gaps.

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 'Lock the final time on a plan' with a specific verb and resource. It distinguishes from siblings like whenna_best_times, which shows available times, and whenna_mark_availability, which is for input.

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 requires the creator_key from whenna_create_plan and explains two usage modes: use_best or explicit day/start. However, it doesn't explicitly contrast with alternatives like whenna_best_times for when not to use.

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 discloses key behaviors: replaces previous answer, empty array means explicit unavailability (✗), withdraw removes answer entirely, and result includes unapplied ranges. This is comprehensive.

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?

Five concise sentences, front-loaded with the primary action, each sentence adding essential information without repetition 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?

Given no output schema, the description mentions return values (unapplied ranges). However, it does not cover error cases (e.g., invalid id) or what happens on success. Still, it provides enough context for most use cases.

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 75%, and the description adds value for 'name' (use human name for recognition) and clarifies 'free' empty array behavior. However, 'id' parameter lacks any description in both schema and tool 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?

The description states a specific verb ('set') and resource ('participant's free times on a plan'), and distinguishes from sibling tools like whenna_best_times by focusing on marking individual availability.

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 implies usage for setting availability but does not explicitly state when to use this tool vs alternatives like whenna_best_times or whenna_lock_time. No 'use when' or 'do not use when' 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 provided; description fully discloses behavior: cloning setup, proposing candidate days, linking, emailing, returning new plan with its creator_key, and idempotency. No hidden side effects.

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

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

Single paragraph, front-loaded with purpose. Every sentence adds value: cloning, candidate days, linking, emailing, return value, idempotency. No 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?

With no output schema or annotations, description covers all needed aspects: purpose, prerequisites, return value, side effects, idempotency. Agent can 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 has 0% description coverage; description adds meaning by implying 'id' is the finished plan's id and 'creator_key' is an authorization key. Could explicitly state these, but sufficient given context.

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?

Clearly states 'Group memory: start the group's next plan from a finished one.' Lists specific actions: cloning setup, proposing candidate days, linking old to new, emailing opt-ins. Distinct from siblings like whenna_create_plan which creates a new plan from scratch.

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 mentions requirement for creator_key and idempotency. Implies context of a finished plan. Could be improved by explicitly contrasting with whenna_create_plan, but sufficient for typical use.

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?

Description adds behavioral details beyond annotations: mutual exclusivity and automatic calendar link for video rooms. IdempotentHint annotation is not contradicted. Good disclosure for a mutation tool.

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

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

Two efficient sentences, front-loaded with main purpose. No 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?

Given no output schema and simple parameters, description covers key behavior. Could mention return value or success signal, but omission is acceptable for a tool with idempotentHint.

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% (only location and video_call have descriptions). Description adds context about mutual exclusivity but doesn't explain id or creator_key parameters beyond their requirement. Adequate but not exceptional.

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 'Set' and the resource 'where the group meets', distinguishing between two options: a place name or video_call. Sibling tools like whenna_create_plan confirm this is a focused location-setting tool.

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 states that place and video room are mutually exclusive and that creator_key is required. Provides clear context but doesn't list when-not-to-use or alternative tools explicitly.

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