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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only hints at two modes without explaining side effects, validation requirements, state changes, or prerequisites. 'Validated job_id' implies a check but does not describe what validation means or what happens with invalid input. The description does not disclose whether the tool mutates state, requires authentication, or returns job progress.

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 compact sentence with no wasted words, but it is not well-structured because it awkwardly combines two potentially distinct operations. The phrase 'using question mode' is jargon and does not aid clarity. It is concise but at the expense of necessary explanation.

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

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

For a tool with six optional parameters, no annotations, and zero schema description coverage, the description provides only minimal context about question mode and job resumption. An output schema exists, so return values are not the main gap, but the missing explanations for context, asset_count, and instruction make the definition incomplete. An agent cannot confidently determine required inputs or correct mode selection from this description alone.

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 six parameters, but it only alludes to 'question', 'job_id', and 'response'. Parameters like 'context', 'asset_count', and 'instruction' are completely unmentioned, leaving their roles unclear. The phrase 'validated job_id and response fields' adds some meaning, but it is insufficient for an agent to construct a correct call.

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 verb ('Classify') and a resource ('Cassette question'), but 'question mode' is vague and unexplained, making the primary purpose ambiguous. It also introduces a secondary 'resume an interrupted job' use case without clarifying how it relates to the tool's main function. The description does not clearly differentiate this tool from siblings like cassette_run_job or cassette_job_status.

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 two usage contexts: classifying a question and resuming an interrupted job with a validated job_id and response. However, it provides no explicit guidance on when to choose this tool over alternatives such as cassette_run_job or cassette_job_status. There are no exclusion criteria or conditional instructions beyond the vague phrase 'using question mode.'

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

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

No annotations are provided, so the description carries the full behavioral burden. It adds some useful nuance with 'cooperative' and 'persisted', but it does not disclose side effects, whether cancellation is guaranteed or reversible, auth requirements, or failure 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?

A single front-loaded sentence with no filler. Every qualifier ('request', 'cooperative', 'persisted') adds meaningful context, making this an appropriately concise and structured description.

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

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

For a one-parameter tool with an output schema, the description is close to sufficient. But with no annotations and no lifecycle context, an agent is left uncertain about when cancellation applies, whether completed jobs can be cancelled, and what 'cooperative' means in practice.

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

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

Schema description coverage is 0% and the only parameter has just a title. The description does not explicitly explain that job_id is the identifier of the target job, where to get it, or its expected format, so it fails to compensate for the schema's lack of detail.

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

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

States a specific action ('request cooperative cancellation') and a specific resource ('persisted Cassette job'). No sibling tool serves the same cancellation purpose, so it is clearly distinguishable from run_job and job_status.

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 cancellation verb and the qualifier 'persisted' suggests the job must already exist. However, the description does not explicitly say when to use it, when not to use it, or how it relates to other job-lifecycle 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?

With no annotations provided, the description carries the full burden and handles it well: it discloses session-scoped persistence, effect timing (applies from the next run_job turn), the default (GPT-5.6 Luna with xhigh thinking), and the read-versus-write dual mode. Minor gaps remain, such as behavior on invalid model ids or partial-change semantics, but the operational behavior an agent needs to predict side effects 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?

Five sentences, roughly 70 words, with the trigger condition front-loaded in the second sentence and every sentence carrying load: purpose, when, how, persistence, default. There is no filler, no repetition of schema fields, and no wasted 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?

For a moderate-complexity config tool with an output schema, the description covers all operational essentials: trigger, both modes, parameter meaning, persistence, timing, and the default. The presence of an output schema covers return-value details, so nothing critical is missing for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate, and it clarifies each parameter: session_id alone triggers view mode, model accepts 'id or label' (a format not present in the schema), and thinking_level is a changeable option with its enum values left to the schema. It adds mode-distinction semantics that the bare property names do not convey, though it stops short of giving concrete examples.

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?

Opens with a specific verb+resource framing ('On-demand model picker for the session') and narrows the scope with an explicit trigger: 'Call only when the user asks to view or change the Cassette model.' It distinguishes itself from execution siblings like cassette_run_job by describing the dual view/change behavior on the model configuration.

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 invoke — 'Call only when the user asks to view or change the Cassette model' — and further branches by mode: with only session_id (view), or with model/thinking_level (change). It also gives timing context by noting the change 'applies from the next cassette_run_job turn,' connecting the tool to its execution sibling. No inference is required to select this tool.

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

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

