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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a behavioral constraint: pitch detection only works on monophonic renders, which is non-obvious and critical for correct invocation. It also clarifies the output scope without contradicting the annotations.

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

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

Two sentences with no redundancy. The primary purpose (report metrics) is front-loaded, and the critical caveat about monophonic rendering is placed in the second sentence. Every phrase adds value, making it appropriately concise and well-structured.

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

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

The tool has 7 parameters and no output schema, which places a heavy burden on the description to explain return structure and parameter semantics. It only covers the main output types and a single constraint, leaving most parameter behavior unexplained. An agent would struggle to correctly set maxFrequency, minFrequency, windowSeconds, or channel without additional context. The description is too thin for the tool's complexity.

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

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

Schema description coverage is only 14% – only 'path' has a description, leaving channel, detectPitch, maxSegments, maxFrequency, minFrequency, and windowSeconds undocumented in the schema. The description fails to compensate: it only mentions that pitch detection is optional and mentions monophonic requirements, but provides no meaning for the other parameters. This is a major gap for an agent trying to set frequency bounds or segmentation 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 states a specific verb ('Report') and resource ('WAV file'), enumerating the outputs (duration, peak/RMS level, silence) and the optional pitch detection. It clearly distinguishes from sibling analysis tools like summarize_fms or compute_ticks by focusing on WAV audio analysis, and even references export_audio as a related but different 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 provides explicit guidance for the pitch detection option: it expects a monophonic render and gives a concrete example of how to produce one using export_audio with separateChannels. This helps the agent decide when to enable detectPitch. It does not fully contrast with all sibling tools, but the context is sufficient for a read-only analysis tool.

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

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

Annotations already establish idempotent and non-destructive behavior, so the bar is lower. The description adds genuinely useful behavioral details beyond annotations: automatic filling of object ids, envelope masks and 256-slot pattern tables, plus the important pitch-offset gotcha about FamiStudio note names being one octave above standard pitch. This is valuable extra context with 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 information-dense and well-structured: a concise summary paragraph, two compact JSON examples, and a crucial octave-offset warning. Every sentence contributes something necessary, with 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 very large nested schema and no output schema, the description covers the core knowledge an agent needs: what the input looks like, how the two note formats behave, what gets auto-filled, and how the returned object can be used downstream. It does not describe every optional field or error scenario, but those are partly represented in the schema and annotations, making this reasonably 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?

With only 50% schema description coverage, the description compensates well by giving concrete absolute and grid examples, explaining the sustain behavior in grid form, and clarifying that outputPath is for writing a .fms file. The schema mostly lists types, so this interpretive guidance is necessary and useful. It does not enumerate every nested field, but the schema already provides structural detail for those.

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+object: 'Compile a compact JSON song specification ... into a complete FamiStudio project object', and clearly mentions the optional .fms output. It also distinguishes itself from sibling tools by stating the returned project can be passed directly to export_audio / verify_roundtrip / validate_fms, giving it a clear identity.

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 makes the use case explicit: when you have a compact JSON spec and want a FamiStudio project object or .fms file, use this tool. It also names downstream consumers of the result, which helps an agent plan a pipeline. However, it does not explicitly contrast with create_fms or state when not to use it, so it stops 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?

Beyond the read-only and idempotent annotations, the description reveals the exact conversion formula, the 'uniform groove' assumption, and NTSC/PAL frame rates. It does not describe the return shape or behavior with conflicting parameters, but the annotations already cover the safety profile.

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-loads the core formula before giving use cases. There is little redundancy, though the dense FamiStudio-specific phrasing could be clearer for unfamiliar agents.

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 provides the essential conversion formula and primary use cases, but leaves meaningful gaps: semantics of noteLength/patternLength, return value details, and behavior when no or multiple conversion inputs are supplied. It is adequate for the main path but not fully self-sufficient.

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

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

Schema description coverage is 0%, and the description only clarifies the ticks/seconds relationship and NTSC/PAL values. It does not explain how pal, ticks, seconds, noteLength, or patternLength map to the computation; noteLength and patternLength are especially underspecified.

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

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

