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

No annotations provided; description only states the action without disclosing implications like permissions, state changes, or failure conditions.

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

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

Structured with Args and Returns sections. Sentences earn their place, though Returns section could be slightly more concise. Overall well-organized.

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?

Completes the picture with parameter details, example, constraints, and return fields. Adequate given no output schema and moderate complexity.

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 0%, but description adds explanations for all parameters including examples for 'asset_scopes' and length constraint for 'decision_comment'.

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?

Clearly states the verb 'Accepts' and the resource 'subscription request to a specific asset in Amazon DataZone'. Distinguishes from sibling tool 'create_subscription_request'.

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 explicit guidance on when to use this tool versus alternatives. Does not mention prerequisites like an existing pending request.

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?

Without annotations, the description carries the full burden but only mentions idempotency via client_token. It does not disclose permissions, side effects, rate limits, or what happens if the owner already exists. The return value is vaguely described as 'Any: The API response.'

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 concise and front-loaded with the main purpose, followed by a clear Args section. One point deducted because the Args section could be more structured (e.g., bullet points) but the content is efficient and necessary.

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

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

For a tool with 6 parameters and no output schema, the description covers the parameters well but lacks details about behavior (e.g., error cases, what the API response contains). Some behavioral context, like whether ownership replaces or appends, is missing.

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, the description fully compensates by explaining each parameter's purpose (e.g., owner_identifier 'can be IAM ARN for users', entity_type defaults and options). This provides essential meaning beyond the schema's bare titles.

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

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

The description clearly states the verb 'Adds an owner' and the resource 'entity (domain unit or project)' in Amazon DataZone, providing a specific and unambiguous purpose that distinguishes it from sibling tools like add_policy_grant or create_project.

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

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

No guidance is provided on when to use this tool versus alternatives such as add_policy_grant or create_project_membership. The decision is left entirely to the agent without explicit context or exclusions.

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 must fully disclose behavioral traits. It states the tool 'adds a policy grant' but does not mention permissions required, whether the operation is reversible, or any side effects (e.g., impact on existing grants). The idempotency via client_token is hinted but not explicitly stated. The description is too sparse for safe agent decision-making.

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 uses a clear Args/Returns structure. However, it is overly verbose with repetitive phrasing (e.g., 'The ID of the domain', 'The ID of the entity'). Many descriptions could be shortened or merged. The return value description is minimal and vague.

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 8-parameter, 5-required tool with no output schema, the description is insufficient. It does not explain what a policy grant is, how it interacts with DataZone's permission model, or what the response contains beyond 'the API response'. The tool is complex, and the description lacks the context an agent needs to use it correctly.

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

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

The schema coverage is 0%, so the description must compensate. It lists parameters with types and brief descriptions, adding some value (e.g., enumerating possible values for entity_type and policy_type, mentioned in prose). However, many descriptions are trivial (e.g., 'The ID of the domain') and merely restate the parameter name. Additional details like format constraints or allowed values are missing.

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

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

The description clearly states the action ('Adds a policy grant') and the resource ('specified entity in Amazon DataZone'). The verb and resource are specific and unambiguous. However, it does not differentiate from sibling tools like 'add_entity_owner', which also adds permissions.

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

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

There is no guidance on when to use this tool versus alternatives (e.g., add_entity_owner). The description lacks prerequisites, context, or any indication of appropriate use cases. The parameter descriptions are functional but do not help an agent decide when to invoke this tool.

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 full burden for behavioral disclosure. It describes the creation and return values but omits side effects (e.g., whether asset is immediately published), permission requirements, or error conditions. This is insufficient for a mutation 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?

The description is structured with Args and Returns sections, but it is verbose (10+ lines). Some parameter details could be condensed without losing clarity. It is functional but not optimally concise.

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

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

Given the complexity (11 params, no output schema) and no annotations, the description covers creation details and return structure comprehensively. However, it lacks information on prerequisites or potential failures, which slightly reduces completeness.

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

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

Schema description coverage is 0%, yet the description manually enumerates all 11 parameters with constraints (e.g., name length 1-256), types, and examples (e.g., forms_input, glossary_terms). This adds full semantic meaning beyond the bare 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 clearly states 'Creates an asset in the Amazon DataZone catalog,' using a specific verb and resource. This distinguishes it from sibling tools like create_glossary or create_project, which target different entities.

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 does not provide explicit guidance on when to use this tool versus alternatives like publish_asset or search. Usage is implied only through the action of creating an asset, but no when-not-to or prerequisites are mentioned.

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 full burden. It details parameters, return structure with example, and implies idempotency via client_token. However, it lacks explicit notes on error conditions, permissions, or side effects beyond creation.

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 well-structured with intro, args docstring, returns, and example. It is front-loaded with purpose. While slightly verbose, every section adds value and the structure aids readability.

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 7-parameter tool with no output schema, the description covers input, return values, and gives an example. Missing are error handling and potential side effects, but overall it is fairly complete for an agent to invoke correctly.

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

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

With 0% schema description coverage, the description adds extensive parameter semantics: patterns, length constraints, dictionary structure for aws_location, and explanation of props type. This far exceeds the bare 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 clearly states 'Creates a new connection in Amazon DataZone' and specifies the context as the DataZone MCP server. Among siblings like get_connection and list_connections, the creation purpose is distinct.

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 indicates it's for creating DataZone connections within the DataZone MCP server, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like update or other creation tools.

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 details the creation action, required parameters, and return value including error messages. It mentions idempotency via client_token. However, it does not mention prerequisites like required permissions or domain/project existence.

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 long but well-structured with Args and Returns sections. Every sentence adds value, but it could be slightly more concise by condensing some examples. Overall, it is effective.

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

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

Given the complexity (14 parameters, 0% schema coverage, no output schema), the description is highly complete. It covers all parameters, provides examples, and explains the return value. No critical gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It provides detailed explanations for all 14 parameters, including examples for complex types (configuration, asset_forms_input, recommendation, schedule). This goes beyond what the schema 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?

The description clearly states 'Creates a data source in Amazon DataZone and associates it with a project.' This is a specific verb and resource. There are no sibling tools that create a data source, so no confusion.

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 implicitly indicates when to use this tool (when a data source needs to be created). It does not explicitly state when not to use or alternatives, but given the context of sibling tools, the usage is straightforward.

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 must disclose behavioral traits. It only lists parameters and returns but does not mention side effects, permissions, idempotency, or asynchronous behavior. For a creation tool, this is insufficient.

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 well-structured using Args/Returns format and is not overly verbose. It clearly lists all parameters and return fields, though it could be slightly more concise.

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 8 parameters and no annotations, the description provides basic usage information and return fields. However, it lacks context about prerequisites, errors, or the creation process, which would be needed for a complete understanding.

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%, but the description adds meaningful explanations for each parameter, such as 'name (str): The name of the domain' and 'domain_execution_role (str): The ARN of the domain execution role'. This compensates for the lack of schema descriptions, though some parameters like 'single_sign_on' are only briefly defined.

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

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