With no annotations, the description carries the behavioral disclosure burden. It reveals that the tool is a direct, no-LLM command-lane edit, requires a specific environment flag, expects a specific input envelope, relies on expected_version, and describes how undo rewinds shared history. This is strong disclosure, though it does not detail all side effects or failure conditions.

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

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

Three dense sentences deliver purpose, usage boundaries, prerequisites, input shape, versioning, and undo behavior without repetition. The most important trait ('Surgical no-LLM timeline edit') is front-loaded, and every clause adds signal.

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 and the tool is moderately complex, the description covers the critical call pattern, prerequisite, workflow order, and differentiation from cassette_run_job. The main remaining gap is undocumented session_id semantics and the full set of tool_name values, but an agent can still invoke the tool correctly with what is provided.

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 usefully explains that input is always a payload wrapper, that expected_version comes from the last timeline read, and that tool_name 'undo' pairs with input.cursorSequence. However, it does not explain session_id semantics or enumerate the other valid tool_name values, leaving part of the parameter surface 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 a specific verb and resource: 'Surgical no-LLM timeline edit through the manual-editor command lane.' It names concrete operations (trim, text, delete, undo) and explicitly contrasts itself with cassette_run_job. An agent can immediately tell what this tool does and how it differs 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?

The description gives explicit when-to-use guidance: 'Use for small named changes... after reading cassette_timeline' and 'big or creative briefs go through cassette_run_job.' It also flags the required environmental prerequisite CASSETTE_DIRECT_EDIT=1, leaving little ambiguity about when this tool should be selected.

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

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

With no annotations, the description carries the full burden. It does disclose a useful behavior: 'Generates a cryptographically random session_id when omitted,' and restricts input to trusted local media. However, it does not mention side effects, whether the original file is moved/copied, authentication needs, or the response format.

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

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

Two sentences with no filler. The main purpose is front-loaded, and the session_id generation note is a concise, valuable addition. Every word earns its place.

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

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

Given the tool's complexity (11 params, no schema descriptions, no annotations), the description is too sparse. It does not clarify the meaning of optional metadata fields, the expected format of source_path, or the output behavior (although an output schema exists). An agent would likely need to guess at most parameters.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It only explains session_id (generated when omitted) and leaves the other 10 parameters, including required source_path, completely unexplained. This is insufficient for an 11-parameter tool.

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

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

The description clearly states the action ('Ingest'), the resource ('a trusted local media file'), and the source constraints ('active host project or an explicitly configured media root'). This is specific enough to distinguish it from sibling tools like cassette_list_assets or cassette_timeline.

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 implies when to use it (when you have a local media file from an allowed root) but provides no explicit guidance on when not to use it or which sibling tool would be a better alternative. The source restriction is useful context, but alternatives are not mentioned.

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

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

With no annotations, the description carries the full burden and handles it well. It discloses that the tool stores data privately, that matching is read-only, that the Client ID appears in the transcript, that validation failure preserves existing configuration, and that the agent must not fabricate credentials. This is strong behavioral disclosure.

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

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

The description is front-loaded with the core action and purpose, then adds necessary user-interaction and safety instructions. Every sentence adds meaningful guidance, and it remains compact for the amount of safety-critical context it conveys.

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

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

For a simple one-parameter setup tool with an output schema present, the description covers the essential interaction script, privacy concern, failure behavior, and security constraints. Nothing critical is missing for an agent to invoke it correctly.

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

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

Schema coverage is 0%, so the description must compensate. It does: the lone parameter client_id is explained as the user's own Jamendo Client ID, no Secret is involved, and the tool must ask for it rather than invent one. This gives the agent everything needed to handle the parameter correctly.

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

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

The description clearly states the action: validate and privately store this machine's Jamendo Client ID for read-only music matching. It names a specific resource (Client ID), a specific verb (validate/store), and its purpose, which differentiates it from matching or ingestion 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 description provides explicit step-by-step guidance: explain the read-only application requirements, warn about transcript exposure, ask for the Client ID, and never invent or request a Client Secret. It does not explicitly name alternative tools or state when not to use this tool, but the setup context is clear.

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

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

With no annotations provided, the description carries the full disclosure burden and does it well: it reveals that this is a re-attachment mechanism rather than a fresh poll, that calling it once is enough, and that wait_for_change_sec can block up to 30 seconds for a phase transition. The safety profile is unstated, but the core behavior an agent must know before invoking 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?

