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

With no annotations, the description carries full behavioral burden. It usefully discloses idempotency handling via clientToken and that writes may be disabled, but does not state required IAM permissions, whether the operation is reversible, or the shape/contents of the returned dict beyond 'the created experiment template'.

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 two-sentence summary is well front-loaded, but the bulk of the text is an Args list that duplicates the input schema one-for-one and includes 'ctx', which is not an agent-facing parameter. The duplication is filler rather than earned content.

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 an 11-parameter creation tool with no annotations and no output schema, the description is only minimally adequate: it identifies the tool and error behavior but omits permission requirements, return-value contents, and how the nested/opaque structures (actions, targets, stop_conditions) should be shaped. The agent is left to infer most integration details.

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

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

Schema description coverage is 100%, so the baseline is 3. The Args section simply restates the schema's own descriptions verbatim (e.g., 'Optional additional tags to apply to the template') and adds no format, constraint, or structural meaning beyond what is already structured data.

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 first sentence states a specific verb+resource ('Create a new AWS FIS experiment template'), and the second sentence clarifies what a template contains (targets, actions, stop conditions). This cleanly separates it from sibling UpdateFISExperimentTemplate, GetFISExperimentTemplate, and the List* 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 create versus update an existing template, when this is preferable to other siblings, or what prerequisites (e.g., a valid IAM role, enabled writes) must hold. The only hint is the buried 'Raises ... when writes are disabled' line, which is a failure condition rather than usage guidance.

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

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

With no annotations, the description carries the full burden and does disclose two useful traits: the operation can fail 'when writes are disabled' and supports idempotency via client_token. However, it says nothing about required permissions, whether the write is destructive/reversible, or rate limits, so the behavioral picture is only partly filled in.

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?

Purpose is front-loaded in the first sentence, which is good, but the Args section duplicates the 100%-covered schema verbatim and adds little, while Returns/Raises are genuinely informative. Overall it is somewhat padded for a six-parameter tool.

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

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

For a mutation tool with six parameters, no annotations, and no output schema, the description usefully states the return shape and the write-disabled failure mode. It still leaves gaps: no explanation of what a 'scope' or 'query' filter actually accepts, and no guidance on where the created view can be referenced.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters. The Args block merely restates those same descriptions (query, view_name, name, tags, scope, client_token) without adding format, default, or constraint detail beyond the schema.

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

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

The description gives a specific verb+resource ('Create a Resource Explorer view') and ties the view to a concrete purpose: finding and filtering resources for fault injection experiments. It implicitly distinguishes itself from the read-side sibling ListResourceExplorerViews, though it never names that sibling explicitly.

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

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

It says the created view is for fault-injection resource filtering, which implies a context, but it never states when to create a new view versus reuse/list an existing one, nor does it name ListResourceExplorerViews as the alternative. No when-not conditions or prerequisites are given.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that it reads from AWS Config and returns configuration history plus relationships, and the parameters imply read-only retrieval, but it says nothing about required AWS permissions, pagination, or failure behavior when a resource is not found. Useful context is present but key operational traits are missing.

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 and use cases are front-loaded in two well-formed sentences, with structured Args/Returns sections. The Args section largely duplicates the schema, and the 'ctx' parameter listed does not appear in the input schema, adding minor noise.

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?

There is no output schema, so the description helpfully sketches the return ('Dict containing resource relationships and configuration details'). Combined with full parameter coverage and worked examples, an agent has enough to invoke it correctly, though pagination and error semantics remain unaddressed.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The Args block essentially restates the schema text ('AWS resource type', 'AWS resource ID to discover relationships for') without adding format, constraints, or interaction details. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb and resource: it 'retrieves the configuration history for a specific AWS resource and returns its relationships.' This clearly separates it from the sibling SearchResources/List* tools without needing to name them. It stops short of explicit sibling differentiation, so a 4 rather than a 5.

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

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

