DropTrack

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is known. The description adds value by explaining the two-step behavior (save image, optionally assign to target), but it does not disclose whether assignment overwrites existing artwork or whether deletion is possible later.

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 that packs the source, action, output, and optional assignment without fluff. It is efficiently front-loaded and every word contributes to understanding the tool's operation.

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

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

Given the presence of a full input schema with 100% coverage and an output schema, the description covers the workflow context well. It lacks only minor guidance on prerequisites such as job completion status, but the explicit reference to droptrack_get_ai_job makes the intent clear enough.

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

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

Schema description coverage is 100%, and each parameter is already explained in the input schema. The description merely restates the target type without adding new semantic details about jobId, candidateId, assign, or targetType.

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') and names the exact resource (an AI album artwork candidate from droptrack_get_ai_job), the resulting artifact (a reusable DropTrack image), and the optional target (track or playlist). This clearly distinguishes it from siblings like droptrack_generate_album_art and droptrack_delete_album_art_image.

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 clearly implies the usage context: after obtaining candidates via droptrack_get_ai_job, this tool accepts one. It does not explicitly mention when not to use it or name alternatives, so it misses the full 'when-not/alternatives' bar.

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

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

Annotations already convey that this is a write operation (readOnlyHint: false) and non-destructive (destructiveHint: false). The description adds no behavioral details beyond 'Add a new contact', such as side effects, required permissions, or behavior when the company context is missing, but it does not contradict the annotations.

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, direct sentence with no filler or redundant phrasing. It places the verb and object first, making the tool's purpose immediately 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 tool with seven parameters and an output schema, the description covers the basic intent but leaves ambiguity around what 'current company' means and whether a company context must already exist. The 100% schema coverage and output schema reduce the burden, so the description is adequate but not fully self-sufficient.

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 for all seven parameters, so the structured data fully documents each field. The description adds no additional parameter-level meaning beyond the general sense of 'new contact', which is acceptable under the baseline given high schema 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 states a specific verb and resource ('Add a new contact') plus a scope ('to the current company'), which clearly conveys the tool's core action. It distinguishes itself from siblings like droptrack_add_contacts_to_list and droptrack_create_contact_list by focusing on a single contact added to a company, though 'current company' is not precisely defined.

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 minimal context ('current company') but no explicit guidance on when to use this tool versus alternatives such as droptrack_add_contacts_to_list or droptrack_create_contact_list. There are no exclusions, prerequisites, or decision rules, leaving the agent to infer usage from the name and sibling list.

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

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

Annotations already declare readOnlyHint=false, which aligns with the mutation described. The description adds a small precondition ('existing contact list') but does not disclose behavior such as duplicate handling, idempotency, or repercussions for invalid contact IDs. With annotations covering the basic mutation/destruction profile, this is acceptable but not rich.

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 that is clear, front-loaded with the action, and contains no filler. It efficiently communicates the core operation without unnecessary elaboration.

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, two-parameter write operation with fully documented parameters and an output schema present. The description covers the essential precondition that the list must already exist, though it could have explicitly noted duplicate or invalid contact behavior; overall it is sufficiently complete for correct invocation.

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

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

Schema description coverage is 100%, and both parameters are already documented as listId and an array of contact IDs. The description reinforces that multiple contacts can be added, but it does not add meaningful details beyond what the schema already provides, so the baseline score 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 ('Add'), a clear resource ('contacts'), and a target context ('existing contact list'). It distinguishes this from sibling tools like droptrack_add_contact and droptrack_create_contact_list by emphasizing the list already exists and that one or more contacts are being added.

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

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

The phrase 'existing contact list' implies the list must already exist before calling this tool, which is useful. However, it does not explicitly state when to use this tool versus alternatives such as droptrack_create_contact_list or droptrack_add_contact, leaving the routing mostly to inference.

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

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

Annotations declare readOnlyHint=false, yet the description frames this as a pure analysis call ('Analyze... and return structured analysis'). The schema reveals significant undisclosed side effects: creating new DropTrack tracks when title/artist are provided, saving a new active track version when trackId is set, and potentially returning asynchronously with polling instructions per analysisTimeoutMs. This is not a direct annotation contradiction, but a material under-disclosure for a mutating 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 tight sentences with zero waste. The verb and supported inputs are front-loaded, and the second sentence earns its place by establishing the workflow benefit (no browser analyzer visit). Appropriate length for the tool's scope.

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 15 optional parameters, multiple input pathways, async timeout behavior, and track-creation side effects, the description is too thin. It doesn't surface key decision points an agent needs: new track vs new version (trackId/title/artist), sync vs async behavior and polling, or the prerequisite upload flow via droptrack_create_audio_analysis_upload. An output schema exists, so return values need no explanation, but the central behavioral choices are left entirely to schema spelunking.

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 genuine value by enumerating accepted input formats (WAV, MP3, AIF, AIFF, SoundCloud, Spotify), which guides selection among the five input-source parameters (s3Url, audioUrl, providerUrl, uploadKey, audioBase64). It avoids duplicating the schema's already-detailed 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 uses a specific verb ('Analyze') with explicit resource types (WAV, MP3, AIF, AIFF, SoundCloud URL, Spotify track URL) and states the outcome: structured analysis returned through MCP. It also distinguishes from the browser-based analyzer workflow. However, it doesn't differentiate from the sibling droptrack_get_track_analysis, which could be confused for retrieving analysis of an existing track.

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

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

No guidance on when to use this tool vs alternatives. The schema hints at an upload workflow (upload_key returned by droptrack_create_audio_analysis_upload) and versioning behavior via trackId, but the description never tells the agent whether to prefer this tool over droptrack_get_track_analysis for existing tracks or how the upload flow relates. 'No browser analyzer visit is required' excludes a non-MCP alternative only.

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

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

Annotations already disclose destructiveHint=true and readOnlyHint=false, covering the mutation risk. The description adds some useful context by noting that it applies already-stored results and matches batch_auto_tag behavior, but it does not explain whether existing metadata is overwritten or how missing stored tags are handled beyond what the schema's queueMissing parameter already says.

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

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

The description is a single efficient sentence that front-loads the core action. There is no filler, tautology, or unnecessary restatement of the tool name.

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 output schema and fully documented parameters cover the mechanics, but the description lacks enough usage context to help an agent reliably choose this tool over related tagging and AI-analysis siblings. It is minimally viable but leaves selection guidance to inference.

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

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

Schema description coverage is 100%, and all four parameters already have meaningful descriptions in the schema. The tool description adds no parameter-level detail, so it is adequate but does not go 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 names a specific operation ('Apply stored AI track-tagging results to track metadata') and clearly identifies the resource being affected. It does not explicitly differentiate from sibling tools like droptrack_request_track_tagging or droptrack_get_track_tags, though 'stored results' partially signals that this is not the tool for requesting new tagging.

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

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

There is no explicit guidance about when to use this tool versus related alternatives such as droptrack_request_track_tagging, droptrack_analyze_audio, or droptrack_get_track_tags. The phrase 'stored AI track-tagging results' implies a prerequisite, but the description never states it directly or names alternative tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful scope with 'public' and lists the directory categories, but provides no behavioral detail such as pagination behavior, authentication, or rate limits; the bar is lower due to annotations, so this is adequate but minimal.

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

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

A single sentence with no filler; the action and resource come first. It is appropriately brief for a tool whose full parameter detail lives in the schema.

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 browse tool with fully documented parameters and an output schema, the description is mostly sufficient, but it does not address the closely related sibling get_track_submission_opportunities or explain when the public directory tool is preferred. That missing routing context is a clear gap.

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 schema fully documents all 8 parameters. The description only restates the accountType categories (labels, DJs, bloggers, playlist curators) that already appear in the schema, adding no new parameter-level meaning.

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 the specific verb 'Browse' and names the resource: the public DropTrack submission directory, plus the entity types included. It is clear, but it doesn't explicitly distinguish itself from the sibling droptrack_get_track_submission_opportunities, so it stops short of full differentiation.

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

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

