Starchild Music

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

Annotations already declare this a safe read (readOnlyHint, destructiveHint false), so the bar is lower. The description contributes real value beyond them by explaining the economics — 2 credits per style, 3 for songs over 3:30 — which the agent needs to interpret the returned balance. It omits error/fallback behavior for unconnected users.

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

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

Two short sentences, front-loaded with the resource and scope, with the cost context placed after the core definition. No filler or restated schema content.

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

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

For a zero-parameter read tool with no output schema, the description roughly covers the return ('their credit balance') and pricing context, but leaves the response shape and the not-connected case unspecified. Adequate but not 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?

The tool takes zero parameters, so there is nothing to disambiguate; schema coverage is trivially 100%. Baseline 3 is appropriate since the description neither adds nor omits parameter meaning.

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

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

States a specific resource ('credit balance') and its scope ('for a connected Starchild member'), so an agent immediately knows what it retrieves. It is not a tautology of the name, though it doesn't name-differentiate from siblings, which it doesn't need to since the sibling set is unrelated.

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?

Implies usage by naming a precondition ('connected Starchild member') and by explaining credit costs, which suggests checking this before spending. However, it never says when to call it versus alternatives or what to do if the member is not connected.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond them: the output is a link, the cart is populated automatically, and the actual transaction happens elsewhere on starchild.music — a key behavioral boundary. It does not mention link lifetime, authentication, or the 10-item cap, keeping it at a 4.

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 tight sentences, each earning its place: purpose first, checkout boundary second, parameter guidance third. No restatement of the name or title and no filler.

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

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

With no output schema, the description does explain the return value as a link that opens a pre-populated cart, which is what an agent needs. The 10-item and 1-item bounds live in the schema, so they need not be repeated. Missing only minor operational detail such as link permanence or sharing semantics.

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 carry parameter meaning. It does compensate for the license field by naming concrete values (song-only, song-instrumental, royalty-free, exclusive-license) that the schema lacks an enum for. However, the required 'song' field is never explained — whether it takes an id, title, or slug is left to inference, leaving half the semantics uncovered.

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?

States a specific verb+resource ('Turn chosen songs and licenses into one link') and immediately clarifies the resulting artifact: a Starchild cart URL with items pre-added. It also names the sibling license_options as the source for license ids, so an agent can separate it from search_songs, license_options, and checkout flows without opening any schema.

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 establishes context ('Checkout happens on starchild.music') which implicitly tells the agent when this tool applies versus when it does not — this builds a link, it does not complete a purchase. It also directs the agent to license_options for valid license ids. There is no explicit when-not or named alternative for the overall workflow, so it falls short of a 5.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world). The description goes beyond them by disclosing the return artifact (a starchild.music link), the fact that the original vocal is preserved, and the edge-case behavior of listing available styles when the requested style does not exist for that song.

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 action, then the return artifact, then the fallback path. No filler, though the long parenthetical example list makes the first sentence slightly heavy.

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

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

For a simple two-parameter read tool with no output schema, the description covers what is returned, the key preservation guarantee (original vocal), and the failure path. Only the sibling differentiation and auth/prerequisite context are absent.

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

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

Schema coverage is 100%, so the baseline is 3, but the description enriches the 'style' parameter with additional concrete examples (Country, Acoustic Indie, Electro Rock, Latin Salsa, Piano Ballad Orchestral) and implies styles are song-specific, adding meaning the schema's terse 'e.g. country' does not.

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

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

States a specific verb+resource ('Hear a Starchild song in a different production style') and clarifies the outcome (a link opening on starchild.music with the original vocal). However, it never distinguishes itself from siblings like transform_song or check_transform, which an agent could easily confuse with this one.

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 scenario of use is implied by the description (hearing an existing song in another style), and the fallback behavior when a style is unavailable is noted. But there is no explicit when-to-use guidance, no prerequisites, and no routing away from the similarly named transform_song/check_transform siblings.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is clear. The description adds that it returns progress and listening links and that it requires a connected Starchild member, which is useful extra context not in annotations. However, it does not describe polling behavior, rate limits, or what happens if the job is not found or expired.

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

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

The description is a single concise sentence that is front-loaded with the key context (Starchild member, progress and listening links). It is efficient and wastes no words, though it could be slightly more informative without being verbose.

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

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

