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

With no annotations at all, the description carries the full behavioral burden. It does not state that the operation is read-only, whether it needs cluster-wide or namespace-scoped RBAC to read NetworkPolicy objects, or what the analysis result looks like (list of policies vs. a verdict on allowed/denied traffic).

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; no repetition of the name or schema. Well sized for a two-parameter read tool.

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

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

No output schema exists, so the description should at least hint at the shape of the analysis (which policies matched, which rules restrict traffic). It also omits any note about permissions or that a missing pod/namespace yields an error, leaving an agent under-informed about results for a tool whose value is entirely in its output.

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% with only two simple parameters, so the schema already conveys pod_name and namespace meaning including the namespace default. The description adds nothing beyond that, which is the expected baseline here.

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 ('analyze') and a specific resource ('NetworkPolicies apply to a pod') plus the second outcome ('detect traffic restrictions'). No sibling tool touches network policy, so an agent can route to this without ambiguity.

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 purpose implies when it is useful (pod connectivity or traffic-blocking issues), but there is no explicit when-to-use, when-not-to-use, or named alternative. The agent must infer that this pairs with check_service_endpoints or trace_service_to_pods for connectivity debugging.

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 the concrete check performed (readiness of backends) which is a real behavioral trait, but leaves unstated whether it returns a list versus an error, severity classification, and whether it is cluster-wide or namespace-scoped by default.

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 followed by the specific detection condition. Zero filler; 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?

For a simple two-parameter read-only diagnostic with fully documented params, the description covers the core intent. With no annotations and no output schema, it should still say what a result looks like (per-service readiness status, list of unhealthy services) to be complete.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds nothing about the parameters — it does not mention the namespace default or the all-services-when-omitted behavior. Since the schema already documents both, the description neither compensates nor adds meaning; slightly below baseline.

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

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

States a specific verb and resource ("check service endpoints") and sharpens it with the exact condition detected: services with no ready backends. It is clearly distinct from siblings like find_orphaned_services or trace_service_to_pods, though it never explicitly names a sibling to contrast 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?

Usage is implied by the stated failure mode (detecting zero-ready-backend services), so an agent can infer when the tool matters. However, there is no explicit when-to-use/when-not-to-use guidance and no routing to the closely related trace_service_to_pods or get_namespace_health.

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. 'Inspect' implies a read-only operation, but it doesn't disclose permission requirements, whether it fails or returns empty when Istio/Linkerd isn't installed, or whether the scan is limited to the given namespace or cluster-wide.

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

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

A single compact sentence with the resource and the enumerated inspection targets front-loaded, and zero filler. Nothing in it needs to be trimmed.

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

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

For a read-only diagnostic with a single optional parameter, the description names what is inspected, which partially compensates for the missing output schema. However, it omits scope-of-namespace behavior, prerequisites (mesh must be installed), and any indication of the result shape beyond the category names.

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

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

Schema coverage is 100%, and the schema already documents the single namespace parameter and its default. The description adds nothing about scope (namespace-only vs. all namespaces) or how the namespace affects the results, so the baseline 3 applies.

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

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

