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

No annotations are provided, so the description carries the full behavioral burden. It implies a bulk mutating operation against TAK Video Manager but says nothing about idempotency (are already-advertised paths re-POSTed?), auth/permission requirements, partial-failure behavior, or side effects on the TAK side.

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

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

A single front-loaded sentence with no filler — the action, scope, and destination are all in the first clause. 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?

An output schema exists, so return values need not be described. However, for a no-arg bulk write operation with no annotations, the description omits failure modes, idempotency, and prerequisites, leaving the agent unable to predict what happens on a second 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?

The tool takes zero parameters, so the baseline of 4 applies; there is no parameter semantics for the description to clarify.

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?

Names a specific verb (POST), a specific resource subset (every ready MediaMTX path), and the destination system (TAK Video Manager). It is distinguishable from mediamtx_paths, which merely lists paths, though the description never names that sibling to make the contrast explicit.

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

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

There is no guidance on when to invoke this versus mediamtx_paths or tak_publish_video, no stated prerequisites (e.g. that paths must be in a 'ready' state, or that MediaMTX must be reachable), and no indication of when not to run it.

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. 'Tail logs' implies a read-only operation, but it does not say whether it streams continuously or returns a one-shot snapshot, what happens if the container is stopped or missing, or whether authentication/permissions are required. Significant gaps for a tool with zero annotation coverage.

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

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

A single front-loaded sentence with no filler. It is appropriately terse, though the brevity contributes to the informational gaps noted elsewhere.

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

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

An output schema exists, so return values need not be explained, but the description leaves both parameters undocumented and the streaming-vs-snapshot behavior unclear for a tool with no annotations. For a two-parameter operational tool this is under-specified.

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

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

Schema description coverage is 0%: neither 'name' nor 'tail' is documented. The description only loosely implies that 'name' is the container and 'tail' relates to log lines; it never clarifies that name accepts a container name/ID or that tail is a line count with a default of 80.

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 ('tail') and resource ('logs for a Docker container'), which is enough to separate it from docker_ps (which lists containers). It does not explicitly name a sibling alternative, but the action/resource pair 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?

No guidance on when to use this versus docker_ps or any other diagnostic tool, no prerequisites (e.g. container must be running), and no exclusions. The agent must infer usage entirely from the name.

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 bears the full burden. It usefully discloses the ALLOW_DOCKER=1 gate, which is a real operational precondition. However it does not say whether running, stopped, or all containers are returned, nor mention any filtering 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 short clause with the resource front-loaded and the gating condition appended; nothing is wasted and nothing is buried.

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 read tool with an existing output schema, the description is nearly sufficient — return values are covered by the output schema and the precondition is disclosed. It would be complete with a note on which container states are listed.

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 the schema needs no elaboration and the description correctly omits parameter detail. Baseline 4 applies for a no-parameter tool.

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

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

States a specific verb and resource ('List Docker containers'), which is unambiguous and clearly distinct from the other docker tool (docker_logs). It does not explicitly contrast with siblings, but the resource itself differentiates 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?

The parenthetical '(ALLOW_DOCKER=1)' implies a precondition for the tool to work, which is implicit usage guidance. There is no statement of when to prefer this over docker_logs or what scope of containers it covers.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does flag which actions are destructive enough to require confirm=true, which is real value, but it omits auth/permission requirements, reversibility of stop/uninstall, and any explanation of what 'raw' mode actually does beyond one example.

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 core purpose is front-loaded in the first line, and the action list and confirm rule follow as compact fragments. Nothing is padded, though the 'raw body_json' line is slightly cryptic without more surrounding explanation.

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

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

An output schema exists, so return values need not be described. But with no annotations and a multi-action tool that can mutate infrastructure, the description should do more: it does not explain sibling selection or the consequences of the destructive actions it gates behind confirm.

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

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

Schema coverage is 0% and the schema has no enum, so the description meaningfully compensates: it supplies the full action vocabulary, shows the body_json shape for raw calls, and defines confirm semantics for destructive actions. Only 'module' is left unstated, though it is self-evident from the endpoint template.

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 ('Call /api/<module>/<action> on the infra-TAK console'), so an agent understands this is a low-level API dispatcher. However, it offers no differentiation from siblings like marketplace_deploy, marketplace_control, and marketplace_uninstall, which appear to overlap with the deploy/start/stop/uninstall actions listed here.

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

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

