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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the destructive action, specific files affected, the 30-minute idle guard, and how force=true bypasses that guard. This is thorough and clear.

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 two concise sentences, front-loaded with the action and resource, and every word adds value. It avoids redundancy and is 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?

For a simple one-parameter tool with no output schema, the description covers purpose, usage, behavior, and parameter semantics comprehensively. No critical information is missing for an agent 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 description adds meaning beyond the schema by explaining what the 30-minute idle guard is and how force relates to it. While the schema describes force as 'Clean even if the draft was touched recently', the description provides the underlying context, making the parameter's intent clearer.

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: 'Delete the in-flight draft state' with specific file paths. The verb 'Delete' and resource are unambiguous, and it distinguishes itself from sibling tools by focusing on cleanup of draft state rather than creation or publishing.

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 states when to use: 'Use to abandon a draft or after a completed publish.' It also explains the force=true condition for overriding the idle guard. However, it does not mention when NOT to use or alternative tools, leaving it just short of full 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, the description carries the full burden. It discloses that the tool pulls data and appends to a sheet, and provides a time estimate, which are useful behavioral clues. However, it omits potential side effects such as duplicate handling, whether the sheet is modified destructively, or error behavior for failed external calls.

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, information-dense sentence followed by a time estimate. Every element contributes value with no 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?

The description captures the core operation and timing but lacks context about the return value, failure modes, or handling of duplicate entries. Given the mutation of an external sheet and reliance on third-party APIs, more behavioral detail would improve 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?

Schema description coverage is 100% with clear per-parameter descriptions ('Luma event id', 'Meetup event id', 'Target Google Sheet id'). The tool description aligns with these parameters but adds no extra semantic detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description uses a specific verb 'pull', names the sources (Luma and Meetup), and the destination (master Google Sheet), making the tool's purpose unmistakable. It clearly distinguishes from siblings like draft_event or speaker_lookup, which have different objectives.

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?

'Phase 3' implies a particular workflow step but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions. The description is not misleading but offers only implied usage context.

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

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

With no annotations, the description carries the transparency burden. It discloses key behaviors: the form is public, the URL gets stored in the draft, and the operation takes ~30s. It does not explain reversibility, permission requirements, or failure behavior, but the stated side effects and latency give meaningful insight beyond the schema.

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 succinct sentences convey purpose, usage, and a critical behavioral note in under 30 words. Every part earns its place; no filler or repetition of schema details.

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 provides purpose, usage trigger, side effect, and timing. It omits operational details like required authentication, error handling, and how event_format affects the form, but given the schema covers parameters and the overall scope is narrow, it is reasonably complete. The draft integration is a key context that prevents ambiguity.

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%—all three parameters (title, folder_id, event_format) have descriptions. The tool description adds no extra semantic context for the parameters, so it rests at the baseline of 3 without enhancing or detracting from the schema's clarity.

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 identifies a specific action ('Create a public Google registration Form'), the resource (Google Form), and a follow-up side effect ('store its URL in the draft'). It distinguishes itself from siblings like 'set_registration_link' and 'draft_event' by focusing on form creation and draft integration.

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 the condition for use: 'Use when the organizer has no Meetup/Luma link.' This tells the agent exactly when to choose this tool over alternatives, providing a clear decision rule.

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 discloses key behavioral traits: writes to /tmp/draft_event.json, uses Gemini, takes 30-90 seconds, enforces a single-event concurrency limit via shared state, and interprets times as Europe/London. This goes well beyond what annotations might have provided and gives the agent a clear mental model of side effects and constraints.

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 yet information-dense. Each sentence serves a purpose: purpose, usage guidance, timezone note, duration, concurrency warning, and cleanup pointer. No filler or repetition exists. It is well-structured, starting with the core action and then layering constraints.

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 having no output schema, the description tells the agent what to expect: a structured draft file with description and LinkedIn copy. It covers duration, concurrency, timezone handling, and how to reset state. The tool's simplicity (one parameter) means this description is fully sufficient for safe and correct invocation.

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

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