The description implies the tool is for browsing a public directory, which gives some context, but it never states when an agent should choose this over get_track_submission_opportunities or other list tools, nor any exclusions. The use case is inferred from the verb and resource rather than explicitly specified.

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

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

Beyond the annotations, the description adds valuable behavioral context: the URL is authenticated and short-lived, plan limits are enforced before upload, and allowed file formats are specified. It also clarifies that the tool creates a URL rather than performing the actual upload. No contradictions with annotations.

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

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

A single sentence, front-loaded with the core action, followed by key constraints. Every phrase carries meaning; there is no 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 description is complete enough for calling the tool: it states the purpose, accepted file types, and key constraints, and an output schema exists to document return values. Minor gaps remain around the specifics of plan-limit enforcement and the exact lifetime of the URL, but these are not required to make the call.

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 schema fully documents the parameters. The description adds contextual framing around audio file upload and plan-limit enforcement, but it does not add per-parameter meaning beyond what the schema already provides. 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 states a specific action ('Create'), a specific resource ('authenticated short-lived S3 upload URL'), and a precise scope (WAV, MP3, AIF, or AIFF files). It clearly distinguishes itself from analysis or download siblings by focusing on creating an upload URL rather than performing analysis or retrieval.

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 this tool: when an audio file needs an S3 upload URL before analysis/upload. It names no alternatives, exclusions, or explicit conditions for choosing a sibling tool, leaving some inference to the agent.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the create behavior is expected. The description adds the useful scoping detail that the list is created in the current company, but does not disclose other behaviors like duplicate handling or permission requirements.

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

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

The description is a single, clear sentence with no filler. It front-loads the core action and resource, making it easy for an agent to parse quickly.

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 create tool with an output schema and 100% parameter coverage, the description is essentially complete. It includes the important company-scoping detail, though slightly more context about the response or failure behavior would make it fully robust.

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 the single 'name' parameter is already described as 'Name for the new contact list'. The description adds no additional parameter-level meaning, so the baseline score 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 ('Create') with a clear resource ('contact list') and scopes it to the current company. This clearly distinguishes it from siblings like droptrack_add_contacts_to_list and droptrack_list_contact_lists.

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 the tool is for creating a new contact list, which is sufficient for a simple creation action. However, it does not explicitly state when to prefer this over alternatives such as droptrack_add_contacts_to_list or provide exclusions.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description carries the burden of explaining behavior. It does so richly: it creates but does not send, persists a specific set of campaign attributes, supports exclusions by normalized email and saved recipient snapshots, and rejects U+2014 em dashes. This is far more than the annotations imply.

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 dense sentences with the core action front-loaded and no filler. Every sentence contributes: the first defines the operation, the second details what is persisted and excluded, and the third gives the validation prerequisite.

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 14-parameter complexity, 100% schema coverage, and presence of an output schema, the description covers purpose, side effects, exclusion semantics, the em-dash constraint, and the required validation step. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds semantic value by grouping the side effects into concepts like 'active subscribed recipients', 'exact playlist', and 'creator identity', and by clarifying the meaning of the two exclusion parameters with 'normalized-email members' versus 'exact saved recipient snapshots'. Much is a synthesis of the schema, but the grouping and workflow guidance are genuinely useful.

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, unambiguous action: 'Create and read back a complete Draft-status campaign without sending it.' It names the resource, the status, and the key boundary (no send), which clearly distinguishes it from send, validate, and read-only campaign 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 gives actionable guidance: 'Use campaign exclusions for historical no-repeat guarantees' and 'Run droptrack_validate_campaign_draft before opening the native Send Test flow.' It does not explicitly state when not to use the tool or name a direct alternative, but the context is clear enough for an agent to select it appropriately.

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

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

Beyond the destructiveHint annotation, the description adds meaningful behavioral detail: the delete is a soft-delete, and the operation also unassigns the image from tracks or playlists. It also scopes the effect to assets owned by the authenticated company, which is valuable context for authorization-aware 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 a single, front-loaded sentence that states the action, the target resource, and the key side effect. Every element earns its place and there is no redundant or filler wording.

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 one-parameter operation with a documented output schema and clear annotations, the description provides adequate context to select and invoke the tool correctly. The ownership scope and unassignment side effect are disclosed, leaving no critical gaps.

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

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

The schema fully describes the only parameter, imageId, as 'AI image ID to delete'. The tool description reinforces that this references an album artwork image, but the parameter's meaning is already clear from the schema. No additional parameter-level guidance 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 uses a specific verb ('soft-delete') and names the exact resource ('AI-generated album artwork image') plus the side effect ('unassign it from tracks or playlists'). This clearly distinguishes it from related tools like generate_album_art or accept_album_art_candidate.

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 clearly conveys the intended use case: removing an AI-generated album art image owned by the authenticated company. It does not explicitly name alternatives or provide when-not-to-use guidance, but the operation is specific enough that an agent can infer when it applies.

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 discloses that the operation is asynchronous ('Queue') and outlines the expected follow-up polling and acceptance steps, which annotations do not convey. It adds meaningful behavioral context beyond the readOnlyHint/destructiveHint flags, though it does not mention rate limits, costs, or failure modes.

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 with no filler. The core behavior is front-loaded, and the follow-up workflow is stated immediately after. Every sentence adds navigation 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?

The description plus a fully documented input schema and output schema cover most invocation needs. It provides the essential workflow handoff, though it could slightly improve by noting that the operation returns a job identifier or that generation may take time.

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 documents every parameter including defaults and enums. The description does not add parameter-level meaning beyond the schema, so the 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 uses a specific verb 'Queue' with a clear resource ('AI album artwork generation') and target scope ('track or playlist'). It clearly distinguishes this from generating other content types like artist bios or press releases, and names the exact companion tools in the workflow.

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 sequential context: call this to queue generation, then poll with droptrack_get_ai_job, then accept with droptrack_accept_album_art_candidate. It names the relevant sibling tools precisely, though it does not explicitly state 'do not use X instead' or discuss conditions that would make an alternative preferable.

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 clearly conveys asynchronous behavior ('Queue... Poll with droptrack_get_ai_job') and provides the exact polling contract via jobType=artist_bio. It also scopes the operation to the authenticated company, adding meaningful context beyond the annotations, which only indicate readOnlyHint=false and destructiveHint=false.

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 with no filler: the first states the action, the second gives the essential follow-up step. The most important information is front-loaded and 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?

For a no-parameter async job-queueing tool with an output schema present, the description is fully complete. It tells the agent what the tool does, the scope, and exactly how to retrieve the result via droptrack_get_ai_job, so no critical information is missing.

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

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

The input schema has zero parameters, so there are no parameter details to document. The description adds implicit-context meaning by noting that the operation applies to the authenticated company, which is the relevant contextual input for this tool.

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, 'Queue', and a clear resource, 'an AI artist bio draft', scoped to 'the authenticated company'. It is easily distinguished from sibling generation tools like droptrack_generate_album_art and droptrack_generate_press_release because the target artifact is explicitly an artist bio.

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 states exactly what action to take after invoking this tool: poll droptrack_get_ai_job with jobType=artist_bio. It clearly implies this tool is the right entry point for generating a bio draft, though it does not explicitly list alternatives or when not to use it.

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 discloses the asynchronous queue-then-poll behavior, which is not evident from the annotations alone. It also adds an ownership requirement, giving the agent a basis to check permissions before invoking. No contradiction with annotations; readOnlyHint=false aligns with 'Queue' being a write 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?