It gives a prerequisite ('confirm=true required for deploy, uninstall, start, stop, restart') and enumerates valid actions, which is useful direction. But it never says when to prefer this generic call over the dedicated marketplace_deploy / marketplace_control / marketplace_uninstall siblings, leaving the key routing decision 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?

No annotations are provided, so the description carries the full burden, and it discloses nothing beyond the verb list. It never mentions the 'confirm' parameter's safety role, whether interruption of a running module is disruptive, permission requirements, or reversibility — all critical for a lifecycle-control operation.

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 front-loaded sentence with zero wasted words and the allowed actions stated up front. It is efficient, though the extreme brevity borders on under-specification rather than genuine conciseness.

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?

An output schema exists, so return values need not be explained, but for a mutation tool with no annotations and 0% parameter documentation the description leaves too much open: which modules exist, what 'confirm' gates, and what state changes result. It is not adequate for a lifecycle-control operation.

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

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

Schema description coverage is 0%, but the description partially compensates by enumerating the valid action values (start/stop/restart), which the schema leaves as an unconstrained string. It adds nothing for 'module' and completely omits the meaning of 'confirm' (default false), leaving a third of the parameters opaque.

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 (control, elaborated as start/stop/restart) and resource (a marketplace module), so an agent knows exactly what the tool does. It does not, however, distinguish itself from siblings like marketplace_deploy or marketplace_uninstall, which also mutate marketplace state.

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

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

There is no guidance on when to choose this tool over marketplace_deploy, marketplace_call, or marketplace_uninstall, nor any prerequisites or sequencing notes. Usage must be inferred entirely from the tool name.

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 it does disclose the async nature of the operation (it starts a job) plus how to observe progress via polling. That is real behavioral value, but it omits the safety profile of the 'confirm' gate and whether the deploy is destructive or reversible.

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, front-loaded sentences with no filler; the primary action comes first and the follow-up hint second. It is terse rather than padded, though that terseness borders on under-specification.

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?

An output schema exists so return values need not be explained, but for a deploy tool with a confirm gate and 0% parameter coverage, the description leaves too much undefined. An agent cannot tell what 'confirm' does or what 'params_json' expects.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does not. 'module' appears only incidentally in the polling hint, while 'confirm' and 'params_json' are entirely unexplained despite being central to invoking a deploy safely.

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

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

The description states a specific verb and resource ('Start a marketplace deploy job'), which clearly distinguishes it from siblings like marketplace_uninstall or marketplace_list. It lacks explicit sibling differentiation, but the deploy action 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?

The second sentence gives a follow-up action ('Poll marketplace_call(module, 'log')'), which is genuinely useful guidance on what to do after invoking. However, there is no statement of when to use this vs alternatives, prerequisites, or what the confirm parameter gates.

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 behavioral burden. It implies a read-only catalog lookup ('keys this MCP knows how to drive'), which is useful, but does not state whether the result is static or dynamic, whether it reflects installed vs available modules, or any permission requirements. Adequate but thin.

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

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

A single, front-loaded sentence with no waste. Slightly terse for an entry-point discovery tool, but efficient.

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?

Output schema exists, so return format need not be described. With zero parameters, the description covers what the tool is; the main gap is explicit guidance that this is the discovery entry point feeding the other marketplace_* tools.

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

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

Zero parameters, so the baseline is 4. The description's phrase 'keys this MCP knows how to drive' usefully frames what the empty-argument call returns.

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: a catalog of marketplace module keys. An agent can tell it lists known keys, and the sibling names (marketplace_call, marketplace_deploy, marketplace_uninstall) imply this is the discovery step. It does not explicitly say 'list/return' as a verb, but the noun phrase 'Catalog' is reasonably clear.

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

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

No explicit when-to-use or when-not-to-use guidance. The sibling names imply this is a discovery/listing tool that precedes marketplace_call or marketplace_deploy, but that routing is left to inference rather than stated.

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

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

With no annotations, the description carries the full burden. It usefully discloses the confirmation gate beyond what the schema shows (confirm defaults to false), which is genuine behavioral context for a destructive operation. However, it says nothing about irreversibility, what data is removed, permission/role requirements, or why admin_password exists.

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 terse sentences with zero padding; the action and the safety precondition are both stated up front with 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?

