Kranz MCP

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

No annotations exist, so the description carries the full behavioral burden. It conveys the mutation intent ('cancel') and that it targets running actions, but says nothing about what state the action ends in, whether cancellation is idempotent, error behavior for already-finished actions, or permission 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 tight sentence, front-loaded with the verb and scope. Nothing redundant; every word carries weight.

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 needn't be explained, but for a destructive mutation tool with no annotations and an undocumented required parameter, the description is far too thin. It lacks behavioral, safety, and parameter detail an agent needs to invoke it 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%, and the description adds zero parameter context. The 'action' parameter is undocumented anywhere, and the 'runtime' parameter's meaning ('Project runtime to address...') is defined but not clarified further. With an undocumented required parameter, the description should compensate but does not.

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 ('cancel') and resource ('currently running non-interactive action'). The 'non-interactive' qualifier usefully scopes it, distinguishing it from interactive actions, though sibling tools like stop/action_run aren't referenced to sharpen the boundary.

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 word 'Explicitly' hints that this is distinct from something implicit, but the description never says when to use this versus stop, down, or action_run, nor does it state prerequisites. No when/when-not guidance is provided.

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, and it discloses almost nothing. "Describe" weakly implies a read, but there is no statement about side effects, permissions, or runtime resolution behavior beyond what the schema already says.

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 waste, so it is maximally brief and front-loaded. That brevity, however, comes at the cost of substance, leaving key specifics unstated rather than merely compressed.

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, and the runtime parameter is covered by the schema. For a simple two-parameter read tool this is close to sufficient, but the cryptic OWNER/ACTION format and absence of any usage context leave minor 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 50%: runtime is documented in the schema but action has no description anywhere. The "OWNER/ACTION" phrasing adds a format hint for the action parameter that the schema lacks, which is genuinely useful, but it does not fully compensate for the undocumented parameter.

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?

"Describe" is a specific verb and the resource is an action, with "one" signaling a singular lookup versus the sibling action_list. However, "exact OWNER/ACTION" is cryptic shorthand and does not clearly explain what an OWNER/ACTION identifier is or how this differs from action_result, which is only inferable from the name.

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 explicit when-to-use guidance or mention of alternatives such as action_list or action_result. The singular "one" weakly implies lookup of a specific action, but the agent must infer the selection logic 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?

