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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), so the bar is lower; the description adds real value by disclosing the three-value verdict and explaining why a setting matters ('close when inactive' would blind the BRB switcher). It stops short of describing how the verdict is structured or how warnings surface, but the operational rationale is rich.

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 purpose and the check list, then the verdict enum, then read-only. It is a single dense run-on sentence that is efficient for a checklist tool, though the long parentheticals add reading cost without strictly earning every word.

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

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

With no output schema, the description carries the return-value burden and does supply the verdict vocabulary (ready, ready_with_warnings, not_ready), plus the read-only guarantee. It does not say what fields accompany the verdict or how failures are itemized, a minor remaining 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 description coverage is 100%, so all three parameters (liveScene, brbScene, feedInput) are already documented in the schema. The description references live/BRB scenes and the Media Source feed, but adds no naming or format detail beyond what the schema provides, so the baseline 3 applies.

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 precise verb (checks) and a well-scoped resource (OBS wiring for an incoming phone/camera IRL feed), then enumerates the exact conditions verified. An agent can distinguish this pre-flight IRL check from narrower siblings like check_source_record or get_overview 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?

The framing ('ready to go out', 'wired for an incoming phone/camera feed') clearly implies the pre-stream readiness use case. However, it never states when not to use it or names an alternative check tool for a narrower question, leaving the agent to infer routing among the many sibling checkers.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful behavioral detail by listing the exact checks performed and the possible return verdicts ('ready', 'ready_with_warnings', 'not_ready'). It does not explain warning severity or required permissions, but the added diagnostic scope is substantial.

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 check's purpose, then lists the validation areas, the return verdict, and the read-only trait. It is dense but mostly earns its length. Minor waste comes from the redundant Spanish question and the trailing 'Read-only', which restates the annotation.

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?

There is no output schema, so the description must explain the return value, and it does by naming the three verdict outcomes. It also lists the checked configuration areas thoroughly. It stops short of explaining how an agent should act on warnings or failures, but for a diagnostic check the coverage is strong.

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, so there are no parameter semantics to document. Under the rubric, zero parameters sets the baseline at 4, and the description does not need to compensate for any schema gaps.

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

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

The description states a specific verb ('Finds', 'checks') and resource ('Source Record filter', record settings), and enumerates the exact properties being validated. It is clearly distinguishable from generic get/list siblings because it performs a pre-record readiness check rather than simply retrieving settings.

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 title and opening '¿Listo para grabar?' imply a pre-recording check, so usage is implied. However, there is no explicit statement of when to call this tool, when not to, or how it differs from alternatives such as check_irl or start_record.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral detail beyond that: returned values are merged with OBS defaults, differing fields are flagged, and secret fields are redacted — the redaction note in particular is information an agent cannot get from annotations or 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?

A single compact sentence with no filler; the substantive payoff (defaults merged, diffs flagged, secrets redacted) is front-loaded and every clause 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?

With no output schema, the description usefully characterizes the return payload and its redaction behavior, which is the main thing an agent needs. It falls short only on how the input is identified and what happens on a missing/invalid name.

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?

There is one parameter (inputName) with 0% schema description coverage, so the description must compensate and does not. 'One input' only vaguely gestures at identification; it never says whether the value is a display name, internal name, or ID, nor whether unknown names error or return defaults.

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 resource and scope ('Settings of one input') and describes the return payload (OBS defaults merged in, differing fields, redacted secrets). It implicitly contrasts with the write sibling set_input_settings, but never names it or any other sibling, so differentiation is left to inference.

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 only implied: an agent can infer this is the read path for inspecting a single input's configuration, versus set_input_settings for mutation. There is no explicit when-to-use, no when-not-to-use, and no named alternative such as list_inputs for enumeration.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the stream key is redacted, so the agent knows credentials will not be exposed, and it discloses that a recording folder path is included in the response.

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 sentence that front-loads the primary resources (stream, recording) before the more peripheral ones. Every clause names a distinct returned field, so nothing is wasted, though it is a verbless fragment.

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

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