Three sentences with zero filler. The first sentence front-loads purpose and trigger conditions, the second delivers the usage directive and the important non-loop warning, and the third clarifies the wait parameter. Each sentence earns its place.

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

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

For a status/attach tool with an output schema and 4 optional parameters, the description covers the essential decision points: when to use it, what to do after the call ('act on the phase'), and the wait cap. Minor gaps remain (limit, session_id semantics), but nothing that would prevent a correct first invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explicitly explains wait_for_change_sec (adds the 30-second cap, which the schema lacks) and implicitly ties job_id to the re-attachment scenario. However, limit and session_id receive no semantic guidance, leaving two of four parameters under-explained.

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

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

The description states a specific verb and resource: 'Re-attach to a job' whose cassette_run_job did not return. It enumerates the exact triggering scenarios (host restart, cancellation, wait=false) and explicitly disambiguates itself from a progress loop, so an agent can clearly distinguish this from siblings like cassette_run_job and cassette_cancel_job.

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

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

The description gives a clear when-to-use condition ('whose cassette_run_job call did not return') and a strong when-not signal ('it is not a progress loop'), plus a call-once directive. It stops short of naming a specific alternative tool for progress polling, so the exclusion is implicit rather than explicit, but the context is unambiguous.

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

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

With no annotations, the description carries the behavioral disclosure burden. It adds one useful behavioral trait: the returned assets are scoped to a single session. However, it does not explain required inputs, whether both session_id and chat_id are needed, or any pagination/filtering 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?

One direct sentence with no filler. The primary action and resource are front-loaded, and the scoping detail follows immediately. Every word earns its place.

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

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

Although an output schema exists and the tool is conceptually simple, the lack of parameter guidance makes it incomplete. An agent cannot reliably know whether to supply session_id, chat_id, or both, especially with no required parameters and zero schema descriptions.

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 the undocumented chat_id and session_id parameters. It mentions 'one Cassette session' but never clarifies which parameter identifies that session or what chat_id means in relation to it.

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

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

The description states a specific action ('List'), a concrete resource ('media assets'), and a clear scope ('isolated to one Cassette session'). This distinguishes it from sibling tools like cassette_ingest_media or cassette_timeline, so an agent can identify its function.

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 'isolated to one Cassette session' implies this tool is for retrieving assets within a session, which gives some usage context. However, it does not explicitly state when to prefer this over alternatives, nor does it mention any conditions 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?

With no annotations provided, the description fully carries the behavioral disclosure burden. It clearly discloses the side effect of password replacement across all machines, the need for user confirmation, and the crucial safety property that credentials are verified before any write occurs, leaving an existing working setup untouched. This is strong behavioral transparency.

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

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

The description is concise yet information-dense; each sentence earns its place. It front-loads the primary action, then covers the alternative flow, the critical constraint about server-generated passwords, and the safety guarantee. There is no fluff or repetition.

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

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

For a login tool with no annotations, an output schema available, and four parameters, the description provides complete context: when to call it, what parameters to use, what side effects occur, and what safety behavior to expect. Nothing essential is missing for an agent to invoke it correctly.

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

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

Schema description coverage is 0%, but the description compensates exceptionally well. It explains that email plus the server-generated password is the normal path, that password is never user-chosen, and that request_new_password and confirm_replace must be passed together to replace the password. This makes all four parameters and their interrelationships clear.

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 core purpose: signing the current machine in to Cassette, with an explicit alternative for password replacement. It names the specific verb and resource, and it is unmistakably distinct from sibling tools like cassette_ingest_media or cassette_run_job, so an agent can easily tell when this is the login 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?

The description gives explicit and detailed usage instructions, including the requirement to ask the user for their server-generated password, never invent one, and the exact condition for requesting a replacement password with both request_new_password=true and confirm_replace=true. It does not explicitly compare against sibling tools, but no sibling appears to handle authentication, so this is a minor gap.

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

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

With no annotations supplied, the description carries the full burden of behavioral disclosure. It does not state whether the tool is read-only, whether it modifies session assets, what it does if assets are missing, or what 'session assets' means in practice.

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

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

The description is a single efficient sentence with the main action front-loaded and no filler. It is concise, but the brevity leaves the substance to be covered by other dimensions.

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

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