The description clearly identifies the operation: converting between seconds and ticks, and even provides the governing formula and frame rates. It does not explicitly distinguish this tool from siblings, but no sibling appears to offer the same arithmetic conversion.

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 concrete use cases: turning a target duration into a tick count for a spec, and checking how long a pattern budget lasts. It does not state exclusions or alternatives, but the provided guidance is sufficient for common selection.

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 signal this is a non-read-only, non-destructive, idempotent operation. The description adds useful behavioral context by stating it always writes a .fms file and returns a path plus structural summary. It does not explain overwrite behavior, but the idempotent hint and 'always writes' phrasing cover the essential side effect.

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 wasted words. The core behavior and return value are stated first, followed by a clear use case. Every sentence contributes useful information.

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

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

For a two-parameter wrapper, the description gives the key facts: it writes a file, returns its path, and returns a structural summary. Since there is no output schema, mentioning the return value is especially valuable. Minor details like overwrite behavior or summary contents are absent but not critical for invocation.

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

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

Schema description coverage is 100%, so the schema already documents the spec object and outputPath thoroughly. The description adds no new parameter-level meaning beyond the title's reference to a 'song spec.' This is the appropriate baseline given the schema's completeness.

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 operation: a convenience wrapper around compile_song_spec that writes a .fms file and returns its path plus a structural summary. It distinguishes itself from the sibling compile_song_spec by emphasizing the file-writing behavior.

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 usage guidance: 'Use this when the goal is a file on disk.' It also names the alternative compile_song_spec, which helps an agent distinguish the two. It stops short of explicitly stating when not to use it, but the conditional framing makes the intended use clear.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior, and the description adds meaningful behavioral context: it performs a structural diff, accepts files or inline objects, and reports differences across metadata, instruments, and note content. No contradictions.

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

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

Two tight sentences with no filler; the primary action and the intended use case are front-loaded.

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

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

The read-only safety profile and intended use case are clear, and listing the diff categories covers the return behavior enough for many calls. However, with 0% schema coverage and no output schema, the absent parameter relationship guidance makes the definition incomplete for confident 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 coverage is 0%, so the description must clarify the four parameters. It says projects can be 'files or inline objects', which hints at projectA/projectB vs projectPathA/projectPathB, but it never maps parameters to their roles or explains how object and path arguments relate, leaving a caller to guess.

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, 'Structurally compare two FamiStudio projects', and narrows the scope to 'metadata, instruments and per-note content'. This clearly separates it from the sibling tools, none of which are described as a two-project diff.

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 gives an explicit use case: 'Use it to confirm that a rewrite did not change the musical content.' It does not name alternatives or state when not to use it, 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?

Annotations already mark the tool as idempotent and non-destructive; the description adds useful behavioral context by naming the external dependency and summarizing the return payload (artifact path, duration, peak level, audibility check for WAV). 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?

Three sentences with no filler: purpose first, then prerequisite, then return summary. Every sentence earns its place and the most important scoping information is front-loaded.

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

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

For a 10-parameter tool with 10% schema coverage and no output schema, the description is too thin. It does not clarify parameter relationships, defaults, or how to specify the project, leaving an agent to guess at 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 only 10%, so the description must compensate, but it does not explain most of the 10 parameters such as rate, songs, loopCount, channelMask, project vs projectPath, durationSeconds, or separateChannels. It only hints at formats via the title and WAV-specific return info.

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 ('Render') and resource ('FamiStudio project') and clearly identifies the output as an audio file, matching the title's WAV/MP3/OGG scope. It is easily distinguished from siblings like export_text or create_fms.

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 gives an actionable prerequisite: FamiStudio 4.5.x must be installed, and it tells the agent to call famistudio_info first if unsure. It does not explicitly contrast with alternatives such as run_famistudio or analyze_audio, so it stops short of full when/when-not 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 indicate idempotent and non-destructive behavior, which the description does not contradict. The description adds the fact that it returns a preview of the produced file, which is valuable behavioral context. However, it does not disclose whether the tool writes to the filesystem beyond the preview, or what happens on failure. Given annotations carry part of the burden, 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 reasonably compact given the range of exporters listed. The most important info (what it does, preview return) is front-loaded. It could be slightly streamlined, but it avoids unnecessary fluff.

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 8 parameters, no output schema, and only 13% schema coverage, the description does not adequately compensate. It leaves most parameters unexplained, does not describe the return structure beyond 'preview', and offers no guidance on parameter combinations or required dependencies. For a tool of this complexity, the description 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 only 13% (only outputPath described). The description lists the possible command values but does not explain any of the other seven parameters (songs, cleanup, maxBytes, asmFormat, project, projectPath). It also does not clarify how the command parameter maps to the listed exporters or how outputPath is used. The description adds almost no value to the schema's sparse information.

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 (convert/export), a resource (project), and the target formats (text or assembly). It lists concrete exporter commands, making its function unmistakable and distinguishing it from sibling tools like export_audio. The mention of 'verification and reading note data' adds context that further clarifies its niche.

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 partial guidance by noting that FamiStudio text is 'excellent for verification and for reading note data', which hints at a use case. However, it does not explicitly state when to choose this tool over siblings (e.g., export_audio) or when not to use it. There is no mention of alternative tools or exclusion criteria.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about what information is gathered (probed paths, available commands, allowed directories) but does not disclose additional behavioral traits beyond that.

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

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