The description clearly states 'Creates a new Amazon DataZone domain' with a specific verb and resource. No sibling tool duplicates this action, so it is easily distinguishable.

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

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

No guidance on when to use this tool versus alternatives or prerequisites. The description lacks any context about when to create a domain versus other 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 exist, so description carries full burden. It details arguments and return shape but does not mention side effects (e.g., idempotency via client_token is implied but not stated), permissions, or error conditions. Adequate but not comprehensive.

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?

Well-structured: leading statement, then Args and Returns sections. Concisely covers details without extraneous content. Could be slightly tighter (e.g., remove redundant pattern text), but overall efficient.

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?

Covers parameters and return value adequately given output schema exists. Missing prerequisites (e.g., domain must exist, parent must exist) and error handling. Adequate but could benefit from more domain context.

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

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

Schema description coverage is 0%, so description adds significant value by documenting all five parameters with patterns, constraints, and optional notes. It lacks explicit default values but still provides meaning beyond the bare 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 clearly states 'Creates a new domain unit in Amazon DataZone', which is a specific verb and resource. It distinguishes from sibling tools like create_domain (which creates a domain) and get_domain_unit (which retrieves).

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 explicit guidance on when to use or when not to use this tool versus alternatives. The name implies creation, but no context like 'use when you need to add a new organizational unit within an existing domain' is provided.

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?

The description only states it creates a form type and lists return fields. It does not mention side effects, required permissions, rate limits, or any destructive behavior. The Union type note on 'model' is a minor behavioral detail but insufficient for full transparency given no annotations.

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 well-structured with a one-line summary, Args, Returns, and an example. It is detailed but not overly verbose; each section serves a clear purpose.

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

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

Given the lack of output schema, the description provides a comprehensive Returns section. It covers all input parameters thoroughly, including nested objects. No major gaps for the agent to understand tool usage.

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 description fully compensates for the 0% schema coverage by detailing each parameter: patterns, lengths, defaults, and the Union nature of 'model'. The example further clarifies usage, adding significant meaning beyond the schema's type definitions.

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 explicitly states 'Creates a new metadata form type in Amazon DataZone,' providing a specific verb and resource. This clearly distinguishes it from sibling tools like create_asset or create_project, which target different resources.

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 explicit guidance on when to use this tool versus alternatives. The example shows usage but does not contrast with other create tools or specify conditions like when not to use it.

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

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

The description explains the creation action and lists parameters, but does not disclose potential errors, prerequisites (e.g., domain must exist), or side effects. With no annotations, the description carries full burden and provides only basic behavioral information. No contradictions.

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 structured with clear sections (Args, Returns, Example) and is concise. The example adds practical value. However, the opening sentence is slightly redundant with the Args section that follows.

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

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

Given the absence of an output schema and annotations, the description covers all parameters and returns a generic 'API response'. It lacks details on error conditions, edge cases, or prerequisite checks (e.g., domain existence), which would be needed for full completeness.

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

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

The schema has 0% description coverage, but the description's Args section adds meaningful context for each parameter (e.g., 'The ID of the domain where the glossary will be created'). This compensates well, though details like character limits are provided inconsistently (only for name and description).

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?

Clearly states 'Creates a new business glossary in Amazon DataZone.' The verb is specific ('creates'), the resource is defined ('business glossary'), and the platform is named, differentiating from siblings like create_glossary_term which creates a term within a glossary.

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 explicit guidelines on when to use this tool versus alternatives, such as when a glossary should be created before terms. The context is implied by the sibling tools (e.g., create_glossary_term), but no direct 'when to use' or 'when not to use' guidance is given.

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

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

No annotations provided, so description carries full burden. It discloses creation nature, idempotency via client_token, default status, and patterns. Adds behavioral context beyond schema.

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?

Well-structured with Args, Returns, and Example. Slightly verbose but justifies its length by covering all parameters thoroughly. Conciseness is reasonable given schema lack.

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?

Covers all 8 parameters with details, includes return type and example. Lacks prerequisites (e.g., domain and glossary must exist) but good overall for a creation tool without output schema.

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 0%, so description fully compensates. Provides patterns, length constraints, defaults, and an illustrative example for term_relations. Adds significant meaning beyond the schema fields.

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?

Clearly states it creates a business glossary term in Amazon DataZone. Distinguishes from sibling tools like create_glossary (creates glossary) and get_glossary_term (retrieves term).

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?

Implicitly clear that it is for creating terms within an existing glossary, but does not explicitly state when to use vs alternatives like create_glossary or the retrieval tool. No exclusion guidance.

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

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

No annotations are provided, so the description carries the full burden. It only states that the tool creates a project and returns an API response, but fails to disclose side effects, permissions, or safety implications. For a mutation tool, this is minimal.

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 well-structured with a clear first sentence, a detailed Args list, and a Returns section. It is relatively concise, though the Args list is somewhat redundant with the schema. Still front-loaded and easy to parse.

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

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

Given no output schema and moderate complexity (7 parameters), the description is incomplete. It lacks details on naming conventions, uniqueness constraints, or asynchronous behavior. The return type is vague ('Any'). More context is needed.

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 0%, and the description compensates by listing all parameters with brief explanations in the 'Args' section. This adds basic meaning, but does not cover constraints or formats. It provides average clarity 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 clearly states it creates a new project in an Amazon DataZone domain. It uses a specific verb and resource, and it distinguishes itself from sibling tools like create_project_membership and create_project_profile.

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 lists arguments but does not provide explicit guidance on when to use this tool versus alternatives. It lacks context on prerequisites or when not to use, though the purpose is clear.

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 should disclose behavior. It only says 'Make a request to the API' without noting whether the operation is destructive, idempotent, or requires specific permissions. Minimal transparency.

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 concise (one introductory sentence followed by parameter list) but not well structured for quick scanning. Parameter explanations are terse and repetitive.

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

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

Given 4 required parameters, no output schema, and no annotations, the description is incomplete. It omits success/error conditions, return value, side effects, and preconditions. Does not explain the purpose of designations or member identifiers.

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%. The description adds minimal value: it lists parameter names and repeats type info (e.g., 'domainIdentifier (str): The identifier of the domain'). This is only slightly better than the bare schema, lacking context like allowed values or relationships between parameters.

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 'Make a request to the Amazon DataZone CreateProjectMembership API,' clearly indicating the verb (Create) and resource (ProjectMembership). It distinguishes from siblings like list_project_memberships by implying a create action, but lacks explicit 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?