It gives concrete use-case guidance: 'useful for understanding resource dependencies, such as finding which subnet an ALB is placed in or which security groups are attached to an instance.' This tells the agent when the tool is the right choice. It does not name alternatives or when-not-to-use conditions, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses no information about permissions, read-only nature, error behavior for invalid IDs, rate limits, or any other trait beyond the basic retrieval purpose.

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 front-loaded with a clear purpose statement, but the second sentence largely repeats the first ('detailed information' vs 'comprehensive information'), and the Args/Returns sections add little. It is not excessively long, but it contains 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 one-parameter read tool, the description covers the basics but omits useful context: what 'experiment details' actually include, error handling, and any behavioral notes. Without annotations or an output schema, these gaps matter more.

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 100% description coverage for the single 'id' parameter, and the description merely restates it as 'The experiment ID to retrieve details for.' No additional meaning, format, or constraints are added beyond what the schema already provides.

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 detailed information about a specific experiment' and 'retrieves comprehensive information about a single FIS experiment identified by its ID.' The scope ('single FIS experiment') implicitly distinguishes it from ListFISExperiments, but no sibling is named 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?

The description implies usage by requiring an experiment ID and describing retrieval of a single experiment. However, it never states when to use this tool versus alternatives like ListFISExperiments or GetFISExperimentTemplate, nor does it list any exclusions or prerequisites.

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 implies a read operation ('retrieves') but says nothing about permissions/IAM requirements, what happens when the ID does not exist, or rate/throttling behavior. For a lookup tool with zero annotation coverage, this is thin.

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

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

The first two sentences are redundant, both saying it retrieves details of one template by ID. The Args/Returns boilerplate is standard but adds little, and the actual meaning is spread across duplicated prose rather than front-loaded once.

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

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

For a simple one-parameter read tool this is minimally adequate, but with no output schema the description should say more about what 'details' contains (e.g., action targets, role ARN, stop conditions) and how a missing ID is surfaced. It leaves those gaps open.

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

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

Schema coverage is 100% and the single parameter 'id' is fully documented in the schema, so the baseline is 3. The description restates 'identified by its ID' without adding format, validation, or sourcing details beyond the schema.

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

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

States a specific verb ('Get') and resource ('experiment template') plus the scoping key (its ID), so the agent knows it is a single-item retrieval. It does not, however, distinguish itself from the sibling GetFISExperiment, which retrieves an experiment rather than a template; the template-vs-experiment distinction is only inferable from the name.

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

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

The description only says what it does, not when to choose it over GetFISExperiment or ListFISExperimentTemplates. No prerequisites, no exclusions, no alternative routing is offered, leaving the agent to infer usage entirely.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses the return type ('Dict containing stack resources') but says nothing about read-only safety, pagination/result limits, permissions needed, or behavior when the stack name does not exist — notable gaps for a listing tool with zero annotation coverage.

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 and readable, but the first two sentences restate the same idea (retrieves resources / lists resources), and the Args and Returns blocks largely duplicate the input schema and add little. Some trimming would help.

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 single-parameter read tool with no output schema, the description covers purpose, parameter, and a use case. It leaves out pagination/scale behavior and error handling, so it is adequate but not fully 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 100% with a single required parameter, so the schema already documents stack_name fully. The description's Args section merely restates the same meaning, adding no syntax, format, or constraint detail beyond it.

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 ('Retrieves'/'lists') and resource ('resources that have been created by an individual stack' / 'all resources within a specific CloudFormation stack'), which cleanly contrasts with sibling ListCloudFormationStacks (which lists stacks, not their contents). However, it does not explicitly name or route away from any sibling, so it stops short of full differentiation.

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

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

It gives one concrete use case ('useful for identifying potential targets for fault injection experiments'), which implies when to reach for this tool. But it names no alternatives, prerequisites, or exclusions, so the when-to-use guidance remains partial.

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 burden. It usefully discloses scope ('current AWS account and region') and the return type, which is more than nothing, but it omits pagination behavior (important for listing 'all' stacks), permission requirements, and whether results are truncated.

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

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

Short and front-loaded, with the core action stated first. There is minor redundancy between 'Retrieve all AWS CloudFormation Stacks' and 'lists all CloudFormation stacks in the current AWS account and region,' plus a near-vacuous return line, but nothing seriously 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?