Two tight sentences cover the full purpose: the first reports executable findings, the second lists server capabilities. There is no repetition, filler, or unnecessary wording.

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

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

With no parameters and a straightforward read-only purpose, the description is fully complete. It enumerates every category of output the agent should expect: executable status, version, probed paths, CLI export commands, and allowed directories.

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

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

The tool has zero parameters and schema coverage is 100%, so no parameter documentation is needed. The description adds no parameter semantics, but the baseline of 4 is appropriate for a parameterless tool.

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

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

The description names a specific verb ('Report') and resource ('FamiStudio executable'), then enumerates the exact items covered: found status, version, probed paths, available CLI export commands, and allowed read/write directories. This clearly distinguishes it from sibling tools like run_famistudio or export_audio, which perform actions rather than report environment state.

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

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

The description implies this is an environment-discovery tool: it reports executable presence, version, probed paths, export commands, and allowed directories. However, it never explicitly states when to use it or when to prefer alternatives, and it does not name any sibling tools or exclusion conditions.

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

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

Annotations already convey readOnly, idempotent, and non-destructive. The description adds a critical behavioral restriction: version 19 only, with failure/re-save implications for older files. It also explains the structural-overview mode via includeNotes. This goes beyond the annotation baseline.

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

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

Two tight sentences: the first front-loads the purpose and the content of the output, the second gives a parameter tip and a version constraint. Every sentence adds new information and there is no filler.

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

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

For a read-only tool with no output schema, the description covers the primary output content, the only optional parameter's behavior, and the version limitation. It does not mention error handling or default values, but given the simple 2-parameter surface and strong annotation coverage, it is sufficiently complete for correct invocation.

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

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

Schema description coverage is 50% (path only). The description compensates for the undocumented includeNotes parameter by explaining its effect: setting it to false yields a structural overview for large projects. It also clarifies that the tool returns structured JSON content, which gives meaning to both parameters in 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 clearly states the verb ('Decode') and resource ('.fms file') and enumerates the output content (songs, channels, patterns, notes, instrument envelopes). It is specific enough to distinguish the tool from create_fms or export_audio, but it does not name any sibling tool explicitly, so it misses the top tier for differentiation.

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

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

The description gives explicit guidance about when to set includeNotes=false for large projects and places a hard constraint: only version 19 files (FamiStudio 4.5.x) can be read, with a clear instruction that older files must be re-saved. This is useful context, though it does not explicitly compare against alternatives like summarize_fms or famistudio_info.

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, destructiveHint=false, and idempotentHint=true. The description adds valuable context by specifying the exact command pattern and emphasizing 'no shell involved,' which is a meaningful security/safety disclosure. It also signals arbitrary-command capability via 'escape hatch,' while not contradicting any annotation.

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

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

Two sentences with zero filler. The purpose is front-loaded, the command syntax is compact and unambiguous, and the alternative-routing note is appended. Every sentence earns its place.

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

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