No guidance on when to use this tool versus alternatives (e.g., add_policy_grant or create_project). No when-not-to-use scenarios or prerequisites are mentioned.

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 full responsibility. It describes the creation action and return format but does not disclose side effects, permissions, idempotency, or error behavior. A create operation is inherently more transparent than a mutation, but details are lacking.

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 well-organized with Args and Returns sections. It is slightly verbose but each sentence adds useful detail. It is front-loaded with the purpose, making it easy to scan.

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

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

Given the complexity (6 parameters, optional nested objects) and the presence of an output schema, the description covers all necessary details: parameter constraints, return fields, and optionality. It is sufficiently complete for an AI agent to invoke the tool correctly.

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

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

The description adds significant value beyond the input schema by providing patterns for domain_identifier and name, explaining the structure of environment_configurations, and clarifying defaults. Since schema coverage is 0%, this compensation is crucial and well done.

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

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

The description clearly states 'Creates a new project profile in Amazon DataZone,' using a specific verb and resource. However, it does not differentiate from sibling tools like create_asset or create_connection, preventing a perfect score.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical scenarios, or when not to use it.

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

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

No annotations provided, so description must cover behavioral traits. It mentions idempotency via client_token and return values, but lacks disclosure on side effects, permissions, rate limits, or failure modes.

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?

Well-structured with clear purpose, args, and returns sections. Each part adds value, though could be slightly trimmed in parameter examples without losing clarity.

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?

Describes input parameters and return object structure in detail. Lacks error scenarios and prerequisites (e.g., domain existence), but overall sufficient for a create tool with complex parameters.

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?

Description provides detailed explanations and examples for all 6 parameters, including tagged union format for subscribed_principals and length constraints for request_reason, compensating for 0% schema description coverage.

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

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

Description clearly states 'Creates a subscription request in Amazon DataZone.' This distinct verb-resource combination differentiates it from siblings like 'accept_subscription_request' and 'get_subscription'.

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 explicit guidance on when to use this tool versus alternatives like 'accept_subscription_request'. The description implies it's for creating requests but lacks when-not and precondition information.

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 details the information retrieved (metadata, lineage, forms, etc.) and implies a read-only operation. While it could mention idempotency or permissions, the level of detail about the response is sufficient for understanding behavior.

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 well-structured with sections for main description, use case, related tools, args, and returns. It is informative without being verbose, though slightly longer than necessary.

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

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

Given no output schema, the description provides a detailed list of return fields. It explains the concept of an asset and differentiates it from a data source. The three parameters are fully documented. This is adequate for an AI agent to use the tool correctly.

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

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

Schema coverage is 0%, so the description must compensate. It provides clear descriptions of each parameter: domain_identifier, asset_identifier, and revision (optional), adding meaning beyond the schema's property names.

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

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

The description clearly states the verb 'Retrieves' and the resource 'one specific asset', and distinguishes from siblings by explicitly naming 'search' and 'get_data_source' as alternatives for different use cases.

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 explicitly says 'Use this API when you want to inspect or manage a particular known asset', and contrasts with search for discovery and get_data_source for data sources, providing clear guidance on when to use this tool vs alternatives.

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

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

Without annotations, the description carries the full burden. It reveals that the tool is a read operation ('gets'), clarifies that connections are non-destructive, and explains the effect of the 'with_secret' parameter on the return value. However, it does not explicitly state permissions needed or any other behavioral nuances like rate limits, but the detail is adequate for a simple read 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?

The description is well-structured: one-line summary, explanatory paragraph, related tools, parameter details, return details, and an example. It is front-loaded with the core purpose and uses minimal but necessary text. No redundant sentences.

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 all major aspects: purpose, usage comparison, parameter semantics, return structure, and an example. It lacks only minor details like prerequisites or explicit read-only indication, but for a 3-parameter read tool with no output schema, it is nearly 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?

Input schema has 0% description coverage, so the description must compensate. It does so thoroughly with an 'Args' section defining each parameter: 'domain_identifier' (pattern), 'identifier' (length constraints), and 'with_secret' (default, purpose). This adds significant meaning beyond the bare 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 clearly states 'Gets a connection in Amazon DataZone', specifying the verb and resource. It also distinguishes 'connection' from 'data source' by explaining that connections are credentials+config while data sources are specific locations, differentiating it from the sibling tool 'get_data_source'.

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 includes a 'related tools' section explicitly contrasting with 'get_data_source', telling when to use each: 'get_connection' for metadata and config, while 'get_data_source' for detailed information about a specific data location. This provides clear when-to-use and when-not-to-use guidance.

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

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

No annotations provided; description carries full burden. Clearly indicates it is a read operation (retrieval). Explains concepts like data source vs. data asset vs. connection, aiding understanding. Does not explicitly mention rate limits or idempotency, but appropriate for a GET 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?

Well-structured with sections and bullet points. Provides needed details without excessive verbosity. Minor redundancy in explaining data source vs. asset, but overall efficient.

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?

Comprehensive for a retrieval tool with no output schema. Covers purpose, usage guidelines, parameter semantics, and related tools. No gaps identified.

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 description must compensate. It lists both parameters in Args section with brief descriptions (domain ID, data source ID), but adds little beyond the schema field names and required status. Some context added but not rich.

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?

Clear verb ('Retrieves detailed information'), specific resource ('specific, known data source'), and explicit context. Distinguishes from sibling tools list_data_sources and get_asset.

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?

Explicitly states when to use ('when user mentions a specific data source by name, type, or context') and lists detailed information it provides. Also mentions related tools and their purposes.

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 full burden. It states it calls the API and returns response or None, but does not disclose read-only nature, authentication needs, rate limits, or side effects. The behavior is implied but insufficiently explicit.

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 very concise with clear sections for arguments and returns. Every sentence adds value, and it is front-loaded with the core action.

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 get tool with one parameter and no output schema, the description is mostly complete. It covers input and output (returning API response or None). Minor gap: does not mention HTTP status or error handling beyond returning None.

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

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

Schema description coverage is 0%, so the description must compensate. It adds an example value and explains that identifier is the domain identifier. While not exhaustive, this provides meaningful context beyond the bare 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 clearly states it calls the GetDomain API for a domain identifier. It specifies the resource and action, but does not explicitly differentiate from sibling tools like get_domain_unit or list_domains, though the context implies it's a retrieval operation.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention that list_domains should be used for enumerating domains, nor does it state that this tool is for fetching details by ID.

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 present, so the description must fully disclose behavioral traits. It states the tool retrieves info but does not mention permissions, error conditions, idempotency, or side effects. While 'get' implies safety, the lack of explicit behavioral context is a gap without annotations.

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 concise yet comprehensive: a one-line purpose followed by structured Args and Returns sections. Each sentence serves a purpose, and the format is easy to parse. No superfluous text 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 simple retrieval tool with two parameters, the description covers input (with patterns) and output (a detailed dict). It is nearly complete, though it lacks mention of potential errors or auth requirements. With output schema present (implied by the Returns section), the description is thorough enough for this complexity level.

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, the description adds significant value: it explains each parameter including regex patterns ('domain_identifier' pattern '^dzd[-_][a-zA-Z0-9_-]{1,36}$') and natural language descriptions. This compensates fully for the schema's lack of descriptions, though it could include examples or 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?