For a read-only status-check tool with one required parameter, the description is incomplete. It fails to explain the 'job' parameter, does not cover prerequisite (connected member is mentioned but not elaborated), and lacks details on what 'progress' means or how to interpret the listening links. Without an output schema, the description should do more to set expectations.

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 single parameter 'job' has no description in the schema. The tool description does not explain what 'job' represents, its format, or where to obtain it. This is a significant gap because the parameter is required and 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 states that it returns progress and listening links for a transform, which gives some idea of the resource. However, 'Check my new version' in the title is ambiguous, and the description does not explicitly say it checks the status of an existing transform started by transform_song; it implies it by referencing the sibling tool. Without the sibling reference, the purpose would be unclear.

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

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

The description mentions that it is for a connected Starchild member and references a transform started with transform_song, but it does not provide explicit when-to-use guidance such as 'use this after calling transform_song to poll for completion' or when not to use it. There is no comparison to 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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the useful detail that the tool returns the full attribute set (licenses availability, similar songs), which signals completeness. It does not discuss rate limits, auth needs, or behavior when a title matches multiple songs.

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: the first front-loads the purpose and enumerates return fields, the second cleanly documents the accepted identifier forms. No redundant or filler text.

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

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

For a single-parameter read tool with full schema coverage and annotations covering safety, the description is nearly complete. It omits only edge-case behavior (ambiguous title matching, error handling), which is minor given the tool's simplicity.

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

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

Schema description coverage is 100% and the schema already documents the 'song' parameter with the same three accepted forms. The description repeats that information without adding syntax, format, or disambiguation rules (e.g., what happens with an ambiguous exact title). Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb ('Full details for one Starchild song') and enumerates the exact fields returned (writers, genres, moods, key, tempo, production styles, similar songs, licenses). This distinguishes it from siblings like search_songs (discovery) or play_song (playback). An agent can tell exactly what this tool retrieves.

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

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

The phrase 'for one Starchild song' alongside the accepted identifier forms ('song id, its starchild.music link, or its exact title') implies this is the lookup tool for a known song, versus search_songs for discovery. However, it never names search_songs or an exclusion condition, so usage is inferable but not 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, openWorldHint=false, and destructiveHint=false, so the safety profile is clear. The description adds useful context about the informational scope, but it does not explain the return format or that this is a static guidance tool rather than an action tool.

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

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

The description is a single front-loaded sentence that states the audience and the covered topics with no filler. Every clause adds meaningful scope information.

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

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

For a zero-parameter, read-only informational tool, the description supplies the essential context: who it is for and what guidance it provides. No output schema exists, so return-value details are not required.

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 zero input parameters, there are no parameter semantics for the description to clarify. The baseline for a parameterless tool is 4, and the description does not mislead about 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 names the audience (songwriters and catalog owners) and the exact topics covered (listing songs, costs, licensing earnings, rights). This clearly distinguishes it from sibling tools like license_options, get_song, and search_songs, which handle specific licensing or song data rather than the selling process.

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

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

The description implies when to use the tool by naming its audience and subject matter, but it does not explicitly say when to choose it over siblings like license_options or account_status. No exclusions or alternative guidance 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 already declare readOnlyHint and non-destructive. The description adds valuable behavioral context: the tool's output differs based on whether a song is provided, prices are one-time and in USD, and it returns a full price list. No rate limits or auth requirements are mentioned, but these are less critical for a read-only pricing tool.

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

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

Three sentences, front-loaded with the core purpose and then the two modes. Every sentence earns its place, though the final sentence about currency/one-time could be considered minor detail. Overall efficient 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?

Given one optional parameter, no output schema, and annotations covering safety, the description is complete enough: it explains what the tool returns in both modes and the pricing nature. It does not mention output format or pagination, but these are less relevant for a pricing lookup.

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

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

Schema description coverage is 100%, so the parameter is fully documented. The description adds meaning by explaining that the song parameter is optional and that omitting it yields the standard price list. It does not add syntax details beyond the schema, but the dual-mode explanation is helpful context.

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 statement of purpose ("What licensing a Starchild song costs") and clarifies the dual behavior (with/without a song). It distinguishes itself from siblings like get_song or build_cart, but does not explicitly compare to them. No sibling directly overlaps, so a 4 is appropriate.

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

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

The description implies when the tool is useful by describing two modes (with a song, without a song), but it does not explicitly state when to use this over alternatives like build_cart or how_to_sell_songs. The behavioral split is informative but not framed as usage guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description goes beyond that by disclosing what the user actually gets: an in-chat player, original recording plus all production styles, mid-song style switching, and per-style starchild.music links. It omits error behavior for invalid ids/titles.

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

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

One front-loaded sentence that leads with the action and then the result, with no filler. It is dense with parenthetical detail but every clause conveys real behavior, so little is wasted.

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

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