For a generic escape-hatch tool with 5 params and no output schema, the description covers the essential aspects: purpose, command shape, safety (no shell), and alternative selection. It does not explain return values or error behavior, but these are secondary for a wrapper tool and the annotations already cover safety profile. Minor omission is timeout semantics, but the parameter name is self-explanatory.

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 60% (extraArgs and timeoutMs lack descriptions in the schema). The description compensates for extraArgs by embedding it in the command pattern '[extraArgs...]', and clarifies how input/command/output map to the CLI. However, timeoutMs remains completely undocumented in both schema and description, and command examples are only in the schema—so the description only partially bridges the 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 identifies the tool as an 'escape hatch' for FamiStudio commands not wrapped by the server, naming specific examples (NSF export, ROM export, assembly export with exotic options). It also distinguishes from siblings by noting when wrappers like export_audio / export_text are preferred, so an agent can immediately tell this is the generic fallback.

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 the condition for use: commands this server does not wrap. It also provides a direct alternative directive: 'Prefer export_audio / export_text when they fit,' giving an agent clear routing guidance. This is the strongest form of usage guidance—specific when-to-use and when-not-to-use.

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, idempotentHint, and destructiveHint, so the description need not repeat safety. It adds value by specifying the output contents (pattern order, note dumps, tick totals, duration), which goes beyond the annotations. No contradiction with annotations.

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

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

Two sentences with no filler. The first sentence front-loads the core output, and the second gives a concise usage directive. 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?

The tool has no output schema and three undocumented parameters, and the description does not explain the listing format, the effect of maxPatternsPerChannel, or how project vs projectPath are used. For a summarizer with potentially complex output, this 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 by explaining the three parameters (project, projectPath, maxPatternsPerChannel). It does not mention any of them, leaving their meaning and effect entirely undocumented. This is a critical 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 states a specific verb ('Return') and resource ('a readable listing of a project'), and details the content: every song with pattern order, per-pattern note dumps, tick totals, and rendered duration. It also frames the purpose ('review what a .fms actually contains'), which clearly distinguishes it from siblings like read_fms (likely raw dump) and validate_fms (validation).

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

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

The description provides a clear usage context: 'Use this to review what a .fms actually contains.' This tells the agent when to invoke it, but it does not explicitly state when not to use it or name alternatives. It lacks exclusions, 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is established. The description adds value by detailing exactly which invariants are verified and stating that the tool returns a list of problems, which conveys useful behavioral expectations 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 dense but well-structured: it leads with the core action, lists concrete invariants, and ends with the return type. Every clause carries useful information without repetition or padding.

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 thoroughly explains what is validated, but it omits essential invocation guidance for the two ambiguous parameters. With no output schema and no parameter documentation, an agent cannot confidently construct a correct call using only this 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 description coverage is 0%, and the description provides no explanation of the two parameters (`project` and `projectPath`). It does not clarify whether both can be supplied, which is preferred, or how the object form differs from the path form, making correct invocation ambiguous.

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 every invariant FamiStudio relies on when loading a project, and enumerates specific checks like four-envelope masks, unique object ids, and pattern table sizes. This makes the resource and action much more specific than the title alone and distinguishes it from sibling validation/export/read tools.

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

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

The description gives clear context: use this when you need to ensure a project satisfies FamiStudio's loading invariants. It does not explicitly exclude alternatives or mention when not to use it, but the context is clear enough that an agent can infer appropriate usage among the sibling tools.

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

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

Annotations already provide idempotentHint=true and destructiveHint=false, so the description doesn't need to repeat those. It adds context about the internal steps (re-export, render WAV) and the reporting behavior, which is useful beyond the annotations. But it doesn't disclose side effects like temporary file creation or whether the project is modified, so it only partially fills the behavioral gap.

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

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

Two sentences, front-loaded with the primary purpose and a usage cue. Every word earns its place, with no fluff or repetition. The structure is efficient 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 six parameters, no output schema, and zero parameter descriptions, the description is far from complete. It omits all parameter semantics, the return format, and the meaning of 'expected length'. An agent would have to guess or look elsewhere to call this tool correctly. This is a serious deficiency for a 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 description coverage is 0%, and the description mentions none of the six parameters (project, workDir, projectPath, renderAudio, durationSeconds, expectDurationSeconds). An agent cannot infer what these mean or how to set them from the description, which is a severe gap given the absence of any schema-level documentation.

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

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

The description states a specific, high-level purpose: an end-to-end validity check that re-exports to FamiStudio text, renders a WAV, and reports on clean loading and expected audio length. This clearly distinguishes it from simpler siblings like export_text or export_audio, and the instruction 'Run this after generating a .fms file' ties it to a concrete workflow.

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

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

It gives a clear temporal cue ('Run this after generating a .fms file') that tells the agent when to invoke it. However, it does not explicitly list alternative tools or when not to use it, leaving some ambiguity relative to siblings like validate_fms or diff_fms. The usage context is clear but lacks explicit exclusion guidance.

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