FableCut

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

With no annotations, the description carries full behavioral disclosure burden. It explains that the path is copied into media automatically, threshold has adaptive defaults, and registerMusic extracts and registers the music track on A1. No contradictions or hidden side effects are apparent.

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 moderately long but well-structured: purpose first, then outputs, then recipe, then cross-reference. Each sentence adds value, but minor redundancy (e.g., 'Remake recipe' repeats some info). Still efficient for the amount of detail.

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

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

Despite no output schema, the description thoroughly explains the return values (shot boundaries, per-shot audio energy, beats, BPM, loudness curve, drop, extracted music) and provides a complete recipe for using the blueprint. It also references documentation for further details. No gaps identified.

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

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

Schema coverage is 100%, and the description adds value: for 'path' it clarifies absolute vs. media/ src; for 'threshold' it explains adaptive default values (0.30→0.20→0.12) and tuning guidance; for 'registerMusic' it describes extraction and registration. This enhances understanding beyond the schema.

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

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

The description clearly states the tool analyzes a reference video into an EDIT BLUEPRINT for rebuilding with different footage over same music. It lists specific outputs (shot boundaries, per-shot audio energy, beats, BPM, loudness curve, drop, extracted music) and distinguishes from siblings via cross-reference to documentation.

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

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

The description explicitly says when to use (analyze reference for remake) and provides a step-by-step remake recipe. It does not explicitly state when not to use, but the context and sibling tool names imply its specific role. Cross-reference to docs enhances 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?

With no annotations, the description carries the full burden and does so richly: it is a mutation (writes keyframes), it multiplies clip volume so level/keyframes/fades are untouched, re-running replaces previous dips, linked stems get the same keys, requires ffmpeg+ffprobe on PATH, and refuses locked clips unless force. These are exactly the side-effect and prerequisite facts an agent needs.

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?