For a complex 10-parameter tool with no annotations and zero schema description coverage, one high-level sentence is not enough. The presence of an output schema helps with return values but not with parameter roles, selection guidance, or behavioral 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%, so the description should compensate for the 10 parameters, but it only names 'instruction' and 'session assets.' It does not add meaning to style, duration, constraints, output_format, requires_assets, or the cassette_language options.

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

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

The description states a specific action ('Build') and a clear object ('a complete Cassette edit prompt') plus the source inputs. It conveys what the tool does, though it does not explicitly compare it with siblings like cassette_edit or cassette_timeline.

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

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

No guidance is provided on when to choose this tool over direct alternatives such as cassette_edit, nor are prerequisites or exclusions mentioned. Usage must be inferred from the word 'prompt,' which is insufficient for a 15-tool family.

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

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

With no annotations, the description must carry the behavioral disclosure burden. It reveals that registration is optional, but does not explain side effects, whether the session is modified, what 'register' means, or any prerequisites or failure behaviors. The schema hints at fallback and optimization flows, which the description ignores.

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 with no filler or redundancy. Every phrase adds meaning and it is easy to parse quickly, even if more content is needed elsewhere.

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

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

For a tool with seven parameters, no annotations, and no schema descriptions, this one-line description is far too sparse. The tool's fallback, continuation, and optimization behaviors are completely unexplained, and the relationship to sibling matchers is missing.

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

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

Schema description coverage is 0%, yet the description offers no explanation of the seven parameters, including required ones like instruction and search_queries. The agent gets no help understanding how these values shape the matching or registration behavior.

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 ('Match') and resource ('Free To Use background-music asset'), and adds the 'optionally register' nuance. It reads as a clear purpose, though it does not explicitly contrast with the similarly named sibling cassette_match_exact_bgm.

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 states what the tool does but gives no guidance on when to use it versus alternatives like cassette_match_exact_bgm or jamendo_music_matcher. There is no mention of when-not scenarios, fallback conditions, or when registration should be enabled.

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

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

With no annotations, the description carries the behavioral burden. It does disclose two important behaviors: downloading is optional, and the match is registered with the session, signaling a side effect. But it does not address failure behavior, permissions, overwriting behavior, or what happens when download is disabled.

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 with no filler. Every clause adds meaningful information: the exact match, optional download, and session registration. It is easy to parse and appropriately sized for a high-level purpose statement.

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 10 parameters, no annotations, and no schema descriptions, the description must anchor correct invocation, but it omits key context: what instruction is for, what 'exact' means in matching behavior, what continue_after_match and optimization_enabled do, and what happens on no match. The output schema does not compensate for these invocation 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 description coverage is 0%, and the description only loosely maps to 'song and artist', 'download', and 'session'. It says nothing about the required instruction parameter, continue_after_match, optimization_enabled, singer, songTitle/song_title, or how title/artist are interpreted. For a 10-parameter tool, this is insufficient 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 states a specific action: matching an exact song and artist, with optional download and session registration. The word 'exact' helps differentiate it from the sibling cassette_match_bgm, but the sibling is not named and the differentiation is implicit rather than explicit.

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

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

The phrase 'exact song and artist' implies this tool is for cases where a precise track is known, as opposed to cassette_match_bgm. However, there is no explicit statement of when to use it versus alternatives, no exclusions, and no guidance for ambiguous or failed matches. Usage context is implied but not stated.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It usefully reveals that rendering only starts for decision=export and that this should be called as an immediate follow-up. However, it does not explain what happens for continue, needs_user, or failed decisions, nor whether the tool mutates job state in a way that requires caution.

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 dense sentences with important information front-loaded: the decision condition appears first, then the specific usage scenario. Some wording is repetitive ('explicit... export' appears twice), but overall it is efficient and focused.

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

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

The tool is moderately complex with four parameters, an enum, and no annotation support. The description covers the main export trigger well and tells the agent exactly when to act, but it omits the meaning of the other enum decisions, the role of reason and summary, and how this tool relates to the surrounding cassette job lifecycle tools.

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 parameter meaning. It explains the decision=export value and ties it to rendering, but it does not clarify job_id, reason, or summary semantics. The agent is left to guess what reason text is expected and whether summary is required for certain decisions.

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 action ('Resolve a review-required completion') and specifies the key behavior: rendering starts only with an explicit, validated decision=export. It is more specific than a tautology, though 'review-required completion' is not fully defined and the agent must infer the exact resource from context.

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

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