The opening line 'Retrieves detailed information about a specific domain unit in Amazon DataZone' clearly states the action and resource. This distinguishes it from siblings like 'list_domain_units' (which lists multiple) and 'create_domain_unit' (which creates), establishing a unique purpose.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as 'list_domain_units' for multiple units or other retrieval tools. It lacks any context about prerequisites, fallbacks, or when not to use, leaving the agent without decision-making support.

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 must carry the burden for behavioral traits. It only states 'Gets' which implies read-only, but does not disclose idempotency, prerequisites, or any special behaviors beyond the return structure.

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 organized with bullet points and an example, making it easy to parse. While it is lengthy due to detailed return fields, it is appropriately structured for a complex output.

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, the description fully documents the return object fields. Input parameters are thoroughly described, and an example is provided, making the tool complete for agent invocation.

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

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

The input schema has 0% description coverage, but the description provides detailed parameter semantics including types, patterns, and constraints for both domain_identifier and identifier, significantly adding value.

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

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

The description clearly states 'Gets an Amazon DataZone environment', which is a specific verb and resource. It distinguishes from sibling tools like get_asset, get_connection, and list_environments, making its purpose unambiguous.

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

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

The description does not explicitly state when to use this tool versus alternatives such as list_environments for multiple environments. While the context implies retrieval by ID, more explicit guidance would improve clarity.

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 operation ('Retrieves') and details the return fields, but does not explicitly state idempotency, permissions, or non-destructive nature. The behavioral traits are partially disclosed but not comprehensively.

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 lengthy due to a detailed return schema, but it is well-structured with clear sections for summary, related tools, args, and returns. The front-loading of the main purpose is good, but the verbosity slightly reduces conciseness.

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

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

Given the lack of annotations and output schema, the description covers purpose, parameters with constraints, and comprehensive return fields. It also references a related tool. It is complete enough for a read operation, though it omits error conditions or prerequisites.

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 input schema has 0% description coverage, but the description provides meaningful details for both parameters, including patterns and length constraints. This adds significant value beyond the schema, compensating for the lack of schema descriptions.

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 explicitly states 'Retrieves metadata and definition of an environment blueprint,' using a specific verb and resource. It distinguishes from the sibling tool 'get_environment_blueprint_configuration' by noting that the latter retrieves configuration schema, clarifying the purpose.

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 mentions a related tool but provides no explicit guidance on when to use this tool versus alternatives. It lacks statements like 'use this when...' or 'do not use when...', leaving the agent without clear selection criteria.

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 provided, so the description carries full burden. It clearly indicates this is a read-only operation (gets configuration) and provides a detailed return structure including fields, patterns, and types. It transparently describes what the tool returns, ensuring the agent knows behavior without hidden side effects.

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 structured with clear sections (overall purpose, Args, Returns) and is front-loaded with the main purpose. While somewhat verbose due to detailed patterns and constraints, every part adds value. A minor reduction in length would be possible, but the current structure aids readability.

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

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

Given the moderate complexity, absence of output schema, and no annotations, the description fully documents the return structure with every field, pattern, and description. The two parameters are thoroughly explained. The tool's behavior and results are completely covered.

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 0%, but the description provides complete parameter documentation with patterns and explanations for both 'domain_identifier' and 'identifier'. The Args section adds meaning beyond the schema by explaining the purpose and constraints of each parameter.

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

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

The description clearly states it gets an Amazon DataZone environment blueprint configuration, specifying the exact resource and action. It distinguishes from sibling tools like 'list_environment_blueprint_configurations' and 'get_environment_blueprint' by focusing on the configuration schema and parameters.

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 does not explicitly state when to use this tool versus alternatives. It implies use for retrieving detailed configuration of a specific blueprint, but lacks guidance on when not to use or alternative tools. Usage context is only suggested by the tool name and general description.

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 provided. The description describes the normal behavior (retrieves details and returns fields) but does not disclose error conditions, permissions needed, or side effects. Adequate but not comprehensive.

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 well-structured with Args, Returns, and an Example. The return section is verbose but clear. Front-loaded with the purpose sentence. Slightly long but earns its length.

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

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

Given no output schema, the description provides a comprehensive list of return fields and includes an example. It covers all necessary contextual information for a simple retrieval 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?

Even though schema coverage is 0%, the description includes detailed parameter documentation with patterns, lengths, and optionality (e.g., 'Pattern: ^dzd[-_][a-zA-Z0-9_-]{1,36}$' for domain_identifier). This adds substantial meaning beyond the bare 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 clearly states 'Retrieves detailed information about a specific metadata form type in Amazon DataZone', providing a specific verb ('retrieves') and resource ('metadata form type'), which distinguishes it from siblings like 'create_form_type'.

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 explicit guidance on when to use this tool vs alternatives, such as when to use get_form_type versus search_types or other getters. The description only describes the action, not the context.

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 bears full responsibility for transparency. It explains the tool is a read operation, lists return fields with types and constraints (e.g., status can be DISABLED or ENABLED), and includes timestamps and user info. However, it does not mention permissions, error conditions, or pagination behavior.

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 well-structured with Args, Returns, and Example sections. It is front-loaded with the core purpose. While it is detailed, it is appropriately sized for the complexity of the tool (2 parameters, multiple return fields). Could be slightly more concise but still effective.

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

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

Given there is no output schema, the description enumerates all return fields with types and constraints. Parameter semantics are fully covered. The example adds practical context. For a simple retrieval tool, this is complete and leaves no major gaps.

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%, but the description provides comprehensive parameter details: each parameter has a clear description, type, and regex pattern. An example demonstrates usage. This fully compensates for the lack of schema descriptions.

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

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

The description clearly states the tool's purpose: 'Retrieves detailed information about a specific business glossary in Amazon DataZone.' It uses a specific verb ('retrieves') and resource ('business glossary'), and distinguishes it from siblings like 'get_glossary_term' and 'create_glossary'.

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

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