States a specific verb (Inspect) and a specific resource (Istio/Linkerd mesh config), then enumerates the concrete subject matter: VirtualServices, mTLS mode, and sidecar injection status. No sibling tool touches service-mesh configuration, so an agent can select this unambiguously.

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 gives no when-to-use guidance, no prerequisites, and no alternatives or exclusions. An agent must infer from the domain that this is the diagnostic tool for mesh-related questions rather than, say, general networking (analyze_network_policy, inspect_ingress_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 usefully discloses what the check inspects (pod status, replica count, restart rate), but it does not state whether the operation is read-only, what permissions are required, or how failures are surfaced.

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 that identifies the operation and enumerates the key signals checked. Every phrase contributes useful information with no waste.

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

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

For a zero-parameter health-check tool with no output schema, the description adequately explains the conceptual return values (pod status, replica count, restart rate). It could be more complete by clarifying what constitutes a healthy versus unhealthy result or confirming the read-only nature of the check.

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 score is 4. The description adds no parameter detail, but none is needed for a no-argument health check.

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 ('health check') and resource ('CoreDNS'), and lists the concrete signals it reports: pod status, replica count, and restart rate. It does not explicitly differentiate itself from sibling tools such as debug_dns_config or list_pods, so it falls short of a 5.

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

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

The phrase 'Quick CoreDNS health check' implies the tool is for a fast health assessment, but there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives like debug_dns_config or list_pods. Usage is therefore implied 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?

No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is read-only, how the correlation is computed (time proximity? label matching? namespace scoping?), what happens with an empty window, or how costly/heavy the query is across two backends.

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 resource pairing and scope come first. It is efficient but so terse that it borders on under-specification rather than true 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?

For a cross-system correlation tool with no annotations and no output schema, the definition should explain what the correlated result looks like (paired alerts and events? a timeline? confidence scores?) and how namespace scoping affects matching. None of that is present, leaving an agent unable to predict the return shape.

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

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

Schema coverage is 100%, so defaults for time_from (now-1h) and time_to (now) and the optional namespace are already documented. The description's 'in a time window' adds only a light framing and no format or syntax detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (correlate) plus two named resources (Dynatrace alerts, Kubernetes events) and a scope (time window). It is clearly distinct from single-source siblings like get_dynatrace_problems or get_namespace_events, though it never names 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 statement of when to use this over the sibling tools it overlaps with (get_dynatrace_problems + get_namespace_events), no prerequisites (does it require both Dynatrace and cluster access?), and no exclusions. Only the phrase 'in a time window' hints at suitable scenarios.

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. 'Debug' and 'checks' imply a read-only diagnostic operation, and the enumerated checks give real scope information, but the text says nothing about permissions required, whether the checks are safe to run in production, what happens when pod_name is omitted, or what the result looks like.

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, and the three checks are listed compactly. It is efficient but so compressed that no guidance or behavior could be included.

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 and no output schema, the description must carry the definition, and it covers the scope of checks but not the return shape, permissions, or the difference between the optional pod-level path and the cluster-level CoreDNS path. Adequate but with clear gaps for a two-mode tool.

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

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

Schema description coverage is 100% for both optional parameters, so the schema already explains pod_name and namespace including the default. The description adds no additional semantics, such as what the pod_name check reports beyond policy, so the baseline of 3 applies.

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

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

The description pairs a specific verb ('Debug') with a resource ('DNS') and enumerates the three concrete checks: CoreDNS health, Corefile config, and pod DNS policy. However, it does not differentiate itself from the sibling coredns_health_check, which appears to cover an overlapping portion of the same scope.

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 coredns_health_check, check_service_endpoints, or trace_service_to_pods, nor any exclusion or prerequisite. The only usage hint is what the name implies.

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. "Describe" implies a read-only inspection and the phrase "full container specs and rollout conditions" usefully previews the payload, but nothing is said about permissions, error behavior for missing deployments, or how much detail is truncated.

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; the return scope follows immediately after the verb and resource.

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 two-parameter read tool this is close to adequate, and it gestures at the return content. With no output schema and no annotations, however, the agent still lacks any statement of the response shape or failure modes.

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

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

Schema coverage is 100% and both parameters (name, namespace with default) are documented in the schema. The description adds no semantics beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ("Describe a deployment") and adds the scope of what is returned (container specs, rollout conditions). It is readable against the sibling list_deployments without consulting either schema, though it never names that sibling explicitly.

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

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

No when-to-use guidance, no preconditions, and no routing to alternatives such as list_deployments or describe_pod. The only signal is the implicit describe-vs-list contrast carried by the names.

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, and it does disclose the returned content (DNS policy, network config, containers, conditions), which tells the agent this is a read that produces a large structured payload. It does not mention behavior on a missing pod, whether the read requires permissions, or how verbose the output 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 short phrase, front-loaded with the key scope ('Full pod description') and then the notable included sections. It is efficient, though the fragmentary noun-phrase form lacks an explicit verb.

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

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

For a two-parameter read tool with full schema coverage and no output schema, the description adequately conveys what comes back. It leaves gaps around error behavior and output size, which matter for a 'full description' call that can return a large object.

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%, with both 'name' and 'namespace' documented including the default value, so the schema does the heavy lifting. The description adds no further meaning about scoping, name format, or cross-namespace lookup, so the baseline 3 applies.

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

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

The phrase 'Full pod description' names a specific resource and signals a detailed single-object read, which is distinguishable from list_pods and get_pod_logs in the sibling set. It stops short of explicitly contrasting with those siblings, but the verb+resource intent 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 guidance on when to use this instead of list_pods, get_pod_logs, or describe_deployment, nor any prerequisite or exclusion. An agent must infer the selection criteria from the sibling names alone.

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 the meaningful semantic that matching is selector-based against *running* pods (so a service with only pending/crashed pods counts as orphaned), but it says nothing about read-only behaviour, cluster-wide vs per-namespace scope, or what the result looks like.

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 the discriminating condition, with no filler. 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?

For a simple one-parameter read tool this is close to sufficient, but with no output schema the description never indicates what comes back (service names? namespaces? selector details?) or that the operation is non-mutating, leaving the agent to guess at the response shape.

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

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

Schema description coverage is 100% for the single optional `namespace` parameter, and the description adds nothing about it. Baseline 3 applies; the description neither clarifies default scoping nor whether omitting the parameter aggregates across namespaces beyond the schema's 'default' note.

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 plus the exact detection criterion: services whose label selectors match no running pods. That distinguishes it from the neighbouring check_service_endpoints (endpoint-based) and trace_service_to_pods (selector-to-pod tracing), though it never names those siblings explicitly.

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

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

There is no 'use this when...' framing, no exclusions, and no reference to any of the 18 sibling tools. The agent must infer that this is a diagnostic for services that shouldn't receive traffic.

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 disclosure burden, and it only implies read-only behavior through the verb 'Fetch'. It says nothing about tenant/auth requirements, rate limits, pagination, or what a returned 'problem' contains, leaving real behavioral questions unanswered.

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, though the terseness comes at the cost of the behavioral detail the tool needs given it has no annotations.

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 three-parameter, all-optional read tool with full schema coverage and no output schema, the description is marginally adequate, but it leaves the return shape and tenant/auth assumptions unexplained.

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 optional parameters are already documented in the schema, and the description only reiterates the namespace filter. It adds no interpretation of the status enum values or the default time window beyond what the schema states.

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 ('Fetch') and precise resource ('Dynatrace Davis AI problems'), which no sibling tool duplicates, so an agent can distinguish it from the Kubernetes diagnostics in the sibling list. It stops short of explicitly pointing away from the closest relative, correlate_alerts_with_k8s.

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 Kubernetes namespace' implies the intended Kubernetes troubleshooting context, but the description never states when to prefer this over correlate_alerts_with_k8s or get_entity_health, nor any prerequisites such as a configured Dynatrace tenant.

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 full burden. It reveals that data comes from Dynatrace and names two metrics, but says nothing about required credentials/connectivity, time window defaults, behavior when the entity name isn't found, or how many entities a name may match.

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 resource and metric examples front-loaded; nothing is wasted, though it is terse to the point of leaving gaps handled 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 two-parameter read tool with no output schema, the description covers purpose and two sample metrics but omits return shape, time range, and failure modes. Adequate as a minimum viable definition, not complete.

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

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

Schema coverage is 100%, with both entity_name and entity_type documented and entity_type's allowed values enumerated in the schema. The description adds little beyond confirming the 'service/entity' scope; 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 ('Get') plus a specific resource ('Dynatrace health metrics') and names the concrete metrics returned (response time, error rate). It does not differentiate from the closely related sibling get_dynatrace_problems, so an agent must guess which Dynatrace tool to pick.

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 versus get_dynatrace_problems or the Kubernetes-level health tools (get_namespace_health, check_service_endpoints). No prerequisites, no exclusions, no alternative 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 disclosure burden. 'Get' implies a read, but nothing states that events are namespaced-only (no cluster-wide option), whether there is a time window or sort order on results, or how large result sets behave beyond the limit param. For a zero-annotation tool this is 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?

One sentence, zero waste, with the capability and the motivating use case front-loaded. It stops just short of being too terse to be actionable.

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?

All params are optional and fully documented in schema, and there is no output schema to explain. However, the description omits that results are scoped to a single namespace (defaulting to 'default'), which materially affects how an agent calls it across a cluster.

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%, and the description's mention of filtering by type or reason aligns with the event_type/reason params without adding format or interaction detail. Baseline 3 is appropriate when the schema already documents all four parameters including defaults.

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

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

Specific verb+resource: 'Get Kubernetes events' with the filtering dimension (type/reason) named inline. No sibling tool covers events, so differentiation is implicit but the scope is unmistakable.

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?

'Great for spotting OOMKills, BackOffs' implies a diagnostic use case, which gives the agent a hint about when this is the right call. But there is no explicit when-not guidance, no mention of how it relates to get_namespace_health or describe_pod for the same troubleshooting flow.

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 the return shape (pod counts, warnings, overall status) and the read-only nature is implied by 'get', but nothing is said about how the 'health score' is computed, what counts as a warning, or whether this is a live query versus a cached rollup.

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 tightly packed sentence with the resource and result contents front-loaded and zero filler. It is arguably too terse rather than padded, so it scores well on economy but leaves gaps 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 single-parameter read tool with no output schema, the description should explain what the returned health score and warnings mean. It lists the components but not their semantics or scale, so an agent knows roughly what comes back but not how to interpret 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?

There is a single optional parameter with 100% schema coverage, including the default of "default". The description adds nothing beyond the schema, which is acceptable at this coverage level 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 gives a specific verb+resource ('health score rollup for a namespace') and says what the result contains (pod counts, warnings, overall status). It clearly differs in kind from sibling list/describe tools by virtue of being an aggregate, though it never names a sibling explicitly.

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

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

Usage is only implied: an agent can infer this is the at-a-glance check for a namespace. There is no explicit when-to-use, no when-not-to-use, and no routing versus close siblings like get_namespace_events, get_entity_health, or list_pods.

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 operation and mentions tailing, but says nothing about whether logs are current-only or previous-container logs, streaming behavior, permissions, or error conditions.

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. The core action and optional limit are immediately clear.

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 input schema is fully documented and there is no output schema to explain, so the description is minimally adequate. However, with no annotations and no output schema, it should do more to explain log-fetching behavior and when this tool is preferred over pod-description siblings.

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 four parameters are already documented in the schema. The description adds only the idea of a tail line limit, which is already covered by the schema's tail_lines 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?

States a specific verb and resource ('Fetch logs from a pod container') and mentions the optional tail limit. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as describe_pod or list_pods.

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 like describe_pod for pod state versus logs. Usage is only implied by the verb 'Fetch'.

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 safety profile, and 'validate'/'inspect' plus the concrete check list reasonably implies a non-mutating diagnostic. However, it does not state whether it fails or reports on a missing IngressClass, what the result shape is, or whether cluster-wide read permissions are needed.

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 line that names the verb first and then the two checks; there is no filler. Size is proportionate to a two-optional-parameter read tool.

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

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

For a simple two-parameter diagnostic with no output schema, the description covers what is checked but not how to interpret a failure or how results relate to the endpoint-checking sibling. Minimal viable, with a clear gap around outcome semantics.

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% — both parameters (namespace with a stated default, optional ingress_name) are fully documented in the schema. The description adds no syntax or scoping detail beyond that, 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 (validate) and resource (ingress routing) and enumerates the two concrete checks performed: IngressClass existence and backend service endpoints. This distinguishes it from most siblings, though it does not explicitly separate itself from the overlapping check_service_endpoints.

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 alternatives, despite siblings like check_service_endpoints and analyze_network_policy covering adjacent ground. The prerequisite context (e.g., 'use when an Ingress returns 503') is left entirely for the agent to infer.

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 full burden; it does disclose the shape of the return data (replica counts and conditions), which is real added value. It never states that the operation is read-only, what happens for a nonexistent namespace, or whether results are limited to one namespace, leaving behavioral gaps for an unannotated tool.

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 or redundancy. It is efficient, though its brevity leaves room for one more clause of routing or scope guidance without becoming verbose.

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

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

With no output schema and no annotations, the description must cover return semantics, and it partially does (replica counts and conditions). It is still thin on namespacing behavior and failure modes for a Kubernetes listing tool, leaving an agent with unanswered questions before invocation.

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

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

Schema description coverage is 100%, so the single namespace parameter (including its "default" default) is already fully documented in the schema. The description adds no meaning beyond that—for example, whether omitting namespace could ever mean all namespaces—so the baseline of 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+resource ("List deployments") and adds what the response contains ("replica counts and conditions"), which goes beyond the name alone. It does not distinguish itself from the close sibling describe_deployment, so an agent must infer that this is the summary-list variant rather than the detailed one.

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

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

Usage is only implied by the verb "List" and the sibling name "describe_deployment"; nothing states when to prefer this over a detailed describe or over list_pods. No exclusions, prerequisites, or alternative routing are given.

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, and it does add useful disclosure about what the response contains (status, readiness, restart counts) which substitutes for a missing output schema. However, it says nothing about default namespace behavior when the param is omitted, pagination/limits, or whether the call is scoped to all namespaces.

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

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

A single front-loaded sentence that names the resource, the scope, and the returned fields with zero filler or 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?

For a two-parameter read-only list tool with a fully documented schema, the description covers purpose, scope, and return content. The only real gap is behavior when namespace is omitted or whether label_selector is echoed, but nothing critical is missing for correct invocation.

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

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

Schema coverage is 100%, with both parameters fully documented in the schema (namespace default "default", label_selector example). The description adds only that results are namespace-scoped and never mentions label filtering, 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+resource (list pods) plus scope (namespace) and the fields surfaced (status, readiness, restart counts). This distinguishes it from get_pod_logs and describe_pod reasonably well, though it never explicitly contrasts itself with describe_pod, which also targets pods.

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, despite siblings like describe_pod (single-pod detail) and list_deployments. An agent must infer that this is the 'many pods, summary view' tool from the name alone.

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 full disclosure burden. It does reveal cluster-wide scope ('all nodes') and what signals are examined, but says nothing about read-only safety, permissions required, whether it contacts a live cluster, or failure behavior for unreachable nodes.

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 first and the inspected signals after the dash. Zero filler, 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?

For a parameterless read tool this is nearly sufficient: it tells the agent what is checked and over what scope. The only real gap is that with no output schema, the agent cannot predict the response shape or whether per-node results are aggregated or 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, which is the baseline 4 case — there is no parameter semantics to explain and the empty schema is consistent with a cluster-wide status sweep. Nothing in the description contradicts that.

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 (check network status of all nodes) and enumerates the two things inspected: NetworkUnavailable conditions and PodCIDR allocations. That clearly separates it from the pod-, service-, DNS- and policy-focused siblings, though it never explicitly names a sibling it contrasts 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?

Usage is only implied — an agent can infer it belongs in node-level network troubleshooting, but there is no explicit when-to-use, no statement of when to prefer analyze_network_policy, debug_dns_config, or check_service_endpoints instead, and no prerequisites noted.

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 state whether this is read-only, whether it requires permissions, how expensive the trace is, or what the output looks like.

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 waste. The path chain is compact and immediately readable.

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

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

With no annotations and no output schema, the description should at least explain the return shape or the behavioral profile of the trace. It only states what path is followed, leaving the agent uncertain about output and side effects.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description adds no additional meaning about service_name or namespace beyond what the schema provides, which is the baseline expectation.

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 (trace a Service) and enumerates the exact path traversed: Service → EndpointSlices → Pods → NetworkPolicies. This distinguishes it reasonably well from siblings like check_service_endpoints, though it does not explicitly name an alternative.

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 by 'Trace full path' and the chain of resources, suggesting debugging connectivity across endpoints, pods, and network policies. However, there is no explicit guidance on when to choose this over check_service_endpoints or analyze_network_policy.

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