Two sentences, zero filler. The primary action and prerequisite are front-loaded, and the follow-up polling instruction is placed directly after. 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 an async job-queueing tool with an output schema, the description is complete: it states the action, target, ownership requirement, and how to retrieve the result. The sibling tool list and output schema provide additional context, and nothing essential is missing.

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

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

The schema already documents all three parameters with complete descriptions (100% coverage), so the description need not add more. It does not provide additional parameter-level nuance beyond the schema, matching the baseline for full schema 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 states a specific verb ('Queue'), a specific resource ('AI press release draft for a track'), and a crucial scoping condition ('owned by the authenticated company'). This clearly distinguishes it from sibling generation tools like droptrack_generate_album_art and droptrack_generate_artist_bio, which target different content types.

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 clearly communicates the trigger context: generating a press release for an owned track. It also provides a concrete next step ('Use droptrack_get_ai_job with jobType=press_release to poll the result'), though it does not explicitly mention alternatives or exclusions.

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

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

Annotations already declare this read-only and non-destructive. The description adds useful behavioral context beyond those hints: it returns aggregate totals over a date range and switches granularity when campaignId is supplied. There is no contradiction with the readOnlyHint.

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 short sentences front-load the core operation and then add the only conditional that changes behavior. There is no filler and no redundant restating of schema fields or annotations.

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 an output schema present and read-only/non-destructive hints in the annotations, the description covers the essential invocation context: date range, aggregation scope, and the single-campaign override. It is complete for a simple analytics getter, though it does not explicitly distinguish itself from nearby analytics siblings such as droptrack_get_campaign_analytics.

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 all three parameters with descriptions, which sets a baseline of 3. The description adds semantic value by explaining that supplying campaignId changes the result from company totals to a single campaign, and 'over a date range' clarifies the role of from and to.

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 ('Get Grow/ads daily analytics') and then states the exact scope: company totals or a single campaign when campaignId is supplied. This clearly differentiates it from sibling tools like droptrack_get_label_ad_analytics, which target label-level data.

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 for when to use the tool: for daily analytics over a date range, optionally scoped to one campaign via campaignId. It does not explicitly name alternatives or state when not to use it, so it stops short of full routing guidance, but the intended usage is 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds context that the result includes landing page, creatives, and recent daily metrics, but it does not disclose further behavior such as metric date ranges or authentication needs.

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 concise sentence that front-loads the action and resource, then lists what is included. There is no filler, though it is minimal.

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, read-only detail lookup with an output schema present, the description covers the core purpose and data scope. It could mention how to discover campaign IDs or differentiate from related campaign tools, but the description is not critically incomplete.

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 has 100% coverage for the single parameter and already describes campaignId as 'The ads campaign ID'. The tool description does not add parameter-level meaning beyond that, so the baseline 3 applies.

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

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

The description uses a specific verb and resource: 'Get details for a Grow/ads campaign' and names concrete included content (landing page, creatives, recent daily metrics). It reads clearly and is more informative than the title, though it does not explicitly differentiate itself from siblings like droptrack_get_campaign_details or droptrack_get_ad_analytics.

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

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

No guidance is provided about when to choose this tool over alternatives such as droptrack_list_ad_campaigns, droptrack_get_campaign_details, or droptrack_get_ad_analytics. The intended use is implied, but there are no exclusions or routing cues.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe, read-only nature is clear. The description adds minimal behavioral context like 'current' and 'recent', but does not disclose pagination behavior or any other operational details. Since annotations cover the key safety traits, a mid-range score is appropriate.

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

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

The description is a single, front-loaded sentence that states the action and the returned data without any fluff or repetition of the tool title. Every word earns its place, making it easy to scan and understand quickly.

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 output schema provides return-value details, and annotations cover the read-only safety profile. The description is sufficient for a simple, parameter-less invocation. The only minor gap is not explicitly pointing to the label-wallet sibling as an alternative, but this does not hinder correct basic 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?

Both parameters (limit and cursor) are fully described in the input schema with defaults, ranges, and descriptions, giving 100% schema coverage. The description does not add any parameter-specific meaning, which is acceptable since the schema already carries the full burden. This matches the baseline score of 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 uses a specific verb ('Get') and clearly identifies the resource: the company ads wallet balance and recent wallet transactions. The word 'company' distinguishes it from the sibling tool 'droptrack_get_label_ads_wallet', which targets a different scope. This is unambiguous and directly describes what the tool does.

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 the tool: when you need the company ads wallet balance or transactions. However, it does not explicitly state when not to use it or mention the alternative label-wallet tool. The agent must infer the distinction from the word 'company', which is acceptable but not 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the 'queued' and 'poll' context, indicating an asynchronous job lifecycle, but does not describe polling semantics, status behavior, or rate limits. This is adequate but not richly 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 one short, front-loaded sentence that names the action, resource, and supported job types. Every word contributes, and there is no filler or redundant restating of the tool name.

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 that the schema fully documents parameters and an output schema exists, the description is mostly sufficient: it identifies what is polled and the relevant job types. It is slightly incomplete because it leaves usage distinctions to inference, but the structured inputs cover invocation details.

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 schema already documents all four parameters and their dependencies. The description only repeats the jobType enum values without adding new meaning, so it does not elevate the baseline score.

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: 'Poll a queued AI job' with a specific resource (AI jobs) and enumerates the supported job types. It does not explicitly contrast this with droptrack_list_ai_jobs or the generate_* tools, so it is clear but lacks explicit sibling differentiation.

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

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

The description gives no guidance on when to use this tool versus listing all AI jobs or when to poll after calling a generate tool. The intended usage is only implied by the word 'poll' and by schema details like 'Message ID returned by the generate tool,' but no explicit when/when-not guidance is provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavioral context beyond annotations: it returns the 'current' company artist profile and indicates that recent generated bio jobs are included, which clarifies data freshness and scope without contradicting the annotations.

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

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

The description is a single front-loaded sentence that states the resource, purpose, and contents with minimal waste. Every phrase 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 zero-parameter interface, read-only annotations, and presence of an output schema, the description is complete. It identifies the resource type, the feature it supports, and the key data categories returned, leaving no critical gap for an agent to call 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 there is no parameter ambiguity to resolve. The description's field list gives useful context about what the returned profile contains, and the schema is fully trivially covered.

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 and resource: 'Get the current company artist profile' and enumerates the actual content included (bio, socials, genres, recent tracks, recent generated bio jobs). This clearly distinguishes it from sibling tools like droptrack_generate_artist_bio or droptrack_get_label_info.

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 context by noting the profile is 'used by the AI artist bio feature,' but it does not explicitly say when to choose this tool over related alternatives or when not to use it. Usage is inferable but not directly guided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that results are per-recipient and include opens, plays, downloads, and feedback, but it does not disclose details such as pagination, time-window limits, or empty-result semantics. This is acceptable given the output schema 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?

A single tightly worded sentence front-loads the main action and resource, then lists the exact engagement types. No words are wasted and no redundant restatement of the tool name appears.

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 one-parameter read-only tool with a full input schema and an output schema, the description is complete enough: it names the campaign context, the per-contact granularity, and the engagement dimensions returned. Nothing else is required 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 only parameter, campaignId, is already fully described in the schema ('The campaign ID') with 100% schema coverage. The description adds no campaignId-specific meaning, so it meets the baseline but does not go 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 states a specific verb ('Get'), a precise resource ('per-contact engagement analytics for a campaign'), and enumerates the exact metrics included (opens, plays, downloads, feedback). This clearly differentiates it from sibling tools like droptrack_get_campaign_details and droptrack_get_ad_analytics, which target different data.

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 scoping phrase 'per-contact engagement analytics ... for each recipient' implies when to use it, but there is no explicit when-not or pointer to alternatives such as get_campaign_details or get_campaign_nudge_summary. An agent must infer selection from the resource wording.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by listing what data is returned, but it does not address error behavior, auth, or rate limits; this is acceptable given the read-only annotations but not exceptional.

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

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