The description provides an example and parameter details, but does not explicitly state when to use this tool versus alternatives. Among sibling tools, there are other 'get' operations, but no guidance on when to choose 'get_glossary' over them.

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 states retrieval (a read operation) and lists return fields, giving some behavioral insight. However, it does not disclose error handling, authorization needs, or potential side effects.

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 well-structured with a purpose sentence, args, returns, and example. It is somewhat lengthy but appropriate for the detail needed. Front-loads the main action.

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

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

Given no output schema, the description provides a comprehensive return structure and an example. It covers both parameters and expected output. Missing error handling or permissions, but for a read tool it is fairly 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?

The input schema has 0% description coverage. The description adds full parameter semantics: 'The ID of the domain where the glossary term exists' and 'The ID of the glossary term to retrieve' with patterns, providing essential meaning 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 clearly states it 'Retrieves detailed information about a specific business glossary term in Amazon DataZone,' specifying the verb, resource, and platform. It distinguishes from sibling 'get_glossary' by focusing on a term rather than the glossary itself.

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 explains what the tool does but does not provide explicit guidance on when to use it vs. alternatives like search or list_tools. Usage is implied but not contrasted with siblings.

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 full burden. It discloses that specifying a listing version returns only that version's details, and the Returns section details the response structure. It does not mention auth requirements or side effects, but the 'get' verb implies a safe 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.

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

The description is well-structured with purpose, behavior note, args, and returns sections. It is front-loaded but could be slightly more concise by avoiding the full schema repetition in Args; however, that repetition adds value given the 0% schema coverage.

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

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

Given the tool's simplicity (get operation with 3 parameters, no output schema), the description is complete: it defines the resource, explains optional behavior, details all parameters, and describes the return structure including listing statuses and item details. No gaps are evident.

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%, but the description adds meaningful semantics for all three parameters: it provides patterns, length constraints, and explanatory text (e.g., 'The ID of the Amazon DataZone domain', 'The ID of the listing', 'The revision of the listing'). This fully compensates for the missing schema descriptions.

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 explicitly states the tool gets a listing, defined as a record of an asset at a given time in Amazon DataZone. It clearly identifies the verb and resource but does not differentiate from sibling tools like search_listings or other get_* 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?

The description implies usage when you have domain_identifier and identifier, and notes optional listing_revision behavior. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives such as search_listings.

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 describes the return data but does not disclose side effects, rate limits, permissions, or idempotency. As a read operation, the lack of such details is acceptable but not exemplary.

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 purpose and use cases, but the list of return fields is somewhat verbose and could be trimmed. It is structured but not maximally concise, earning a middling score.

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

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

Given the lack of output schema and annotations, the description should provide more context about parameters, error scenarios, and prerequisites. It covers return fields but leaves gaps in parameter semantics and behavioral context.

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

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

Schema coverage is 0%, so the description must compensate. It mentions 'known project by name or context' but the schema uses identifiers, not names. The description does not explain what the parameters represent or how to obtain them, leaving ambiguity.

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

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

The description uses a specific verb 'Retrieves' and resource 'project' in Amazon DataZone, clearly distinguishing it from sibling tools like 'list_projects' and other get_* tools. It also specifies the type of information returned, making the purpose unambiguous.

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

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

The description explicitly states when to use the tool: when the user is asking about a known project and wants to view deployment status, user roles, or audit metadata. It does not provide explicit 'when not to use' or name alternatives, but the context is clear enough.

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 bears full responsibility. It clearly indicates a read operation ('Get') but does not mention required permissions or any side effects. The detailed return value structure helps, but the lack of explicit read-only behavior or security context lowers the score.

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

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

The description is verbose, especially with the full return structure. While every sentence is informative, it could be more concise. The Args and Returns sections are well-structured, but the length is slightly excessive for a tool with 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?

Given the absence of an output schema, the description provides a thorough breakdown of the return value, including nested fields. For a getter with 2 required parameters and no complex nesting, this is nearly complete. Missing only minor aspects like error conditions or pagination (not relevant here).

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 input schema has 0% description coverage, but the description compensates by providing patterns and constraints for both parameters (e.g., regex patterns for domain_identifier and identifier). This adds valuable meaning beyond the bare JSON schema, justifying a score above baseline 3.

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

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

The description clearly states 'Get the details of the project profile in an Amazon DataZone domain.' It uses a specific verb ('Get') and resource ('details of the project profile'), which distinguishes it from sibling tools like 'list_project_profiles' (lists many) and 'create_project_profile' (creates).

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

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

The description implies when to use it (when you need details of a specific project profile) but does not explicitly state when not to use it or compare with alternatives. With siblings like list_project_profiles and create_project_profile, explicit usage guidance would improve this score.

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 provided, so description carries full burden. It discloses the return structure in detail (status, timestamps, listing details, etc.). However, it does not mention authentication, rate limits, or that it is a read-only operation, which is implicit.

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 well-structured with Args and Returns sections. While informative, it could be slightly more concise by moving patterns to the schema's description fields, but it remains focused.

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 get tool with two parameters and no output schema, the description covers input patterns comprehensively and details the return structure fully. It is contextually 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%, but the description adds pattern constraints for both parameters (domain_identifier and identifier) and explains the return structure. This adds meaningful value beyond the bare 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 clearly states 'Gets a subscription in Amazon DataZone,' using a specific verb and resource. It distinguishes from siblings like create_subscription_request or accept_subscription_request, which are mutation 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?

The description implies usage for retrieving a subscription's details but does not explicitly state when to use it versus alternatives or when not to use it. No callouts for prerequisites or exclusions.

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 provided, so description carries full burden. It indicates a read operation (retrieve) and details return structure, but lacks information on required permissions, side effects, or error conditions. The return format is well-described.

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?

Description is moderately concise with structured Args/Returns sections. However, it repeats info that could be in schema annotations (patterns, valid values) and includes a line break in the pattern string. Some 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?

Given no output schema and no annotations, the description adequately explains input parameters and return values. However, it lacks prerequisites, error handling, and does not address the mismatch with the input schema. Incomplete for a tool with 3 parameters and no other structured context.

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

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

Schema has 0% description coverage. The description adds patterns and valid values for parameters, but there is a contradiction: description names parameter 'type' with required status, while schema has 'user_type' not required. This mismatch reduces reliability and could confuse agents.

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

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

The description clearly states the tool retrieves a user profile in a specified Amazon DataZone domain for a given user. The verb 'retrieves' and resource 'user profile' are specific. Among siblings like search_user_profiles, this tool uniquely identifies a single profile by identifiers.

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 explicit guidance on when to use this tool vs alternatives. With 47 sibling tools including search_user_profiles, the description does not clarify when to use a direct retrieval versus a search. Implied usage only.

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 clearly indicates this is a read/list operation by using 'lists' and describes the return structure including pagination via nextToken. It does not mention side effects, permissions, or rate limits, but the read-only nature is evident from the verb and schema.

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 the purpose and uses clear sections (Args, Returns). However, it repeats phrases like 'The ID of the ...' for multiple parameters, making it slightly verbose. Overall, it is well-organized and each sentence adds value, but could be more concise.

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

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

