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

Annotations are absent, so the description carries the full burden of behavioral disclosure. It conveys a read-only operation through the verb 'Read', but does not explain kubeconfig handling, error behavior, whether the target namespace must exist, or what the return value contains.

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, no filler, and the core action is front-loaded. Every word earns its place.

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

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

With no output schema and no annotations, the description should clarify return values and operational context. It does not state what the read returns, how kubeconfig_path affects execution, or any prerequisites. For a simple read tool this is a noticeable gap.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for 'namespace' and the kind enum via 'labels and/or annotations', but kubeconfig_path is entirely unexplained. The parameter meaning is only partially enriched.

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 ('Read') with a precise resource ('labels and/or annotations on a namespace'). It clearly distinguishes the tool from the sibling namespace_metadata_set, which performs the complementary write operation.

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. The sibling namespace_metadata_set is implied as the write counterpart, but the description never states a selection condition or exclusion. An agent must infer usage 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?

With no annotations present, the description must carry behavioral disclosure on its own. It does add one meaningful behavior — deleting a nonexistent key succeeds — but it does not cover other likely behavioral concerns such as permissions, whether setting an existing key overwrites it, or failure behavior for a nonexistent namespace.

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 definition is two short sentences with no filler. The primary operation is front-loaded and the deletion edge case is a useful, non-redundant addition.

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 metadata mutation tool, the description plus schema is largely sufficient: the required parameters are identifiable and the unusual idempotent-delete behavior is stated. Still, no annotations and no output schema mean the definition leaves room for additional context about prerequisites and failures.

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 low (20%), and the description partially compensates by clarifying that 'kind' selects labels vs annotations and that 'key' is the metadata key being deleted. It does not explain namespace or kubeconfig_path, although those are fairly self-explanatory from their names and types, and the value-null semantics are already 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?

The description uses a specific verb combination ('Set or delete') with a precise resource ('one label or annotation on a namespace'), which clearly conveys the mutation operation and distinguishes it from the sibling namespace_metadata_get tool.

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

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

The operation is stated clearly, so an agent can infer that this tool is for modifying namespace metadata rather than reading it. However, the description does not explicitly mention when to use it over namespace_metadata_get or provide any exclusion/alternative 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 burden of behavioral disclosure. It mentions that output is capped, which is useful, but does not disclose side effects, authentication/connection requirements, failure behavior, or the fact that arbitrary commands may have cluster-wide impact.

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 compact and front-loaded with the primary action, and the additional output-cap warning earns its place. It is lean, though slightly under-specified for the number of parameters involved.

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?

Given no output schema, no annotations, and sparse parameter documentation, the description leaves important context missing: what the command result looks like, how optional parameters behave, and whether any preconditions exist before invoking the vcluster. The output cap notice is the only contextual detail provided.

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 only 25%, with just the command parameter described. The description provides general advice about narrow queries but does not explain the semantics of name, namespace, or kubeconfig_path, leaving the agent to infer them from names alone.

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

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

The description states a specific verb and resource: 'Run a command inside a vcluster via vcluster connect.' This clearly distinguishes it from the sibling tools like vcluster_kubeconfig, vcluster_pause, and vcluster_describe.

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 operational guidance ('prefer narrow queries over -o yaml across all namespaces') and warns about output capping, which implies this tool is for targeted queries. However, it does not explicitly state when to use this tool versus alternatives or when not to use 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 are provided, so the description carries the behavioral burden. It explicitly states 'Read-only', which is important safety information, but it does not disclose auth requirements, side-effect confirmation beyond read-only, or what the returned report contains.

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 two short sentences with no filler. The purpose is front-loaded, and the follow-up sentence provides actionable context without 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 simple read-only diagnostic tool, the description covers the key use case and safety trait. However, with no output schema and no annotation support, it omits return-value expectations and parameter semantics, leaving a moderate completeness gap.

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

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

Schema description coverage is 0%, yet the description adds no direct meaning to the three parameters. The property titles (Name, Namespace, Kubeconfig Path) are self-evident, but the description never explains which parameters are needed or how they interact.

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

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

The description states a specific action ('Report') and a specific resource ('control-plane certificates and expiry for a vcluster'). It is distinct enough from siblings like vcluster_describe or vcluster_kubeconfig, though it does not explicitly contrast them.

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

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