One compact sentence that front-loads the verb-resource pair and then lists relevant fields, with no filler or repetition. 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 read-only detail lookup with one required parameter, an output schema, and readOnly/destructive annotations, the description gives an agent enough to select and invoke the tool correctly. No critical operational context is missing.

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

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

The single parameter campaignId is fully documented in the schema with type and description, giving 100% schema coverage. The description adds no parameter-specific detail beyond the schema, so it meets the baseline but does not exceed 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 uses a specific verb-resource pair ('Get full campaign details') and enumerates concrete fields such as subject, recipient counts, status, and settings. This makes the tool's scope immediately clear and distinguishes it from sibling analytics or list 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 phrase 'full campaign details' clearly conveys the intended use case: retrieving the complete detail record for a single campaign. It does not explicitly name alternatives or when-not-to-use, but the purpose statement provides sufficient context within the large sibling set.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, lowering the burden on the description. The description adds the data-scope context (which five categories are returned) but does not disclose behavioral traits such as whether the digest state may be absent for campaigns without a configured digest, or whether totals are computed live. No contradiction with annotations; the 'Get' verb aligns with the read-only hint.

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

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

A single, front-loaded sentence beginning with the verb 'Get' that packs five distinct data categories into a compact, scannable list. Every word earns its place; there is no filler, repetition, or boilerplate.

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 one required parameter and an output schema present, the description adequately covers the data scope, and the description need not explain return values. The only meaningful gap is the absence of explicit differentiation from the nudge-related siblings, but overall the definition is sufficient for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3 even without parameter details in the description. The phrase 'for a campaign' reinforces that campaignId scopes the result, but the description adds no meaningful format, range, or constraint information beyond what the schema already states for this single required 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 uses a specific verb ('Get') with a clear resource ('campaign nudge summary') and enumerates exactly what is returned: nudge settings, funnel totals, stuck-contact buckets, sent nudge history, and weekly digest state. This level of specificity distinguishes it from siblings like droptrack_get_campaign_details and droptrack_get_campaign_analytics, which cover different data domains.

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 usage context is implied through the enumerated data categories — an agent can infer this is the aggregate nudge overview for a campaign. However, there is no explicit when-to-use guidance, no exclusions, and no routing to closely related siblings such as droptrack_list_campaign_nudge_contacts or droptrack_get_contact_nudge_context, which would clarify when per-contact detail is needed instead.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is fully consistent with that. The description adds the 'timestamped' nature of the returned comments and the three scope modes, which clarifies expected behavior without contradicting the annotations.

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

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

A single compact sentence that front-loads the core purpose and enumerates all supported scopes without redundant phrasing. 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?

Combined with the rich input schema, output schema, and annotations, the description covers what the tool does, which scopes it supports, and its read-only safety profile. It omits no critical context needed to invoke the tool correctly, though it could briefly mention pagination 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 100%, so the parameters are already well documented. The description adds no new parameter-level meaning beyond what the schema provides, matching the baseline expected for high schema 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 action ('Get'), the resource ('timestamped comments'), and the valid scopes (track, playlist, campaign). This fully distinguishes it from the many other get_* tools in the sibling list, none of which retrieve comments.

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 for when to use the tool: when timestamped comments are needed for a track, playlist, or campaign. It does not explicitly name alternatives or exclusion conditions, but no sibling tool offers comparable comment retrieval, so the context is sufficient.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds 'subscription status' as a useful output detail, but it does not disclose behaviors like error handling, required permissions, or data freshness. This is adequate but not rich.

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

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

The description is a single, front-loaded sentence: 'Get the full profile of a specific contact including subscription status.' Every word 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?

The tool is a simple read-only getter with one well-documented parameter, behavioral annotations, and an output schema. The description is sufficient for basic invocation, though it could be slightly more complete by pointing to how to obtain a contactId. Overall, no critical missing information for correct 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%: each parameter already has a description, and the sole parameter contactId is documented as 'The contact ID.' The description's 'specific contact' reinforces the parameter's role but adds no meaningful semantic detail beyond the schema, 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 and resource: 'Get the full profile of a specific contact.' It also adds a distinguishing detail, 'including subscription status,' which clarifies the scope of the returned data and separates it from more narrow sibling tools like get_contact_nudge_context.

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

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

The description gives no explicit guidance on when to use this tool versus siblings such as droptrack_search_contacts or droptrack_get_label_contact_360. It does not mention prerequisites, exclusions, or alternatives, so an agent must infer usage from the name and parameter alone.

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

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

Annotations already carry the safety profile (readOnlyHint=true, destructiveHint=false), so the description only needs to add behavioral context beyond that. It does clarify what 'nudge context' means operationally by enumerating the two return categories, which adds genuine value. It stops short of disclosing the recency window behind 'recent', ordering, or pagination behavior, though the presence of an output schema reduces the burden.

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

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

A single sentence with a front-loaded verb+object and a colon-delimited enumeration of the two return categories. Every word earns its place — no filler, no repetition of the title or schema 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 fully documented parameters, safety annotations, and an output schema present, the description is nearly complete. The only meaningful gaps are the undefined 'recent' time window and the lack of sibling disambiguation, both minor against the structured fields carrying the rest of the burden.

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

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

Schema description coverage is 100%: contactId ('The contact ID') and limit ('Maximum campaigns and sent nudges to return', with min/max/default) are both documented in the schema itself. The description adds no parameter-level detail beyond what the schema already states, so the baseline 3 applies.

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

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

The description opens with a specific verb and resource ('Get CRM nudge context for one contact') and then defines the deliverable precisely via two data components: active campaigns watching the contact and recent automated nudges sent for it. The 'for one contact' scope plus the campaign/nudge breakdown distinguishes this from campaign-scoped siblings like droptrack_get_campaign_nudge_summary and droptrack_list_campaign_nudge_contacts.

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 scope 'for one contact' implies this is the tool for single-contact nudge-context lookups, and the two enumerated data components hint at what the agent will receive. However, the description never states when to prefer this over the closely related siblings (get_campaign_nudge_summary, list_campaign_nudge_contacts) or when not to use it. With roughly 55 siblings, explicit routing guidance would materially help.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds an authorization requirement ('Requires label-admin access') and clarifies the cross-roster scope, which are behavioral details beyond the annotations. No contradiction 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 a single, tight sentence with no filler. It front-loads the action and resource, then adds the key access constraint. 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 read-only analytics tool with a full input schema and an output schema, the description adequately covers purpose, scope, and access level. It does not elaborate on behavioral edge cases, but the structured fields already carry parameter details, so nothing critical is missing for a correct call.

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 'date range' maps to the required from/to parameters, but it does not add extra meaning for artistIds or labelCompanyId beyond what the schema already provides.

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

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

The description states a specific verb (Get), a clear resource (cross-roster Grow/ads analytics), and a scope (over a date range). The 'cross-roster' and 'label-admin access' terms help distinguish it from the likely per-user ad analytics sibling, though it does not explicitly name droptrack_get_ad_analytics as the alternative.

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 a useful prerequisite ('Requires label-admin access') and implies that this tool is for label-level, cross-roster analytics. However, it does not explicitly state when to choose this tool over related siblings such as droptrack_get_ad_analytics or droptrack_get_label_analytics, leaving the usage guidance implied rather than stated.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds useful context by disclosing the admin-permission requirement. This goes beyond the annotations and helps an agent understand authorization prerequisites.

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 with no filler. The core action and resource are stated first, followed by the permission requirement. 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 simple read-only operation, an output schema, fully documented optional parameters, and annotations covering safety, the description is sufficient. It conveys the resource, the data returned, and the required permission level.

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

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