Given 9 parameters (2 required) and an existing output schema, the description thoroughly explains all parameters and the return structure (items and nextToken for pagination). It does not cover error conditions or when to use the next_token parameter, but it provides sufficient context for the agent to invoke the tool correctly.

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

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

Since schema description coverage is 0%, the description provides detailed parameter documentation including constraints (e.g., max_results 1-50, default 50; name 0-64 chars), valid values (sort_by: 'NAME'; sort_order: 'ASCENDING'/'DESCENDING'; type: list of enumerated values), and explanations for each parameter. This goes far beyond the schema's type-only definition.

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 explicitly uses the verb 'lists' and the resource 'connections in Amazon DataZone', making the tool's purpose very clear. It distinguishes itself from sibling tools like list_data_sources and list_domains by specifying 'DataZone connections' and the context 'in the DataZone MCP server'.

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 it is 'specifically for listing DataZone connections' but provides no explicit guidance on when to use this tool versus alternatives like get_connection or search. It does not mention when not to use it or contrast with siblings, leaving the agent to infer usage from the name.

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 return structure and pagination but does not explicitly state that it is read-only or mention any side effects, auth, or rate limits. For a list operation, this is adequate but not exhaustive.

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 well-structured: purpose sentence, usage guidelines, related tools, parameter descriptions in bullet style, and return info. It is front-loaded with key information and every section is relevant without redundancy.

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

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

With 9 parameters and 2 required, no annotations, and no output schema, the description fully covers all needed aspects: purpose, when to use, parameter semantics, and return structure including nested objects. It leaves no major gaps.

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%, but the description provides detailed parameter information including types, constraints, patterns, valid values, and required status for each parameter. This adds significant meaning beyond the bare 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 starts with 'Retrieve a list of data sources in Datazone domain', clearly stating the verb and resource. It also distinguishes from the sibling tool 'get_data_source' by specifying when to use each. This meets the highest standard.

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 explicitly states when to use this API ('browsing, searching, or filtering') and when not ('config details of a known data source'), and directs to an alternative tool. It also includes related tools section.

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 provided, so description carries full burden. It discloses pagination, max_results limits, status filtering, and return format, which provides good behavioral context.

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?

Description is concise with clear Args and Returns sections, no wasted words.

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?

Explains return structure despite no output schema. All 3 parameters documented. No gaps for a listing 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 has 0% description coverage. Description adds meaningful details for all parameters: max_results default and max, next_token pagination, status examples. Greatly enhances 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?

Description clearly states 'Lists Amazon DataZone domains' with a specific verb and resource. It is distinct from sibling tools like create_domain, get_domain, etc.

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 as a listing tool, but no explicit guidance on when to use this tool versus alternatives like get_domain or other listing tools.

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 only states the basic read operation without disclosing permissions, pagination, or any side effects. The agent gets minimal behavioral insight.

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 concise with a single sentence for functionality, followed by structured Args and Returns. It is well-organized and free of unnecessary content, though the Returns line is vague.

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

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

Given no output schema and no annotations, the description leaves out important details like pagination, response format, and prerequisites. The agent may struggle to use the tool effectively without additional context.

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

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

With 0% schema coverage, the description adds value by providing example identifiers for both parameters. However, the explanations are essentially rephrasing the parameter names, offering limited additional context beyond the examples.

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

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

The description clearly states the action 'lists child domain units' and specifies the parent domain unit in Amazon DataZone. It distinguishes from siblings like 'list_domains' which lists domains, and 'get_domain_unit' which retrieves a single unit.

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

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

No guidance on when to use this tool versus alternatives, such as 'get_domain_unit' for a single unit or 'list_domains' for top-level domains. The description lacks usage context.

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 details return structure and pagination, but does not explicitly state that the operation is read-only or safe. It provides reasonable behavioral context for a list tool but lacks explicit safety disclosure.

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 verbose, with redundant 'Args:' sections and a lengthy return structure. It front-loads the main purpose but could be more concise. The docstring style is structured but includes unnecessary repetition.

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

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

Given that an output schema exists (context signal), the description provides comprehensive parameter details and return structure. It covers pagination and parameter constraints. However, it lacks mention of permissions or side effects, which would be helpful for a tool with no annotations.

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 compensates by explaining each parameter: domain_identifier pattern, max_results range, next_token purpose. It also describes return structure, adding meaning beyond the schema's property names.

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

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

The description clearly states that the tool 'lists environment blueprints' and specifies the domain context. However, it does not differentiate itself from the sibling tool 'list_environment_blueprints', which could cause confusion. The name includes 'configurations', but the description refers to 'blueprints', slightly ambiguous.

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

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

There is no guidance on when to use this tool versus alternatives like 'list_environment_blueprints' or other listing tools. The description only implies usage for listing, without specifying 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 burden. It describes the function and return values but does not disclose behavioral traits such as whether the operation is read-only, any side effects, rate limits, or authentication requirements. The mention of pagination via next_token is useful but incomplete.

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 well-structured with a clear one-liner, followed by Args and Returns sections. It is concise, though slightly verbose with parameter patterns. Every sentence adds value, making it easy to parse.

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 (though not shown), the description already explains return values. It covers all parameters, pagination, and filtering. However, it lacks context on when to use this list vs. other related tools, which is addressed in the usage guidelines dimension.

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 description adds significant meaning beyond the input schema. It explains each parameter's purpose, constraints (e.g., patterns, min/max length, default values), and filtering behavior. This compensates for the 0% schema coverage, providing rich semantics.

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

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

The description clearly states 'Lists environment blueprints in an Amazon DataZone domain.' It uses a specific verb ('Lists') and resource ('environment blueprints') and distinguishes from sibling tools like get_environment_blueprint (singular) and list_environment_blueprint_configurations.

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 explicit guidance on when to use this tool versus alternatives. The description lists parameters but does not indicate the expected context or exclusions. The purpose is clear, but usage context 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?

Discloses pagination via next_token and max_results, and return structure with items and nextToken. No annotation provided, but description adds value by detailing fields in the response. However, does not explicitly state read-only nature or authorization 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?

Well-structured with Args and Returns sections; front-loaded purpose. Some verbosity in parameter docs but each part adds value. Appropriate for complexity.

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?

Covers purpose, parameters, and return structure thoroughly. Missing error handling or authorization details, but acceptable for a list operation with straightforward 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?

With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation including patterns, required status, and constraints. This adds significant meaning beyond the bare 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?