For a read-only, single-parameter tool with no output schema, the description adequately conveys what invoking it produces. It does not cover failure modes or whether playback requires an existing session, leaving minor 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 100% and the single 'song' parameter is fully documented in the schema (id, link, or exact title). The description adds no additional syntax or format guidance, so the baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb (play) and resource (Starchild song), and even describes the resulting UI surface (in-chat player with original recording plus every production style). It does not, however, distinguish itself from siblings like get_song or transform_song, which an agent must disambiguate.

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?

Usage is implied by the verb 'play' — an agent can infer this is for listening/playback rather than retrieving metadata or transforming. But there is no explicit when-to-use vs. get_song/search_songs/change_style, and no statement of prerequisites (e.g., must a song exist first?).

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, non-destructive, and closed-world, so the safety profile is covered. The description adds meaningful behavior beyond that: results render in an in-chat browser where 'every result plays, in every production style,' and that pagination is available via offset. It stops short of stating result limits or empty-result behavior, but adds real 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?

Three sentences, front-loaded with the core capability, then the filter options, then the result behavior and pagination. No waste; every clause 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 no output schema and 7 parameters, the description covers the search mechanics, filter options, result presentation, and pagination. It could be more complete by noting the maximum result count or default limit, and by clarifying whether filters are ANDed or ORed, but it is solid for a search tool of this 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 50-60%, with enums for tempo and vocal and examples for mood and genre, but the description doesn't elaborate on parameter usage beyond restating the categories. The offset parameter's role in pagination is explicitly called out in the description, which is helpful, but the rest is already in the schema. Baseline 3 is appropriate given 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?

States a specific verb+resource ('Search Starchild's catalog of original songs') and distinguishes itself from siblings like get_song and play_song by being a semantic catalog search. The description makes clear this is the discovery entry point, not a retrieval-by-ID tool.

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?

Explains the intended query style ('describe the song in plain words') and lists optional filters, and mentions using offset for more results, which is clear operational context. However, it doesn't explicitly name which sibling to use instead when the agent already knows the song (get_song) or wants to play a specific track (play_song).

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 only declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the description carries real extra weight: it discloses credit cost (2 per style, 3 per style over 3:30), latency ('takes a few minutes'), async behavior (returns a job id), and a persistent side effect (results save to the member's Gen library). It does not say whether credits are consumed on failure or how to cancel a job, so it is short of a 5.

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 dense but well front-loaded paragraph: eligibility, action, cost, then follow-up tooling. Every clause carries information, though the stacked parentheticals ('(2 per style, 3 per style for songs over 3:30)') make it slightly hard to scan.

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

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

With no output schema, the description still covers the return (a job id consumed by check_transform) and the persistence side effect, plus cost, latency, eligibility, and the cheaper alternative. An agent has everything needed to decide 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 coverage is 100%, so the baseline is 3; however the description adds meaning beyond the schema by tying credit consumption to the styles parameter count and describing direction as free-form 'plain words' creative guidance. It still doesn't clarify the song identifier resolution order (id vs. link vs. title) that the schema only lists.

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?

States a specific verb and resource ('render NEW versions of a catalog song in chosen production styles, keeping the original vocal') and pins down scope with the eligibility qualifier 'For a connected Starchild member.' It is immediately distinguishable from change_style (existing styles) and check_transform (job polling).

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 routes the agent: 'Use change_style first for styles that already exist (free),' and names check_transform as the follow-up for the returned job id. It also states the precondition (connected member) and the cost condition, so the when-to-use decision is fully specified.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds real behavioral value the annotations do not: the expected input format (SC-2026-123456) and the fact that a successful check returns song and license coverage, not just a boolean.

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 sentence, front-loaded with the action and the identifier, with the return scope appended. Every clause earns its place and nothing is padded.

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

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

For a one-param read-only lookup with no output schema, the description covers the action, the input format, and the nature of the result. It does not mention what happens on an invalid/unknown certificate or whether the number is case-sensitive, which would round it out.

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 carry the parameter. It supplies the exact certificate format (SC-2026-123456), which is the single most useful thing an agent needs to avoid a malformed call, well above the baseline for a one-parameter tool.

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

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

States a specific verb (check/verify) and resource (Starchild license certificate number), and adds concrete scope: whether the certificate is genuine and which song/license it covers. No sibling tool does certificate verification, so it is clearly distinguishable from get_song, license_options, etc.

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?

Usage is implied — verify a certificate you already hold — but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative such as license_options for browsing rather than verifying. Adequate but with a clear gap.

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