Schema description coverage is 100%, and each parameter already has a meaningful description. The tool description adds no further parameter-level meaning but does not need to, since the schema carries the burden.

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 and resource: 'Get the label shared ads wallet balance and recent transactions.' This is distinct from siblings like droptrack_get_ads_wallet by the qualifiers 'label shared', though it does not explicitly name or contrast those siblings.

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

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

The only usage guidance is 'Requires label-admin access,' which states a precondition but not when to choose this tool over alternatives such as droptrack_get_ads_wallet or droptrack_set_label_shared_wallet. No exclusions or alternative-selection criteria are provided.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds value beyond this by disclosing the label-admin access requirement and the cross-roster aggregation scope. There is no contradiction between the description and the annotations.

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 with no filler: the core operation and scope are front-loaded, followed by the useful access requirement. Every clause 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?

The description is complete enough for selection and invocation: it states the purpose, scope, and access requirement, while the 100% parameter coverage and output schema cover parameter details and return shape. It does not discuss alternatives in depth, but that is a minor gap rather than a blocker.

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 even without parameter detail in the description. The description adds contextual framing around date-range analytics, but artistIds and labelCompanyId semantics are already fully documented in the schema.

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

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

The description clearly identifies the operation with a specific verb and resource: 'Get cross-roster label analytics over a date range,' and enumerates the contents (totals, artist rollups, top tracks, top contacts). The 'label' and 'cross-roster' framing distinguishes it from the many sibling analytics tools focused on tracks, campaigns, or ads.

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 clear context for when to use it: label-admin-level analytics aggregated across a roster over a date range, and it states the admin access prerequisite. However, it does not explicitly name alternative analytics tools or state when not to use this one, so it stops short of full exclusion guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is established. The description adds valuable context by disclosing the admin-access requirement and clarifying the returned data shape ('engagement timeline and per-artist breakdown'), which goes beyond the annotations.

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 with no filler. The core function is front-loaded, and the access requirement is stated succinctly. 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 read-only single-contact lookup with a full output schema and clear annotations, the description is nearly complete. It conveys what the tool returns and who may use it. It could slightly improve by naming a sibling alternative for basic contact details, but the output schema covers return structure and no critical calling context is missing.

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

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

Schema description coverage is 100%, so both contactId and labelCompanyId are already documented in the schema. The description adds no additional parameter-level meaning, which is acceptable given the complete schema coverage, so the baseline of 3 is appropriate.

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

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

The description clearly states a specific verb ('Get'), a specific resource ('one contact'), and a distinctive scope ('cross-roster engagement timeline and per-artist breakdown'). This differentiates it from sibling tools like droptrack_get_contact_details or droptrack_list_label_contacts, which would not provide the 360-degree engagement view.

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 the tool is for label administrators needing a comprehensive single-contact engagement view, and it explicitly notes the 'label-admin access' prerequisite. However, it does not explicitly state when to prefer this over alternatives like droptrack_get_contact_details or when not to use it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description only needs to add behavioral context. It adds the active-company default and the exact families of metadata returned. No contradiction with annotations.

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

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

One front-loaded sentence with no filler. Every element—default scope, metadata categories, and override context—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?

This is a simple read-only lookup with zero required parameters and an output schema present. The description, combined with annotations and schema, leaves no material gap for an agent deciding whether or how to invoke it.

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

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

Schema description coverage is 100%, and the sole parameter labelCompanyId is already described as an 'Admin-only override'. The description adds the default context of 'active company' but does not need to explain the parameter further. Baseline 3 is appropriate when the schema carries the semantic weight.

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 plus resource: 'Get label-family metadata for the active company'. It enumerates concrete content (parent label, sub-accounts visible to label admins, shared wallet status), which distinguishes it from label analytics, wallet, or contact siblings.

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

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

Clear context is provided: the tool operates on the active company unless an admin override is supplied. It does not explicitly state when-not-to-use or name an alternative, but its scope is specific enough to route an agent away from track/campaign/ad-analytics getters.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds no further behavioral context such as auth requirements, rate limits, or side effects, but it is consistent with the read-only nature.

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

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

A single front-loaded sentence states the main action and the key contents of the result with no filler. The minor repetition of 'feedback' does not meaningfully reduce 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?

For a simple read-only lookup with one documented required parameter and an output schema, the description provides enough information for correct invocation. No critical usage details are missing.

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

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

The single parameter playlistId is fully documented in the schema as 'The playlist ID', so the description does not need to compensate. It adds no format or source guidance, but the schema is sufficient at 100% 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 action ('Get') and the resource ('full playlist details'), and enumerates the included content: tracks, feedback, and stats. This differentiates it from list_playlists and get_track_details without ambiguity.

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 this tool is for retrieving comprehensive details about a single playlist, but it does not explicitly explain when to choose it over sibling tools like list_playlists or get_track_details. The context is inferable rather than stated as guidance.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by explaining that the tool attests environment identity and that callers must verify the database-target match before proceeding. It goes beyond the annotations without contradicting them.

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

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

The description is four sentences with no filler. It front-loads what the tool attests, then delivers essential pre-write guidance, verification criteria, and a warning. Every sentence contributes distinct value, making it efficient and well-structured.

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

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

Given zero parameters, a rich output schema, and annotations covering the read-only safety profile, the description is complete for an agent. It explains why, when, and how to use the tool, including the guardrails needed for safe writes. Nothing essential is missing.

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

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

The tool has zero parameters, so there is nothing for the description to explain about inputs. Per the rubric, 0 params earns a baseline of 4, and the description appropriately focuses on the tool's purpose and usage rather than inventing parameter details.

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 ('Attest') and names the exact resources: stage, base URL, non-secret database fingerprint, database-target match, Lambda identity, region, and authorization role. This clearly distinguishes it from the many sibling getters by describing a unique environment-verification 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?

The description explicitly states when to call this tool: 'Call this before any write.' It also gives concrete follow-up actions, such as requiring databaseTargetMatchesExpected=true, comparing against the canonical environment table, and passing the exact stage and fingerprint to guarded write tools. This is strong, actionable 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?

Annotations already cover readOnlyHint=true and destructiveHint=false. The description adds behavioral context by clarifying that the tool reads existing output and does not queue or apply AI track tags, which helps prevent misuse without repeating annotation 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?

Two tightly worded sentences: the first states the core action and optional features, the second clarifies a key non-behavior. Every sentence contributes meaningful information with no filler.

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

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

Given the rich annotations, 100% schema coverage, and existing output schema, the description fully supports correct tool selection. It also preempts the most likely confusion with analysis/tagging tools, so nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema fully documents all seven parameters. The description adds only high-level context about 'post-upload workflow status and personalized submission opportunities', which loosely maps to statusOnly and includeOpportunities but does not add parameter-level detail.

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 ('Read') with a clear resource ('existing structured analyzer output') and scope ('for a track or track version'). It also distinguishes the tool from analysis-creation siblings by explicitly stating it does not queue or apply AI track tags.

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 clearly implies this is for reading existing analyzer results, not for triggering analysis or tagging. The explicit statement 'This does not queue or apply AI track tags' provides a useful exclusion, though it does not name alternative sibling tools directly.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds minor behavioral context by enumerating the three metric types and the optional version scoping, but it does not disclose aggregation granularity (e.g., totals vs. daily breakdowns) or timezone/date handling. Acceptable but not rich.

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 with zero wasted words. The core behavior (verb, resource, metrics, date range) is front-loaded in the first sentence, and the optional scoping is cleanly appended in the second.

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 full schema coverage, safety annotations, and an output schema present, the description is nearly complete. The only real gap is the absence of disambiguation from droptrack_get_track_downloads, which could otherwise cause an agent to pick the wrong tool for a downloads-specific request.

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 schema fully documents all four parameters, including the optional versionId filter. The description's mention of 'optionally scope results to a specific track version' reinforces versionId but adds no meaning beyond the schema. 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 states a specific verb ('Get'), resource ('track analytics'), and the metrics covered (plays, downloads, views) over a date range. It is clear and unambiguous, though it does not explicitly differentiate itself from the similarly named sibling droptrack_get_track_downloads, relying instead on the metric enumeration to signal its aggregating nature.

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 case is implied: call this when you need track analytics metrics aggregated over a date range, optionally filtered by version. However, there is no explicit when-to-use guidance, no when-not-to-use exclusions, and no mention of alternatives such as droptrack_get_track_downloads, which is a meaningful omission given the sibling set.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a bit of response-content context (versions, genre, key, audio URLs) but no additional behavioral traits beyond what annotations and the output schema already provide.

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

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