With no output schema, the description carries the burden of explaining the return payload, and it does so by listing every major status group plus the service details. It is complete enough to call correctly, with only minor ambiguity about response shape and overlap with get_overview.

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

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

The tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate. No parameter semantics are needed or missing.

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 enumerates exactly what the tool returns — stream, recording, replay buffer, virtual camera status, recording folder, all OBS outputs, and stream service details. It is a specific resource enumeration rather than a tautology, though the verb is only implied and it does not distinguish itself from the overlapping sibling get_overview.

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?

There is no statement of when to call this versus alternatives such as get_overview, which likely reports similar stream/recording state. The agent must infer usage purely from the content list.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the scope of the response contents, which is modestly useful, but says nothing about caching, refresh cadence, or error behavior when OBS is disconnected.

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?

It is a single compact sentence with no waste, but it is an unstructured comma list without a leading verb or organizing clause, so the reader has to parse the inventory to find the point.

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, no output schema, and read-only annotations covering safety, the enumerated field list effectively serves as the return-value contract and is broad enough (version, performance, state, settings, folder) for an agent to know what it gets. It stops just short of stating structure or units (fps, disk units).

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies.

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 is a noun-phrase inventory of the payload (version, performance stats, stream/record state, scene, profile) with no verb, so the agent must infer 'returns a snapshot of OBS' from the name alone. It does distinguish itself from narrow siblings like get_video_settings or list_scenes by its breadth, but the purpose is implied rather than stated.

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?

There is no when-to-use guidance and no routing to alternatives. The sibling set contains overlapping tools (get_video_settings, get_outputs, list_scenes), and the description never says whether this is a preferred first call or a fallback aggregator.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered without description help. The description adds only the field inventory (resolutions, frame rate); it says nothing about units, defaults, or whether settings reflect saved project state.

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 short noun phrase with no filler. It is front-loaded and wastes no words, though the fragmentary phrasing is slightly less clear than a full sentence would be.

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

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

With no output schema, the description carries the burden of explaining the return, and it does list the main setting categories, which is roughly adequate for a simple read. It omits units, value ranges, and return shape, leaving meaningful 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?

The schema declares zero parameters, so there is nothing for the description to disambiguate. The baseline of 4 applies for a parameterless getter.

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 enumerates the specific settings returned (canvas/base resolution, output resolution, frame rate), which lets an agent distinguish it from sibling get_input_settings or get_outputs. It lacks an explicit verb like 'Returns', but the resource content is unambiguous.

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

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

There is no statement of when to use this tool versus get_input_settings, get_outputs, or get_overview, and no prerequisite or context guidance. The agent must infer usage purely from the tool name and the field list.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: results are ordered top to bottom as in OBS, defaults are filled in, and secrets are redacted — the redaction disclosure in particular is non-obvious and matters for interpreting output.

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

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

Two short sentences that front-load the resource and scope. The closing 'Filters apply top to bottom' restates the ordering point already made by 'top to bottom as in OBS', so one clause is mildly redundant.

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

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

With no output schema and no annotations explaining returns, the description should say more about the shape of a returned filter (name, kind, enabled state, index) rather than only its ordering and settings treatment. It is adequate for a simple list tool but leaves the return contract partially unspecified.

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?

At 67% schema coverage, the description meaningfully compensates: it explains the sourceName omission semantics ('or of every source and scene') and, more importantly, what includeSettings actually yields (defaults filled in, secrets redacted) — detail the schema's bare boolean with a default does not provide. Only 'kind' is left to 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 names the resource (filters) and states its scope precisely: filters of one source, or of every source and scene, returned in OBS display order. It is clearly distinguishable from the mutating siblings (set_filter_settings, set_filter_enabled, set_filter_index), though it never names those siblings 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?

