Dynamoi

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

The description adds rich behavioral context beyond annotations: idempotency ('return the existing link instead of creating a duplicate'), verification hold ('may stay unpublished in verification hold'), the fact that it is free and does not create a paid ad campaign, and the update behavior for customDescription. No contradiction with the provided 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 focused paragraph front-loads the primary usage rule, then efficiently covers caveats, exceptions, and output handling. Every sentence adds value—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?

Despite the presence of an output schema and annotations, the description covers edge cases (playlists, duplicates, verification hold), non-goals (ad campaign creation), and final answer formatting. It is thorough enough for an agent to select and invoke the tool correctly in varied situations.

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 for explaining parameters. It only clarifies spotifyUrl (album/track/artist URL/URI) and customDescription (updates public description). Required artistId is left unexplained, and format, clientRequestId, and userIntentSummary have no semantic clarification despite non-obvious names.

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 ('create one free Dynamoi Smart Link from a Spotify album or track URL/URI') and clearly distinguishes itself from the sibling tool for full-catalog artist imports by naming the alternative. This makes the tool's purpose immediately clear and unique among 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?

Explicitly states when to use this tool ('Use this when the user wants to create one free...'), when not to use it ('Spotify playlist URLs are not supported today'), and names the preferred alternative for other cases ('For full-catalog artist imports or artist hub requests, prefer dynamoi_create_smart_links_from_spotify_artist').

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 indicate mutation and destruction, but the description adds crucial context: background catalog import starts without dashboard need, verification hold for high-popularity/unverifiable links, and the instruction to lead with artist hub URL and avoid exposing internal IDs. These details go beyond the annotation hints and help the agent manage user expectations safely.

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 dense but every sentence earns its place: trigger condition, artistId nuance, background behavior, free status, verification hold, ad campaign exclusion, and output guidance. It is not overly verbose, though it could be restructured slightly to separate main actions from caveats.

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 (5 params, background import, verification holds, output responsibilities), the description covers the key operational scenarios, edge cases (unverifiable artists), and interaction requirements (leading with hub URL). The presence of an output schema means return format details are not required, and the description provides sufficient guidance for an agent to invoke and present results 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 schema description coverage at 0%, the description needed to explain the parameters. It only meaningfully covers artistId ('omit artistId so Dynamoi can create the first artist'), leaving format, clientRequestId, and userIntentSummary unexplained. While enum values and types are in the schema, the description does not add semantics for these parameters, which 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 function: 'create, import, or refresh free Smart Links for the artist catalog and return the artist hub.' It specifies the resource (Spotify artist catalog) and verb (create/import/refresh), and distinguishes from sibling tools like dynamoi_create_smart_link_from_spotify by referencing the plural 'smart links' and catalog-wide operation.

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 opens with 'Use this when...' and gives a specific trigger (user provides Spotify artist URL wanting Dynamoi to create/import/refresh links). It includes conditional guidance (omit artistId if no Dynamoi artist yet), explains background import implications, and explicitly excludes paid ad campaigns, which sets it apart from dynamoi_launch_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 declare readOnlyHint=true, and the description adds useful context that the state is account-level and can span multiple artists, which explains why it should not be used for artist-specific checks. No contradiction with annotations is present.

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 organized with purpose first and exclusions following, and each sentence contributes a concrete decision rule. It is somewhat long and repeats the 'do not use' sentiment in several clauses, but it remains structured and 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?

With an output schema present and strong read-only annotations, the description does not need to enumerate return fields. It comprehensively covers purpose, scope, and sibling alternatives, though the unexplained format parameter keeps it from being fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It tells the agent to 'Always pass intent' and gives examples that map to intent categories, but it never explains the optional format parameter (json vs summary) or default behavior. This is a partial but not complete compensation.

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 tool as covering the signed-in Dynamoi account itself, including who is logged in, accessible organizations/artists, and account-level platform connections. It also distinguishes the tool from siblings like dynamoi_get_platform_status and dynamoi_list_artists, making its unique purpose 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?