One focused sentence, front-loaded with the action and resource, and no filler. The list of returned fields earns its place by clarifying scope.

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 read-only detail lookup with a complete input schema and an output schema present, the description covers everything an agent needs 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?

Schema coverage is 100% and the single parameter has a clear description ('The track ID to get details for'). The tool description adds no further parameter meaning, so the 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 starts with a specific verb and resource: 'Get full details for a specific track', then lists distinguishing content (all versions, genre, key, audio URLs). This differentiates it from sibling track tools like get_track_analytics, get_track_downloads, and get_track_tags.

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?

Clear context is provided: use when you need comprehensive details for one track. It does not explicitly name alternatives or exclusion conditions, but the content list (versions, genre, key, audio URLs) helps the agent choose it over focused sibling tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful output scope ('who downloaded, format, version, and when') but does not disclose any additional behavioral traits such as pagination behavior, ordering, or filtering semantics.

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

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

A single well-structured sentence that front-loads the core action and resource, then gives the relevant detail fields in a compact list. There is no redundancy or wasted wording.

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 a fully documented input schema, an output schema, and annotations indicating a safe read operation, the description provides sufficient context for an agent to understand what this tool does and when it is relevant. No critical operational details are missing.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description does not add meaning beyond the schema, and under the rule that high coverage gives a baseline of 3, this 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 names the specific verb ('Get'), resource ('download history for a track'), and the kind of information returned ('who downloaded, format, version, and when'). This clearly differentiates it from sibling track tools like get_track_details, get_track_analytics, and get_track_tags.

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 intended use is implied: use this when you need a track's download history. However, the description does not explicitly state when not to use it or point to a sibling alternative, leaving the choice to the agent's inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered without help from the description. The description adds that results are 'structured' and 'personalized,' but that describes output shape rather than behavior. No side effects, rate limits, pagination details, or other behavioral traits are disclosed, though an output schema exists to cover return structure.

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

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

A single, front-loaded sentence that names the action, resource, scope, and result categories without any filler. Every word earns its place, and the core purpose is 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 read-only query tool with a full output schema and 100% parameter schema coverage, the description nails the core purpose and scope. The only notable gap is the absence of an explicit pointer to the sibling browse tool for when the user does not have a specific track in mind, but that is an enhancement rather than a critical omission.

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 all eight parameters already have descriptive text. The tool description adds no parameter-specific meaning beyond naming the result categories that map to accountTypes; that's marginal on top of the schema. The baseline of 3 applies when the schema does the heavy lifting.

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 ('Return') and a clear resource: structured promotion/submission opportunities personalized for one track, and it enumerates the categories (record labels, DJs, bloggers, playlist curators). It clearly conveys what the tool does, but it does not explicitly contrast itself with the sibling 'browse_submission_opportunities' tool, so it doesn't fully differentiate on its own.

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

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

The phrase 'personalized for one track' implies the intended use case—use this when you have a specific trackId and want matched opportunities—but the description gives no explicit when-to-use vs. alternatives guidance, no exclusions, and no mention of the browse tool for non-track-specific discovery. The usage context is only 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns with those by saying 'Read stored...' It adds useful behavioral context about the data source (tag_audio workflow) and clarifies that it is not returning track analyzer results. No contradiction or hidden destructive behavior is indicated.

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 short sentences with no filler. The primary purpose is stated first, and the key distinction from track analyzer output is provided immediately after.

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 one required parameter, a readOnly annotation, no destructive behavior, and an output schema. The description identifies the data source and the key sibling distinction, which is sufficient for an agent to select and correctly invoke this 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?

Schema description coverage is 100%, and the single parameter trackId is already described as 'Track ID to inspect.' The description adds no extra parameter-level meaning, but because the schema fully documents the parameter, the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Read') and a specific resource ('stored AI track-tagging output from the dedicated tag_audio workflow'). It also distinguishes this tool from track analyzer output, which directly addresses the closest sibling category.

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 clearly implies this tool is for reading stored AI tagging results rather than running or inspecting analyses. It explicitly separates this from track analyzer output, giving an agent a useful exclusion criterion, though it does not name the sibling tool or state exact when-to-use conditions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful context about the specific types of email notification settings included, but does not disclose behavior such as authentication requirements, response shape, or any side effects. This is acceptable given the annotations and output 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?

The description is a single sentence that front-loads the core action and resource, then adds concrete detail about setting categories. Every part of the sentence earns its place, and there is no fluff or redundant restating of the tool name.

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 that the tool has no parameters, the annotations declare it read-only and non-destructive, and an output schema exists, the description is sufficiently complete for an agent to select and invoke the tool correctly. No critical context is missing.

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

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

The tool has zero parameters and schema description coverage is 100%, so there is no parameter ambiguity to resolve. The description does not need to explain parameter semantics because none exist. Baseline 4 is appropriate for a zero-parameter tool.

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 and resource: 'Get the authenticated user email notification settings', clearly distinguishing this as a read operation for the current user's notification preferences. It also enumerates the specific setting categories (weekly/monthly reports, engagement emails, campaign nudge email updates), which removes ambiguity about what the tool returns.

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 states what the tool retrieves but provides no guidance on when to use it versus alternatives such as droptrack_get_campaign_nudge_summary or droptrack_list_campaign_nudge_contacts. There is no mention of exclusions, prerequisites, or conditions that would route an agent to this tool over sibling getters.

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

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

Annotations (readOnlyHint=true, destructiveHint=false) already establish this as a safe, closed-world read operation, lowering the burden on the description. The description adds moderate value by stating the scope ('current company') and the data facets returned (budget, delivery, landing page, creative counts), but it does not go deeper into return-shape quirks or filter interplay. This is consistent with the read-only annotations; no contradiction.

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

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

A single sentence that fronts the action ('List') before the resource, scope, and return data, with zero filler or repetition of schema details. Every clause earns its place, making it appropriately sized and well-structured.

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

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

For a simple paginated list tool with four optional, fully documented parameters, an output schema, and read-only safety annotations, the description covers the essential invocation context. The only material gap is defining the 'Grow/ads' category and explicitly distinguishing it from droptrack_list_campaigns and droptrack_list_label_ad_campaigns, which is a differentiation gap rather than a structural one.

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%: all four parameters (limit, cursor, status, promotionType) carry their own descriptions, defaults, and bounds. The description contributes no additional parameter semantics—it summarizes return fields rather than input meaning—so the baseline 3 applies.

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

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

The description pairs a specific verb ('List') with a well-defined resource ('Grow/ads campaigns for the current company') and previews key returned fields (budget, delivery, landing page, creative counts). The 'current company' scope and ads focus help differentiate it from siblings like droptrack_list_campaigns and droptrack_list_label_ad_campaigns, though those alternatives are never named. The unexplained 'Grow/ads' terminology keeps this from a 5.

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

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