Description clearly lists environment profiles with filtering options, using specific verb 'list' and resource 'environment profiles'. It distinguishes from sibling tools by focusing on a specific entity, but does not explicitly differentiate from similar list tools like list_environments.

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?

Implies usage when needing environment profiles for a domain, optionally filtered. No explicit guidance on when not to use or alternatives among sibling list tools.

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 indicates the tool lists environments (implying read-only) and returns the API response or None on error. It does not explicitly state that it is non-destructive, nor does it disclose prerequisites, permissions, or rate limits. The behavior is partially described but not fully transparent.

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 structured as a clear docstring with Args, Returns, and Example sections. It is front-loaded with the purpose, and every sentence provides necessary information. No redundant or filler 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?

Given 11 parameters and no output schema, the description documents all parameters and the return type. However, it does not detail the response structure beyond 'API response containing environment details'. Pagination via next_token is mentioned but no further pagination behavior. The example helps, but more response detail would improve completeness.

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

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

The input schema has 0% description coverage, but the description includes a full Args block documenting all 11 parameters with brief explanations, types, and defaults. For status, valid enum values are listed. This adds complete meaning beyond the schema, fully compensating for the lack of schema descriptions.

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

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

The description clearly states the verb 'Lists' and resource 'environments in Amazon DataZone', providing a specific action. However, it does not differentiate from sibling list tools like list_environment_profiles or list_environment_blueprints, relying on the tool name for distinction. This is clear but lacks explicit sibling differentiation, so not 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 provides no guidance on when to use this tool versus alternatives. There are many sibling list tools, and the description does not mention when to choose list_environments over list_domains, list_projects, etc. No when-to-use, when-not-to-use, or alternative tool references are given.

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

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

No annotations are provided, so the description carries the full burden. It describes pagination, sorting, and the return structure (members list, next token). It does not mention authentication or error conditions, but for a read operation it is fairly transparent.

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?

Well-structured with Args and Returns sections, but somewhat verbose as it repeats schema details. However, since the schema lacks descriptions, this is justified.

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

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

Given no output schema, the description details the return structure and pagination. It covers the main aspects, though it could mention prerequisites like existing domain/project.

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 0%, but the description fully documents each parameter with patterns, valid values, and defaults. It adds significant meaning beyond the schema's bare titles and types.

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

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

The description clearly states the tool lists memberships of a specified Amazon DataZone project, with the verb 'lists' and resource 'memberships'. It distinguishes from siblings like create_project_membership (creation) and list_projects (projects list).

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 explicit guidance on when to use this tool versus alternatives like search or list_projects. Usage is implied by the tool's purpose, but no when-to-use or when-not-to-use conditions 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 must fully disclose behavioral traits. It mentions pagination parameters but does not state ordering, filtering capabilities, rate limits, or that it is a read-only operation. The return type is vaguely described as 'API response' without detail.

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 structured with clear Args and Returns sections, which is helpful for an AI agent. It is relatively concise, but the Returns section is minimal and could be more informative without significant added length.

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

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

Given the absence of an output schema, the description should elaborate on the return structure. It only states 'the API response containing the list of project profiles', which is insufficient. No error conditions or edge cases are mentioned. The tool has only three parameters, so basic completeness is adequate but not thorough.

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 0% description coverage, so the description must compensate. It provides meaningful descriptions for all three parameters: domain_identifier, max_results (with range and default), and next_token (pagination). This adds value beyond the schema, though domain_identifier format is not explained.

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

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

The description clearly states the action (lists), resource (project profiles), and scope (in an Amazon DataZone domain). It effectively distinguishes from sibling tools like list_projects (lists projects) and get_project_profile (retrieves a single profile).

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 does not explicitly state when to use this tool versus alternatives such as list_projects or search. Usage is implied for listing all project profiles in a domain, but no guidance on prerequisites or when to use is provided.

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 provided, so description carries full burden. It does not disclose safety (read-only), potential errors, rate limits, or other behavioral traits. Only states it returns 'The API response containing the list of projects'.

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?

Description is structured as a docstring with Args and Returns, concise and front-loaded with the main purpose. Every sentence adds value.

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

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

Given no output schema, description adequately covers return type. All parameters are documented. Could include more details on pagination behavior or output structure, but sufficient for a list operation.

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?

All 6 parameters are described in the Args section with clear meanings (e.g., 'domain_identifier: The identifier of the domain'). Schema has no descriptions, so description fully compensates.

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

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

The description clearly states 'Lists projects in an Amazon DataZone domain with optional filtering and pagination.' It uses specific verb and resource, distinguishing it from sibling tools like create_project or get_project.

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

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

No guidance on when to use this tool versus alternatives or when not to use it. The description only states what it does without context or exclusions.

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 bears full responsibility. It details the return structure but does not disclose side effects, permissions required, potential errors, or whether the operation is reversible. The description is adequate but not comprehensive.

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 well-structured with a single-sentence summary followed by Args and Returns sections. Every line adds value, and the most important information (purpose) is front-loaded.

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

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

Given the absence of an output schema, the description provides a detailed Returns section listing key response fields. However, it does not explain error conditions, required permissions, or how this tool relates to other asset lifecycle tools (e.g., create_asset, get_listing). Nevertheless, the core behavior is well-covered.

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

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

Schema description coverage is 0%, so the description must compensate. It provides clear, concise descriptions for all four parameters (e.g., 'The ID of the domain containing the asset'), adding meaning beyond the schema titles. This fully compensates for the lack of schema descriptions.

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

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

The description clearly states 'Publishes an asset to the Amazon DataZone catalog,' which is a specific verb-resource combination. It distinguishes from siblings like create_asset (creates but does not publish) and get_asset (retrieves).

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 (you must have an asset to publish) but does not explicitly state when to use this tool versus alternatives such as create_asset or get_listing. No exclusions or prerequisites are mentioned.

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 full burden. It details parameters, constraints (e.g., patterns, valid ranges), pagination via next_token, and return structure (items, nextToken, totalMatchCount). It does not explicitly state idempotency or rate limits, but the example and parameter details provide solid behavioral insight.

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 well-structured with Args, Returns, and Example sections. It is longer than necessary but justified by the need to explain 10 parameters without schema descriptions. The one-line purpose statement at the start aids quick understanding.

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

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

Given the tool's complexity (10 parameters, no output schema), the description covers all inputs, return values, and pagination. It lacks only minor details like error handling or typical use comparisons, but is sufficient for an agent to invoke correctly.

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

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