The input schema already provides 100% coverage for raw_notes with a descriptive note about minimum length. The description adds extra semantic value by advising on content ('title, speakers, date/time, format') and clarifying timezone interpretation, which helps the agent craft a better raw_notes value. This elevates it above the baseline 3.

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: 'turn raw event notes into a structured draft (description, LinkedIn copy) via Gemini'. It specifies the resource (raw event notes) and output (draft written to /tmp/draft_event.json). It also distinguishes itself from siblings by framing this as 'Phase 1A', which separates it from later-stage tools like publish_event or schedule_linkedin.

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: this is the initial drafting step, and it tells users to provide as much detail as possible. It also warns about the one-event-at-a-time constraint and explicitly directs users to cleanup_state when abandoning a draft. However, it does not explicitly name alternatives for other scenarios or state when not to use this tool, so it falls short of a 5.

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

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

With no annotations, the description fully discloses critical behavioral traits: it is 'VERY SLOW — can take 15-40 minutes', has shared state constraints ('Only ONE event may be in flight at a time'), and writes to event-details.json. It also warns against retrying and points to cleanup_state for starting over. This is exemplary 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 compact and front-loaded with the core action, followed by critical operational warnings. Every sentence adds value, and the structure makes the long-running nature and concurrency limit immediately clear.

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 complex, long-running, stateful tool with no output schema and no annotations, the description covers the main inputs, outputs (links written to event-details.json), duration, concurrency, and fallback cleanup. It is sufficient for an agent to invoke and monitor the tool correctly.

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

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

The input schema provides full descriptions for both parameters (hint_date and hint_title), so schema coverage is 100%. The tool description does not add extra meaning beyond the schema, but the hints are logically connected to finding the recording, so a baseline score of 3 is appropriate.

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

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

The description gives a specific, multi-step account: 'find the event recording + transcript on Drive, trim silence, upload to YouTube, and write links back into the event's event-details.json.' It clearly distinguishes this from siblings like draft_event (earlier phase) and cleanup_state (abandonment) by framing it as 'Phase 3'.

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 context: it's a long-running phase that must not be retried while running, and it mentions cleanup_state as the way to abandon a draft. It doesn't explicitly contrast with publish_event or other siblings, but the 'Phase 3' label and concurrency warning give practical 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, the description discloses multi-minute execution, shared-state /tmp/draft_event.json serializing events, and concurrency limit of one, plus a warning to wait for the result.

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

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

Front-loaded purpose, followed by structured preconditions and notes; every sentence adds non-redundant information.

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

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

For a multi-step side-effect-heavy tool with no output schema, it covers actions, preconditions, excluded features, timing, concurrency, and recovery path.

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 is empty with zero parameters; description explains the tool operates on pre-existing draft state and refers to shared state path, clarifying what 'inputs' are implied.

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?

Description opens with 'Phase 2: publish the drafted event' and enumerates concrete actions (Drive folder, event-details.json, Calendar event with Meet link, Luma listing, social queues), clearly distinguishing it from drafting and cleanup.

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?

Explicit preconditions (draft exists, set_registration_link succeeded), exclusion (Meetup/poster not automated), and a pointer to cleanup_state for abandonment.

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 directly states the safety rule (stop on conflict) and latency. It conveys a read-only check through the verb 'check', but doesn't explicitly describe return behavior or state that no modifications occur, which is a minor gap.

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 focused sentences: purpose, usage timing, and critical rule/latency. No wasted words, well-structured, and easy to parse.

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 simple tool (2 params, no output schema, no annotations), the description provides all necessary operational context: when to run it, what it checks, how to react to conflicts, and expected latency. It is complete for correct usage.

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 100% coverage for both parameters, so the description adds no new parameter details. Baseline 3 applies as the description neither enhances nor contradicts 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 function: checking the WCC admin Google Calendar for conflicts at a proposed time. It uses a specific verb ('check') and resource ('WCC admin Google Calendar'), and its purpose is distinct from siblings like draft_event.

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 instructs to 'Run this BEFORE drafting an event with a date', providing clear sequential guidance relative to draft_event. It also specifies mandatory action on conflict ('MUST STOP and ask the user to pick a different time') and indicates the operation takes ~10s.

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 behavioral disclosure burden. It discloses the return format (JSON array of ISO timestamps), the exact timing rule (10 days out through event day at 10:00 Europe/London), and that it is 'Instant', implying no side effects or external calls. It does not explicitly state idempotency or error handling, but for a pure computation 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 two short sentences that front-load the main purpose, then add necessary detail about the output format and timezone. No unnecessary words or filler; every sentence contributes value.

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 1-parameter utility returning an array, the description is nearly complete: it specifies input, output format, and the exact schedule rule. It does not mention edge cases like invalid dates or whether the event must exist, but these are less critical for a stateless computation. Thus it is slightly shy of perfect 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?