The 'current company' scoping provides an implicit usage signal: this is the company-level ads campaign list, as opposed to label-level (droptrack_list_label_ad_campaigns) or general campaigns (droptrack_list_campaigns). However, there is no explicit when-to-use statement, no exclusion, and no named alternative, so the agent must infer context from scope words alone.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, which covers the safety profile. The description adds only the 'recent' temporal scope and the allowed job categories, which is modest context but not a contradiction or significant disclosure.

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

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

A single, front-loaded sentence that immediately conveys action and object. No filler, redundancy, or 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?

Given full schema coverage, a read-only annotation, and an output schema, this description is mostly sufficient. It could have noted pagination or type-specific filter constraints, but those are already present in the schema, so nothing essential is missing.

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

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

Schema coverage is 100%, and every parameter already has a description and enums where relevant. The description's mention of press releases, artist bios, and album art mirrors the jobType enum but does not add 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?

Description states a specific verb ('List'), resource ('AI jobs'), and scope ('for press releases, artist bios, or album art') that maps cleanly to jobType. It is clearly the plural/list counterpart to droptrack_get_ai_job, though it does not explicitly name or differentiate from that sibling.

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

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

The intended use is implied: list recent AI jobs. However, there is no explicit guidance about when to prefer this over droptrack_get_ai_job or other list tools, and no mention of alternatives or exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the 'company' scoping context and the asset-type taxonomy, which is moderately useful, but it does not disclose behavioral details such as default assetType=image filtering or pagination behavior beyond what the schema already states.

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

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

A single front-loaded sentence that states the verb, resource, and scope with zero filler words. Every element contributes meaning, and the parenthetical efficiently disambiguates the asset categories.

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 rich structured context — 100% parameter coverage, an output schema, and read-only annotations — the description covers the essential purpose adequately. The main gap is the absence of sibling-routing context, but the conditional parameter relationships are already documented in the schema, so nothing critical for invoking the tool correctly is missing.

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

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

Schema description coverage is 100%, so the baseline of 3 applies. The description's phrase 'uploaded/AI images or documents' loosely maps to the assetType and sourceType enums, but it adds no parameter-level detail beyond what the schema already documents for each of the 7 parameters.

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

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

The description names a specific verb ('List') and resource ('company assets'), then clarifies scope with 'uploaded/AI images or documents,' which distinguishes it from sibling list tools like droptrack_list_tracks and droptrack_list_playlists by resource category. It is clear and actionable, though it does not explicitly name a sibling it is not, so it stops short of the top score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention the many related siblings (e.g., droptrack_generate_album_art, droptrack_accept_album_art_candidate, droptrack_get_ai_job) or note when a different tool would be more appropriate, leaving all routing decisions to the agent.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds context about the fields returned, but it does not disclose any behavioral traits such as whether only nudge-enabled recipients are listed, how pagination behaves beyond schema defaults, or any access/authorization prerequisites.

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 with no filler. The core listing action and the returned data categories are front-loaded, and every clause earns its place by clarifying what the tool does.

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 rich annotations, 100% schema parameter coverage, and the existence of an output schema, the description is largely sufficient for an agent to invoke the tool correctly. A minor gap is that it does not clarify whether the tool returns every campaign recipient or only those with active nudge signals, though the wording leans toward listing recipients with their associated state.

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 all four parameters are already documented clearly with types, defaults, and constraints. The description does not add further semantic meaning to campaignId, limit, cursor, or search beyond what the schema provides, so the 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 uses a specific verb ('List') and resource ('recipients in a campaign') and enumerates the exact data elements included: CRM nudge signal state, sent nudges, next scheduled nudge, and reply suppression status. This clearly distinguishes it from sibling tools like get_campaign_nudge_summary or get_contact_nudge_context.

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 the use case: retrieving per-recipient nudge details for a campaign. However, it does not explicitly state when to prefer this tool over alternatives like droptrack_get_campaign_nudge_summary or droptrack_get_contact_nudge_context, and it offers no exclusion criteria or 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows the operation is safe. The description adds boundary context ('current company') and specifies the returned fields, which is useful, but it does not disclose pagination behavior or return-format details 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?

The description is a single sentence that front-loads the action and resource, then specifies the scope and the main data fields. There is no wasted wording or repetition of schema 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 simple read-only list tool with full schema coverage, an output schema, and safety annotations, the description adequately covers purpose, scope, and content. Nothing essential for invoking the tool correctly is missing.

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

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

Schema description coverage is 100% — both 'limit' and 'cursor' have their own descriptions, defaults, and constraints. The description adds no additional parameter meaning, so a baseline of 3 is appropriate.

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

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

The description uses a specific verb ('List') and resource ('campaigns'), and adds scope ('current company') and concrete content fields (status, opens, plays, downloads, feedback count). This clearly differentiates it from siblings like list_ad_campaigns and get_campaign_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?

The description implies when to use the tool—when a high-level list of campaigns in the current company is needed—but does not explicitly state when not to use it or name alternatives such as get_campaign_details or get_campaign_analytics. The usage context is clear but not exclusionary.

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

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

Annotations already declare the tool read-only and non-destructive. The description adds useful behavioral context: the user may belong to multiple companies, and any company switching must happen through the authenticated client/session rather than through a model-visible tool. No contradiction with annotations.

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, each earning its place. The main purpose is front-loaded in the first sentence, and the second sentence provides an important usage constraint without any 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 zero-parameter, read-only listing tool with an output schema, the description is complete. It explains what is listed, who it applies to, and the key switching constraint, so an agent can invoke it correctly without further clarification.

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 there is nothing to document beyond the schema. The description adds meaningful context about the scope of the result—companies the authenticated user belongs to—which is enough for a parameterless tool.

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 lists all companies the authenticated user belongs to, using a specific verb and resource. It is clear and distinct from siblings like list_tracks or list_campaigns, but it does not explicitly name or differentiate against a similar sibling.

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

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

It provides clear context by noting this is useful for users with multiple label/company accounts. It also explicitly warns that company switching cannot be done through a model-visible tool, giving the agent a when-not-to-use boundary, though it names no alternative tool.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds context that results include contact counts and are scoped to the current company. However, it does not disclose pagination behavior or that 'all' lists may require multiple calls despite the limit and cursor parameters.

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 that is concise, front-loaded, and contains no filler. Every part of the sentence contributes meaning: the action, the resource, the scope, and the returned count 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?

Given the simple listing nature of the tool, the presence of an output schema, and annotations covering safety, the description is mostly complete. The only minor gap is the relationship between 'all contact lists' and the pagination parameters, which could leave an agent unsure whether one call returns everything.

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 limit and cursor parameters are already fully documented in the schema. The description adds no additional parameter-level meaning, which is acceptable given the high schema 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 a specific action ('List'), a resource ('all contact lists for the current company'), and an additional useful detail ('with the number of contacts in each list'). This distinguishes it from sibling tools like create_contact_list, search_contacts, and get_contact_details without ambiguity.

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 tool is for retrieving all contact lists scoped to the current company, with per-list contact counts. It does not explicitly name alternatives or exclusion criteria, but the scoping language makes the intended use clear relative to the sibling tools.

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

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

