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

Reveals critical behavioral traits: returns interactive form or needs_input JSON, tier-capped album_quality, multi-step workflow, and post-creation photo upload guidance. Since no annotations exist, the description carries full burden and does so thoroughly.

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 with a clear flow, but notably long (multiple paragraphs). Each sentence serves a purpose, but some procedural details could be condensed without losing clarity. Still, it's well-organized 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?

Comprehensive given the absence of output schema: describes return values (event id, access code, URLs). Covers the multi-step interaction for album settings and integration with upload workflow. No missing elements apparent.

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?

Adds significant meaning beyond schema by explaining that album_quality, enable_downloads, is_collaborative are user preferences not to be guessed, and provides the proper elicitation workflow. Schema already covers 100% of parameters with descriptions, but the tool description enriches their contextual usage.

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 creates a new FindMe event (wedding/photo gallery) and specifies return values (event id, access code, URLs). Distinguished from sibling tools like get_event, update_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?

Provides explicit when-to-use instructions (photographer requests to create an event), detailed step-by-step process for first call vs. subsequent calls, how to handle defaults, and when to include explicit preferences. Also advises calling get_upload_link after creation if photos are involved.

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 the description fully discloses behavior: soft-delete, immediate hiding, 7-day retention before permanent purge. This conveys the crucial mutation and data lifecycle aspects clearly.

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 purpose and followed by key behavioral details. No wasted words.

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

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

For a simple 1-param tool with no output schema, the description covers behavior thoroughly: soft-delete, immediate effects, data retention, permanent purge. It misses only a mention of return value or error conditions, but overall is nearly 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?

With 0% schema description coverage, the description adds no meaning to the single parameter event_id beyond what the schema provides (just a string type). The description could have explained that event_id identifies the event to delete, but it did not.

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

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

The description clearly states 'Soft-delete an event,' using a specific verb and resource. It distinguishes from sibling tools like restore_event by explaining the soft-delete behavior and data retention policy.

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 when to use (soft-delete), what immediately happens (event hidden, photos stop appearing), and that it can be restored within 7 days. It mentions restore_event as a recovery option, but does not explicitly discuss when not to use this tool vs alternatives like update_event.

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 full burden. It implies a read-only operation by saying 'confirm' and 'returns', but does not explicitly state that no data is modified or that it is safe to call multiple times. However, for a simple info retrieval tool, this level of transparency 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 a single paragraph that efficiently packs purpose, return values, usage instructions, and error handling. It could be slightly shorter, but every sentence serves a clear function.

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

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

With no output schema, no annotations, and zero parameters, the description fully covers what an agent needs: what the tool does, what it returns, when to call it, and how to handle results. No important gaps remain.

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 schema coverage is 100%. The description adds no parameter information, but none is needed. Per guidelines, 0 parameters yields a baseline of 4, and the description does not detract from 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: to confirm the FindMe account and Google Drive connection. It lists the specific pieces of information returned (email, plan tier, event count, Google email) and distinguishes itself from sibling tools like get_event or get_usage by focusing on session-level context rather than individual resources.

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 guidance: 'ALWAYS call this once at the start of any conversation that involves listing events, uploading photos, importing from Drive, or any account-scoped action'. It also advises surfacing the result to the photographer and gives instructions for handling mismatched emails or missing Drive connections.

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 mentions returned stats (photo_count, etc.) but does not explicitly state that it is a non-destructive read operation or disclose any other behavioral traits like authentication requirements.

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

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

Two sentences that are concise and front-loaded. First sentence states purpose and output, second sentence provides usage guidance. No wasted words.

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

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

Adequately complete for a simple 1-parameter tool with no output schema. Description covers purpose, when to use, and key output fields. However, it could mention that the tool is read-only or that the event_id must be valid.

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% for the single parameter (event_id). The description adds value by explaining what the tool returns (stats), but does not add beyond the schema for the parameter itself.

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 'Get full details for one event' with a specific verb and resource. Distinguishes from siblings because it's the only tool that retrieves a single event's full details.

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 says 'Use when the photographer asks about the status or stats of a specific gallery.' Provides clear context for use but does not explicitly mention when not to use 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?

With no annotations, the description bears the burden. It discloses the default time window but does not state whether the operation is read-only, requires authentication, or other behavioral traits.

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 that front-load the tool's purpose and list of metrics, then provide usage context. Every sentence adds 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?

Given the tool's simplicity, no output schema, and no annotations, the description adequately covers the tool's functionality, default behavior, and 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 coverage is 67%, and the description clarifies that the 'from' and 'to' parameters are optional with a default window of 'event creation to now', adding value beyond the schema's date format 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 description clearly states the tool retrieves aggregated analytics for an event, listing specific metrics (guest visits, unique visitors, etc.) and the default time window. It also gives example user queries, distinguishing it from sibling tools like get_event or get_usage.

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 example use cases (e.g., 'how many people viewed the Johnson wedding?') but does not mention when not to use the tool or suggest 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 bears full responsibility for behavioral disclosure. It states that the tool returns a PNG image that the AI can display or save, implying a read-only operation. However, it does not discuss potential errors, required permissions, rate limits, or what happens if the event ID is invalid. For a missing annotation scenario, this is insufficient.

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

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

