Dynamoi

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

Annotations indicate destructiveHint=true and idempotentHint=true. The description adds that links are free, may go on verification hold, and that existing links are returned or updated. It also instructs on response format, providing behavioral context beyond 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 well-structured and front-loaded with the primary use case. However, it is somewhat lengthy and could be more concise without losing essential details.

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

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

The description covers the main purpose, sibling distinction, verification, idempotency, and response instructions. It lacks explanation for some parameters, but the output schema helps fill gaps. Overall, fairly complete for the tool's complexity.

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

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

Schema coverage is 0%. The description explains spotifyUrl implicitly and mentions customDescription, but does not describe format, clientRequestId, or userIntentSummary. This is insufficient for a tool with 6 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 clearly states it creates a free Dynamoi Smart Link from a Spotify album, track, or artist URL. It specifies the resource (Smart Link) and action (create), and distinguishes from the sibling tool for full-catalog imports.

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 says when to use this tool (single Spotify link or starter release) and when to prefer the sibling (full-catalog). It also mentions unsupported playlist URLs, verification holds, and duplication behavior, providing clear 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?

Adds valuable context beyond annotations: background catalog import, free Smart Links, verification hold, and that it does not create paid campaigns. 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?

Single concise paragraph with front-loaded primary use. No wasted sentences, but could be more structured (e.g., bullet points for parameter guidance).

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

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

Covers main behavioral aspects and distinguishes from siblings, but lacks parameter descriptions for most inputs. Output schema exists, so return values are handled. Overall adequate but with 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?

Only partially explains two of five parameters (spotifyArtistUrl and artistId). No description for format, clientRequestId, or userIntentSummary despite 0% schema coverage. Lacks necessary detail for correct usage.

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

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

The description clearly states the trigger (user gives Spotify artist URL) and the outcome (create/import/refresh Smart Links for the artist catalog and return artist hub). It distinguishes from sibling tools like dynamoi_create_smart_link_from_spotify.

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 explicit conditions for omitting artistId and mentions verification hold for certain cases. It does not explicitly state when not to use or name alternative tools, but the context is clear.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read operation. The description adds valuable behavioral context: the account-level state can span multiple artists, and intent must match the explicit question. This goes beyond annotations to clarify scope and usage constraints.

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

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

The description is a single paragraph that is well-structured, starting with when to use, then examples, then negative guidance with alternatives. It is slightly verbose but every sentence adds value. Could be trimmed slightly, but overall effective and 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?

The description covers the tool's purpose, usage boundaries, and behavioral scope. With an output schema present, return values are documented elsewhere. However, it does not explain the 'format' parameter, which is a minor gap. Overall, it is complete enough for an agent to select and invoke correctly given the context of sibling tools and annotations.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions the 'intent' parameter but does not explain its enum values or the 'format' parameter. The description adds that intent should match the explicit account question, which is helpful but incomplete. The enum values for intent are not described, and format is ignored.

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 is for when the user explicitly asks about the signed-in Dynamoi account, with examples like who is logged in, organizations, artists, or platform connections. It distinguishes from siblings by naming dynamoi_get_platform_status and dynamoi_list_artists for related but different purposes.

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

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

The description explicitly states when to use (explicit account questions) and when not to use (not for specific Meta/YouTube onboarding, not for enumerating artists, not for generic context checking). It provides direct alternatives: dynamoi_get_platform_status for artist-specific platform status, dynamoi_list_artists for listing artists.

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 behavioral context: return of artist-level performance across all campaigns, inclusion of 30-day rollups or daily breakdowns, and granularity/format options. No contradictions. Could mention output schema, but not required.

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, front-loading purpose, then giving parameter guidance, then usage boundary. Every sentence provides distinct value with no redundancy or waste.

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

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

Given the tool's complexity (4 params, nested objects), the description covers purpose, usage, parameter semantics, sibling differentiation, and post-call behavior. Output schema exists, so return value details are not needed. The description is complete for the agent to select and invoke correctly.

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

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