The description gives a concrete trigger scenario: use it when a vcluster appears healthy but is unreachable, because expired certs produce opaque connection failures. It provides clear context but does not mention alternatives or explicit when-not-to-use conditions.

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 burden of behavioral disclosure. It does disclose a meaningful trait: 'Never switches the caller's kube context.' However, it doesn't mention other potential behaviors like permissions, side effects, or error conditions. This is a useful but partial disclosure, warranting a mid-range score.

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 extremely concise: two short sentences with no filler. It front-loads the primary action and includes a useful behavioral note. Every word earns its place, making it appropriately sized for the information it conveys.

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 12 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain parameter semantics, expected side effects, prerequisites, or return behavior. The single behavioral note is insufficient for an agent to use this tool correctly without additional context.

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 only 25%, so the description should compensate by explaining parameters. The description does not mention any of the 12 parameters (name, expose, values, etc.). It adds zero meaning beyond what the schema already provides, and leaves the majority of parameters undefined.

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 clearly states the action: 'Create a vcluster.' This is a specific verb and resource, and it distinguishes from siblings like vcluster_list, vcluster_delete, etc. The additional note about not switching kube context adds clarity 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 description provides no guidance on when to use this tool versus alternatives. It doesn't mention context, prerequisites, or conditions favoring this over sibling tools. The verb 'create' implies usage, but there is no explicit or implied guidance beyond that.

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 behavioral disclosure burden. It does disclose two key traits: deletion is irreversible, and the host namespace is preserved by default. However, it omits other important behaviors such as wait blocking by default, PVC deletion semantics, and the destructive potential of delete_namespace, which is only covered in the schema, not the description.

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 with no filler. The key facts—delete action, irreversibility, and default namespace preservation—are front-loaded and each sentence contributes meaning. This is an excellent example of concise, structured tool documentation.

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 has 7 parameters, no annotations, no output schema, and low schema description coverage. The description covers only the headline destructive behavior and one default. It does not address blocking behavior, data survival, namespace targeting, kubeconfig handling, or not-found behavior, leaving the agent under-equipped to invoke it correctly in varied scenarios.

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 only 29%, so the description should compensate for under-documented parameters. It adds partial meaning by clarifying the default for delete_namespace ('host namespace is preserved by default'), but it says nothing about name, wait, keep_pvc, namespace, kubeconfig_path, or ignore_not_found. The compensation is insufficient for a 7-parameter destructive operation.

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 clear verb and resource: 'Delete a vcluster.' It adds meaningful scope notes ('Irreversible. The host namespace is preserved by default.') that go beyond mere repetition of the tool name. It does not explicitly distinguish from sibling tools, but the delete action itself is clearly differentiated from list, describe, create, pause, and resume.

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 about when to use this tool versus alternatives, nor any exclusions or prerequisites. The description implies 'use this to delete a vcluster,' but it does not discuss cases like pausing instead of deleting, or when keep_pvc or delete_namespace should be set. This leaves the agent to infer usage from the tool 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?

With no annotations, the description carries the disclosure burden. It reveals the namespace default behavior and that the tool surfaces status/resources/configuration, but it does not state whether the operation is read-only, what output format is returned, or whether a kubeconfig is required.

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

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

Two short sentences with no filler; the core purpose is front-loaded and the namespace default follows as a useful clarification.

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 no annotations and no output schema, the description should cover return format, parameter meaning, and behavior. It covers purpose and namespace default but omits kubeconfig_path semantics and any output/error behavior, leaving an agent to guess.

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

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

Schema description coverage is 0%, so the description must explain parameters. It only adds meaning for namespace by giving the vcluster-<name> default; name is left implicit and kubeconfig_path is completely 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?

The description states the tool returns status, resources, and configuration for a single vcluster, which is a clear scope and distinguishes it from vcluster_list. It lacks an explicit verb, relying on the tool name 'describe', and does not specify what 'resources' or 'configuration' include.

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 'one vcluster' wording implies this is for inspecting a single vcluster rather than listing all clusters, but no alternatives or exclusions are named. The namespace default is helpful execution context, not tool-selection 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 discloses that the operation disconnects, but does not explain side effects, whether authentication is needed, what happens to the current kubeconfig context, or whether the optional kubeconfig_path affects which connection is terminated.

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, direct sentence with no filler or redundancy. The action is front-loaded and every word 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 no annotations, no output schema, and one undocumented optional parameter, the description is too sparse. It gives enough to recognize the tool's purpose but not enough to invoke it correctly with confidence, especially regarding kubeconfig_path semantics and behavioral impact.

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

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

The schema has one optional parameter, kubeconfig_path, with 0% schema description coverage, and the description does not mention it at all. An agent cannot determine whether the path identifies the connection, overrides the current context, or is irrelevant when null.

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 ('Disconnect') and a clear resource ('currently connected vcluster'). It is unambiguous and clearly distinguishable from sibling tools such as vcluster_list, vcluster_pause, or vcluster_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?

The description implies the tool is used when a vcluster connection exists and should be terminated, but it does not explicitly state prerequisites, when to use this tool versus alternatives, or what 'currently connected' means in practice. Usage is implied 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?