An output schema exists, so return values need no explanation, but for a destructive, unannotated tool the definition omits the effects of uninstalling, the role of admin_password, and any recovery story. It is under-specified for the risk profile of the operation.

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

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

Schema description coverage is 0%, so the description must compensate for all three parameters. It only clarifies confirm (that it must be true) and leaves admin_password entirely unexplained and module undocumented beyond the tool name, despite admin_password being a meaningful optional input for a privileged uninstall.

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 (uninstall) and resource (marketplace module) in a single front-loaded sentence. It is inherently distinguishable from siblings like marketplace_deploy, marketplace_list, and marketplace_call, though it does not explicitly name a boundary against them.

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 one concrete precondition ("Requires confirm=true"), which tells the agent how to invoke it safely, but gives no when-to-use vs. when-not guidance and never mentions alternatives or the sibling tools that manage the same modules.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure and delivers almost none of it: it does not state that this is a read-only/query operation, whether any authentication or permissions are required, or whether it hits a live server. The only saving grace is that it is an 'info' tool, which weakly implies a non-mutating read.

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 short sentence with no filler and the resource front-loaded, which is structurally clean. But at four words it reads as under-specification rather than disciplined conciseness, leaving the agent with no operational 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?

An output schema exists and there are no parameters, so the description needn't explain return values or arguments. What is missing is the behavioral layer (read-only status, server requirements) that no annotation covers, making it minimally adequate rather than 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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter-level detail is 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 names the resource (MediaMTX server) and the kind of data returned (info), which at least separates it from mediamtx_paths at a high level. However, it supplies no verb and 'info' largely restates the tool name, so the exact nature of the output is left vague.

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, when not to, or which sibling to prefer. An agent must infer that this is the server-level counterpart to mediamtx_paths purely from the name.

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. 'List' implies a safe read and it discloses the control API binding on :9898, but it never confirms read-only semantics, pagination, or error behavior for a live streaming service.

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 with the purpose front-loaded and no filler. The second sentence is only loosely connected to invoking the tool, which slightly dilutes it.

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?

A zero-parameter read tool with an output schema needs little prose, and the description covers what it returns. The only gap is the absence of routing guidance relative to mediamtx_info.

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 clarify; the baseline of 4 applies. The description correctly implies the call is unconditional.

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 ('List MediaMTX paths'), so the agent knows exactly what it returns. It does not, however, distinguish itself from the sibling mediamtx_info, which an agent could reasonably confuse it with.

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, no prerequisites, and no reference to the sibling mediamtx_info as an alternative. The second sentence about the control API port is environmental trivia, not usage direction.

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

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

With no annotations, the description carries the full burden. It usefully discloses two behavioral facts: the operation mutates by appending (not replacing) and that it triggers a redeploy, plus the confirm gate. It says nothing about permissions, reversibility, what happens to existing nodes on conflict, or failure behavior.

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

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

Two tight sentences with the action front-loaded and the prerequisite immediately after. No filler, though the second sentence is terse to the point of being a 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?

An output schema exists, so return values need not be described. For a mutating tool with zero annotations, the definition covers the safety gate but omits the flow_json payload format and any side-effect detail, 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?

Schema description coverage is 0%, so the description must compensate. It correctly flags that confirm must be true, which is critical because the schema defaults it to false and does not list it as required. However, flow_json — the required parameter — gets no format or content explanation at all.

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 gives a concrete verb and resource: append nodes to current flows and redeploy. That distinguishes it from nodered_list_flows and nodered_deploy_flows, though it never names those siblings explicitly, so the differentiation is inferable 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?

It states a hard prerequisite (confirm=true required) but gives no guidance on when to choose this over nodered_deploy_flows, nodered_install_node, or nodered_inject. Usage context is implied by the name rather than explained.

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

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

With no annotations, the description carries the full burden. It does disclose the most important behavior for a mutation tool: this replaces the *running* document (destructive/overwriting) and demands an explicit confirm flag as a guard. It stops short of saying whether the prior flow set is recoverable, whether the deploy is atomic/validated, or what happens on partial failure.

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 the action and the safety requirement. Nothing is padded, though the terseness shades into under-specification rather than pure economy.

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?

