Server Quality Checklist

Tool Scores

• list_deploymentsA
  3.8/5.0
  Behavior4/5

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

  Annotations mark readOnlyHint=true and destructiveHint=false, aligning with the non-mutating list operation. The description adds output details (replica counts, age) but no hidden behavior.

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

  Conciseness5/5

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

  Two sentences, tightly packed with the operation's scope and returned fields; no filler.

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

  Completeness4/5

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

  A read-only list tool with clear parameter coverage in the schema and adequate output guidance in prose. No output schema exists, but the listed fields are simple and the behavior is likely clear.

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

  Parameters3/5

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

  The JSON Schema already describes both parameters (context, namespace) with 100% coverage. The description adds no new meaning beyond what the schema fields already say.

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

  Purpose4/5

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

  Uses a specific verb ('List') and resource ('deployments'), with the scope of returned data (state, replica counts, age) stated. It does not explicitly distinguish itself from sibling list tools, but the resource type is named.

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

  Usage Guidelines3/5

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

  Implies a read-only listing operation by context, but does not state when to choose it over alternatives or specify any exclusions.

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

• describe_podA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds specific details about return content (per-container state, termination reasons, crash exit codes, conditions, events) which goes beyond annotations, providing useful behavioral transparency about what to expect from the tool.

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

  Conciseness5/5

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

  The description is a single, compact sentence that immediately states the purpose and lists the specific details returned. No filler or redundancy. Perfectly front-loaded.

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

  Completeness4/5

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

  For a read-only describe tool, the description covers what it returns (per-container state, reasons, exit codes, conditions, events) and the scope (one pod). Given the annotations already indicate read-only, this is sufficient. Slight gap: it doesn't mention the namespace/name parameters explicitly, but schema covers that.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all three parameters (namespace, name) are fully described in the schema. The description does not add extra parameter semantics beyond what the schema already provides, so it stays at the baseline of 3.

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

  Purpose5/5

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

  The description clearly states the tool performs a 'deep-dive' on a single pod, specifying per-container state, waiting/termination reasons, last crash exit code, conditions, and recent events. This is specific and distinguishes it from siblings like list_pods (which lists) and get_events (which retrieves events).

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

  Usage Guidelines3/5

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

  The description implies usage for in-depth pod inspection, but does not explicitly state when to use it over alternatives like describe_resource or get_events. No exclusion criteria are given, so the agent must infer when this is the right tool.

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

• list_nodesA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true. The description adds output detail (Ready, role, version, IP) but no additional behavioral boundaries beyond what annotations provide.

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

  Conciseness5/5

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

  One sentence, clear and directly informative; no redundancy with schema or annotations.

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

  Completeness4/5

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

  For the tool's narrow scope (list nodes), the schema covers the only parameter; the description gives the returned fields, and the siblings provide related operations. Lacks an output schema, but optional for such outputs.

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

  Parameters4/5

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

  Schema already provides full description of 'context' (the kubeconfig context; omit for server default). Description reinforces target semantics in readable terms, though plain schema would likely be enough.

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

  Purpose5/5

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

  The description uses the specific verb 'list' with a specific resource ('cluster nodes') and includes the key result fields (Ready, role, kubelet version, internal IP), distinguishing it from node/pod listing tools.

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

  Usage Guidelines3/5

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

  Clear context is given (list nodes), but no explicit when-to-use guidance or named alternatives; sibling names 'list_pods' and 'get_nodes' imply adjacent functions.

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

• list_namespacesA
  4.1/5.0
  Behavior3/5

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

  Annotations already mark the operation as read-only and non-destructive, which covers side effects. The description adds output details (status and age) but doesn't mention pagination, filters, or authentication caveats. Given the annotations carry the safety signal, a 3 for neutral value is appropriate.

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

  Conciseness5/5

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

  The description is a single, lean sentence that states the purpose and output aspects without any filler. It is front-loaded and entirely relevant, earning a top score.

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

  Completeness5/5

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

  This is a simple read-only list operation. With annotations covering side effects and the schema documenting the only parameter, the description supplies enough context (status, age) and does not require deeper detail. The tool is complete for its purpose.

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

  Parameters3/5

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

  The schema has full (100%) coverage for the single 'context' parameter with an explicit description, so the description does not need to repeat it. It adds no new parameter meaning beyond the schema, so baseline 3 applies.

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

  Purpose5/5

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

  The description clearly states the tool lists namespaces in the cluster and includes status and age, which is specific and distinguishes it from sibling list tools (list_nodes, list_pods, etc.) that target other resource types.

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

  Usage Guidelines4/5

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

  The description clearly establishes when to use the tool (when you need a list of namespaces) and given the resource in the name, no alternative is needed. However, it does not explicitly mention when not to use it or direct to siblings for other resources, but the context is unambiguous enough for a 4.

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