Since no annotations are provided, the description carries the transparency burden. It discloses the nontrivial return convention (path to a 0600 temp file rather than contents), the reason (client credentials), the fact that the caller's context is unchanged, and the need to delete the file afterward. These are the key behavioral details an agent needs.

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 compact and front-loaded: the core purpose appears in the first sentence, followed by the return convention, security rationale, and cleanup instruction. Every sentence earns its place with no filler or repetition.

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 description explains what the tool returns, why it returns a file path, and how to handle the result, which is critical given there is no output schema. However, with five parameters and no annotations, it leaves parameter meanings and default behavior under-specified, so an agent may not know how to set `namespace`, `kubeconfig_path`, or `insecure` 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 only 20%, with just `server` having a description. The description adds no parameter-level detail, leaving `name`, `insecure`, `namespace`, and `kubeconfig_path` to be inferred from their names. This does not compensate for the low schema coverage.

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 the exact operation ('Export a vcluster kubeconfig') and adds a distinguishing qualifier ('without switching the caller's context'), which clearly separates it from sibling commands like vcluster_create or vcluster_delete. There is no ambiguity about the resource or the action.

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 implies when to use the tool: when another tool needs a vcluster kubeconfig and the current context must be preserved. However, it does not explicitly name alternatives or state when not to use it, so the agent must infer the decision boundary from the context-preservation wording.

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 discloses the read-only nature implicitly ('List') and the scope ('current Kubernetes context'), but doesn't mention whether it requires a kubeconfig, what happens if no vclusters exist, or any side effects. For a list operation, the lack of explicit read-only confirmation and error behavior is a 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?

One sentence, front-loaded with the action and resource. No wasted words. It earns its place by stating the scope ('current Kubernetes context').

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 2 optional parameters and no output schema, the description is mostly adequate. However, it doesn't explain the kubeconfig_path parameter's role or how the 'full' flag affects output beyond the schema's own description. The lack of annotations means the description should state that this is a read-only operation, which it only implies.

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%: the 'full' parameter is described in the schema, but 'kubeconfig_path' has no description. The tool description adds no parameter-level meaning beyond the schema. With 50% coverage, the description should compensate for the undocumented kubeconfig_path parameter, but it doesn't.

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 ('List') and resource ('vclusters') with a clear scope ('in the current Kubernetes context'). It distinguishes itself from siblings like vcluster_describe (which implies detail on one) and vcluster_create/delete (mutations), though it doesn't 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?

The description implies usage: call it to list vclusters in the current context. It doesn't explicitly state when to use this vs vcluster_describe or when not to use it. The 'current Kubernetes context' phrase gives some context but no exclusions or alternatives.

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 transparency burden and does add meaningful behavioral context: it stops workloads and preserves state. It is honest about the non-destructive nature, though it could mention reversibility or prerequisites more explicitly.

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, tightly packed sentence with no filler. The key action and scope are front-loaded, making it easy to scan and quickly understand.

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 three-parameter tool, the description captures the core behavior but misses parameter semantics and explicit guidance on when to use it versus resume or delete. Without annotations or an output schema, a bit more context would improve completeness.

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

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

Schema description coverage is 0%, and the description does not explain any of the three parameters. The required 'name' is partially inferable from the tool purpose, but namespace and kubeconfig_path semantics are left completely undocumented.

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 clearly states the action ('Pause a running vcluster'), the target resource, and the key behavioral outcome ('stopping its workloads without deleting state'). It distinguishes this tool from siblings like vcluster_delete and vcluster_resume by emphasizing state preservation.

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 implies the tool is for temporarily suspending a vcluster while retaining state, but it does not explicitly say when to choose pause over resume or delete, nor does it mention any exclusions or alternative routing. Usage context is present but left largely 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?

With no annotations provided, the description must carry the burden of behavioral disclosure, but it only says 'Resume a paused vcluster.' It does not indicate side effects, required permissions, reversibility, or what state changes occur. An agent would have no idea whether resuming triggers downtime, requires cluster admin rights, or has any other implications.

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, tightly written sentence with no redundant words. It is appropriately front-loaded with the core action. However, it is so sparse that it borders on under-specification rather than genuine conciseness, hence not a 5.

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 three parameters (one required), no output schema, and no annotations, the description is severely incomplete. It does not explain what inputs are needed, what happens after calling, or any prerequisites. An agent would need to guess whether 'name' alone suffices or how namespace/kubeconfig_path affect behavior. The description leaves too much to inference.

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

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

Schema description coverage is 0% for all three parameters, so the description is the only source for parameter meaning. It mentions none of the parameters (name, namespace, kubeconfig_path). The required 'name' is not even flagged as essential, nor are the optional parameters explained. This is a complete failure to compensate for the schema's silence.

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 clear verb ('Resume') and resource ('a paused vcluster'), and naturally contrasts with the sibling 'vcluster_pause'. It is not a tautology and is unambiguous about its primary action. However, it lacks any nuance about what resuming entails (e.g., restoring state) or how it relates to other lifecycle tools.

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 tool versus alternatives. No mention of preconditions (e.g., the vcluster must be paused), no mention of when NOT to use it, and no reference to sibling tools. The only implied usage is that it is the opposite of pause, but that is not explicit.

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