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 usefully discloses the auto-refresh side effect and dependence on a cached SSO refresh token, but omits failure behavior, required permissions, and what happens when no valid token exists.

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

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

The core purpose is front-loaded in a single efficient sentence, and the Args block is short. The parameter note is thin but not padded.

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

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

An output schema exists, so return values needn't be explained, and for a one-parameter tool the description is largely sufficient. Still, with no annotations, a credential-mutating refresh operation would benefit from stating side effects and failure conditions.

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

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

With 0% schema description coverage and one parameter, the description must compensate, and it does explain profile_name and its default. However, it introduces a discrepancy: the description says it defaults to 'default' while the schema declares default: 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+resource: it checks validity of AWS credentials and auto-refreshes via cached SSO token. This is clearly distinct in behavior from siblings like aws_get_caller_identity or aws_switch_profile, though it never names or contrasts them 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 explicit when-to-use guidance, no prerequisites, and no mention of the alternatives among the sibling tools (aws_switch_profile, aws_list_profiles, aws_get_session_env). The agent must infer that this is a pre-flight credential check.

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

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

With no annotations, the description carries the full burden, and it does disclose the underlying mechanism (an STS call) and the shape of what comes back. It does not say what happens with no valid credentials/expired session, whether the call has side effects, or whether it requires network access — gaps that matter for a credential-adjacent 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?

Two short lines, front-loaded with the outcome (identity + returned fields) before the argument note. The 'Args:' block is slightly formulaic for a single optional parameter, but nothing is wasted.

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

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

An output schema exists and the single optional parameter is explained, so an agent has enough to invoke this correctly. Error/permission behavior is unaddressed, which is the only meaningful omission for a one-parameter read 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 0% and the only parameter is a bare nullable string, so the description does the work: it explains that profile_name selects which profile to check and that omission falls back to the default profile. It doesn't cover behavior for a nonexistent profile name, which is the remaining gap.

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

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

The description gives a specific verb ('Get'), a precise resource ('current AWS caller identity') and even enumerates the returned fields (Account ID, IAM Role/User ARN, User ID). It is unmistakably clear what the tool returns, but it never contrasts itself with siblings such as aws_ensure_credentials or aws_list_profiles, so it stops short of the top band.

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

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

It states that profile_name is optional and that the default profile is used when omitted, which implies the basic usage pattern. However there is no explicit guidance on when to call this vs. aws_ensure_credentials or aws_switch_profile, and no prerequisites (e.g. credentials must already exist) are stated.

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

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

With no annotations, the description carries the full burden, and it does disclose that the values are 'raw' credentials intended for subprocess injection. It says nothing about whether credentials are temporary/STS-scoped, whether they are cached, how long they remain valid, or the security implications of handling the returned secrets — meaningful omissions for a credential-exposing 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?

One compact sentence front-loads the return contents, and the single parameter note is kept brief. The 'Args:' block is slightly ceremonial for one optional argument but not wasteful.

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

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

An output schema exists, so return-value documentation is unnecessary, and with only one optional parameter the surface is small. The definition is nearly complete, with the only real gap being behavioral/security context around the credentials it exposes.

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 schema only exposes a nullable 'Profile Name' with default null, so the description must compensate; it does explain the parameter is an AWS profile name and states the effective default ('default'), which the schema does not convey. Minor tension exists because the schema declares default null while the text says it defaults to 'default'.

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 ('Get raw AWS session environment variables') and enumerates exactly what is returned (AccessKey, SecretKey, SessionToken, Region), which differentiates it from siblings like aws_get_caller_identity or aws_list_profiles. It does not, however, explicitly contrast itself with the closest sibling, aws_ensure_credentials, whose purpose could overlap.

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 'for isolated subprocess execution' implies the use case, so an agent can infer this tool is for obtaining env vars to hand to a child process rather than for making API calls directly. But no alternatives are named and no when-not-to-use condition is given, leaving the choice between this and aws_ensure_credentials to inference.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only listing but says nothing about pagination, whether instances across all states are returned, permission requirements, or error behavior for invalid credentials. For a zero-annotation tool this is a thin behavioral profile.

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 purpose is front-loaded in a single sentence, followed by a compact Args block that maps directly to the parameters. No filler text, though the Args/Sphinx style is slightly verbose for only two parameters.

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

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

An output schema exists, so return values need not be explained, and with 2 optional parameters complexity is low. However, with no annotations and no mention of credential prerequisites or result scope (all instances vs. running only), the description is adequate but leaves meaningful gaps for an agent invoking it cold.

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, and it does: it names both parameters, gives concrete region examples ('us-east-1', 'us-west-2'), and restates the profile default. It does not discuss region format validity beyond examples or profile resolution rules, but the added value over the bare schema is substantial.

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

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

States a specific verb and resource ('List EC2 instances') plus the scoping dimensions (region, profile). The resource is distinct from all siblings (EKS clusters, profiles, caller identity), so an agent can route by resource without opening the schema. It stops short of explicitly naming an alternative tool, which keeps it at 4.

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 versus the sibling listing tools, nor on prerequisites such as whether credentials for the named profile must already exist. The description only says a profile is 'used', leaving context entirely 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, the description carries the full burden. It does disclose the key side effect that update_kubeconfig=True mutates the local ~/.kube/config, which is genuinely useful behavioral context. However, it says nothing about credential requirements, what happens when no clusters exist, or any side effects of the default path.

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?