Front-loaded with the core action and free of filler, but very dense with long multi-clause sentences (em dashes, parentheticals) that pack several behaviors into each line. Efficient rather than wasteful, though slightly heavy to parse.

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 7-parameter mutation with no output schema, it covers what the agent needs: side effects, idempotency, dependency requirements, lock/force behavior, stem propagation, and what it writes. Nothing essential for correct invocation 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 coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema — the interpolation/ramp semantics of attack and release, the gap-bridging rationale behind threshold, the defaulting logic of `under` ('every audio track the music isn't on'), and that amount 0 removes ducking.

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

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

States a specific verb and resource ('Duck music under dialogue') plus the exact mechanism (finds voice via RMS threshold, writes duck keyframes in dB on the music clips). It clearly separates this from sibling audio tools like normalize_audio or denoise by naming the ducking/auto-duck pipeline explicitly.

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

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

Explains when this applies (ducking music under voice) and gives operational triggers: raise threshold if room noise triggers ducks, amount 0 clears, force to touch locked clips. It does not explicitly name sibling alternatives to prefer in other situations, so it stops short of full when/when-not routing.

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 and does so well: discloses that it renders a new FLAC into media/, that linked stems switch while the picture file stays (preserving links/timing), that re-runs are idempotent (reuses rendered file), the ffmpeg+ffprobe PATH prerequisite, and locked-clip refusal behavior. These are exactly the side effects an agent must know before invoking.

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?

Dense but front-loaded: purpose first, then mechanism, revert, idempotency, prerequisites, and force. Every sentence earns its place, though the parenthetical about picture files is slightly nested.

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 mutation tool with no annotations and no output schema, the description covers purpose, side effects, file layout, idempotency, prerequisites, and refusal semantics – more than enough 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 coverage is 100% – all three params are documented including the enum, defaults, and semantics of 'off'. The description adds the 'off restores original' behavior and force rationale, but the schema already carries most of this, so baseline 3 is appropriate.

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

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

States a specific verb and resource ('Reduce background noise... on audio clips') and names concrete noise types (hiss, hum, room tone). Distinguishes itself from siblings like fablecut_normalize_audio and fablecut_auto_duck by identifying the exact mechanism (FFT denoiser / Noise control), so an agent can route correctly without opening a schema.

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

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

Explains when to use and what state changes occur, and covers the 'off' revert and force/locked-clip condition. Lacks explicit contrast with sibling audio tools (normalize_audio, auto_duck), which is the only 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?

The description indicates a read-only retrieval operation ('Return the documentation'), but does not explicitly state it has no side effects. Since no annotations are provided, the description carries the full burden; it successfully conveys the non-destructive nature through context.

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 clear sentences plus a token tip. Front-loaded with purpose, no superfluous words. Every sentence earns its place.

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

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

For a simple documentation retrieval tool with one optional parameter, the description covers purpose, usage, and filtering. It could mention what happens if a section is not found, but given the lack of output schema and low complexity, it is adequately complete.

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

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

The description adds significant value beyond the schema: explains the substring match behavior, provides concrete examples (props, Recipes, Remake), and offers a token-saving tip. This fully compensates for the schema's brief parameter description.

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

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

The description clearly states the tool's purpose: 'Return the FableCut project schema documentation'. It lists specific content areas (clips, tracks, props, etc.) and distinguishes itself from sibling tools which handle project data manipulation or analysis.

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 advises 'Read this before editing', indicating when to use this tool (before making edits). The token tip provides optimization guidance. While alternatives are not named, the context signals show siblings operate on projects, not documentation.

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 does so well: it discloses the hot-reload behavior, that profiles are dry-run against ffmpeg at export start so bad args are rejected before rendering, and the default color matrix/range (BT.709 tv). These are non-obvious operational traits an agent could not infer from the schema.

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

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

Four sentences, front-loaded with the core purpose and profile shape before the editing and validation caveats. Slightly dense but every sentence adds distinct information; nothing is wasted.

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

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

No output schema exists, so the description takes on the return-shape burden and does so by describing the per-profile fields. Combined with the hot-reload and dry-run notes, an agent has what it needs to call and interpret the result.

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 'detail' and 'profile' parameters are already documented. The description adds useful context about what a profile contains (raw ffmpeg args, jpegQuality, extension, color), which indirectly explains what 'detail' expands, but does not add syntax or defaults beyond the 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?

Opens with a specific verb+resource ('List ffmpeg encoding profiles') and names the source file and export mode, which no sibling tool touches. An agent can distinguish this from the project/media/status siblings immediately.

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 purpose: 'Use to pick a profile id for project.encodeProfile,' tying it to a downstream field. It also covers extension ('Edit encoding-profiles.json on disk to add custom profiles'), but gives no explicit when-not or alternative-tool routing.

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 does so richly: it discloses the browser execution model (open tab or headless Chrome/Edge), the FABLECUT_CHROME env var, the ffmpeg-on-PATH prerequisite, a one-export-at-a-time constraint, and that timeout leaves the export running. This is well beyond what structured fields provide.

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

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

Front-loaded with the core purpose, then layers execution model, prerequisites, and async controls. It is dense and somewhat long but nearly every sentence carries operational value; a small amount could be tightened without losing 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 7-param, side-effecting render tool with no output schema, the description covers prerequisites, execution venue, concurrency, waiting/polling/cancel semantics, and timeout behavior. Nothing an agent needs to invoke it correctly appears to be 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 100%, so baseline is 3; the description adds marginal meaning by tying {job} to polling ('poll with {job}') and {cancel:job} to stopping a running export, and by restating the range default ('inPoint→outPoint when set, else the whole timeline'). It reinforces rather than fully re-documents the parameters, so it sits just above baseline.

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

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

States a specific verb and resource ('Render the timeline to a video file in exports/') and immediately differentiates it from siblings by noting it uses the editor's own Fast export compositor and encoding profile. An agent can distinguish it from fablecut_encode_profiles and fablecut_status at a glance.

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?

Gives explicit when-to-use guidance: default waits for the file, 'Long edits: pass wait:false, then poll with {job}; {cancel:job} stops one.' Also explains the where modes (auto/tab/headless), making the selection conditions for alternatives concrete rather than inferred.

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 must cover behavioral aspects. It describes the output format options but does not mention error conditions, permissions, side effects, or whether the operation is idempotent (implied read-only). The description is adequate but not thorough.

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

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

The description is two sentences long, front-loaded with the purpose, and the second sentence efficiently delivers a valuable tip. Every sentence serves a purpose with no redundancy.

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

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

Given only one optional parameter and no output schema or annotations, the description covers the main scenario (obtaining the project with optional compact format). However, it omits details like error handling, what the full JSON looks like, or behavior when the project is missing. It is minimally viable but not comprehensive.

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

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

The input schema covers the parameter compact with a basic description. The description adds meaningful context: 'one-line-per-clip summary (ids, tracks, timings, non-default props)' and advises when to use each mode, going beyond what the schema provides.

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

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

The description clearly states the verb 'Get' and resource 'FableCut project (the timeline document)', distinguishing it from sibling tools that patch or set projects. The compact option is also mentioned, adding specificity.

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 token tip provides explicit guidance on when to use compact:true versus full JSON, which helps the agent decide the parameter value. However, it does not compare against sibling tools like fablecut_status or fablecut_analyze_reference, so usage boundaries are not fully delineated.

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 does: it discloses side effects (local files are copied, remote files downloaded into ./media/), a refused input class (remote SVG/CORS-breaking URLs), and the deliberate decision not to retain the URL as the playback src. It also states the return value and how to use it.

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

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

Three tight sentences, front-loaded with what the tool does and then the input rules and return value. Every clause adds actionable information with 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 single-parameter import tool with no output schema, the description covers the operation, input forms, failure modes, side effects (copy/download location), and the shape of the result plus how to use the returned id. Nothing material 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 coverage is 100% so the baseline is 3, but the description adds real semantics beyond the schema: accepted source forms, format restrictions, and the .svg local-vs-remote distinction that the schema's one-line description does not convey.

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

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

States a specific verb (import) and resource (a media file into FableCut's media library and the project), and the scope is narrow enough to distinguish it from siblings like fablecut_patch_project or fablecut_analyze_reference. An agent can identify the operation without opening the schema.

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

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

Gives concrete selection rules for the single input: a local absolute path (copied, .svg allowed) vs. an https:// URL (downloaded, video/audio/image only, remote SVG refused). It does not mention any alternative tool or when this is the wrong choice relative to siblings, 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?

With no annotations, the description carries the full burden and does so richly: the measurement standard (ITU-R BS.1770 integrated LUFS / sample peak), that it writes props.gain in dB, that linked stems share one gain so a stereo pair stays balanced, that it refuses locked clips unless force:true, and that volume keyframes/fades are left untouched.

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 dense paragraph that is front-loaded with the core action and wastes little, though the run-on style packs many clauses (stems, keyframes, prerequisites, locking) together. Every clause is informative, so it stays efficient despite its length.

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 4-param mutation tool with no annotations or output schema, the description is nearly complete on behavior and prerequisites. The one gap is that it never states what the call returns (e.g., measured values), which the missing output schema would otherwise need it to cover.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: target units depend on mode (LUFS vs dBFS), the force flag's intent ('only when they asked'), and concrete target values. It clarifies the mode/target interplay better than the schema alone.

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

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

States a specific verb and resource ('Loudness-normalize clips') plus the exact mechanism (measures source audio, sets props.gain). An agent can instantly differentiate this from siblings like fablecut_denoise or fablecut_auto_duck, which perform unrelated audio operations.

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

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

Provides concrete usage context via typical targets (-14 LUFS streaming, -16 podcast, -23 broadcast, peak at -1 dBFS) and states a prerequisite (ffmpeg + ffprobe on PATH). It does not explicitly name a sibling alternative or state when not to use it, 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?

With no annotations, the description carries the full behavioral burden and does so thoroughly: it re-reads the latest document from disk, applies ops in order, bumps revision once, saves atomically, aborts the whole patch on an invalid op, and refuses edits on locked clips/tracks unless force:true. It also documents updateClip merge rules (top-level replaced, props merged key-by-key, null deletes).

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 front-loaded first clause delivers the core guidance and the price/comparison rationale immediately, and the volume of op documentation is largely justified by the tool's complexity. However, the remainder is a single dense run-on paragraph of ·-separated fragments rather than a scannable structure, which makes it harder to parse than necessary.

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 multi-op patch tool with no output schema and no annotations, the description covers transactional behavior, lock semantics, merge rules, op enumeration, and even a pointer to the 'Audio mix' docs for setFxKeys. Nothing an agent needs to invoke it correctly appears to be 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?

The input schema only has an opaque 'ops' array whose own description defers to the tool description ('see tool description for shapes'). The description fully compensates, enumerating every op shape with field-level detail (e.g., gain ranges −60…+12, pan −1…1, color enum values, easing, three-point edit semantics).

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

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

States a specific verb and resource ('Apply targeted edits to the FableCut project') and explicitly distinguishes itself from the get+set siblings by naming the cheaper, merge-safe alternative. An agent can identify the tool's role without reading any schema.

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

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

Explicitly says 'PREFER THIS over get+set for every edit' and quantifies why (~10-100x cheaper, merge-safe). It also gives clear when-to/when-not guidance around locked material ('Leave locked material alone; only if the user asked you to change it, pass force:true').

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

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

Discloses auto-bumped revision, instant hot-reload, conflict error and retry pattern, and force overwrite behavior. No annotations to contradict.

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 concise, front-loaded sentences covering all crucial aspects without waste.

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

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

Explains behavior well but lacks description of return value. Given set operation, minor gap.

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

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

Schema coverage is 100%, description adds value by clarifying the 'project' must be complete and the read-modify-write cycle, and explains 'force' usage.

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

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

Clearly states it replaces the project JSON with the complete document, distinguishing from patch tools. Verb 'replace' with resource 'project' is specific.

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 instructs to read, modify, send whole. Provides conflict-safety retry guidance. Could mention that partial updates should use fablecut_patch_project.

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 discloses key behavior: auto-starting the web server. Does not detail error handling or idempotency, but for a status tool, this is adequate 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?

A single sentence that concisely conveys purpose, behavior, and usage recommendation. No wasted words.

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

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

For a zero-parameter tool with no output schema, the description covers core functionality and usage. Could mention response details more explicitly, but overall 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?

No parameters in schema, so baseline 4 applies. Description adds no parameter info, but none is needed.

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 ensuring the editor web server is running (auto-start) and retrieving the editor URL, project summary, and media library. It distinguishes from siblings by stating 'Call this first in a session.'

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 'Call this first in a session,' providing clear usage guidance as a prerequisite. Lacks details on when not to use or alternatives, but the instruction is sufficient for an agent.

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