For a zero-parameter, no-annotation list tool with no output schema, the description supplies the essential context: what it returns and where it operates. The main omission is pagination/'all' semantics, which is a modest gap given the tool's simplicity.

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

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

The tool takes zero parameters, so the baseline is 4. There are no parameter semantics to clarify, and the description correctly does not invent any.

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 ('Retrieve all AWS CloudFormation Stacks') and scopes it to the current AWS account and region. It is clearly distinguishable from siblings like GetStackResources or ListFISExperiments, though it does not explicitly name a sibling to differentiate against.

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

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

Usage is only implied via the motivating clause 'providing information that can help identify potential targets for fault injection,' which hints at reconnaissance-style use. There is no explicit when-to-use guidance, no when-not-to-use, and no routing to alternatives such as GetStackResources for stack details.

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 helpfully discloses scope (current account and region) and that pagination is handled automatically, plus the return shape. However, it omits authorization requirements, rate limits, and error behavior, which matters for an unannotated tool.

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

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

Front-loaded with the core action, then scope and pagination in a compact second sentence. The 'Returns:' block is somewhat redundant for a simple dict but not wasteful enough to penalize heavily.

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?

There is no output schema, but the description compensates by explaining the return value (a dict of experiment details organized by name). For a zero-parameter read tool with no annotations, this covers the essentials an agent needs, though permission/error context is absent.

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

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

The tool takes zero parameters, so the schema cannot be improved upon and the baseline of 4 applies. The description correctly indicates no filtering arguments are needed.

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 ('Retrieves a list of') and resource ('Experiments') within AWS FIS, and the scope (current account and region) is clear. It implicitly distinguishes itself from GetFISExperiment (singular) via the plural 'list', though it never names siblings explicitly.

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

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

Usage is implied by the listing framing, but the description gives no explicit when-to-use guidance or exclusions relative to siblings like GetFISExperiment or ListFISExperimentTemplates. The agent must infer that this is the bulk-listing option.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that pagination is handled automatically and that scope is the current account and region, which is real added value, but it does not state read-only semantics, required permissions, or ordering.

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 short and front-loads the core action. The trailing 'Returns: List of experiment templates with their details' is largely redundant with the opening sentence and adds little.

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

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

For a parameterless list tool with no annotations and no output schema, the description covers scope and pagination but stays vague about the returned structure ('with their details'), which the agent would otherwise have to discover at call time.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to compensate for on this dimension.

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 all experiment templates') and clarifies the FIS resource and AWS account/region scope. It does not, however, differentiate itself from the nearby ListFISExperiments (experiment runs vs. templates) or GetFISExperimentTemplate, so the sibling boundary is left implicit.

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

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

There is no when-to-use guidance and no reference to alternatives such as GetFISExperimentTemplate for a single template or ListFISExperiments for runs. The agent must infer the selection criteria 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, the description carries the full behavioral burden; it partially meets this by disclosing that results are scoped to the current AWS account and region (i.e., no cross-account listing). It says nothing about pagination, permissions, or result limits, which are material for a list-all operation.

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

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

The purpose is front-loaded in the first sentence and the account/region scoping follows immediately; sizing is appropriate. The final "Returns: List of Resource Explorer views" line simply restates the title and earns little 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?

For a no-parameter, read-only list tool with no output schema, the description covers what it returns, the scope of the results, and why the results matter. Only pagination/authorization behavior is unaddressed, which is a minor gap given the tool's simplicity.

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 per the rubric the baseline is 4. There is no parameter syntax or meaning the description could add, and the schema is not a source of gaps here.

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

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

States a specific verb ("List") and resource ("Resource Explorer views") and adds useful context about scope (current AWS account and region) and purpose (fault injection experiments). It does not, however, distinguish itself from relevant siblings such as SearchResources or CreateResourceExplorerView, so an agent must infer the boundary.

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

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