• describe_argocd_appA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral detail by enumerating what the tool returns: Git/Helm sources, sync/health status, error conditions, OutOfSync or unhealthy resources, last sync result, and deploy history. This goes beyond the annotations and helps set expectations for a diagnostic read operation.

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

  Conciseness5/5

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

  The description is two sentences with no wasted words. The first sentence front-loads the tool's purpose and enumerates its key outputs, while the second provides a concrete diagnostic use case. It is dense but easy to parse.

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

  Completeness4/5

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

  With no output schema, the description compensates by listing the main content categories and a clear use case. It does not detail the exact return format or pagination behavior, but for a diagnostic read tool with two well-documented parameters, the provided information is sufficiently complete for an agent to select and invoke it correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, and both parameters have clear descriptions in the schema: 'name' references list_argocd_apps, and 'context' explains default behavior. The tool description adds no additional parameter semantics, but the schema already carries the full burden, so a baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description opens with 'Full detail for one ArgoCD Application' which clearly identifies the verb (provide/detail), the resource (ArgoCD Application), and singular scope. It distinguishes itself from siblings like list_argocd_apps by emphasizing 'one' application and from generic describe_resource by specifying ArgoCD-specific content.

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

  Usage Guidelines4/5

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

  The description explicitly states when to use the tool: 'Use this to diagnose why an app is Degraded or a sync failed.' This provides clear contextual guidance, though it does not explicitly mention when not to use it or name alternative tools such as describe_resource or get_events.

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

• describe_resourceA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the description is not required to restate safety. It adds the behavioral detail that it 'Returns the full object', which is useful. The description does not introduce any contradictions with annotations, and it provides enough context beyond the structured fields (e.g., that it works with CRDs).

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that starts with the core purpose ('Fetch any Kubernetes resource') and then adds the essential qualifying detail about CRDs and required identifiers. There is zero wasted wording; every phrase earns its place.

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

  Completeness4/5

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

  Given the tool's general scope, the description is complete for an agent to understand its usage: it fetches any resource, returns the full object, and the schema provides all parameter details. It might have mentioned that it supports both namespaced and cluster-scoped resources, but the schema already clarifies this via the optional namespace field. The absence of an output schema is mitigated by the statement that it returns the full object, so no additional return-value documentation is needed.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds extra meaning by noting that it works for CRDs and providing examples (SealedSecret, Certificate), which clarifies the expected kind values. It also highlights the interplay of apiVersion, kind, and name, reinforcing the required parameters beyond the schema's individual descriptions.

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

  Purpose5/5

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

  The description clearly states the action ('Fetch'), the resource ('any Kubernetes resource'), and the key identifying parameters (apiVersion, kind, name). It explicitly includes CRDs like SealedSecret or Certificate, which distinguishes it from sibling tools that target specific resource types (e.g., describe_pod, describe_argocd_app). The purpose is unambiguous and stands out from the siblings.

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

  Usage Guidelines3/5

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

  The description implies it can be used for any resource, but it does not explicitly mention when to prefer this over the more specific describe tools (like describe_pod) or when not to use it. No alternatives or exclusions are stated, leaving the usage guidance somewhat implied rather than explicit.

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

• get_eventsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral details like 'newest last' and the filtering capability, providing useful context beyond the schema. It does not contradict annotations.

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

  Conciseness5/5

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

  Two concise sentences, front-loaded with the core purpose and then the filtering option. No wasted words, every part adds value.

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

  Completeness4/5

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

  The tool is simple (read-only list with optional filters) and annotations cover safety. The description adequately explains purpose and filters; it might mention the output format (a list) but that is implied. It is complete enough for reliable invocation.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all parameters are documented in the schema. The description reinforces namespace and only_warnings usage but adds no new syntax or format details beyond what the schema provides. A baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states it retrieves recent cluster events, newest last, which is specific and distinct from sibling tools like list_pods or get_pod_logs. It mentions the resource (cluster events) and ordering, making it unambiguous.

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

  Usage Guidelines4/5

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

  The description provides clear guidance on filtering ('Filter to one namespace and/or Warning-type events only'), implying when to use it for scoped event lookup. It lacks explicit exclusions or alternatives, but the sibling context and the filter note make the use case clear.

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

• list_argocd_appsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare this read-only and non-destructive (readOnlyHint=true, destructiveHint=false). The description adds valuable behavioral context: KubeAid disables auto-sync by default, so OutOfSync apps are typically awaiting a deliberate sync. It also discloses the return fields, which is useful given no output schema.

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

  Conciseness5/5

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

  Three sentences with no fluff. The first sentence fronts the action and resource, the second adds context, and the third gives usage direction. Every sentence earns its place.

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

  Completeness4/5

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

  For a list tool with optional filters and no output schema, the description is complete enough. It lists the return fields (sync status, health, deployed revision, auto-sync), provides domain context, and gives usage guidance. Minor gaps like pagination are not critical for this tool.

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

  Parameters3/5

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

  The schema covers all three parameters with descriptions (context, project, only_problems), so the description does not need to repeat them. It adds no extra parameter-level meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb 'List' with the resource 'ArgoCD Applications' and scope 'KubeAid manages in this cluster', clearly distinguishing it from sibling tools like describe_argocd_app. It also lists the exact fields returned, making the tool's purpose unmistakable.

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

  Usage Guidelines4/5

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

  Provides a clear directive 'Start here for any GitOps question', indicating this is the entry point for such queries. It also explains the auto-sync behavior to help interpret results, though it does not explicitly name alternatives like describe_argocd_app for app-specific details.

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