Schema coverage is 100%: the only parameter, event_date_iso, is described and example provided. The description mentions 'event date' but adds no new semantic detail beyond what the schema already offers. Baseline 3 is appropriate since the schema fully documents the parameter.

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

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

The description clearly states the tool generates the 11-post LinkedIn cadence timestamps for an event date, with a specific scope (10 days out through event day, 10:00 Europe/London). This distinguishes it from sibling tools like draft_event or publish_event, which handle content creation or publishing rather than timestamp generation.

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 when an event date is known and the cadence timestamps are needed, but it does not explicitly state when to use this instead of alternatives. Sibling tools suggest it is part of an event workflow, but no direct exclusions or prerequisites are mentioned.

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

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 does mention 'Instant' and clarifies the target as the current event draft, but it does not disclose whether an existing URL is overwritten, what happens if no draft exists, or any error conditions. For a mutation tool, this is moderate transparency but leaves notable gaps.

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—two sentences—and front-loaded with the action verb. The workflow constraint is integrated in a natural, imperative way without unnecessary detail. Every word 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 simple two-parameter tool with complete schema descriptions, the description covers the core purpose and a critical workflow prerequisite. It does not explain return values or overwrite behavior, but given the tool's low complexity and lack of output schema, the remaining gaps are minor.

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 describes both parameters fully (url and file), so the baseline is 3. The description adds value by specifying valid URL sources (Meetup/Luma/Google Form), which enriches the otherwise generic 'The registration URL' in the schema. This elevates it above 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 uses a specific verb ('Save') with a clear resource ('registration URL') and target ('current event draft'). It also lists example URL types (Meetup/Luma/Google Form), which helps distinguish this from sibling tools like create_registration_form, which likely creates a new form rather than saving an existing link.

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 states the tool is REQUIRED before publish_event and that publishing without a registration link is forbidden. This provides strong when-to-use context. However, it does not explicitly name alternative tools or state when not to use this tool beyond the publish prerequisite, so it falls short of the most explicit 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, the description must disclose behavioral traits. It mentions latency (~10s) but does not explain side effects of create/upload actions, whether they modify the database, or permission requirements. This is a significant gap for a tool that can mutate data.

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

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

The description is compact, uses examples, and front-loads the database name. It could be more structured per action, but for its length it's efficient.

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 supports five distinct actions with side effects, yet only search and download are illustrated. No output schema is given, so return formats for search/download are undeclared. The create/upload actions lack any parameter guidance beyond 'action-specific parameter,' making the description incomplete for the tool's complexity.

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

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

Schema covers both parameters, and description adds example usage and clarifies the 'params' field as 'Speaker name or action-specific parameter,' which helps disambiguate the generic 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?

Clearly states it searches the WCC Google Drive speaker database and enumerates the supported actions. However, the tool name 'speaker_lookup' suggests read-only lookup, while actions include create/upload, which slightly muddies the 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?

Provides a specific use case: 'Use before drafting to reuse existing speaker bios.' This gives clear when-to-use context. Does not mention alternatives or exclusions, but among sibling tools, none competes for speaker database access.

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