The description implies usage by noting the views "can be used to find and filter resources for fault injection experiments," which gives the agent a reason to call it. It offers no explicit when-to-use vs. when-not guidance and never names an alternative (e.g., SearchResources), leaving the reader to infer the choice.

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 pagination behavior via next_token/max_results and a dict return, and 'search' implies a non-mutating read, but it says nothing about required permissions, query syntax limits, or result/rate constraints.

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 first two sentences are near-duplicates of each other and the Args block largely repeats the schema verbatim, adding length without new information. Front-loading of the core purpose is fine, but the redundancy costs it.

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 do more. It mentions a dict of results and pagination info but not the result shape, and omits permissions, error cases, and sibling disambiguation for a four-parameter search tool.

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

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

Schema description coverage is 100%, so each of the four parameters is already documented in the schema. The description restates them (query string, view ARN, max_results default, next_token) without adding format details, query syntax, or ARN structure beyond the schema.

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

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

States a specific verb (search) and resource (AWS resources) plus the mechanism (Resource Explorer), so the agent knows what it returns. It does not differentiate itself from siblings like ListResourceExplorerViews or DiscoverResourceRelationships, which also query Resource Explorer.

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 line 'can be used to find specific resources for fault injection experiments' gives one usage context, but there is no when-not guidance and no alternative tool named despite several Resource Explorer siblings existing. 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?

No annotations are provided, so the description carries the full burden. It usefully discloses asynchronous behavior ('returns immediately after starting') and that an Exception is raised 'when writes are disabled', which signals a write gate. It omits permissions needed, idempotency/duplicate-start behavior, and what the returned response 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 opening sentence is well front-loaded and the returns/raises notes add value, but the Args block largely duplicates the schema descriptions verbatim, so not every line earns its place. Structure is conventional and readable rather than tight.

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 covers the essential async start behavior and error surface, which is reasonable for a 4-param tool with no annotations or output schema. It still leaves gaps on prerequisites (template existence), permissions, and error semantics, so it is adequate but incomplete.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters, including the 'Name tag' semantics and the run-all/skip-all/stop-on-failure action modes. The description merely restates the same arg list (id, name, tags, action) without adding syntax, constraints, or format detail, so the baseline 3 applies.

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

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

The first sentence states a specific verb+resource ('Starts an AWS FIS experiment') and adds scope ('returns immediately after starting'), which distinguishes it from read siblings like GetFISExperiment and ListFISExperiments. It does not, however, explicitly distinguish itself from CreateFISExperimentTemplate or explain the create-vs-start distinction, 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?

There is no explicit when-to-use guidance, no prerequisite (e.g. an existing experiment template ID) and no named alternative among the many sibling tools. Usage is only implied by the verb 'Starts', which leaves the agent to infer when this is preferable to Get/List/Create operations.

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 confirms this is a mutation and discloses the return type, but says nothing about the critical semantics of an update call: whether omitted optional fields are preserved or cleared, whether the change is reversible, what permissions are required, or whether partial updates are atomic.

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 opening two sentences are front-loaded and useful, but the nine-item Args list duplicates schema text that the agent already receives, and it includes a 'ctx' entry that is not a real parameter. The Returns note earns its place only because no output schema exists.

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 nine-parameter mutation tool with no annotations and no output schema, the description covers the parameter roster and the return value, but omits update semantics, required permissions, and failure modes. It is adequate to identify the tool but thin for invoking 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 100%, so the baseline is 3. The Args block largely restates the schema's own parameter descriptions verbatim and adds no format detail for the complex fields (nested targets/actions maps, stop_conditions array shape), so it neither compensates for nor exceeds the schema.

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

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

States a specific verb and resource ('Update an existing AWS FIS experiment template') and enumerates the kinds of content being changed (targets, actions, stop conditions). An agent can distinguish it from Create/Get/List siblings by the verb, but the description never names those siblings or states the boundary explicitly.

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

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

No when-to-use or when-not-to-use guidance, no prerequisites (e.g., that the template must already exist or that the caller needs FIS permissions), and no mention of alternatives such as CreateFISExperimentTemplate or GetFISExperimentTemplate. The only implicit signal is 'existing', which the agent must infer from the word 'update'.

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