The description consists of two concise sentences. The first states the primary function, and the second adds the value (display/save) and use case (signage). There is no redundancy or fluff; every sentence 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?

Given the tool's simplicity (2 parameters, no output schema, no annotations), the description covers the core purpose and output format. However, it omits error conditions, input constraints (e.g., event must be public), and details on how the image is returned (binary vs. URL). The description is adequate but not comprehensive.

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

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

Schema description coverage is 50% (only 'size' has a description). The tool description adds no additional meaning beyond the schema. It does not clarify the 'event_id' parameter's format or source. The description should compensate for the schema's lack of detail, but it does not.

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

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

The description clearly states 'Get a QR code image (PNG) for an event's public gallery URL.' The verb 'Get' and resource 'QR code image' are specific and unambiguous. It distinguishes itself from sibling tools like 'get_event' (event details) and 'get_event_analytics' (analytics), making the purpose immediately clear.

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 mentions 'Useful for printing signage at events,' which provides a concrete use case. However, it lacks explicit guidance on when not to use the tool, prerequisites (e.g., event must have a public gallery), or alternatives. The context is implied but not thorough.

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 fully discloses behavioral traits: the link requires no login, is reusable, scoped to one event, and photos are automatically resized. It also describes the workflow for the photographer, including the folder upload option. No annotations exist to contradict.

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 front-loaded with the purpose and returns a clear explanation. While relatively long, each sentence provides necessary context or guidance. A slight reduction in detail could improve conciseness, but structure remains 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?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is nearly complete. It covers purpose, behavior, usage workflow, and even hints at alternative scenarios. Minor missing details (e.g., error handling for invalid event ID) do not significantly detract.

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 one parameter (event_id) with 100% schema coverage description. The tool's description adds minimal additional meaning beyond the schema (e.g., 'scoped to this one event'), but baseline for high coverage is 3. No significant extra semantic value is provided.

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: 'Get a no-login "tap-to-upload" link for an event.' It distinguishes itself from sibling upload tools (upload_photos_from_paths, etc.) by providing a link for the photographer to upload, rather than uploading directly.

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 this tool ('THIS IS THE WAY TO UPLOAD when you can't read the photographer's local files') and when not to ('anywhere except a locally-installed Claude Desktop with the findme-mcp filesystem tool'). It provides clear instructions on how to use the returned link.

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 fully bears the burden. It discloses the data returned without any contradiction. Since it's a get operation, no side effects are expected, but explicit mention of read-only nature would improve 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?

Two sentences only, front-loaded with purpose and usage instructions. No extraneous text, every sentence 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?

No output schema, but description fully covers all returned fields (API requests, rate limit, storage, active event count). The description is complete for a simple read-only quota 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?

No parameters in schema, so baseline is 4. Description adds value by explaining what the response contains, which helps the agent understand the tool's purpose even though no parameters are 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 specifies the exact action ('Get current-month usage') and lists the specific metrics returned (API requests used/limit, rate limit, storage used/limit, active event count). It clearly distinguishes from sibling tools that deal with events or uploads.

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 when to use: when the photographer asks about usage, quota, remaining requests, or plan limits. No exclusions or alternatives mentioned, but the context is clear.

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

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 describes default limit, pagination using cursor, and filtering with created_after. However, it does not disclose whether the operation is read-only, any rate limits, or the return format. This is adequate but leaves some 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 extremely concise, with three short sentences. It front-loads the main purpose and then adds details, with no unnecessary words.

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

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

Given the tool is a simple list operation with no output schema, the description covers the essential behaviors: default limit, pagination, and filtering. It could mention return format but is sufficient for common use.

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 baseline is 3. The description adds value by explaining ordering ('most recent first') and usage of cursor for pagination, which goes beyond the schema's individual parameter 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 description clearly states the action (list), resource (events), scope (photographer's), ordering (most recent first), default limit, pagination mechanism, and a filter option. It distinguishes well from sibling tools like get_event (single event) and create_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?

The description implies when to use it (to list events with optional pagination and filtering) but does not explicitly state when not to use it or compare to alternatives. However, the context of sibling tools makes it adequately 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?

No annotations provided, so description carries full burden. It discloses failure conditions (active or past cutoff) but does not describe the return value or success behavior (e.g., returns restored event object). Lacks detail on idempotency.

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 concise sentences with no fluff. Every part 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?

Given low complexity (single param, no output schema, no annotations), the description covers purpose, constraints, and failure conditions. Minor gap: missing return value or success behavior.

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

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