Schema description coverage is 0%, so the description must provide full parameter semantics. It does so comprehensively, including types, valid values (e.g., search_scope enums, additional_attributes options), patterns, optionality, and constraints. The example demonstrates usage, adding practical context.

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 'Searches for assets in Amazon DataZone,' which clearly specifies the verb and resource. However, the search_scope parameter includes GLOSSARY, GLOSSARY_TERM, and DATA_PRODUCT, making the tool broader than just assets. This slight inconsistency prevents 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 provides no guidance on when to use this tool versus sibling tools like search_listings, search_types, or search_group_profiles. It does not specify exclusions or prerequisites beyond the required parameters, leaving the agent to infer appropriateness from the parameter list.

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

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

With no annotations, the description carries the burden. It discloses pagination behavior and error raising (HTTPError), but does not explicitly confirm read-only nature, rate limits, or side effects. The behavioral context is adequate but not comprehensive.

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 well-structured with clear sections (Args, Returns, Raises) and the main purpose is front-loaded. It is fairly concise but could be slightly tighter by removing redundant phrasing. Still, no wasted sentences.

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

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

No output schema exists, so the description must explain return values—it does so with a structured dict including items and nextToken. Error handling is mentioned. However,it lacks edge case details or explanations of status codes. Overall complete for the complexity.

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 0%, so the description fully documents parameters. It adds patterns (e.g., domain_identifier regex), valid values (group_type enum), ranges (max_results 1-50), lengths, and defaults, going well beyond the schema's type-only information.

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 explicitly states the tool searches for group profiles within an Amazon DataZone domain, specifying the resource (group profiles) and the action (search). It distinguishes from siblings like 'search_user_profiles' and generic 'search' by focusing on group profiles.

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 stating it allows finding groups with group type and search text, but it does not explicitly state when to use it versus alternatives or when not to use it. No exclusions are provided.

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?

Without annotations, the description carries the burden. It correctly implies a read-only operation through 'search' and describes input behavior but does not cover rate limits, authentication, or detailed side effects. However, for a search tool, this is sufficient.

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 well-organized: a single-sentence purpose, followed by usage guidance, related tools, and a clear list of arguments. Every sentence adds value without redundancy.

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

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

Covers purpose, usage, and parameters comprehensively. However, the return value is only described as 'API response containing search results' without specific fields or example, which could be improved given the absence of an output schema.

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 description includes a detailed 'Args' section that explains each parameter's type, optionality, and purpose, plus valid values and examples for complex parameters (e.g., additional_attributes, search_in, sort). This compensates for the 0% schema description coverage.

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

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

The description clearly states the tool's purpose: 'Search published data asset listings' with keyword, filter, and sort options. It distinguishes itself from the sibling 'search' tool by specifying that it is limited to published listings.

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?

Explicitly advises when to use this tool ('search only within published data asset listings') and contrasts with the 'search' tool for general discovery, providing clear guidance on alternatives.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It does not mention whether the operation is read-only, requires specific permissions, has rate limits, or any side effects. For a search action, it likely is read-only, but this is not stated, leaving a gap in transparency.

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 structured as a clear docstring with Args and Returns sections. It is front-loaded with the main purpose. However, it is somewhat lengthy due to detailed parameter descriptions; a more concise summary could be beneficial, but overall it remains well-organized and readable.

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

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

Given 10 parameters, no output schema, and no annotations, the description covers all parameters and return values comprehensively, including pagination and defaults. The only missing element is behavioral transparency (e.g., idempotency, permissions), but for a search tool, the parameter and return coverage is sufficient for an agent to invoke it correctly.

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

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

With 0% schema description coverage, the description compensates fully. It provides detailed explanations for each parameter, including regex patterns, valid ranges, allowed values, and defaults. For example, it describes the domain_identifier pattern, max_results range, search_scope values, and pagination token constraints, adding significant meaning beyond the bare 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 clearly states that the tool invokes the SearchTypes action to retrieve type definitions (asset types, form types, lineage node types) that match search criteria. It uses specific verbs and resources, and clearly distinguishes from sibling tools like 'search', 'search_listings', etc., which target different entities.

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 explains what the tool does and its parameters, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., 'search', 'search_listings'). It lacks 'when not to use' or comparative context, leaving the agent to infer usage from purpose 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 provided, the description carries the full burden of behavioral disclosure. It clearly describes that the tool performs a read/search operation with filtering and pagination, and returns a list of user profile summaries with specific fields. There is no mention of side effects, destruction, or access requirements, which is acceptable for a search tool, but it could be more explicit about its read-only nature.

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 well-structured with separate Args and Returns sections, making it easy to parse. It is front-loaded with the purpose statement. While it is relatively long, every sentence adds value, and the structure supports quick reference. A slight reduction in verbosity could improve conciseness, but it is not excessive.

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

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

Given the tool has 5 parameters, no output schema, and no annotations, the description is quite complete. It covers all parameters, explains return structure (including fields and types), and describes pagination. However, it lacks mention of error handling, required permissions, or edge cases, which would be beneficial for completeness.

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

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

The schema has 0% description coverage, so the description must compensate. It does so effectively by detailing each parameter: constraints (pattern, valid range, max length), required status, valid enum values for user_type, and the role of next_token for pagination. This adds significant meaning beyond the schema's titles and types.

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

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

The description clearly states it searches for user profiles within a specified Amazon DataZone domain, distinguishing it from sibling tools like search_group_profiles (for groups) and get_user_profile (for a single profile). The verb 'Searches' combined with the specific resource 'user profiles' and domain context makes the purpose unambiguous.

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

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

The description explains the tool's functionality and parameters, but it does not explicitly state when to use this tool over alternatives or when not to use it. The usage context is implied by its purpose, but there is no direct guidance on selecting it among siblings like search or get_user_profile.

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 provided, so description carries full burden. It mentions idempotency via client_token and lists return fields including status and errorMessage, but does not explicitly state whether the operation is destructive or read-only, nor any required permissions or side effects beyond creating a run.

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 well-structured with explicit Args, Returns, and Example sections. It is front-loaded with the purpose. However, it is somewhat verbose, especially with detailed return field listing, which could be condensed without losing clarity.

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 comprehensively covers what the tool does, all parameters with constraints, and the return structure with detailed fields. There is no output schema, but the inline Return section provides equivalent information. The example adds practical context.

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

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

Schema description coverage is 0%, but the description provides extensive parameter details: patterns for domain_identifier, explanation of client_token for idempotency, optionality, and length constraint. The example further clarifies usage, fully compensating for the schema gaps.

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

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

The description clearly states it 'Starts a data source run in Amazon DataZone' with a specific verb and resource. It distinguishes from related tools like create_data_source and get_data_source by focusing on starting a run, not managing the data source itself.

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 does not explicitly state when to use this tool versus alternatives or mention prerequisites like having an existing data source. It implies usage through parameter details and example but lacks guidance on when-not-to-use or sibling tool comparisons.

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