An output schema exists, so return values need not be described. What an agent still needs before calling correctly — the expected format/content of flows_json and the blast radius of replacing the running document — is absent, so the definition is only minimally complete for a whole-document mutation.

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

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

Schema coverage is 0% and there are two parameters. The description explains confirm's purpose (a required confirmation gate), covering one of the two. flows_json — the entire document payload and required argument — gets no format, size, or shape guidance anywhere, so the description only partially compensates for the coverage 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 concrete verb+resource: 'POST /flows and replace the running Node-RED document,' making clear this deploys a whole flow document. It implicitly contrasts with nodered_add_flow by saying it *replaces* rather than adds, but it never names that sibling or scopes the operation explicitly, 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?

Provides one concrete prerequisite ('confirm=true required'), which is real usage guidance. However it gives no when-to-use framing versus nodered_add_flow or marketplace_deploy, and no conditions under which this should be avoided. Adequate but with clear gaps.

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. It does disclose a meaningful trait beyond the schema: the data comes from the loopback Admin API, which tells the agent this hits a locally running Node-RED instance. It does not state that the call is read-only, nor any auth or failure behavior, so a 3 is appropriate.

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

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

One short, front-loaded fragment with no filler; the resource list leads and the data source trails. It is a noun phrase rather than a verb-led sentence, which slightly weakens immediacy but costs nothing in 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 zero-parameter info tool with an output schema already defining the return shape, the description supplies adequate scope (settings, diagnostics, palette). It omits only the read-only assurance and any precondition that Node-RED be reachable, which are minor for a diagnostic read.

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; the baseline for a no-arg tool is 4.

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 resource (Node-RED settings, diagnostics, and palette) and the source it reads from (the loopback Admin API), which is enough to distinguish it from siblings like nodered_list_flows or nodered_inject. It never explicitly contrasts itself with those siblings, so it stops 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?

Usage is only implied: an agent can infer this is the tool for inspecting Node-RED configuration and health, but the description gives no when-to-use condition, no prerequisites (e.g. Node-RED must be running), and names no alternative.

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 drops it. 'Trigger' implies an action with side effects, but nothing states whether it requires the flow to be deployed, whether it mutates anything persistent, whether it's idempotent, or what the caller gets back. There is no auth, rate-limit, or reversibility 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?

One short, front-loaded sentence with no filler. It is not padded, though 'by id' is the only structural content and a clause on effect would have fit.

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?

An output schema exists, so return values need not be explained, and a single required param keeps the interface small. Still, for an action-bearing tool with no annotations, the description leaves foundational facts (deployment prerequisite, side effects) entirely unstated, so it is only minimally 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?

Only one parameter, and the schema documents it by title only (0% description coverage). The description at least ties node_id to the inject-node concept, so it adds marginal meaning over the bare schema, but gives no format (e.g., how a Node-RED node id looks) or constraint. Baseline 3 for a single param the description doesn't clarify further.

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 (Trigger) and resource (inject node) plus the keying parameter, which is enough to distinguish it from the other nodered_* siblings (info, list_flows, deploy_flows, add_flow, install_node). It loses a point only because it never says what an 'inject node' does — that triggering it injects a message into a flow — which an agent needs to reason about effects.

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

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

No when-to-use guidance at all. Nothing tells the agent whether this is the right tool for injecting a message versus deploying flows or adding nodes, nor that the node must already exist in a deployed flow. Pure one-line capability statement.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a mutation but says nothing about whether the install requires a restart, whether it can fail destructively, what permissions are needed, or what the 'confirm' flag does.

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

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

A single front-loaded sentence with zero filler. It is efficient, though its brevity contributes to the missing detail noted in other dimensions.

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

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

For a mutating install tool with no annotations and an undocumented 'confirm' flag, the description is too thin. The presence of an output schema excuses it from explaining return values, but not from covering the safety/confirmation semantics of installation.

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

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