The description gives a concrete trigger condition: cassette_run_job(export=true) triggered by the user's explicit export request, and instructs the agent to call this tool immediately in the same turn. It also explicitly warns against re-asking the user for authorization. However, it does not describe when to prefer sibling tools such as cassette_job_status or cassette_cancel_job for other outcomes.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains that the call blocks by acting as the wait, streams progress, returns terminal envelopes, and can be detached via wait=false. It also discloses the review_required branch and the required follow-up action, though it does not describe side effects, authentication, or asset mutation.

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 long but information-dense, with the core purpose and blocking behavior front-loaded. Nearly every sentence adds operational value, though some repetition exists around not starting additional runs and not asking for redundant confirmation.

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 operational flow is thoroughly explained for the main user-turn lifecycle, and an output schema exists so return-value documentation is not required. However, with no annotations and 17 undocumented parameters, the description is not fully complete for all calling scenarios, especially around the many model, session, and instruction-related parameters.

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

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

Schema description coverage is 0% across 17 parameters, yet the description only meaningfully explains message, wait, and export-related behavior. Most parameters, including instruction, prompt, chat_message, cassette_message, selectors, session_id, and cassette_model, are left entirely unexplained, which is a large gap for a zero-coverage schema.

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

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

The description states a specific verb and resource: it runs one Cassette edit turn and returns when the result is settled. It also differentiates itself from siblings by naming cassette_job_status and cassette_review_completion, and clearly defines the tool as the waiting call itself.

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 unusually explicit usage rules: exactly one call per user turn, never start follow-up runs, do not poll job_status after a settled result, and use wait=false only to detach into the background. It also names the alternative tool for resuming interrupted jobs and the review completion tool for review_required results.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool is a live read, that contact_sheet=true performs zero-render tiling and saves a local file, and that the returned URI must be URL-encoded because raw paths may contain spaces. This is strong, useful transparency, though it does not cover authentication or error 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?

Every sentence carries meaningful guidance: what the tool reads, when to use it, what contact_sheet does, and exactly how to format the output in Hermes TUI. Despite covering multiple instructions, the description stays compact and front-loads the core 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?

The description is strong for usage and output formatting, and an output schema exists to cover return values. However, for a tool with four parameters and zero schema descriptions, leaving detail and profile undefined is a meaningful gap. The agent can still call the tool with only the required session_id, but full contextual understanding is incomplete.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It does explain contact_sheet's effect well, but it says nothing about detail or profile, and session_id is only implicitly understood from the tool's purpose. The description does not give enough semantic context for the full parameter set.

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

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

The description opens with a specific verb and resource: 'Read the live Cassette timeline as a bounded text digest (CTL).' This clearly differentiates the tool from siblings like cassette_ingest_media or cassette_edit, and the term 'live' plus 'bounded text digest' gives a precise picture of what the tool returns.

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

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

The description gives an explicit usage rule: 'Call this before any statement about project state — never answer from memory.' It also explains when the contact_sheet option matters and how to present the resulting URI. It does not mention alternatives or exclusions, so it stops short of a perfect 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that a result may be 'registered', implying a potential side effect, but it does not explain what registration means, whether files are downloaded (despite download defaulting to true), or what side effects occur beyond search. This is minimal and potentially misleading for a tool with mutable 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 short but not effectively concise; it omits essential context and uses unclear phrasing. The single sentence does not earn its place because it introduces ambiguity ('validated fixed-form', 'optionally register') instead of clarifying the tool's behavior.

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 19 parameters, no annotations, an output schema, and sibling tools, the description is severely incomplete. It does not address parameter semantics, side effects, prerequisites, or selection criteria, making it inadequate for an agent to confidently invoke this 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%, and the description adds no meaning to any of the 19 parameters. It does not explain the required userQuery and searchTerms, the purpose of the many alias parameters, or how the various optional settings behave. The agent must infer everything from parameter names alone, which is insufficient for a complex tool.

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

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

The description identifies the primary action ('Search Jamendo') and a secondary side effect ('optionally register a result'), so an agent can tell it is a Jamendo search tool. However, the phrase 'validated fixed-form music preferences' is jargon-heavy and does not clarify what inputs constitute those preferences, and it does not meaningfully distinguish the tool from Jamendo-related siblings like cassette_jamendo_setup.

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

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

The description gives no guidance on when to use this tool versus the sibling tools, such as cassette_match_bgm or cassette_jamendo_setup. There are no context cues, prerequisites, or exclusions, leaving the agent to guess whether this tool is the right choice for a given music-matching task.

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