Front-loads the purpose sentence and follows with a compact arg list. Slightly redundant for region/profile which repeat schema defaults, but overall efficient with no wasted prose.

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

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

An output schema exists, so return values need not be explained. Given the tool's moderate complexity, the description is essentially complete for calling it: all three params are covered and the kubeconfig side effect is stated. Only minor gaps remain around credential/error behavior.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: region gets concrete examples, profile_name states its default, and update_kubeconfig explains its behavioral effect. This adds real meaning beyond the bare schema types and 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?

States a specific verb+resource ('List EKS clusters') plus a clear scope ('in a specific AWS region') and adds the secondary capability of writing kubeconfig. The purpose is unambiguous, though it never names or contrasts with its closest sibling (aws_update_kubeconfig), which also touches kubeconfig.

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 or when-not-to-use guidance is given, and the alternatives are not mentioned. It's implied you call this to enumerate clusters, but the overlap with aws_update_kubeconfig (which also configures kubeconfig) is never resolved, leaving the agent to guess which tool to pick.

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. It discloses what is inspected (local profiles, active default, regions), and 'List' conveys a non-destructive read, but it says nothing about whether profile files are read from disk, whether credentials are resolved, or any auth/permission requirements.

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

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

A single front-loaded sentence with zero filler. Every clause (profiles, active default, regions) conveys distinct information about the tool's scope.

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

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

With an output schema present, the description needn't document return values, and a zero-parameter read-only tool has little surface area to cover. It is complete enough to invoke correctly, though a brief note on prerequisites (e.g. AWS config files present) would close the remaining gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond the schema. Baseline 4 applies; the description's enumeration of outputs adds light value but is not required at this parameter count.

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

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

States a specific verb (List) and resource (local AWS profiles), and goes further by naming the composite return content: active default profile and configured regions. It is distinguishable from write-oriented siblings like aws_switch_profile, though it never explicitly contrasts with 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 verb 'List' implies a read-only discovery use case, and the sibling set (aws_switch_profile, aws_ensure_credentials) makes the context inferable, but the description names no alternative or condition for choosing this tool. Usage is 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 disclose the concrete side effect — rewriting the default profile in ~/.aws/credentials — which is genuinely useful. However, it omits failure modes (behavior if the profile name doesn't exist), whether other profiles are preserved, and reversibility, leaving meaningful gaps for a persistent mutation.

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?

Front-loaded single sentence stating the action and its target file, followed by a compact Args block. The Args header repeats the schema's parameter name, which is mild redundancy, but the examples justify the space.

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

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

An output schema exists, so return values need not be explained, and the description covers the core effect and parameter meaning. For a persistent credential mutation with no annotations, the absence of error behavior and permission requirements leaves the definition only adequately 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 description coverage is 0%, so the description must compensate, and it does: it explains that profile_name is the profile to set as default and supplies concrete examples ('dev', 'prod', 'qa'). It stops short of stating constraints such as case sensitivity or whether the profile must pre-exist.

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 (switch) and resource (default AWS credentials profile), plus the concrete location of the effect (~/.aws/credentials). It is clearly distinguishable in kind from read-oriented siblings like aws_list_profiles, but it never names or contrasts with a sibling explicitly, so it stops short of a 5.

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

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

The description states what the tool does but gives no when-to-use guidance, no prerequisites (e.g. whether the profile must already exist), and no mention of alternatives such as aws_ensure_credentials or aws_get_session_env. The use case is only inferable from the verb itself.

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

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

No annotations are provided, so the description carries the full behavioral burden and largely fails it. It never says that this writes/overwrites the local kubeconfig file, whether it replaces an existing context for the same cluster, whether it requires the AWS CLI or valid credentials, or what happens on failure. For a mutating configuration tool, that is a significant 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?

The main sentence is front-loaded and wastes nothing, and the Args list is compact. The parameter list restates information the schema container already shows, which is minor redundancy rather than bloat.

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

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

An output schema exists, so return values need not be described. Still, for a tool that mutates local state with zero annotation coverage, the description omits the behavioral context (overwrite semantics, credential prerequisites) an agent would need to invoke it safely.

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 property titles ('Region', 'Cluster Name', 'Profile Name') are near-tautological, so the description's Args block does add real meaning (which AWS region, that the profile is used for authentication). However, it omits the schema defaults (us-east-1, 'default') and gives no format hints for cluster_name.

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 (Configure), resource (local kubeconfig), and target (a specific EKS cluster), which cleanly separates it from siblings like aws_list_eks_clusters or aws_get_caller_identity. It does not explicitly name any sibling as an alternative, 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 scenario is implied by the purpose: use this when you need kubectl pointed at a given EKS cluster. There is no explicit when-to-use statement, no prerequisites (e.g. credentials must already exist), and no mention of related tools such as aws_list_eks_clusters for finding the cluster name.

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