Schema description coverage is 0% and the description only indirectly clarifies 'package' by giving an example value. The 'confirm' parameter, which likely gates a risky or side-effecting action, is left completely unexplained in both the schema and the 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 gives a specific verb ('Install') and resource ('a palette package'), plus a concrete example package name. It is distinguishable from siblings like nodered_deploy_flows or marketplace_uninstall, but it never explicitly contrasts itself with those alternatives.

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, no stated prerequisites, and no mention of when to prefer this over siblings such as marketplace_deploy or marketplace_control. The agent must infer the usage context entirely.

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 it does disclose the operation is a read (GET) against the Node-RED Admin API at 127.0.0.1:1880. However it omits whether an auth token is required, what happens on connection failure, and whether flow credentials are included in the payload.

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 endpoint is front-loaded. It is efficient, though it conveys little beyond the route itself.

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?

An output schema exists, so return values need not be explained, and there are no parameters to document. For a zero-arg read tool this is close to complete, with only the auth/error behavior left unstated.

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 to disambiguate and the baseline of 4 applies. The description adds nothing here, which 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?

Names a specific verb and resource ('GET /flows') against a named API, so an agent can tell it retrieves the flow list. It does not explicitly differentiate itself from siblings like nodered_info or nodered_deploy_flows, but the endpoint phrasing 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 call this versus alternatives, no prerequisites, and no mention of authentication against the Admin API. The agent must infer usage entirely from the route string.

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 burden. The verb 'probe' implies a non-destructive, likely read-only network check across services, and the output schema documents the return shape, but the description discloses nothing about network requests, auth requirements, timeouts, or what happens on partial failure.

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

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

A single front-loaded sentence with the verb first and the targets listed; zero filler. It is terse to the point of omitting any context, but 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?

With zero parameters and an output schema documenting the return values, the description does not need to explain results. However, it omits why an agent would invoke a whole-stack probe instead of the granular sibling tools, leaving a real contextual 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies per the rules; no parameter-level meaning 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?

States a specific verb ('Probe') and enumerates the exact resources targeted (MediaMTX, Node-RED Admin, TAK Marti, infra-TAK console), letting an agent identify it as a composite stack check versus the per-service siblings like mediamtx_info or nodered_info. It does not explicitly say what 'probe' produces (a health/status aggregate), so it falls short of the 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?

There is no when-to-use guidance and no mention of alternatives, even though obvious candidates exist (mediamtx_info, nodered_info, docker_ps for individual services). The agent must infer that this tool exists to check the whole stack at once rather than a single component.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'List' implies a safe read, but the description does not state that it is read-only, whether it paginates, whether it requires authentication, or what triggers an empty result; it discloses nothing beyond the function name.

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 resource is front-loaded after the verb. It is appropriately sized for a zero-parameter list tool, though it is so terse that it borders on under-specification rather than optimal conciseness.

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 an output schema present, the return shape need not be described, and there are no parameters to document. However, for a standalone listing tool with no annotations, the description omits basic behavioral context (read-only nature, pagination, auth), leaving it minimally viable rather than 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 tool takes zero parameters, so there is no parameter semantics for the description to explain. Per the baseline for parameterless tools, the schema fully covers the input surface and the description need not add anything.

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 ('List') and resource ('TAK Server Video Manager feeds'), so the agent knows exactly what the tool returns. It does not explicitly differentiate itself from the sibling tak_publish_video, though the list-vs-publish contrast is inferable from the names.

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 guidance on when to call this tool versus alternatives such as tak_publish_video, nor any prerequisites or preconditions. The description only restates the tool's function without contextual 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 behavioral burden. It does not disclose idempotency, what happens when the path already exists, auth/permission requirements, or whether registration is destructive or reversible — all critical for a write operation.

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

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

A single front-loaded sentence with the verb and target up front. 'With decomposed fields' is the one expendable, unexplained clause that slightly dilutes it.

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?

An output schema exists so return values need no explanation, but for a no-annotation mutation tool with 0% parameter documentation, the description leaves callers without the semantics, prerequisites, or failure behavior they need.

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

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

Schema description coverage is 0% and the description explains neither 'path' nor 'alias'. The phrase 'decomposed fields' vaguely alludes to the parameters but never says what decomposed means or how alias relates to path.

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: 'Register a MediaMTX path on TAK Video Manager', which separates it from siblings like tak_list_videos or mediamtx_paths. However, 'with decomposed fields' is undefined jargon that adds no discriminating meaning.

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

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

No when-to-use guidance, no prerequisites, and no reference to alternatives among the 18 siblings, despite tak_list_videos and mediamtx_paths being plausible near-neighbors. The agent must infer the trigger context entirely.

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