It provides explicit 'Use this when...' triggers and then lists concrete exclusions with named alternatives, such as using dynamoi_get_platform_status for a specific onboarding attempt and dynamoi_list_artists for enumeration. This gives the agent clear decision boundaries.

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 doesn't need to restate safety. It adds useful behavioral context by revealing that format=summary returns a 'strongest-campaign verdict' and that the agent should 'stop and answer' if that comparison is already available, which helps interpret the tool's output 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 dense paragraph with five sentences, each serving a distinct purpose: scope, parameter settings, stop condition, and alternative tool. No filler or redundant restatements of the 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?

With an output schema present and clear annotations, the description covers the essential selection and invocation details, including parameter usage and when to stop. The tool's moderate complexity (4 params, nested dateRange) is fully handled by the combination of description, schema, and 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 0%, so the description compensates for the two key enums: granularity=DAILY for daily breakdowns and format=summary for written rollups/verdicts. It does not elaborate on artistId or dateRange, but those are self-evident from the schema (UUID and date-range object), so the added guidance is sufficient and valuable.

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

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

The description clearly states the tool provides 'artist-level performance across all campaigns' with '30-day rollups or daily breakdowns,' using specific verbs and resource. It also distinguishes itself from dynamoi_get_campaign by explicitly noting when to use that alternative for single-campaign 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 when-to-use guidance ('when the user wants artist-level performance...') and an exclusion ('For one campaign's metrics, use dynamoi_get_campaign')). It also provides actionable parameter instructions, such as 'Pass granularity=DAILY' and 'Pass format=summary', and even a stop condition to avoid redundant tool calls.

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 this as read-only and non-destructive. The description adds that it does not create checkout links or collect payment, and explains the follow-up behavior when billing blocks a launch, which enriches the operational context 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 compact and front-loaded with usage triggers. Every sentence adds value: scope, read-only caveat, and workflow guidance. No fluff 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?

While the description covers the main use cases and the tool has an output schema, the complete absence of guidance on the optional parameters (format, onboardingAttemptId) creates a gap. For a tool with only 3 parameters, this is a notable omission that reduces overall 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 compensate by explaining the parameters. However, it only implicitly references the artist (via 'one artist') and fails to explain the 'format' and 'onboardingAttemptId' parameters. This leaves the agent without sufficient understanding of these inputs.

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 resource and action: checking billing state, credit balance, promo limits, subscription status, and launch-blocking status for one artist. It also explicitly distinguishes itself from campaign analytics and platform connection troubleshooting, making the purpose unambiguous and differentiated from 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?

It provides explicit when-to-use triggers (billing questions for one artist) and when-not-to-use exclusions (campaign analytics, platform connection troubleshooting). It also gives a workflow for when billing blocks a launch, guiding the agent on next steps in context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description goes beyond this by detailing what 'full details' includes (budget, targeting, platform status, next actions) and the meaning of key flags like includeAnalytics, includeDeploymentStatus, and includeCountries. It does not describe pagination or response structure, but the output schema is present, so 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 four sentences, all information-dense and front-loaded with the primary use case. Every sentence earns its place: purpose, flag semantics, exclusion of list use, and format recommendation. There is no repetition of schema information or wasted words.

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

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

Given the tool's complexity (7 parameters, nested object, output schema), the description is quite complete. It addresses the core use case, alternatives, and key parameter behavior. The only gaps are the unexplained analyticsDateRange and analyticsGranularity, but these are secondary and the output schema handles return details. Overall, the description provides enough context for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description carries the burden for parameter meaning. It explains includeAnalytics, includeDeploymentStatus, includeCountries, and format (via the 'prefer format=summary' note). However, it does not clarify analyticsDateRange or analyticsGranularity, which are non-obvious and nested. Since it covers the most important flags but not all parameters, a 4 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 the tool's purpose: retrieving full details for one specific campaign, including budget, targeting, platform status, and next actions. It also distinguishes itself from the sibling tool dynamoi_list_campaigns by explicitly saying 'Do not use this for a campaign list.' The verb 'get' and resource 'campaign' are specific and 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?

The description provides explicit guidance on when to use the tool ('when the user wants full details for one campaign') and when not to use it ('Do not use this for a campaign list; use dynamoi_list_campaigns instead'). It also gives a specific recommendation for post-mutation follow-ups: prefer format=summary. This comprehensively covers usage context and alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds 'without creating a campaign,' which is a minor reinforcement but does not disclose significant behavioral traits beyond the annotations. There is 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 two sentences, front-loaded with the primary use case, and every sentence adds value. 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?

Given an output schema exists, the description needn't detail return values. It covers what the tool does, when to use it, and explicitly contrasts with mutation tools. With 11 params and nested structure absent, the description is sufficient for selection and invocation, though parameter guidance is handled mostly by the 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 0%, so the description carries the burden for parameter meaning. However, it mentions 'proposed inputs' but never explains any of the 11 parameters, such as required artistId/campaignType or optional budgetType/locationTargets. The description adds no value beyond the schema's own names and enums.

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 without creating a campaign, using the specific verb 'validates readiness'. It explicitly references dynamoi_launch_campaign, distinguishing it from sibling tools like launch or update 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 explicit when-to-use guidance: 'Use this when the user is planning a campaign and wants to know if the proposed inputs are ready before dynamoi_launch_campaign.' It also gives a clear exclusion: 'Do not use this to create or mutate campaigns,' which signals 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 readOnlyHint annotation already covers safety; the description adds that this tool correlates onboarding attempts with the browser step and should never be used for personalization. This provides useful behavioral boundaries without conflicting 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?

Three sentences, starting with a clear use case and ending with exclusions. Every sentence adds information 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?

An output schema exists, so return values are covered. The description addresses typical usage, exclusions, and polling behavior, but the missing artistId/format semantics and lack of prerequisites prevent it from being fully self-contained.

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 is responsible for explaining parameters. It explains onboardingAttemptId and onboardingFlow in the polling context, but the required artistId and the format option are left entirely unexplained, which is a meaningful 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 checks connection status for Spotify, Meta, and YouTube and reports blocking setup steps. It distinguishes itself from billing and personalization tools, aligning with its title and sibling 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?

It explicitly says 'Use this when...' and provides concrete exclusions for billing and personalization questions. However, it does not name specific alternative tool names, relying on the reader to infer they exist.

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 non-destructive behavior. The description adds response formatting guidance (lead with public URL, don't expose internal IDs) and clarifies what the tool returns, adding value 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?

Three sentences, front-loaded with the core usage statement, followed by parameter guidance and a response formatting note. No wasted words; every sentence earns its place.

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

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

Given the output schema and read-only annotations, the description covers the key aspects: when to use, what fields are returned, which optional parameters to set, and how to present results. It is sufficiently complete for an agent to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains includeAnalytics and includeArtistSettings, but leaves other parameters (playLinkId, dateRange, granularity, format) semantically unaddressed. Some are self-explanatory, but domain-specific ones like playLinkId are not clarified.

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 gets full details for one free Smart Link, listing specific included fields (release, Spotify URL, public URL, status, theme source, next actions). This distinguishes it from list_smart_links and update_smart_link 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 opening 'Use this when the user wants full details for one free Smart Link' provides clear usage context. It implicitly contrasts with list tools but does not explicitly name 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?

The description provides useful behavioral context (e.g., delivery state ACTIVE, demo-safe simulation), but there is a direct contradiction with annotations: destructiveHint is true while the description implies a creation operation. The description does not reconcile the destructive hint and even suggests safety, earning a score of 1 due to the annotation 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 a single paragraph of four sentences, front-loaded with the primary purpose. It is concise and each sentence adds meaningful guidance, though it could be trimmed slightly without losing essential 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 complexity (17 parameters, nested objects, output schema), the description is too high-level. It does not explain required parameters like artistId, budgetSplits, or campaignType/contentType relationships. The descripiton provides launch workflow guidance but leaves many invocation details unaddressed, especially with the annotation contradiction.

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 17 parameters and 0% schema coverage in the description, it fails to compensate for the low coverage. It briefly mentions spotifyUrl and endDate omission, but does not define their meaning or any other parameter semantics. The description adds minimal value beyond the schema, which itself lacks descriptions.

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

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

The description clearly states the tool creates a new Smart Campaign or YouTube Campaign and starts a launch workflow, using a specific verb and resource. It explicitly distinguishes this from recommendations and previews, making the 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?

It explicitly says when to use ('when the user explicitly wants to create a new Smart Campaign or YouTube Campaign'), when not to use ('Do not use this for recommendations or previews'), and provides detailed guidance on omitting spotifyUrl and endDate for review/demo launches. It also instructs on post-launch behavior, which is valuable context.

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

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

Annotations already declare readOnlyHint and destructiveHint false, but the description adds important behavioral context: empty results indicate a brand-new user and triggers a specific fallback, and passing artistId changes the output to detailed readiness profile. 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 primary usage and packs essential exclusions, alternatives, and edge-case handling into a few sentences. Every sentence adds value; 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?

Given the output schema exists, the description adequately covers purpose, usage contexts, alternatives, and special behavior for empty results. It is complete for an agent to select and invoke the tool correctly, even with minimal parameter description.

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 the description must compensate. It explains artistId's role (full profile vs roster page) but does not describe limit, cursor, or format. While these are conventional pagination/format parameters, the description only partially covers the parameter semantics, leaving 3 of 4 parameters undocumented.

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 explicitly states the tool lists artists/YouTube channels the user manages, along with billing status, active campaign count, and role. It distinguishes from siblings by specifying when to use dynamoi_list_campaigns or dynamoi_get_campaign for campaign details, and clearly defines the roster-list scope.

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 ('when the user wants to see which artists or YouTube channels they manage'), when-not-to-use ('Do not use this for campaign details'), and alternative tools. Also gives guidance for empty results (route to account overview). This is thorough and actionable.

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 read-only safety, and the description adds useful context that Smart Campaign and YouTube catalogs differ, which is a behavioral nuance. It doesn't contradict annotations and provides additional insight beyond the schema.

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

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

The description is two concise sentences with the usage context front-loaded. Every sentence adds value, and there is no redundant information.

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

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

The description covers when to use and campaignType, but does not explain the optional parameters (limit, query, cursor, format) that the schema lists. While output schema exists, the lack of parameter guidance makes it only moderately complete for a 5-parameter 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?

With 0% schema description coverage, the description must explain all parameters. It only explains campaignType's necessity and its effect on results, leaving limit, query, cursor, and format undefined. This is insufficient for full 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?

The description clearly states the tool lists countries targetable for Smart Campaign or YouTube campaigns, with a specific verb and resource. It also distinguishes from generic country advice, making it 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?

It explicitly says when to use ('when the user asks which countries they can target') and what not to use it for ('Do not use this for generic country marketing advice'). It also mandates the campaignType parameter, giving clear invocation 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, covering the safety profile. The description adds a precondition (route via get_account_overview if no artists) but doesn't disclose return behavior, pagination, or error cases, which would add 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?

Four sentences, each with distinct value; front-loaded with primary use case. Could be slightly tighter but contains no 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?

Output schema and annotations cover much of the technical detail. Description covers usage and routing well, but leaves pagination and format ambiguities, and doesn't address edge cases beyond basic routing.

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, so the description must compensate. It mentions filtering by type/status and one artist (artistId), but doesn't explain limit, cursor, or format semantics (e.g., difference between json and summary). With 6 params, this is only partial 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?

Description states 'browse campaigns for one artist, optionally filtered by type or status' – a specific verb+resource+scope. It explicitly contrasts with dynamoi_get_campaign for a single deep dive, distinguishing it from 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?

Provides explicit when to use ('when the user wants to browse campaigns'), when not to use ('Do not use for a single campaign deep dive'), and directs to alternatives (dynamoi_get_campaign, dynamoi_get_account_overview). Also warns against misuse for marketing advice.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds behavioral context by disclosing that includeUrls must be requested explicitly to get public-safe asset URLs, and that format=json returns asset IDs. It does not detail pagination or other side effects, but given the annotations, the description adds value 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?

Three sentences, each with a distinct purpose: primary use case, exclusion, and parameter guidance. No fluff, front-loaded with the most important 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 moderate complexity (5 params) and presence of an output schema and annotations, the description covers the core usage and parameter selection guidance. It does not describe pagination behavior or edge cases, but the output schema fills return-value details. Overall adequate and slightly above minimum viable.

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 explains format and includeUrls, but does not explain limit, cursor, or artistId. While some parameters are self-explanatory (limit, cursor) the artistId is required and not described. The description partially covers the parameter semantics but leaves gaps.

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

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

The description clearly states the tool lists uploaded images/videos for reuse in campaign launch, using a specific verb and resource. It distinguishes from campaign status or analytics tools, and the sibling tool list confirms it is one of many list/get 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 states when to use ('when the user wants to choose from uploaded images or videos...'), when not to use ('Do not use when the user only wants campaign status or analytics'), and provides parameter-specific guidance for format and includeUrls. This is ideal.

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, establishing a safe read operation. The description adds behavioral context beyond this: instructs to show public URLs and avoid internal IDs in the final answer, and describes the desired fallback behavior for empty results. 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?

Four sentences, each earning its place: purpose, exclusion, output formatting rule, and empty-case fallback. Front-loaded with the primary action and 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?

The description covers purpose, when-not-to-use, output presentation, and fallback behavior, and an output schema exists. However, with 8 parameters and no parameter descriptions, the lack of explanation for filtering/pagination options leaves some gaps, though the core invocation is clear.

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, but it does not explain any of the 8 parameters beyond implying artistId via 'one artist'. The filter parameters (limit, query, cursor, format, claimStatus, renderState, publishState) are left completely unexplained, offering no added meaning over the raw 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 opens with a specific verb ('list'), resource ('free Smart Links for one artist'), and enumerates returned fields ('release title, public URL, publish state, claim state, render state, and theme'). It explicitly distinguishes from the sibling tool `dynamoi_list_campaigns`, making 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 direct when-to-use guidance ('Use this when the user wants to list free Smart Links for one artist'), an explicit exclusion ('Do not use this for paid campaign lists; use dynamoi_list_campaigns'), and alternative actions when results are empty (suggesting create tools). This is exemplary.

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 adds valuable context by explicitly stating this is a 'read-only visual preview' and listing actions it does not perform. This reinforces the non-mutating nature with concrete examples, though it doesn't add detail on auth or rate limits.

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 and front-loaded, with the first sentence immediately giving usage scenarios and the second addressing non-actions. Every sentence earns its place, and it is appropriately sized for the tool's complexity.

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, the description doesn't need to explain return values. However, it omits any guidance on the optional parameters, which is a gap given zero schema descriptions. The purpose and read-only nature are clear, but the invocations 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%, and the description does not explain the meaning of 'artistName' or 'releaseTitle' parameters. The property names are somewhat self-explanatory, but the description fails to compensate for the lack of schema documentation, leaving the agent without guidance on how to populate these optional fields.

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: previewing and comparing Dynamoi Smart Link themes. It uses specific verbs like 'preview' and 'compare' and explicitly distinguishes itself from create/update operations, so it effectively differentiates 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 provides explicit 'use this when' scenarios, covering user requests to see what pages look like, compare themes, or preview themes before creation/update. It also states what the tool does NOT do (create, publish, update, promote), though it doesn't name specific 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, so the safety profile is clear. The description adds meaningful context beyond annotations: it explains the tool can return empty results and instructs how to handle that for new users, which is a non-obvious behavioral trait. 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 composed of three concise sentences, each conveying essential information. It is front-loaded with the primary purpose, followed by exclusions and a specific edge-case behavior, with no redundant phrasing.

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 7 parameters, an output schema, and important usage nuances. The description covers when to use the tool and a key empty-result scenario, but it does not explain return values (though output schema exists) or how to leverage parameters like type, limit, cursor, or artistId. This leaves the agent with gaps in operational usage.

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

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

Schema description coverage is 0%, so the description carries the burden for parameter meaning. However, it provides no details about any of the 7 parameters (e.g., query, limit, cursor, format, type, includeArchived). While parameter names and enums are self-explanatory to some degree, the description fails to clarify how to construct queries or use pagination/filtering, leaving 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 explicitly states a specific verb and resource: search for artists, releases, campaigns, or smart links when the exact record is unknown. It clearly distinguishes this from sibling get/list tools by highlighting the discovery context ('do not yet know the exact record to inspect').

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 explicit 'when to use' ('when the user mentions an artist, release, campaign, or smart link but you do not yet know the exact record') and 'when not to use' ('do not use for analytics summaries or billing questions once you already know the target record'). It also gives guidance for the empty-results edge case, suggesting an alternative action.

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 provides rich behavioral details beyond annotations: it returns a signed URL, may show a Page/Instagram selection step, returns different error codes (billing_required, billing_check_unavailable) and advises retrying on transient issues. This adds context not captured by readOnlyHint=false or idempotentHint=true.

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 compact block of six sentences, each carrying necessary information about usage, behavior, error cases, and follow-up. It is front-loaded with a clear usage condition. Slightly dense but not bloated; could be restructured with bullets for readability, but all content 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?

Covers the full lifecycle: precondition (billing active), action (returns OAuth URL), possible intermediate step (Page/Instagram selection), error paths (billing_required, billing_check_unavailable), and post-condition (poll get_platform_status). The output schema is likely available, so not explaining return structure 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 the description does not explain any of the three parameters (artistId, format, userIntentSummary). There is no compensation for the missing schema descriptions, so agents must infer meaning from names alone, which is insufficient for optional parameters like userIntentSummary.

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: start a Meta connection for Spotify Smart Campaigns from chat, returning a signed OAuth URL. It distinguishes this from siblings like dynamoi_start_youtube_channel_link by naming 'Meta' explicitly and describing 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?

Explicitly states when to use: 'when billing is active and the user is ready to connect Meta...'. It also explains what happens when not to use it (billing_required) and provides a follow-up action (poll dynamoi_get_platform_status), giving clear guidance on downstream steps and alternatives.

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

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

Discloses the OAuth flow, the bound to signed-in user and artist, the redirect behavior, and the need to poll with onboardingAttemptId and onboardingFlow=youtube. This exceeds the annotation information (idempotentHint=true) and adds valuable context that the operation is not instantaneous and requires follow-up.

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 serving a purpose: when to use, what it returns, and how to follow up. No fluff or redundancy. It is well-structured and front-loaded with the primary use case.

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 effectively covers the entire workflow for the agent, including the initial call, the OAuth redirect, and the polling step. An output schema exists, so return value details are not needed. However, the lack of parameter explanations creates a minor gap in 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 compensate. It alludes to artistId ('to one Dynamoi artist') but does not explain the 'format' or 'userIntentSummary' parameters. The description focuses on the OAuth flow and omits parameter meanings, leaving the agent to infer from parameter names.

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 action: link a YouTube channel to a Dynamoi artist. It specifies the verb 'link' and the resource 'YouTube channel', and mentions it returns a Google OAuth URL. This distinguishes it from sibling tools 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?

Provides a strong trigger condition: 'Use this when the user is ready to link a YouTube channel to one Dynamoi artist from chat.' It also gives post-return instructions on polling dynamoi_get_platform_status. However, it does not explicitly mention when not to use or suggest alternatives, so not a full 5.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true. The description adds context by stating this 'changes live campaign workflow state or external campaign settings', which goes beyond the annotation hints and clarifies the real-world impact. It does not detail what exactly gets destroyed, but the mutation nature is explicit and consistent 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 two sentences, front-loaded with the primary use case and action types. Every sentence adds value, and the exclusion of inspection-only use is a good structural decision. There is no redundancy or filler.

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

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

Given the tool's complexity (12 parameters, mutation, destructive hint, open world, output schema exists), the description is too thin. It fails to communicate conditional parameter requirements (e.g., that update_budget likely needs budgetAmount and expectedCurrentBudgetAmount) or the existence of consent-related fields. While annotations and output schema provide some context, the description alone leaves an agent unprepared to invoke the tool correctly for non-trivial actions.

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 only 8% (only one of 12 parameters has a description). The description must compensate for the missing parameter semantics, but it only mentions 'action' values and 'budget/end date' generically. It does not explain important conditional parameters like expectedCurrentStatus, expectedCurrentBudgetAmount, consent fields, or how they relate to different actions. This is inadequate for a 12-parameter tool with conditional logic.

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: pause, resume, or update budget/end date for an existing campaign. It uses specific verbs and resource (campaign), and distinguishes from sibling tools like dynamoi_get_campaign or dynamoi_update_smart_link by focusing on campaign lifecycle mutations.

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

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

The description provides explicit when-to-use guidance ('when the user explicitly wants to pause, resume, or update...') and an explicit when-not-to-use exclusion ('Do not use this for inspection-only questions'). However, it does not name a specific alternative tool, only refers to 'inspection-only', so it falls short of the 'alternatives' criterion for a 5.

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

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

Annotations already indicate a non-read-only, destructive, idempotent operation. The description adds context about async behavior (theme-only updates are instant; description/pixel changes may queue background rendering) and confirms it does not affect public availability. This goes beyond the annotations, though it doesn't elaborate on destructive effects or idempotency specifics.

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, each earning its place: the first defines the purpose, the second clarifies a key limitation and action parameter, the third describes performance traits. No wasted words, front-loaded with the primary use case.

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 primary purpose, what it doesn't do, and async behavior, which is good for a complex tool. It lacks guidance on which parameters are expected per action and how existing settings are affected when not provided. The presence of an output schema covers return values, so overall it's fairly complete but with clear 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?

With 0% schema coverage, the description partially compensates by explaining the action enum and tying it to customDescription, theme, and pixel fields. However, 11 parameters exist and many (artistId, playLinkId, clientRequestId, expectedUpdatedAt, userIntentSummary) are left unexplained, relying on naming conventions. It adds some meaning but not enough to fully compensate for the lack of schema descriptions.

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

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

The description clearly states the tool updates Smart Link descriptions or artist-level theme/pixel settings, distinguishing between two specific actions (update_description and update_artist_settings). It also clarifies what the tool does not do (publish/unpublish links), which helps differentiate it from related tools. This is a specific verb+resource with clear scope.

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

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

The description provides explicit when-to-use guidance ('when the user wants to change...') and a when-not-to-use condition ('does not publish or unpublish individual links'). It also tells the user to set the action parameter to one of two values. However, it does not name alternative tools explicitly, so it falls short of full 5-score for alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by specifying the id structure and that the response is the full record, but it does not disclose behavior for invalid/not-found ids or the exact response envelope beyond the 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 two sentences and front-loaded with the contract context. Every clause adds useful information about the tool's role, input format, and output purpose. The phrase 'OpenAI ChatGPT Deep Research / Connectors' is slightly redundant but not bloated.

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 one parameter, helpful annotations, and an output schema, this description is nearly complete: it names the input provenance and format, and the output purpose. Minor gaps like error handling for malformed ids or non-existent records are not addressed, but the core invocation context is sufficiently covered.

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 only defines `id` as a string, but the description fully compensates by documenting the exact valid formats ('artist:<uuid>', 'campaign:<uuid>', 'smartlink:<uuid>') and their source from `search`. This is essential meaning that would otherwise be missing, especially at 0% 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 tool's action: given an id from `search`, it 'returns the full record for citation.' It identifies the specific id formats (artist:<uuid>, campaign:<uuid>, smartlink:<uuid>), making the purpose concrete. However, it does not explicitly differentiate from sibling tools like get_campaign or get_smart_link beyond the composite id format.

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

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

The description provides clear usage context: use after `search` and with a properly formatted id. It also implies the output is for citation, which helps an agent understand intent. It stops short of naming alternative tools for exclusions, but the required prerequisite is 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 declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the intended use case (deep-research citation) but does not disclose additional behavioral details such as result limits or ordering. Since annotations cover the safety profile, a 3 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 two sentences and front-loaded with the tool's purpose. Every word earns its place, with no fluff or repetition of schema/annotation 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?

Considering this is a simple read-only search with one parameter and an output schema, the description fully covers the necessary context: what it searches, why it exists, and the alternative. The output schema handles return-value documentation, so no further detail is needed.

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 schema only defines a string 'query' with min/max lengths. The description compensates by implying that the query is a search term that matches against artists, campaigns, and Smart Links, giving the parameter meaningful context beyond the bare schema.

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

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

The description clearly states the tool's function with a specific verb ('Returns matching') and resource ('Dynamoi artists, campaigns, and Smart Links'). It also distinguishes from the sibling tool dynamoi_search by specifying that this is for Deep Research / Connectors rather than regular ChatGPT chat.

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 usage context: for deep-research sessions where results need to be cited. It also names the alternative (dynamoi_search) for regular ChatGPT chat, giving clear when-to-use and when-not-to-use guidance.

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