No annotations are provided, so the description carries the full behavioral burden, yet it discloses almost nothing beyond the verb. Read-only semantics are only implied by 'List'; scope (project-scoped via the server's starting project), pagination, and result ordering/limits are unstated.

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, front-loaded with the action and qualified by the filter. Nothing redundant and nothing 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?

An output schema exists, so return values need not be described, and the runtime parameter's scope is covered in-schema. However, with no annotations and a terse description, the agent gets no statement of read-only safety, project scoping defaults, or result volume limits.

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%: the 'runtime' parameter is documented in the schema, while 'owner' is bare. The description compensates for 'owner' by stating it filters by exact match and is optional, but adds nothing about runtime scoping or matching syntax beyond what the schema already says.

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 ('List actions') and the optional filter dimension ('exact owner'), so the agent knows this is the read/discovery tool. It does not explicitly differentiate itself from siblings like action_info, action_run, or action_result, though the list-vs-single/exec verbs make the distinction reasonably inferable.

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 filtered by exact owner' implies usage (use when you want a broad listing or a per-owner subset) but never states when to prefer this over action_info or action_result. Usage is implied rather than guided.

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 hints that results may be "retained" (historical), but says nothing about whether it blocks, what happens for an in-progress action, auth requirements, or pagination. For a tool with zero annotation coverage this is a notable gap.

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

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

A single compact sentence with no filler. However, the terseness comes at the cost of the usage and parameter detail the tool actually needs, so it reads as under-specified rather than optimally structured.

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

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

An output schema exists, so return values need not be described. But with no annotations, an undocumented required `action` parameter, and no usage guidance, the description is insufficient for an agent to confidently select and invoke this 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 coverage is only 33% and the required `action` parameter has no description in either place. The description adds a useful hint for `run` (absolute vs. negative-relative), but leaves the required parameter and the run/runtime relationship unexplained.

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 ("Return ... action result"), which cleanly separates it from action_list, action_run, and action_cancel. It does not explicitly differentiate from action_info, which plausibly overlaps, 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?

No statement of when to use this versus action_info, action_list, runs, or wait. The phrase "current or retained" implies post-completion retrieval but gives no exclusion or precondition for choosing 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 and does disclose one genuinely non-obvious trait: MCP request cancellation does not cancel the action, implying fire-and-check semantics. However, it says nothing about permissions/auth, side effects or destructiveness, whether the call blocks, or the confirmation_token flow for risky actions (only the schema hints at that).

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

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

Three short sentences, zero filler, with the core purpose and the parameterization/schema rule front-loaded and the cancellation caveat last. Every sentence earns its place.

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

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

For a tool with an output schema and four parameters, the essentials are covered: what runs, how to supply params, where to find the schema, and the cancellation caveat. The gap is the plan/confirmation-token workflow for guarded actions, which the description leaves to the schema.

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 75% (params, runtime, confirmation_token all documented in-schema; only 'action' is bare). The description adds only that params holds 'typed' values for a parameterized action and that action_info yields the advisory schema. Baseline 3 is appropriate when the schema already documents most 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+resource ('Run one non-interactive action') and scopes it to non-interactive execution, which separates it from interactive variants. It also cross-references action_info for schema discovery, implicitly distinguishing itself from that lookup tool. It stops short of naming action_result/action_cancel, but the core purpose 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?

Gives clear context: use this to run a single non-interactive action, pass params only for parameterized actions, and consult action_info for the advisory schema. The 'non-interactive' qualifier implicitly excludes interactive actions. No explicit when-not guidance relative to plan/up/down or how to retrieve results via action_result.

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; the word 'Return' correctly implies a read-only, non-mutating operation. However, it discloses nothing about journal retention, what happens when a cursor expires, or whether the query is resumable — behavioral facts an agent polling this endpoint would need.

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 a colon-delimited enumeration and zero filler. It is appropriately sized for the amount of information conveyed, though it stops just short of the routing detail that would make it exemplary.

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 values need not be restated, and the description covers the delta-journal concept adequately for a zero-required-parameter read tool. What is missing is the workflow context — how this relates to wait (which also produces cursors) and how to keep polling incrementally — leaving the agent to infer the intended call pattern.

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% (below the 80% baseline), and kinds/limit have no schema descriptions at all. The description partially compensates by mapping the kinds enum values to plain English ('service and action transitions, detected-port changes, and configuration reloads') and by naming the cursor anchor that maps to 'since', but limit, selectors, runtime, and since_generation get no added meaning.

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+resource (return what changed in the runtime) and enumerates the categories returned: service/action transitions, detected-port changes, config reloads. That lets an agent distinguish it from a snapshot tool, but it never explicitly contrasts with siblings like wait, status, or logs, 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?

It mentions the cursor mechanism ('after a cursor') which hints at incremental polling, but there is no explicit when-to-use guidance and no mention of the obvious alternatives (wait, status, logs) that an agent must choose between. Cursor mechanics are a mechanism, not usage guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the scope of inspection, which is real content, but never states that the operation is read-only/non-mutating, what happens on failure, or whether it has side effects. For a tool an agent might invoke casually, the safety profile is left unstated.

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 verb and purpose, followed by a compact enumeration of checks. Every clause earns its place and there is no filler.

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

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

An output schema exists, so return values need not be explained, and the description adequately scopes what the tool inspects. The only shortfall is the unaddressed safety/read-only nature of the operation, which matters more here because no annotations cover it.

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 single 'runtime' parameter has 100% schema description coverage, and the rule sets the baseline at 3 when the schema already documents parameters. The description adds nothing about runtime selection or what omitting it means, so it neither helps nor hurts.

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 ('Run project preflight checks') and enumerates exactly what is inspected: configuration diagnostics, dependency cycles, service directories, env files, shells, and declared ports. An agent immediately knows this is a composite diagnostic sweep rather than a single-resource read. It stops short of naming how it differs from siblings like 'health' or 'status', so it does not earn 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 word 'preflight' implies the usage window (before starting/up), which is genuinely useful implied guidance, but no alternative tool is named and no when-not condition is given. With siblings 'health', 'status', and 'ports' in the same namespace, the description leaves the 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 must carry the behavioral burden; it discloses a significant constraint not present in the schema — that only session-started runtimes are eligible and human-started ones are never affected. It does not address reversibility, graceful shutdown, or failure behavior for an unknown runtime, which a destructive operation would ideally cover.

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, zero padding, with the core purpose and the exclusion rule front-loaded. Nothing is redundant with the schema text.

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, and the description supplies purpose, scope, and the key usage exclusion. For a destructive, confirmation-gated operation it could do slightly more on error/permission behavior, but nothing essential to invoking it correctly 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 description coverage is 100%, so both parameters (runtime and confirm) are already documented in the schema, including the 'as returned by up' provenance and the confirm=true requirement. The description adds only the session-scope constraint on the runtime, which maps to the schema baseline rather than new syntax.

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 (Stop) and resource (a runtime) and immediately narrows scope to runtimes 'this MCP session started with up.' The cryptic tool name 'down' is fully disambiguated, and the session-scope qualifier separates it from siblings like stop, restart, and run_delete.

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

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

Explicitly states the 'when' (stopping a runtime started via up in this session) and the 'when-not' (runtimes started by a person are never stopped from here). It references the counterpart tool 'up' but never names an alternative for the excluded case, so routing for person-started runtimes is left implicit.

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 something valuable beyond the schema: the returned graph merges declared dependency/prerequisite/ownership structure with live service state, which is a genuine behavioral trait. However, it never states that this is a read-only, non-mutating operation, nor anything about cost, latency, or scope limits.

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

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

A single sentence that is front-loaded with the verb and resource, then appends the differentiating detail about live state. No filler, no redundancy.

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

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

An output schema exists, so return-value shape need not be explained, and the one parameter is fully documented in schema. What the description adds — the three graph dimensions and the live-state merge — covers the essentials for a read-only introspection tool. It is only slightly short on scope/cost expectations.

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 a single optional 'runtime' parameter and schema description coverage is 100%, so the schema already explains name/id resolution and the omit-to-use-current-project behavior. The description adds nothing about this parameter, which is acceptable at full coverage but earns no bonus.

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 pairs a clear verb ('Return') with a specific resource: the 'declared dependency, prerequisite, and ownership graph', and it distinguishes itself from a static topology dump by noting that live service state is folded in. It never contrasts itself with siblings like status, plan, or runtimes by name, so it is clear but not fully 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?

There is no explicit statement of when to call this versus alternatives such as status or plan, nor any prerequisites or exclusions. The phrase 'live service state folded in' faintly implies this is the tool for combined static-plus-runtime topology, but that hint is too weak to count as real guidance.

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

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

With no annotations, the description carries the full burden. It discloses the return shape and that a last error and history may be included, implying a read-only diagnostic. However, it says nothing about permissions, side effects, cost, or whether the probe is triggered or merely reported.

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 action verb first and no filler. It is efficient, though the trailing clauses about target, error, and history slightly diffuse the core statement.

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 enumerated, and all parameters are documented with no required fields. For a read-only diagnostic tool with no annotations, the description is adequate, missing only the when-to-use framing that would fully orient the agent.

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 (history, runtime, selectors) are already documented in the schema. The description's mention of 'recorded health history' loosely maps to the history flag but adds no syntax, defaults, or semantics beyond the schema; 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 verb ('Return') and resource ('readiness and liveness probe state'), naming the concrete payload fields (probed target, last error, history). It is clear what the tool does, though it does not explicitly distinguish itself from neighbors like 'status' or 'doctor'.

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 call this versus 'status' or 'doctor', and no conditions or exclusions are stated. The description only says what it returns, leaving the agent to infer the use case.

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 entire burden and delivers very little. 'Bounded' hints at a limit but never states the default for 'tail', how pagination via 'cursor' behaves, whether queries are read-only, or what permissions are needed. The only useful signal is that output is 'normalized'.

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 no buried lede. It is efficient, though the brevity tips into under-specification rather than precision.

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?

This is a nine-parameter query tool with an output schema, so return values needn't be described, but the description omits pagination, runtime/selector targeting, source filtering, and the meaning of the run/runs pair. An agent cannot confidently compose a call from this description alone.

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 9 parameters and only 33% schema description coverage, the description is expected to compensate and does not. It never explains runs vs run, tail, since, cursor, sources, selectors, or with_actions, so six parameters remain opaque across both schema and prose.

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 has a specific verb and resource ('Query ... logs') and scopes it to 'service and action logs', which is more than a tautology. However, the qualifiers 'bounded' and 'normalized' are undefined jargon and it never distinguishes itself from the closely named sibling 'logs_clear' or from 'action_result', leaving the agent to infer the boundary.

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, no prerequisites (e.g. a runtime must exist), and no mention of alternatives. 'logs_clear' sits directly in the sibling list and is the obvious disambiguation target, but the description is silent on 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 must carry the full behavioral burden for what is clearly a destructive operation, yet it never states that log data is permanently removed, whether the effect is reversible, what permissions are required, or how much data is affected. 'Bounded' and 'explicitly selected' are the only hints about scope and are left undefined.

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 wasted words. It is efficient, though the brevity comes partly at the cost of the missing behavioral and parameter detail 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?

For a destructive tool with zero annotation coverage, a required undocumented parameter, and no usage guidance, the description is inadequate — it omits irreversibility, permissions, and selector semantics. The presence of an output schema excuses it from explaining return values but not from these 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 coverage is only 33% — 'runtime' is documented but 'selectors' (required, array of strings, minItems 1) and 'with_actions' are not described in either the schema or the description. The description's phrase 'explicitly selected bounded service/action log buffers' vaguely gestures at selectors but provides no format, syntax, or meaning for that critical required parameter.

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 ('Clear') and resource ('service/action log buffers'), so the action is unambiguous. It does not name or contrast with the sibling 'logs' tool, which is the obvious read counterpart, so it falls short of full sibling differentiation.

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

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

There is no statement of when to use this tool versus 'logs' or any other sibling, and no prerequisites or conditions for invocation. The word 'explicitly selected' hints at scoping but gives no actionable guidance about when clearing is warranted.

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

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

With no annotations, the description carries the full burden and does disclose the most important behavioral fact: resolution happens without execution, and the returned plan 'carries the exact command it would run'. It does not address permissions, validation/failure behavior for bad params, or whether resolution has any side effects, so transparency is good but not exhaustive.

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

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

Two sentences, zero filler, with the non-execution constraint front-loaded before the params cross-reference. Every clause carries information an agent needs.

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-shape explanation is not owed, and the description answers the decisive question (this plans, it does not execute) plus the params-typing question via the action_run cross-reference. The remaining gap is the unaddressed selectors/runtime/include_dependencies semantics in an otherwise annotation-free, six-parameter 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 coverage is 50% across six parameters, and the description adds real value on two of them: it maps the enumerated operations to start/stop/restart/action and says params is the same typed object action_run takes. It says nothing about runtime, selectors, or include_dependencies, leaving half the parameters 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 (resolve) and resource (a versioned start/stop/restart/action plan), and immediately scopes it with 'without executing it', which separates it from the sibling mutators start, stop, restart, and action_run. An agent can tell what this tool does and does not do 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 phrase 'without executing it' implies the dry-run/preview use case and points at action_run as the executing counterpart for parameterized actions, but there is no explicit when-to-use statement, no routing rule such as 'call plan before start', and no stated conditions or exclusions. Usage is inferred rather than instructed.

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. It does disclose one non-obvious behavioral trait: results include processes Kranz does not manage, i.e. the scan is broader than the tool's own managed scope. It says nothing about required privileges, whether the check is local or remote, or failure behavior when a port is closed.

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 scope qualifier is attached efficiently. It is appropriately sized for the operation, though the brevity is partly what leaves the usage gap.

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. However, for a two-parameter diagnostic tool with no annotations, the description omits the runtime-scoping interaction (i.e. that omitting `runtime` targets the server's own project) and any privilege or scope caveats.

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%: `runtime` is documented in the schema, while `ports` has no description. The phrase 'explicit port numbers' partially compensates by signaling that specific port values must be supplied, but adds no format or range detail beyond the schema's integer 1-65535 bounds.

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 (Identify) and resource (current listener on explicit port numbers), and adds a meaningful scope note that it covers processes Kranz does not manage. It does not explicitly distinguish itself from the sibling `ports` tool, 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?

There is no explicit when-to-use guidance and no mention of alternatives such as `ports` or `status`. The phrasing 'on explicit port numbers' faintly implies you must already know the ports you care about, but this is inference rather than stated guidance.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses that the tool does not change port owners, which implies a non-mutating operation, but it omits other operational traits such as required permissions or side effects. This is minimally adequate but leaves clear gaps.

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 a single, front-loaded sentence with no wasted words. It immediately states the action, object, and a key constraint.

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

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

The tool is low-complexity with a fully documented schema and an output schema, so return values need not be explained. The description covers non-mutation but lacks routing guidance among siblings like 'port_inspect', and with no annotations, more operational detail would be expected.

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 fully documented in the input schema. The description adds no additional parameter semantics beyond what the schema already provides, making the baseline score of 3 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?

The description uses a specific verb ('Inspect') and resource ('declared and detected service ports'), making the tool's purpose clear. However, it does not differentiate itself from the sibling tool 'port_inspect', leaving ambiguity about which port-inspection tool to choose.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives such as 'port_inspect' or 'runtimes'. It only implies a read-oriented usage through 'without changing their owners', but gives no context or exclusions.

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 usefully discloses that changes are reconciled into already-running services (a live effect, not a restart), but says nothing about permissions, downtime, idempotency, or what happens if the edited config is invalid.

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 followed by the trigger. Every clause earns its place with no redundancy.

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

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

An output schema exists, so return values need not be explained, and the two parameters are fully documented. What remains thin is failure/safety behavior on a tool that mutates live service state, which the description leaves 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 description coverage is 100%, so both `force` and `runtime` are already fully documented in the schema. The description adds no syntax or usage nuance beyond that, which is the expected baseline when the schema does the work.

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?

Specific verb+resource: 'Re-read the configuration from disk and reconcile it into the running services' states exactly what happens. It does not, however, differentiate itself from closely related siblings like restart or up, which an agent could easily confuse with a config reload.

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?

'Use it after editing a Kranz configuration file' gives an explicit triggering condition. There is no guidance on when NOT to use it or on choosing between reload and restart, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden, and it does disclose one important trait: the cascade to 'affected dependents.' It omits the confirmation-token workflow (a one-shot token tied to a resolved plan), permission requirements, and reversibility, so the behavioral picture is only partial.

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 efficient sentence with the action front-loaded and no wasted words. It is terse to the point of omitting needed prerequisites, but the structure itself is clean.

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 the cascade detail is a plus. But for a mutation tool with no annotations, the description should have covered the plan/confirmation prerequisite and at least gestured at safety, which it does not.

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

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

Schema description coverage is 100%, so the schema already documents runtime, selectors, and confirmation_token thoroughly, setting the baseline at 3. The description's mention of 'resolved application plan' loosely aligns with confirmation_token but adds no syntax or format detail beyond the schema.

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

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

The verb 'restart' and resource 'selected services' are stated explicitly, along with the scope of 'affected dependents.' However, it does not distinguish itself from close siblings like reload, start, or stop, which an agent could reasonably confuse for a restart.

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 restart over reload/start/stop, nor any statement of prerequisites. The reference to a 'resolved application plan' and the required confirmation_token imply a prior plan step, but the description never says a plan/confirmation flow is required first.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses that the run AND its retained output are destroyed, and that explicit confirmation gates the action. It stops short of stating irreversibility, required permissions, or any rate/locking considerations for a destructive 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 that packs purpose, scope, destruction target, and the confirmation gate with no padding. Minor jargon ('absolute ... run') slightly reduces immediate clarity but costs nothing structurally.

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 the description covers the destructive scope and confirmation requirement. The remaining gap is the missing routing guidance against action_cancel for non-completed runs, which leaves a small decision hole.

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

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

Schema description coverage is 100%, so the schema already documents target, run, confirm, and runtime — including the confirmation requirement and the runtime-omission default. The description adds no parameter-level detail beyond this, so 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 verb and resource ('Delete one completed absolute service or action run and its retained output'), and the 'completed' qualifier scopes it meaningfully. It does not explicitly name the closest sibling (action_cancel), so differentiation is only implied by the 'completed' constraint 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: only 'completed' runs are eligible and confirmation is required, which suggests running jobs belong to action_cancel. However, no alternative tool is named and no explicit when-not condition is given, so the agent must infer routing.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the catalog includes provenance and output retention state, which adds useful context about returned data. However, it does not explicitly state that this is a read-only operation, nor does it mention any side effects, auth needs, or rate limits.

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 front-loaded sentence with no wasted words. The only minor issue is the vague term 'bounded', but the sentence is otherwise efficient and appropriately sized.

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

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

For a simple list tool with an output schema and a well-described optional parameter, the description covers what is returned. It falls short on usage context—when to prefer 'runs' over similar siblings like 'runtimes' or 'action_list'—and does not clarify what 'bounded' means in practice.

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 single runtime parameter is fully documented in the schema. The description adds no additional meaning about the runtime parameter, making 3 the baseline 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?

The description states a specific verb (Return) and resource (service and action run catalog), and adds provenance and output retention state. It distinguishes itself from most siblings, though 'bounded' is ambiguous and it never names the adjacent runtimes or action_list tool for contrast.

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 is given about when to use this tool versus alternatives such as runtimes, action_list, or run_delete. The description only says what it returns, not the context or conditions that select 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?

No annotations exist, so the description carries the entire burden. It discloses user-scoped visibility and that returned entries are valid as a runtime argument, but says nothing about safety profile, rate limits, pagination, or ordering beyond the read-only implication of 'List'.

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

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

Two sentences, zero filler, and the core purpose is front-loaded before the recovery-workflow hint. 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?

An output schema exists, so return values need not be restated, and for a zero-parameter list tool the agent only needs to know why and when to call it plus how to reuse the result, both of which are covered.

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 description has nothing to disambiguate and schema coverage is moot. Baseline of 4 applies; the second sentence usefully explains how the result feeds into other calls' runtime argument.

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 the Kranz project runtimes') scoped to the calling user's visibility, which is enough to separate it from 'runs' and 'run_delete' in the sibling list. It stops short of explicitly naming a sibling it is not, so it lands just below the top of the scale.

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 an explicit conditional trigger: read this first when a call returns runtime_required or runtime_not_found. That is a clear 'when' with a concrete downstream action, but there is no statement of when this tool is not needed and no named 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?

No annotations are provided, so the description carries the full burden and largely drops it. It doesn't say whether starting is idempotent, what happens to already-running services, or why a one-shot confirmation_token is required — a strong signal of a two-phase confirm flow that goes unexplained.

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 padding, which is efficient. It loses a point only because the brevity crosses into under-specification for a mutating 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 annotations, four parameters, a required confirmation token, and a mutation semantics, one sentence is not enough. An output schema exists so return values needn't be explained, but the confirmation flow, dependency default, and relationship to 'plan'/'up' remain undocumented.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters, and the baseline is 3. The description's reference to the 'resolved application plan' loosely connects to confirmation_token but adds no syntax, format, or selector-matching detail beyond the schema.

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

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

It states a verb ('Start') and a resource ('selected services'), but the qualifier 'using the resolved application plan' is jargon that doesn't clarify behavior. It also fails to distinguish this tool from close siblings like 'up', 'restart', and 'reload', leaving the agent to guess which entry point applies.

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 mention of alternatives such as 'up' or 'plan'. The phrase 'resolved application plan' hints that a plan step precedes this call, but the relationship is never made 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?

No annotations are provided, so the description carries the full burden. It implies a read ('Return... status') and hints the response includes a structured cause, but says nothing about latency, whether it contacts the runtime, permissions, or what 'live' actually refreshes—and the cause detail overlaps with the existing output 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 sentence with the core action front-loaded, which is good. But the second half is an unnecessarily convoluted clause that costs more parsing effort than the information it delivers, and could have been a plain statement about the state cause field.

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 the input schema is fully described. What is missing is relational context: no indication of how this differs from health/doctor/logs or the scope of what gets inspected, which leaves the definition only minimally viable for a crowded sibling set.

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 (runtime, selectors) are already documented in the schema. The phrase 'selected services' loosely maps to selectors but adds no syntax, defaulting, or filtering semantics beyond what the schema states. 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 concrete verb and resource: 'Return live status for selected services.' However, it never distinguishes itself from close siblings like health, doctor, or logs, and the trailing clause about 'the structured cause of a state whose reason is not the state itself' is opaque rather than clarifying.

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. With siblings such as health, doctor, logs, and ports in the same namespace, an agent gets no help deciding when 'status' is the right call versus those.

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 burden of behavioral disclosure. It usefully reveals a cascade effect ('affected dependents'), which the agent could not infer from the name alone, but it omits whether the action requires confirmation, whether it is reversible, and what the safety/auth profile is.

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 core action leads and the mechanism follows. Nothing extraneous, though the terse form leaves behavioral gaps unaddressed rather than being maximally informative.

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 the 3-param surface is simple. However, for a consequential mutation with no annotations and a confirmation_token in the schema, the description should confirm the plan/confirmation prerequisite and reversibility, which it does not.

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

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

Schema description coverage is 100%, so the schema already documents runtime, selectors, and confirmation_token. The description only loosely references 'selected services' and the 'resolved plan' without adding format, matching, or token-lifecycle detail beyond the schema.

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

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

States a specific verb and resource ('Stop selected services and affected dependents'), which tells an agent what it does. It is distinguishable from siblings like 'start'/'restart', but it never contrasts itself against 'down', which likely also stops things, so the boundary is not fully pinned down.

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 explicit when-to-use/when-not guidance and no stated alternatives. The phrase 'using the resolved application plan' hints at a plan prerequisite and the confirmation_token implies a two-step flow, but the agent is left to infer that rather than being told.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that the tool spawns a background process that outlives the MCP session, where it persists ('kranz ps'), and that it lasts until someone stops it. It also states what it does not do ('without starting any service'), which is the key side-effect an agent needs to know. This is the exact behavioral context annotations would otherwise have had to supply.

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

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

Two sentences, front-loaded with the scope constraint before the durability detail, and the usage restriction last. Every clause carries information: scope, isolation from services, process lifetime, persistence location, and when to invoke. No filler.

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

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

An output schema exists, so return values needn't be explained, and both parameters are fully documented in the schema. The description adds the persistence and confirmation rationale an agent needs before calling. It could be slightly more complete by pointing at the sibling used to stop or inspect the runtime, but nothing critical 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 description coverage is 100%, so the baseline is 3. The description restates the 'process outlives this session' rationale that the confirm parameter's own schema description already gives, adding little beyond the structured field; the directory parameter's default behavior is likewise already documented in 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?

States a specific verb+resource ('Start the runtime of a project') and immediately narrows scope with 'that has none' and 'without starting any service', which separates it from the sibling 'start'. It does not name the sibling alternative outright, so an agent must infer the contrast, but the scope qualifiers make the distinction legible.

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?

'use it only when asked to bring a project up' is an explicit positive condition plus an exclusion ('only when asked'), which is stronger than most definitions. It falls short of 5 because it never names the alternative tool (start/down/restart) that an agent should reach for in other cases.

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. 'Cancellably' is a genuine and useful disclosure (the call can be interrupted), but the description omits what happens on timeout (error vs. return with unmet condition), whether it blocks until a single condition or all selectors, and whether it costs a long-lived connection. For a blocking primitive with zero annotation coverage, these gaps matter.

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 tight sentence with the core action and the condition set front-loaded; nothing is padded. It is efficient, though the extreme terseness leaves the omissions noted elsewhere rather than being wasteful.

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-value explanation is not required. However, for a 4-parameter blocking tool with 2 required params and no annotations, the timeout/cancellation semantics and selector matching rules are left unstated, which leaves the agent guessing about edge-case behavior.

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 75% and the only enum already lists the five condition values, so listing them in the description is largely redundant with structured data. The description adds no syntax for 'selectors' (exact names vs. tags) or the 'timeout' duration format beyond what the schema already states. Baseline 3 is appropriate 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 the verb ('wait') and the exact set of terminal conditions an agent can block on, which is more specific than a bare name. It stops short of naming the resource class (services/containers) explicitly, but the condition vocabulary makes the intent unambiguous. It is reasonably distinguishable from the sibling 'status' (a poll) and 'health'.

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 prefer this blocking wait over polling with 'status' or 'health', nor any guidance on when it is inappropriate. Nothing tells the agent what happens if the condition never becomes true or how 'timeout' interacts with the wait. The word 'cancellably' hints at interruption but gives no usage rule.

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