FPV-DB

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

Annotations declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the release is parsed from the paste header, and the header also supplies the firmware when none is given. That inference behavior is exactly the kind of thing an agent cannot learn from the schema alone.

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 — the core action is in the first clause. The two-sentence structure packs a lot of useful scope information with little waste, though the first sentence is long and slightly list-heavy.

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

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

With no output schema, the description carries the burden of explaining results, and it does: it spells out the categories of findings that will be reported. It doesn't describe result structure or how counts are surfaced, but for a read-only checker the description is nearly 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%, so baseline is 3. The description still adds value: it explains that the `version` and `firmware` defaults are derived from the paste's `# Betaflight / ... X.Y.Z` or `# INAV/<target> X.Y.Z` header, which clarifies why those parameters can be omitted and how they interact.

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: checks a pasted `diff all`/`dump` against a release. It also enumerates exactly what classes of problems are reported (missing, renamed, removed, out-of-range, not-in-list, default-repeat), which clearly separates it from siblings like fw_diff and fw_param.

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?

Clear context for when to use it: a pasted CLI dump that needs validating against a firmware release. It also carves out scope by noting that aux/serial/resource lines are counted rather than checked, so the agent knows what the tool will not do. It does not explicitly name fw_diff as the alternative, 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 and openWorldHint=false, so the description only needs to add context. It does: it discloses the meaningful limitation that renames are only detected when sourceable, and clarifies what 'changed' means (range, values, default). It stops short of describing result shape or ordering.

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 names the resource first and then enumerates the diff categories. No filler, no restatement of the title.

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, closed-world lookup with fully documented parameters and no output schema, the description covers what is compared and the key limitation on rename detection. The only gap is the shape of the returned diff (grouped settings vs. flat list), which an agent must discover by calling.

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 carries the parameter meaning. The description only implies the from/to relationship by saying 'between two releases' and adds nothing about version format or firmware selection beyond what the enum and defaults already state.

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 operation (diff CLI settings between two releases) and enumerates exactly what dimensions are compared (added, removed, renamed, changed). The resource and scope are unmistakable. It doesn't name a sibling alternative, but the diff framing is distinct enough from fw_check_cli and fw_param.

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 must infer that this is the right tool when comparing two firmware releases rather than validating a single CLI paste (fw_check_cli) or looking up one parameter (fw_param). No explicit when-to-use/when-not guidance is offered.

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 description doesn't need to repeat the safety profile. It instead discloses real behavioral value: what the record contains, that the default assumes no board config, and that old names are followed through sourced renames. It stops short of saying what happens for unknown names or which release is used when omitted.

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 resource ('One CLI setting of a firmware release') and enumerates only the fields an agent would care about. No filler; slightly compressed but readable.

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-shape burden and does it well by enumerating the fields returned, including history and rename tracking. It is nearly complete for a read-only lookup; only error/not-found behavior 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 100% – all three parameters, including the enum and the version format example, are documented in the schema. The description adds no syntax or format detail for name/version/firmware beyond the 'renames' note touching on name resolution, 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 specific resource precisely: 'One CLI setting of a firmware release' with the exact fields returned (type, range/values, default, source line, history). An agent can tell it's a per-setting detail lookup, though it never names or contrasts with siblings like fw_check_cli or fw_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?

Usage is only implied by what the tool returns – the agent infers it should call this when it needs details on one named setting. There is no explicit when-to-use, no prerequisite, and no routing to the alternatives (fw_check_cli for pastes, fw_diff for comparisons).

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

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

Annotations already declare readOnlyHint and closed-world openWorldHint, so the safety profile is covered. The description adds real value by disclosing that thrust and VTX tables exist only "where measured"/"where published" and that sources and caveats are included, priming the agent for partial or qualified data. It omits not-found/error behavior.

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

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

One sentence, front-loaded with the action and resource, then a colon-list of return contents and a parenthetical example placed exactly where the ambiguous term appears. Nothing is padded.

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

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

With no output schema, the description carries the burden of describing the return payload and does so concretely, plus annotation-covered safety. For a 2-parameter read-only lookup this is sufficient to invoke correctly.

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

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

Schema coverage is 50%, with `slug` undocumented in the schema — the description compensates well by defining it as the last URL segment and giving a worked example. The optional `type` enum parameter is not addressed at all, leaving unclear whether supplying it changes resolution or is merely advisory.

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 full spec sheet of one part by its slug" is a specific verb+resource, and the enumerated return contents (specs, bench thrust table, VTX table, sources, caveats) make the scope unambiguous. It never names search_parts, so the contrast with the sibling is inferred from the singular scope 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?

Usage is implied: call it when you already hold a part slug. The URL-derivation hint helps, but there is no explicit "use this instead of search_parts when..." routing or note on what to do when the slug is unknown.

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 safety (readOnlyHint=true, openWorldHint=false), and the description adds genuinely non-obvious behavior: only published parts are returned, unknown fields return the type's field list instead of erroring, and matching semantics differ per value type (case-insensitive substring vs numeric range). It omits ordering and what a result item looks like, but the annotations lower the bar.

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, then filter semantics, then a single compact example — every sentence carries information. It is dense but readable; the example is justified because the `filters` object is otherwise opaque. Minor cost: the value-type rules and the example overlap slightly.

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?

Covers the nested `filters` object and the fallback behavior well, but with no output schema the description should say what comes back (list of parts with which fields?) and whether `limit` truncates silently. For a search tool with a nested free-form parameter, those omissions matter more than they would elsewhere.

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 schema description coverage at only 25%, the description must carry the load, and it does so for the hardest parameter: `filters` is a free-form object whose number/string/{min,max} semantics are spelled out with a concrete example. `query` is restated (brand+model) and `type` is shown by example, but `limit` (default 20, max 50) is never mentioned.

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 with scope: "Finds published parts of one type by spec." The agent knows exactly what is being searched and that results are limited to one part type. It never names the sibling `part_specs`, so the boundary between searching and inspecting a type's schema is left implicit even though the fallback sentence hints at it.

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 conveyed only through the worked example (type=motor, stator, weight_g max) and the fallback rule for unknown fields. There is no explicit statement of when to call this instead of `part_specs`, nor any note on prerequisites or empty-result behavior. The example makes the intended call shape inferable but not the routing decision.

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