Annotations already declare this as a read-only, non-destructive operation, so the description is not required to restate safety. It adds the meaningful constraint that label-admin access is required, but otherwise does not elaborate on pagination behavior or result shape beyond what the schema and output schema already convey. No contradiction with annotations.

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, well-structured sentence that leads with the operation and resource, states the scope options, and ends with the access requirement. Every phrase earns its place, and there is no redundant restatement of the tool name or schema.

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 operation, the description plus the fully described input schema and output schema cover the essential information an agent needs: purpose, scope options, access level, and expected output structure. The only minor gap is that 'label family' and 'Grow/ads' are not explicitly defined, but this is unlikely to block correct invocation given the sibling context and title.

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 schema fully documents all six parameters including formats, defaults, and meaning. The description adds high-level context about artist and date scoping, but no parameter-level detail beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description names a specific action ('List'), a specific resource ('Grow/ads campaigns'), and a clear scope ('across a label family, optionally scoped to artists or date range'). This distinguishes it from sibling tools such as droptrack_list_ad_campaigns, which appears to be a broader/non-label listing, and droptrack_get_ad_campaign_details, which retrieves a single campaign.

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 clear prerequisite ('Requires label-admin access') and implies the tool is for label-family campaign listing. However, it does not explicitly state when to prefer this over droptrack_list_ad_campaigns or other campaign-related siblings, nor does it describe exclusions such as non-label contexts.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by noting the admin-access requirement and that the operation is scoped to the active label, which goes beyond the structured annotations.

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 short sentences, with the primary action front-loaded and the access requirement as a direct follow-up. Every word earns its place and there is no redundant phrasing 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 low-complexity read-only list operation with one optional parameter, an output schema, and strong annotations, the description is complete. It states what is listed, the scope, and the required permission; nothing essential is missing.

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

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

Schema description coverage is 100%, and the single optional parameter labelCompanyId already has its own meaning ('Admin-only override: label company ID'). The tool description does not need to repeat parameter details; the schema carries the semantic load, 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 clearly states a specific verb ('List'), a concrete resource ('artist sub-accounts'), and a scope ('under the active label'). This distinguishes it from sibling tools like list_label_contacts or list_label_team without needing to open their schemas.

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

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

It provides clear context by scoping to the active label and explicitly states the required access level ('Requires label-admin access'). It does not name alternatives or state when not to use it, but the context is sufficient for this simple list operation.

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that returned contacts include label versus artist ownership annotations, which is useful context, but it does not disclose pagination, authorization nuances, or other behavioral details beyond what the schema and annotations provide.

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

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

The description is a single sentence that front-loads the action and resource, then adds the distinguishing output characteristic. There is no repetition of the title or schema details and no filler.

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

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

For a read-only list tool with a fully described input schema, an output schema, and safety annotations, the description is nearly complete. The main gap is the absence of guidance on how this relates to sibling contact tools, but the structured metadata covers behavior and parameters adequately.

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 covers all four parameters with descriptions at 100% coverage, so the baseline is 3. The tool description does not add substantial parameter-level meaning; it only hints at ownership scoping through the phrase 'label versus artist ownership annotations.'

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 a specific action ('List contacts') and scope ('across the label family'), plus a distinguishing output trait: label versus artist ownership annotations. It does not explicitly name a sibling tool to differentiate from, but the phrasing is specific enough to separate it from search_contacts or list_contact_lists.

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 a clear context for use: when you need contacts across the label family with ownership annotations. It does not explicitly state when to prefer a sibling like search_contacts or when not to use this tool, but the intended usage is evident.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is fully consistent with them. The description adds one meaningful piece of behavioral context beyond the annotations: the label-admin permission requirement, which matters for an agent deciding whether it is allowed to invoke the tool. No contradiction.

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 with zero filler. The action and scope are front-loaded in the first sentence, and the access prerequisite is placed in the second. 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 read-only tool with one optional parameter and an existing output schema, the description is effectively complete: purpose, scope, and access requirement are all stated, and return values are covered by the output schema. A minor gap is that it doesn't hint at whether team members are returned with roles or permissions, but that is downstream of the output schema.

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%: the single optional parameter labelCompanyId already carries the description 'Admin-only override: label company ID.' The tool description adds no parameter-level meaning beyond what the schema provides, so the high-coverage 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 ('List') with a well-defined resource: 'users with access to the label parent and artist sub-accounts.' The scope phrasing implicitly differentiates it from siblings like droptrack_list_label_artists (artists, not access-granted users) and droptrack_list_label_contacts (contacts, not team access). It stops short of 5 because the sibling differentiation is implicit rather than explicit.

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

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

The only usage guidance is the prerequisite 'Requires label-admin access,' which usefully tells the agent who is authorized to call it. However, there is no when-to-use vs. alternative guidance — nothing distinguishes this from droptrack_list_label_artists, droptrack_list_label_contacts, or droptrack_list_campaigns, which an agent could plausibly confuse with it.

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

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

Annotations already disclose that the operation is read-only and non-destructive, so the description does not need to repeat that. It adds useful scope context ('current company') and output content ('track counts'), but it does not disclose pagination behavior or any additional call-specific side effects; the schema covers pagination rather than the description.

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

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

The description is a single, front-loaded sentence that states the action, scope, and key output field without filler. 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 read-only list tool with a complete input schema, an output schema, and safety annotations, the description is sufficient. It identifies the resource scope ('current company') and the distinguishing output ('track counts'), so an agent can choose and 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?

Parameter schema coverage is 100%, with clear descriptions for both 'limit' and 'cursor'. The description adds no parameter-level semantics beyond the schema, which matches the baseline of 3 for high schema 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 uses the specific verb 'List' with a clear resource ('playlists in the current company') and adds the distinguishing detail 'with track counts.' This clearly separates it from related siblings such as droptrack_get_playlist_details, which would be used for a single playlist's detail view.

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

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

The phrase 'List all playlists' implies this tool is the right choice for a collection-level playlist query, but it does not explicitly state when to prefer it over droptrack_get_playlist_details or how the 'current company' context is established. There is no when/when-not or alternative guidance, leaving usage inferred rather than explicit.

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

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

Annotations already mark the tool as read-only and non-destructive. The description adds meaningful behavioral detail beyond those annotations: results are paginated, and if the library is empty the tool supplies guidance for requesting audio files or Spotify/SoundCloud links. This gives the agent useful expectations about non-standard empty-library 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?

Two sentences, no filler. The primary action is front-loaded, the returned metrics are named, and the pagination plus empty-library behavior are conveyed economically. Every sentence contributes useful 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 simple read-only list tool with a 100%-documented schema and an output schema, the description is complete. It covers the scope, the data returned, pagination behavior, and the notable empty-library edge case. No critical context appears missing.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters (limit and cursor). The description's mention of 'paginated results' reinforces the limit/cursor semantics but does not add new parameter-level meaning beyond what the schema already states.

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

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

The description identifies a specific verb ('List'), a specific resource ('tracks'), and the scope ('in the current company'), plus the distinguishing data points (play, download, and view counts). This makes it clearly distinguishable from siblings like get_track_details or get_track_analytics by framing the operation as a list-level read.

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 clear usage context: it is for listing tracks at the company level, with counts and pagination. It does not explicitly name alternatives or exclusion criteria, but the listing scope and count-based output make it easy for an agent to choose this over detail- or analytics-focused siblings.

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

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

The description discloses that this is an async queue operation rather than a synchronous result-returning call, and tells the agent to poll for results. Annotations already signal mutation (readOnlyHint false) and destructiveness (destructiveHint true), so the description adds useful behavior without contradicting them.

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

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

Two short, front-loaded sentences. The first states the action and scope; the second gives the essential follow-up step. There is no filler 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 two-parameter async queue tool with a complete input schema, output schema, and annotations, the description is sufficient. It explains the action, the single-track scope, and the polling path. A minor gap is not explaining what tag_audio workflow means in practical terms, but the schema and output schema cover the operational essentials.

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%: both trackId and force have clear descriptions. The description adds no extra parameter detail, but that is fine because the schema already fully documents the parameters.

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

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

The description uses a specific verb ('Queue') and a clear resource ('the dedicated tag_audio workflow for one track'), making it easy to distinguish this from read-style siblings like droptrack_get_track_tags. It also explicitly names the follow-up polling tool, reinforcing what this operation is for.

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 clear context: queue the workflow first, then poll with droptrack_get_track_tags. It does not explicitly state when not to use it or compare it to droptrack_auto_tag_tracks, but the single-track scope and async guidance are enough for an agent to select it appropriately.

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