• list_podsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this read-only, safe behavior without contradiction. It adds value by disclosing the exact output fields (derived status, ready count, restarts, node, age), which helps the agent understand what information will be returned. This goes beyond the structured annotations by providing the output contract.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that begins with the primary action ('List pods') and then lists the key output fields in a scannable format. No words are wasted, and the most important information (what it does) is front-loaded. Excellent balance of brevity and information density.

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

  Completeness4/5

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

  For a straightforward read-only list operation, the description covers purpose, output fields, and the critical namespace scoping behavior (including the default). It does not mention pagination or limits, which might be a minor gap for large clusters, but the annotations and schema fill in the safety and parameter details. The description is complete for the tool's apparent simplicity.

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

  Parameters4/5

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

  The schema covers 100% of parameters (context and namespace) with clear descriptions, providing a solid baseline. The description enriches the namespace parameter by explicitly stating that omitting it means 'all namespaces', which is not explicit in the schema. This extra semantic detail is valuable for correct usage.

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

  Purpose5/5

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

  The description clearly states it lists pods with derived status (CrashLoopBackOff, Terminating), ready count, restarts, node, and age. This specific verb+resource combo and the detailed output fields distinguish it from sibling tools like list_deployments or describe_pod. It immediately conveys the exact scope and differentiation.

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

  Usage Guidelines3/5

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

  The description implies usage by mentioning the namespace parameter behavior ('omit for all namespaces'), but does not explicitly state when to use this tool versus siblings like describe_pod or list_deployments. There is no explicit 'use this when' or alternative naming. The guidance is present but implicit, requiring the agent to infer the tool's position among its siblings.

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

• get_pod_logsA
  4.4/5.0
  Behavior4/5

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

  Annotations already confirm read-only and non-destructive behavior; the description adds valuable context about the previous flag and its role in crash debugging. It does not cover streaming/pagination, but the annotations lower the bar and the added context is meaningful.

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

  Conciseness5/5

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

  Two sentences, both necessary and directly informative. The first states the core action; the second gives a high-value usage tip without wasting words.

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

  Completeness4/5

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

  With no output schema, the description and schema collectively provide enough for a logs tool: tailing behavior, line count, namespace/container targeting, and crash-instance option. Minor gap: no mention of output format, but that is generally implied and not critical for log retrieval.

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

  Parameters4/5

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

  Schema covers 100% of parameters, so the baseline is 3, but the description enriches the 'previous' parameter by explaining its purpose and relevance to CrashLoopBackOff, which goes beyond the schema's bare definition. No other parameters need extra explanation given the schema quality.

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

  Purpose5/5

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

  Description uses specific verb 'Tail' and names the resource 'container's logs', with a clear distinction from sibling tools like describe_pod or get_events. It also adds meaningful scope by mentioning 'previous (crashed) instance's logs', making the tool's purpose unmistakable.

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

  Usage Guidelines4/5

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

  The description provides a clear context for using the previous flag ('essential for CrashLoopBackOff') and implies the tool is for reading logs. It does not explicitly compare to alternatives, but the log-specific context and sibling names make the usage clear enough.

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

• list_contextsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint true and destructiveHint false, and the description does not contradict them. It adds useful behavioral context by specifying that output includes default and write-protected status and that the context list is limited to what this server can target.

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

  Conciseness5/5

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

  Single sentence, front-loaded with the verb and object, and every clause adds meaningful detail about scope and output contents. No wasted words.

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

  Completeness5/5

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

  This is a simple, parameterless read-only listing tool. The description conveys what is listed, the scope limitation, and key output features (default and write-protected), which is sufficient for an agent to select and invoke it correctly.

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

  Parameters4/5

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

  The input schema is empty, so there are no parameters requiring clarification. With zero parameters, the description does not need to compensate for schema gaps, matching the baseline for parameter-less tools.

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

  Purpose5/5

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

  Description uses a specific verb ('List') with a clear object ('kubeconfig contexts') and adds scope ('this server can target'). It is clearly distinct from the sibling node/pod/deployment tools.

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

  Usage Guidelines4/5

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

  The description gives clear context for when to use the tool: to see available target contexts, the default, and write-protected ones. It does not explicitly name alternatives or exclusions, but the sibling list makes its unique purpose evident.

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