There is no when-to-use guidance and no mention of the sibling tools that read or mutate filters. The only hint is the implicit read framing ('with settings'), so an agent must infer that this is the inspection tool rather than the mutation 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 establish this is a safe read (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description nonetheless adds real output behavior: settings come back with OBS defaults filled in, and secret fields are redacted — non-obvious traits an agent should know before calling.

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 compact sentence with the primary scope front-loaded and the optional behavior and redaction caveat trailing. No filler, every clause carries 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?

With no output schema, the description carries the burden of describing returns and does so in part (kind, settings with defaults, redacted secrets). It is nearly complete for a 2-param read tool, missing only an explicit note on the kind filter and return shape/pagination.

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 only 50%: 'kind' is documented in the schema while 'includeSettings' has just a default and no description. The description compensates for includeSettings ('optionally their settings with OBS defaults filled in') but never clarifies that 'kind' acts as a filter rather than merely echoing each input's kind, leaving that parameter 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?

States a specific verb+resource ('All inputs (sources) with their kind') and even maps the domain term 'inputs' to 'sources', which helps disambiguate from list_scenes/list_filters. It does not explicitly contrast with the sibling get_input_settings, so it falls short of a 5.

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 'optionally their settings' implies when to set includeSettings, but there is no explicit statement of when to use this bulk list versus get_input_settings for a single input, nor any exclusions. Usage is only implied.

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 readOnlyHint=true and openWorldHint=false, so safety is covered. The description usefully adds what the response contains (scenes in OBS order, the current program/preview scene, and optionally per-scene sources), which goes slightly beyond the annotations, but it says nothing about pagination, error behavior, or connection requirements.

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 short sentence with no filler, and the most important content (scene listing and order) is front-loaded. It is efficiently sized for a one-parameter read tool.

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

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

With no output schema, the description carries the burden of describing returns, and it partially does so (order, program/preview scene, optional sources) but leaves the actual field names and shape unspecified. For a simple listing tool it is adequate but not complete.

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

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

Schema coverage is 100% and the single parameter includeItems is fully documented in the schema. The description's 'optionally the sources in each scene' mirrors that same meaning without adding format or default nuance, so the baseline 3 applies.

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

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

The description names the resource (scenes) and what the listing contains, but it is a verbless noun phrase that essentially restates the tool name 'list_scenes' and the title. It conveys scope (OBS order, current program/preview scene, optional sources) but never states the action, so an agent must infer 'list' from the name alone.

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?

There is no when-to-use or when-not-to-use guidance and no mention of the obvious alternatives among siblings such as get_overview or switch_scene. A read-only listing tool is fairly self-evident, but the description provides no routing context.

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

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

Annotations declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds the data source (OBS_TIMELINE_FILE) and the nature of the summarized content, but no behavioral traits beyond that (e.g., performance, pagination, auth). With annotations covering safety, this is a modest addition.

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 that packs the essential purpose and return content without filler. Every clause contributes to understanding what the tool does and returns.

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

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

With no output schema and 6 optional parameters, the description carries the burden of explaining return values, which it does by enumerating the summary content (program scene durations, session offsets, live-at-time lookup). It does not cover edge cases or defaults, but the schema handles parameter specifics. Adequate for a read-only tool.

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

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

Schema description coverage is 100% for all 6 parameters, so the schema fully documents each parameter. The description mentions time-based and stream-offset lookups but adds no syntax or format details beyond the schema. Baseline 3 is correct when the schema does the heavy lifting.

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

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

States a specific verb ('Summarises') and resource ('scene timeline log'), and details the content returned (program scene, durations, sessions with offsets, live lookup). The resource is unique among the siblings, so an agent can distinguish it, but the description never explicitly names a sibling it is not, which keeps it from a 5.

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 use-case examples ('what was live at a given time or at a given second of a stream'), which implies when to use it. However, it does not state when not to use it, nor does it name alternatives like get_overview or list_scenes. Usage is therefore implied rather than explicit.

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

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

Annotations declare destructiveHint=true and idempotentHint=true, and the description reinforces this by naming the concrete destructive effect (stopping a Source Record filter's file). It goes further than the annotations by disclosing the dry-run-by-default guard and the confirmLive requirement during streaming/recording, though it does not describe the dry-run response or what a live apply returns.

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 short sentences, front-loaded with the core action and followed by the side effect and the guard. Efficient overall, though the first sentence largely restates the title and could have been merged with the side-effect clause.

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 destructive, guarded toggle with no output schema and partial param coverage, the description covers the key safety-critical facts: the default dry-run, the live-apply confirmation, and the side effect. It is slightly thin on the mechanics of what dry_run returns, but nothing needed to call it safely 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 only 40%, so the description must carry weight; it does explain the two most consequential parameters (dry_run default and confirmLive gating). The remaining parameters (sourceName, filterName, enabled) are only inferable from their names, so the gap is not fully compensated.

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 (turn on/off) and resource (filter), and adds a concrete consequence ('Disabling a Source Record filter stops its file') that distinguishes it from siblings like set_filter_settings and set_filter_index. 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?

The description supplies guard conditions for use (dry_run defaults on; confirmLive=true required while streaming/recording), which is real when-to-use guidance. It does not, however, explicitly contrast this tool with set_filter_settings or set_filter_index, so sibling selection is still left to inference.

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 flag destructiveHint=true and idempotentHint=true, so the bar is lower; the description still adds real context the annotations lack — dry_run defaults to true (describe-only), the live-streaming guard, and that the before/after order is reported. It does not spell out what happens to existing ordering or permissions required.

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: what it does, what it returns, and the safety guard — each front-loaded and free of 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 5-parameter mutation tool with no output schema, the description covers the guard semantics and the return ('shows the order before and after'), which substitutes for an output schema. Minor gaps are the two string parameters and the reorder's effect on existing indices.

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 40% schema coverage, the description must compensate and does so for the key ambiguous parameter: 'filterIndex (0 = top, applied first)' gives positional meaning the schema's bare minimum:0 does not. sourceName and filterName remain undocumented anywhere, but their intent is largely inferable from the name.

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 (moves) and resource (a filter) plus the position semantics ('0 = top, applied first'), which cleanly separates it from siblings set_filter_settings and set_filter_enabled that alter a filter's configuration or state rather than its order.

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 a clear precondition for the risky case ('needs confirmLive=true while streaming/recording') and warns to ask the person first, but never names the alternative tools or when a caller should prefer set_filter_settings over reordering.

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 flag destructiveHint=true, and the description adds real behavior on top: the default dry-run guard, the confirmLive precondition during streaming/recording, the overlay merge-vs-replace semantics, and the fact that a before/after diff is returned. That is well beyond what the structured fields convey.

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 with the core action and the overlay default front-loaded, then the guard conditions. No filler, though the parenthetical '(including Source Record)' is a slightly awkward insertion.

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 destructive mutation with no output schema, the description covers the safety model (dry-run default, live confirmation) and mentions the diff result. The main gap is the settings object contents, which neither the description nor the schema constrains.

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 67%, with dry_run, overlay, and confirmLive already documented in the schema; the description largely restates those defaults rather than adding new semantics. It adds nothing for sourceName, filterName, or the shape of the settings object, so it does not compensate for the uncovered parameters.

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 ('Changes settings of a filter') and notes the Source Record case, which distinguishes it from set_filter_enabled and set_filter_index in the sibling list. It stops short of naming an alternative tool outright, so it is clear but not fully sibling-differentiated.

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 usage conditions: overlay defaults to merge-only, dry_run defaults on, and confirmLive=true is required while streaming or recording with the instruction to ask the person first. This tells the agent when the call is safe versus when it needs a live confirmation, though it never routes to a sibling 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 only declare destructiveHint=true and readOnlyHint=false, but the description adds the safety model: dry-run by default, live-change confirmation while streaming/recording, overlay-vs-replace semantics, and that a before/after diff is shown. That is meaningful behavioral disclosure beyond the structured flags.

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 tight clauses, front-loaded with the core action, then overlay semantics, then the diff, then the guard. Telegraphic but every clause carries information an agent needs, with no 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?

For a 5-parameter mutation tool with a nested settings object and no output schema, the description covers the guards, the overlay/diff behavior, and the live-change precondition. It omits which settings keys are valid, though the open-ended settings object makes that arguably out of scope.

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% and the description compensates well: it explains overlay semantics (undocumented in the schema), restates the dry_run default guard, and explains why confirmLive is required (streaming/recording). The settings object's valid fields remain unaddressed, which is the only 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?

States a specific verb and resource ('Changes settings of an input (source)'), which cleanly separates it from the read counterpart get_input_settings and from set_filter_settings/set_filter_enabled. It does not explicitly name the siblings it differs from, so it lands just short of a 5.

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 real operating context: overlay=true only touches the given fields, dry_run is on by default, and confirmLive=true is needed while streaming/recording. It stops short of explicitly telling the agent when to prefer a sibling tool, so no 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 destructiveHint=true and readOnlyHint=false, but the description adds meaningful behavior beyond them: the tool is dry-run by default and requires an explicit confirmLive override when OBS is streaming or recording. That guard detail is exactly the kind of risk context an agent needs before mutating state.

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

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

Two short sentences, front-loaded with what it does and then the guard constraint. No filler, and the parenthetical scope note is genuinely informative rather than restating the name.

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-param mutation with no output schema and annotations covering the destructive profile, the description supplies the guard behavior an agent needs to invoke it safely. It doesn't mention return values or failure modes, but those are largely covered by the schema defaults and annotations.

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 both parameters are self-documenting, so the baseline is 3. The description restates the dry_run default and the confirmLive condition rather than adding format, interaction, or side-effect semantics the schema lacks.

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 (starts the main OBS recording) and adds the Source Record filter side effect, so the agent can distinguish it from stop_record and check_source_record 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 the guard model ('dry_run by default; needs confirmLive=true while streaming'), which tells the agent the precondition for actually applying the change. It does not name a sibling alternative or say when to prefer check_source_record first, 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?

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description adds meaningful context beyond them: the tool only acts during an active recording, requires confirmLive=true, and returns the file path (valuable since no output schema exists). It does not state what happens on failure or whether the file is finalized, but the behavioral profile is well covered.

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 short sentences, front-loaded with the action and its result, followed by the precondition and the default. The parenthetical '(it only acts while recording)' earns its place by explaining why confirmLive is mandatory.

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 destructive two-parameter tool with no output schema, the description covers the action, the precondition, the dry-run default, and the return value. Only minor gaps remain, such as error behavior when no recording is active.

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 both parameters are already documented, including the dry_run default and the confirmLive requirement. The description restates 'dry_run by default' and 'needs confirmLive=true' without adding syntax or edge-case meaning, so the baseline 3 applies.

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 and resource ('Stops the main OBS recording') and adds the return value ('returns the file path'), so the agent knows exactly what happens. It does not explicitly name start_record as the counterpart, but the stop/start pairing is unambiguous from the verb alone.

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 a real precondition: 'it only acts while recording' and that confirmLive=true is always needed, which tells the agent when this call will actually do something. There is no explicit 'when not to use' or alternative routing, but the operating condition 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?

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is partly covered. The description adds genuinely new context beyond them: the two-phase dry-run/confirm flow and the live-stream confirmation requirement, which an agent could not infer from annotations alone. It stops short of saying what happens to the previously live scene or on an unknown sceneName.

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 dense sentences, zero waste, with the core action front-loaded and the guardrails immediately after. Nothing to trim.

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

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

With no output schema, the description plus the dry_run parameter description adequately explain that a dry run only describes the change. For a 3-parameter mutating tool the coverage is solid, though error behavior (nonexistent scene) is unaddressed.

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 67%, and both documented parameters (dry_run, confirmLive) already carry inline descriptions. The description reinforces their semantics with the operational rule ('needs confirmLive=true while streaming/recording'), adding value beyond the schema, though sceneName's absence behavior remains undocumented in both places.

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 ('Puts a scene on program') and clarifies the consequence ('what viewers see'), which disambiguates it from read-only siblings like list_scenes and get_overview. An agent can tell immediately that this is the mutating scene-activation 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?

Gives clear conditions for the guarded workflow: dry_run is the default and confirmLive=true is required while streaming/recording. It never names an alternative tool, but switch_scene has no direct sibling competitor, so the missing exclusion is low-cost.

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