Schema description coverage is 0% and the only parameter `event_id` is a string. The description does not add any additional meaning beyond the schema (e.g., format or validation). Minimal extra 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 clearly states the action 'Restore a soft-deleted event' with a specific resource (event) and verb (restore). It distinguishes from siblings like delete_event (which deletes) and create_event (creates new).

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 tells when to use (within 7-day recovery window) and when not (if already active or past cutoff). It provides clear context but does not explicitly mention 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, but the description fully discloses behavioral traits: field constraints (album_quality changeable only pre-upload, tier-capped), toggling behavior for booleans, nullability for clearing values, and conflict errors.

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 and well-structured, but slightly verbose. Every sentence adds value; no fluff, but could be tightened slightly without losing clarity.

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 9 parameters and no output schema, the description covers almost everything: parameter behavior, constraints, error scenarios. Missing only a note on what the API returns on success, but it's minor given the thoroughness.

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 significant meaning beyond the schema, such as explaining album_quality constraints, toggle behavior for enable_downloads and is_collaborative, and error handling. Schema coverage is 56%, but description compensates fully.

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

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

The description clearly states 'Update fields on an existing event' and lists all modifiable fields, making the purpose explicit. It is distinct from sibling tools like create_event and delete_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?

Provides explicit usage guidance: 'Only include the fields you want to change' and 'Use when the photographer wants to...'. Also includes a specific when-not scenario for album_quality and error handling advice.

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 always returns a redirect message instead of actual photos, explains the Drive scope limitation, and instructs the agent on proper handling. This is highly 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 three sentences, front-loaded with the purpose, then warnings, then actionable instruction. Every sentence is essential, with no wasted words.

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

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

Given the tool's complexity (unsupported in chat, Drive scope limitation) and lack of output schema, the description covers all needed information: what it does, why it fails, how to handle the result. Parameter behavior is contextualized appropriately.

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 75%, and the description adds value by implying that folder_id and folder_url are ignored (since the tool always returns a redirect). It also clarifies that folder_name is for display. While not explicit for all parameters, it provides meaningful context 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 attempts to import photos from a Google Drive folder, using a specific verb and resource. It distinguishes from sibling tools like upload_photos_from_paths and upload_photos_from_urls by focusing solely on Drive folders.

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 the tool is not supported in chat-based AI assistants due to Drive scope limitations, and instructs the agent to surface the redirect message verbatim and not to retry or guess. This provides clear when-to-use and when-not-to-use guidance.

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

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

With no annotations, the description carries full burden. It discloses auto-chunking (max 50 files), file size limits, photo resizing behavior, supported formats, and response stats. It does not mention error handling or prerequisites, but the coverage is strong.

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 and front-loaded with essential info. Some sentences (e.g., the voice instruction) could be moved to a system prompt, but overall each sentence contributes value. Slightly longer than minimal but not wasteful.

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 upload tool, it covers formats, limits, recursion, resizing, auto-chunking, and response stats. Missing error behavior and explicit permission requirements, but overall comprehensive.

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 value: explains that paths can be files, directories, or globs, mentions recursion (though `recursive` param is in schema), and adds context about file limits and supported formats beyond the schema 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 description clearly states the action ('Upload photos or videos from local file paths') and the target resource ('to a FindMe event'). It distinguishes from siblings by explicitly mentioning it is the 'primary upload tool' and contrasting with upload_photos_from_urls and upload_photos_from_drive_folder.

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 guidance on when to prefer this tool: 'prefer it when the photographer says things like...'. It does not specify when not to use it, but the context of sibling tools implies alternatives for non-local uploads.

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. Details download to temp buffer, streaming, auto-resize behavior based on album type, max 50 URLs, response with rich stats, and even style guidance for the AI's output (playful one-liner). No contradictions with annotations since none exist.

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

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

Six concise sentences, front-loaded with purpose, then procedural details, then a behavioral note. No fluff; every sentence adds unique value. Structured logically from what to how.

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 no output schema, description explains response includes stats, mentions limits (50 URLs), and resizing behavior. Missing error handling or specific URL requirements, but given sibling tools and context, this is sufficiently complete for an AI agent to use 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?

Schema coverage is 50% (only urls items described). Description adds context for event_id by linking it to 'FindMe event' and repeats urls description. While it doesn't provide detailed syntax for event_id, the overall usage is clear. Slightly above baseline due to compensating contextual information.

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

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

Description clearly states 'Upload photos/videos from public URLs to a FindMe event' with specific verb and resource. It distinguishes from sibling tools like upload_photos_from_paths and upload_photos_from_drive_folder by explicitly mentioning URLs and giving usage examples (Dropbox, Drive links).

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?

Directly states when to use: 'when the photographer shares Dropbox links, direct Drive download URLs, or similar.' Implicitly excludes local files (paths) and Google Drive folders (drive_folder) by contrasting with sibling tool names. Provides clear context.

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