Schema description coverage is 0%, so the description must add meaning. It explains two key parameters: granularity=DAILY for daily breakdown and format=summary for written rollup. It leaves dateRange and artistId to schema, which provides format/pattern. This is adequate for the tool's usage scenarios.

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

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

The description clearly states the tool's purpose: 'artist-level performance across all campaigns'. It specifies the resource (artist-level performance) and verb (get analytics). It distinguishes from the sibling tool dynamoi_get_campaign by stating when not to use this tool (for one campaign's metrics).

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 explicit guidance: when to use (user wants artist-level performance), what parameters to pass for specific scenarios (granularity=DAILY for daily breakdown, format=summary for written rollup), and what to do after (stop and answer if tool returned requested comparison). It also tells when not to use (for one campaign's metrics, use dynamoi_get_campaign).

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. Description reinforces read-only nature and clarifies it does not create checkout links. However, could detail more about response content or side effects beyond what 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?

Description is compact, well-structured, and front-loaded with use cases. Every sentence adds value without redundancy.

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

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

Covers when to use and behavioral safety, but lacks parameter documentation. Output schema exists, so return values are partially covered. Overall, adequate but missing key param 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 has 0% description coverage, and description does not explain the `format` or `onboardingAttemptId` parameters. It only implies `artistId` is for one artist. This leaves significant ambiguity for agent usage.

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

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

Description clearly states the tool retrieves billing state, credit balance, promo limits, subscription status, and whether billing blocks launches for an artist. It explicitly distinguishes from campaign analytics and platform troubleshooting, making its purpose unambiguous.

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

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

Provides explicit when-to-use scenarios (billing queries) and when-not-to-use (campaign analytics, platform connection troubleshooting). Even includes a workflow: if billing blocks launch, direct user to dashboard then retest.

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. Description adds context about recommended usage after launch and parameter behavior, but does not disclose potential performance or rate limits. Adds value beyond 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?

Four sentences, no fluff. Front-loaded with purpose and key constraints. 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?

Covers main use cases and common scenarios (after launch, summary). With output schema present, return values are covered. Missing explicit guidance on analyticsDateRange and analyticsGranularity, but overall sufficient for agent decision-making.

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

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

With schema description coverage at 0%, description compensates by explaining includeAnalytics (performance), includeDeploymentStatus (delivery blockers), includeCountries (full list only when needed), and format=summary. However, it does not detail the nested analyticsDateRange or analyticsGranularity 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?

Description clearly states verb 'Get' and resource 'campaign', lists specific details (budget, targeting, platform status, next actions), and explicitly distinguishes from sibling dynamoi_list_campaigns for 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?

Explicitly tells when to use ('when the user wants full details for one campaign'), when not to use ('Do not use for a campaign list'), and provides specific parameter guidance (includeAnalytics, includeDeploymentStatus, includeCountries) and a recommendation for after-launch scenarios ('prefer format=summary').

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, but the description adds that it 'validates readiness and targeting without creating a campaign', reinforcing the non-destructive, read-only behavior beyond what 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?

Two sentences, front-loaded with the key use case and exclusions. No fluff or redundant 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 the existence of an output schema, the description adequately covers the tool's purpose and behavior. However, the 0% param coverage means the agent may need more guidance on common inputs, but the description remains sufficient for a readiness-check 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 0% with 11 parameters. The description does not explain any parameter's meaning or usage, leaving the agent to rely solely on the schema, which lacks descriptions. The description fails to compensate for the lack of parameter documentation.

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 validates campaign readiness and targeting before launch, distinguishing it from dynamoi_launch_campaign. The verb 'get' implies read-only, and the purpose is specific: checking if proposed inputs are ready.

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

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

Explicitly tells when to use (when planning a campaign to know readiness) and when not to use (do not create or mutate campaigns). Also names the sibling tool dynamoi_launch_campaign as the alternative for launching.

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; description adds behavioral context about polling and correlation. No contradictions, but does not detail rate limits or error 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?

Three sentences, front-loaded with purpose, no redundancy. 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 output schema exists, return values are covered. Tool is simple; description adequately conveys core usage and polling scenario, but could clarify format parameter.

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

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

Schema description coverage is 0%. Description only addresses onboardingFlow and onboardingAttemptId for polling, ignoring required artistId and format parameter. Insufficient added meaning for half 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 states a specific verb ('know') and resource (connection status of Spotify, Meta, YouTube) and setup steps, distinguishing itself from billing and personalization tools. The purpose is clear and actionable.

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

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

Explicitly provides when to use (polling after connection-start flow) and when not to use (billing, personalization). Includes guidance to pass onboardingAttemptId and onboardingFlow for correlation.

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 indicate readOnlyHint=true and destructiveHint=false, confirming safe read-only operation. The description adds behavioral context: it returns specific fields, explains optional analytics and artist settings, and instructs the agent to lead with the public URL and avoid exposing internal IDs. 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?

The description is three sentences, each with clear purpose: purpose and return fields, optional flags, and presentation instruction. No wasted words, 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?

Although an output schema exists, the description does not specify how to identify the target smart link (e.g., via playLinkId or spotifyUrl). With 9 optional parameters and no required ones, the agent lacks guidance on which parameters to use. Missing parameter explanations reduce completeness.

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

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

Schema description coverage is 0%, so the description must explain all parameters. It only covers includeAnalytics and includeArtistSettings. Other parameters like format, artistId, dateRange, playLinkId, spotifyUrl, granularity, and includeBreakdowns are not explained, leaving gaps for the agent.

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

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

The description clearly states the tool retrieves full details for one free Smart Link, including specific fields like release, Spotify URL, public URL, status, theme source, and next actions. This differentiates it from sibling tools like dynamoi_list_smart_links (listing multiple) and creation 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 explicitly says 'Use this when the user wants full details for one free Smart Link', providing clear context. It mentions optional analytics and artist settings flags but does not explicitly state when not to use it or compare with alternatives like the list 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 provide readOnlyHint false, destructiveHint true, etc. The description adds behavioral context: 'Ads are not necessarily live until the returned delivery state is ACTIVE' and clarifies the tool creates either real or simulated campaigns. 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 paragraph of about 6 sentences, covering purpose, usage, and parameter notes efficiently without redundancy. Could be slightly more structured, but still concise.

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

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

Given the tool's complexity (17 params, nested objects) and the existence of an output schema, the description covers the main workflow, when to use/not use, and key parameter handling. However, it lacks details on error states or prerequisites, which is acceptable with openWorldHint true.

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

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

With 0% schema description coverage, the description only explains spotifyUrl and endDate semantics for review/demo launches. The other 15 parameters, including complex nested objects like budgetSplits and locationTargets, are not described, leaving the agent without meaning beyond schema types.

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

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

The description clearly states it creates a Smart Campaign or YouTube Campaign and starts the launch workflow, distinguishing it from preview/recommendation tools by explicitly saying 'Do not use this for recommendations or previews'.

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

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

Provides explicit when-to-use condition ('when the user explicitly wants to create...'), when-not-to-use ('not for recommendations or previews'), and specific guidance for review/demo launches (omit spotifyUrl/endDate). Also advises against chaining tools after a successful launch.

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 description adds limited value. Does add a behavioral note about empty results routing to dynamoi_get_account_overview.recommendedNextActions, which is helpful but not substantial beyond 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?

Description is front-loaded with primary use case. Each sentence adds value, though it is somewhat lengthy due to behavioral instructions. No superfluous 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?

Tool has 4 params with no schema descriptions, and an output schema exists. Description addresses core purpose, parameter usage for artistId, and empty result handling. Although not all parameters are explained, the guidance is sufficient for an agent to decide when to use 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 0%. Description only explains artistId parameter ('Pass artistId when you need the full profile/readiness details for one artist'). Other params (limit, cursor, format) are not explained, but they are common pagination/style parameters. Minimal added value for 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?

Clearly states verb 'list' and resource 'artists or YouTube channels', specifies what info is returned (billing status, active campaign count, role). Differentiates from siblings by explicitly stating not to use for campaign details and naming alternatives.

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

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

Explicitly defines when to use (user wants to see artists/Youtube channels) and when not to use (campaign details, generic marketing advice). Provides concrete alternative tool names: dynamoi_list_campaigns, dynamoi_get_campaign.

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 read-only and non-destructive behavior. The description adds key behavioral context: the country list depends on campaignType, which is not implied by annotations alone. This helps the agent understand that results vary by parameter value.

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 sentences, front-loaded with critical usage guidance, and contains no extraneous information. 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?

While the description covers core usage and the output schema exists to document return values, it fails to explain optional parameters like pagination (cursor, limit) or output format (format). For a 5-parameter tool, this leaves the agent partially uninformed about full capabilities.

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

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

With 0% schema description coverage, the description should compensate but only mentions campaignType (the required parameter). It does not explain limit, query, cursor, or format, leaving the agent to infer their meaning from names and schema constraints. This is a significant gap.

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

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

The description clearly states the tool's purpose: listing countries for targeting in Smart Campaign or YouTube campaigns. It uses specific verbs ('list') and resources ('available countries'), and differentiates from generic country queries, leaving no 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 explicitly states when to use ('when the user asks which countries they can target') and when not to use ('Do not use this for generic country marketing advice'). It also provides a crucial usage requirement: 'Always pass campaignType because Smart Campaign and YouTube country catalogs are different.'

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. Description adds contextual restrictions (not for personalizing marketing advice, route via account overview if no artists), which are beyond 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?

Short paragraph with front-loaded purpose, each sentence adds value. No redundant words.

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

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

Tool has 6 parameters, 0% schema coverage, but output schema exists. Description covers main intent and usage rules, but does not explain pagination (cursor) or response format, leaving some 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?

Schema coverage is 0%, so description should compensate. It mentions filtering by type or status, hinting at campaignType and status parameters, but omits limit, cursor, and format. Minimal but sufficient for core usage.

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

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

The description clearly states the tool lists campaigns for one artist with optional filters, and distinguishes it from dynamoi_get_campaign for deep dives. Specific verb 'browse' and resource 'campaigns for one artist' are provided.

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

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

Explicit when to use (browse campaigns), when not to use (single campaign deep dive, personalizing generic marketing advice, no artists yet), and alternatives (dynamoi_get_campaign, dynamoi_get_account_overview) are given.

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 indicate read-only and non-destructive behavior. Description adds useful context about when to use format=json and includeUrls, enhancing transparency without contradicting 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?

Three sentences, front-loaded with core use case, no wasted words. 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?

Description covers purpose and key parameters (format, includeUrls) but misses pagination (cursor) and the required artistId. With an output schema present, return values are covered, but parameter details are 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?

Schema description coverage is 0%, so description must compensate. It explains format and includeUrls but not limit, cursor, or artistId. This leaves gaps for an AI agent to infer parameter usage.

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

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

The description clearly states the tool lists media assets for reuse in a campaign launch, differentiating it from sibling tools that handle analytics or status. It explicitly says when not to use it (campaign status or 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?

Provides explicit when-to-use and when-not-to-use guidance. Also gives instructions for format and includeUrls parameters. Lacks explicit naming of alternative sibling tools but context is clear.

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

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

Annotations already indicate readOnlyHint=true, destructiveHint=false. Description adds context: lists only free Smart Links, includes specific fields, and provides alternatives. 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, front-loaded with purpose and alternatives. No wasted words.

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

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

Covers core purpose and required parameter, but lacks guidance on optional filters. Output schema exists, so return values are partially covered by that.

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?

Description only implies artistId importance but does not explain other parameters (limit, cursor, format, claimStatus, renderState, publishState). Schema coverage is 0%, so description should compensate but fails to do so for optional filters.

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

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

Clearly states it lists free Smart Links for one artist and specifies included fields (release title, public URL, etc.). Differentiates from dynamoi_list_campaigns.

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

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

Explicitly says when to use (list free Smart Links) and when not to (paid campaigns, refer to dynamoi_list_campaigns). Offers fallback suggestions when empty and artist has connected Spotify.

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 and destructiveHint; the description reinforces and clarifies the read-only nature by detailing that it 'does not create, publish, update, or promote', adding value beyond 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 concise with two sentences, front-loaded with usage scenarios, and contains no superfluous information.

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

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

Despite missing parameter explanations, the description covers the main purpose, boundaries, and output schema exists; for a simple tool, it is mostly complete but lacks guidance on parameters.

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

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

With 0% schema description coverage, the description does not explain the purpose of the two parameters (artistName, releaseTitle), leaving the agent to guess their role in the preview.

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

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

The description clearly states the tool's purpose as a read-only visual preview of Smart Link themes, and explicitly distinguishes it from create/update/publish actions, which sets it apart from sibling 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 specifies when to use the tool (when user asks about looks, wants to compare/preview before creating/updating) and explicitly states what it does not do, but does not name alternative sibling tools for create/update actions.

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 provide readOnly and non-destructive hints. Description adds context about empty results and new user handling, but omits pagination or performance details.

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 plus a conditional clause. Front-loaded purpose, each sentence adds value without redundancy.

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

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

Covers purpose and usage well but lacks details on output format, pagination (cursor), and parameter roles. Adequate for a search tool with 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 has 0% description coverage. Description does not explain any of the 7 parameters, including enums like type or format.

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

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

Clearly states the tool searches for artist, release, campaign, or smart link when the exact record is unknown. Distinguishes from analytics/billing 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?

Explicitly says when to use (unknown record) and when not to use (known record for analytics/billing). Provides fallback advice for empty results.

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 annotations (readOnlyHint=false, etc.), the description discloses behavioral traits: returns billing_required or billing_check_unavailable on failure, may route through Page/Instagram selection, and requires subsequent polling. 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 front-loaded with the main purpose but includes detailed error conditions and post-use steps. It is well-structured but slightly verbose; could be more concise without losing critical information.

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

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

Given the complexity (OAuth flow, billing verification, polling), the description covers all major steps, error modes, and follow-up actions. Since an output schema exists, the lack of explicit return value description is acceptable.

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

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

Schema description coverage is 0%, and while artistId is implied as required, the description does not explain the meaning or usage of artistId, format (json/summary enum), or userIntentSummary. The focus on OAuth flow and error handling does not compensate for missing parameter guidance.

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

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

The description clearly states the tool's purpose: initiating a Meta OAuth connection for Spotify Smart Campaigns when billing is active. It uses specific verbs ('start', 'connect') and resources ('Meta connection', 'OAuth URL'), and distinguishes from siblings by focusing on the Meta-specific flow.

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

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

Provides explicit when-to-use conditions ('when billing is active and user is ready'), when-not-to-use (billing not active returns billing_required), and retry guidance (billing_check_unavailable). Also specifies that after return, poll dynamoi_get_platform_status until a terminal status is reached.

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?

Describes the OAuth flow and polling behavior. Annotations already indicate idempotentHint=true and no destructiveness, so the description adds useful process context without 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 efficiently cover purpose, usage, and follow-up. Could be slightly more structured (e.g., bullet for polling), but overall clear and front-loaded.

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

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

Explains the overall OAuth flow and polling, which is good for a complex tool. However, missing parameter details limit completeness, though output schema exists.

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

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

Schema description coverage is 0% and the description does not explain any parameters. The required artistId is implied but not detailed, and optional parameters like format and userIntentSummary are ignored.

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

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

The description clearly states the tool returns a Google OAuth URL for linking a YouTube channel to a Dynamoi artist. It specifies the context and differentiates from siblings like dynamoi_start_meta_connection.

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

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

Explicitly says when to use ('when the user is ready to link a YouTube channel') and provides follow-up steps (polling dynamoi_get_platform_status). No misuse conditions needed.

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

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

Description reinforces the destructiveHint annotation by stating it changes live workflow state. While no rate limits or auth details are added, the core behavioral impact is clearly conveyed.

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

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

Two concise, front-loaded sentences with no extraneous information. Every word serves a purpose.

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

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

Given 9 parameters and an output schema, the description is too brief. It lacks details on conditional parameter requirements and expected responses, though the annotations partly compensate.

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

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

Schema has 0% description coverage. Only the 'action' parameter is explained; other important parameters like endDate, budgetAmount, and optional fields are not described. The description adds minimal value beyond the enum.

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

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

The description clearly states the tool's purpose: pausing, resuming, or updating budget/end date for existing campaigns. It distinguishes it from inspection tools like get_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?

Explicitly tells when to use (explicit user request for pause/resume/update) and when not to use (inspection-only questions), providing clear decision criteria for 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?

Description adds value beyond annotations by noting that updates may queue background rendering, which is not evident from readOnlyHint or destructiveHint alone. 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?

Two sentences, front-loaded with purpose, no wasted words. While concise, a bit more structure (e.g., listing key parameters) could improve without losing efficiency.

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

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

Despite having an output schema, the description fails to adequately describe the 11 inputs, relying on the schema which has no descriptions. The tool's complexity demands more parameter guidance for an agent to use it correctly.

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

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

With 0% schema description coverage, the description must compensate but only explains the action parameter and briefly mentions theme/pixel. The remaining 9 parameters (IDs, pixel IDs, timestamps, etc.) are left undocumented, severely limiting parameter understanding.

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

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

Description clearly states two distinct use cases (updating description or artist theme/pixel settings) with specific verb and resource. Differentiates from unrelated tasks like publishing/unpublishing, providing strong purpose clarity.

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

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

Explicitly tells when to use (user wants to change description or update artist-level settings) and what not to do (does not publish/unpublish). Could explicitly mention sibling tools for reference, but context is clear enough.

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 adds behavioral context beyond annotations by detailing the ID format and that it returns the full record. Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description does not contradict annotations and provides useful information about input constraints. It doesn't mention error handling or output specifics, but given the presence of an output schema, this is acceptable.

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 sentences long, front-loaded with the tool's purpose and key constraints. Every sentence adds value: the first identifies the type and origin of the ID, the second states the action and output. There is no redundant or extraneous information.

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

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

Given the tool's simplicity (single parameter, read-only operation, output schema available), the description covers all essential aspects: what the tool does, how to use it (id from search), the ID format, and the return value. The presence of an output schema eliminates the need to describe the return structure. The description is sufficient for an agent to correctly invoke the tool.

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

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

The input schema has a single parameter `id` with no description (0% coverage). The description adds significant meaning by specifying that the id must be returned by `search` and formatted as 'artist:<uuid>', 'campaign:<uuid>', or 'smartlink:<uuid>'. This goes beyond the schema's type constraints (string, length limits) and tells the agent where to get the value and what formats are valid.

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 ('returns the full record') and resource ('record identified by an id from search'). It specifies the ID format with three examples, distinguishing it from sibling get tools that are type-specific. The verb 'fetch' is appropriate for retrieving data, and the description aligns with the tool name.

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

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

The description explicitly says to use this tool when you have an id returned by `search`, which provides clear context. It doesn't explicitly state when not to use it, but the implied workflow (search then fetch) and the existence of sibling get tools (e.g., dynamoi_get_artist) suggest alternatives. Slightly more explicit guidance on when to prefer fetch over those get tools would improve clarity.

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 adds value by specifying the session context (deep-research vs. regular chat). It does not contradict 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 clearly convey purpose and usage differentiation with zero waste. Information is front-loaded 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 the tool's simplicity (single parameter, output schema exists), the description fully captures when and how to use it. No gaps remain.

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

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

With 0% schema coverage, the description should add meaning to the query parameter. It only implies that query is a search term but lacks format guidance, examples, or constraints beyond what the schema 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 clearly states the tool returns matching Dynamoi artists, campaigns, and Smart Links for deep-research sessions, and explicitly distinguishes itself from the sibling dynamoi_search tool for regular chat use.

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 specifies when to use this tool (deep-research sessions) and when not (regular ChatGPT chat), naming the alternative dynamoi_search.

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