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

With no annotations, the description carries the behavioral burden. It adds a meaningful consistency property, but it does not disclose atomicity, failure handling, permissions, or side effects beyond 'one call keeps them consistent.'

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

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

The description is two sentences with no filler. It front-loads the core purpose and then immediately gives a practical use case, making it easy for an agent to scan and apply.

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 combination of a clear purpose, a concrete usage scenario, a detailed input schema, and an output schema makes the definition sufficient for selecting and calling the tool. It could add explicit non-goals, but the current coverage is strong for a complex bulk 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?

Schema description coverage is 100%, and the proposed_change parameter is richly documented with an example and ID uniqueness rule. The prose adds no additional parameter-level meaning, so the baseline score of 3 applies.

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

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

The description states a specific operation: applying many entity changes to a workspace in one call. This distinguishes it from single-entity tools like create_tag or update_workspace, though it could more explicitly enumerate create/update/delete coverage.

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

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

It gives a clear when-to-use rule: use this when creating entities that reference each other, such as a tag and its trigger, because one call keeps them consistent. It does not explicitly mention alternatives or exclusions, but the guidance is concrete and useful.

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 of behavioral disclosure. It clearly describes the return values (credential resolution, read-only mode, OAuth scopes), but it does not explicitly state whether the operation has side effects or what authentication prerequisites exist. The verb 'check' implies a read-only operation, but this is not stated.

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 brief, front-loaded with the purpose, and uses a clear 'Returns' section for the output. Every sentence contributes meaningful information with 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?

The tool is simple (no parameters, output schema present) and the description covers its core behavior and return semantics. One minor gap is that it does not explicitly clarify that this checks the API/credential client rather than a Tag Manager 'client' entity, which could matter given the many client-related sibling tools.

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

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

The tool has zero parameters, so the input schema is already complete and the description cannot add parameter-level meaning. Per the baseline for zero-parameter tools, this is sufficient.

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 ('Check') and names the exact resource ('Tag Manager client') and the condition being verified (configured and can authenticate). The return list reinforces that this is a health/status check, distinguishing it from CRUD operations like list_clients or get_client.

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 intended use case is implied: use this when you need to verify client configuration and authentication status. However, it does not explicitly state when not to use it or name alternatives like get_client or list_clients, leaving some selection work to the agent.

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

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

With no annotations, the description must carry the burden of disclosing that this is likely a destructive operation, which container survives, and what happens to the merged container. The tool description only says 'Merge one container into another' and omits irreversibility, permission requirements, and settings behavior; the schema parameter descriptions partially compensate, but the description itself does not.

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

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

The description is a single sentence with no filler and front-loads the core action, which makes it efficient. It is slightly under-specified for a merge operation, but that deficiency is better captured in other dimensions.

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 non-trivial, likely destructive merge operation with five parameters and zero annotations, this description is too sparse. It does not explain the merge outcome, the surviving container, how setting_source behaves, or any permission or irreversibility caveats; the output schema covers return shape but not the behavioral context needed to invoke the tool safely.

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

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

Schema description coverage is 100%, so the baseline is 3 even though the tool description adds no parameter-specific detail. The input schema already documents account_id, container_id, other_container_id, setting_source, and allow_user_permission_feature_update, including the target container surviving the merge.

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

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

The description states a specific action ('Merge') and resource ('one container into another'), and the combine_containers operation is clearly distinct from sibling tools like update_container or delete_container. However, it does not define what 'merge' implies in terms of content or survival, so it is clear but not fully elaborated.

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

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

The description gives no guidance on when to use this tool versus alternatives such as update_container, move_entities_to_folder, or publish_workspace. No prerequisites, exclusions, or alternative-tool routing is mentioned; usage is only implied by the verb.

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?

There are no annotations, so the description carries the full burden of explaining behavior. It conveys that this is a mutating enable operation but says nothing about idempotency, whether it is additive to existing enabled types, what happens if a type is already enabled, or required permissions. This is too sparse for a write 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?

A single, front-loaded sentence with no filler or redundant clauses. Every word adds either the action or the scope.

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

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

With complete parameter descriptions and an output schema, the description does not need to document inputs or return values. However, because there are no annotations and no usage or behavioral context, the description is not fully complete for an agent deciding to call this mutation safely.

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

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

Schema description coverage is 100%, and the schema already explains each parameter, including the camelCase types format with examples. The description adds no parameter-level detail, but none is needed because the schema is explicit.

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

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

The description states a specific action ('Enable') on a specific resource ('built-in variables in a workspace') and is distinct from the sibling list/delete/revert_built_in_variable tools by verb and from create_variable by the 'built-in' qualifier. The action and resource scope are 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?

No guidance is given about when to choose this over create_variable, list_built_in_variables, or delete_built_in_variable. The intended context can only be inferred from the word 'built-in' and the required workspace identifiers, which is insufficient for routing among many sibling 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?

Without annotations, the description carries the full behavioral burden. It discloses an important failure mode (web containers fail), but it does not mention permissions, idempotency, conflict behavior, or other side effects. The provided context 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?

Two short sentences: the first states the core action and scope, the second delivers the critical caveat. Every word earns its place, and the most operational detail 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 rich input schema and the presence of an output schema, the description is largely sufficient: it provides the one non-obvious environmental constraint. It could add permission or duplicate-handling notes, but nothing essential to invoking the tool correctly 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?

Schema coverage is already 100%, so the baseline is 3. The description adds meaning beyond the schema by clarifying that container_id must reference a server container, not a web container. It wisely avoids repeating the well-documented client object details.

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

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

The description states a specific action (create), a specific resource (client), and a scope (workspace), with the added constraint that only server containers accept clients. This clearly distinguishes it from sibling operations like update_client, delete_client, or list_clients.

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

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

It explicitly tells the agent when the tool is valid (server containers) and when it is not ('Creating one in a web container fails'). This is a direct usage condition that prevents a common mistake, and no alternative create-client sibling exists to confuse routing.

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 disclosing behavior. It only says 'Create a container,' which implies a write operation but doesn't mention permissions, idempotency, side effects, or response behavior. 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 a single sentence, which is concise, but it omits critical context. It is not overly verbose, but it is too brief to be useful beyond stating the obvious.

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

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

There is an output schema, so return values are covered, but the description fails to explain when to create a container, what prerequisites exist, or how it differs from other creation tools. This leaves gaps for an agent deciding whether to invoke it.

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 already documents both parameters with good descriptions, including the container object's structure and allowed usageContext values. The description adds no additional parameter semantics, so a baseline of 3 is appropriate given 100% schema coverage.

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

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

The description clearly states the action 'Create', the resource 'container', and the scope 'in a Tag Manager account'. It names a specific resource that distinguishes it from sibling create_* tools, though it does not explicitly contrast with them.

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

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

There is no guidance on when to use this tool versus alternatives like create_tag or create_workspace, nor any prerequisites such as having an account. The description simply states the action without 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 full responsibility. It doesn't disclose that creating an environment likely mutates resources, nor does it mention any prerequisites (like existing container), authentication requirements, or side effects. The description is too terse to inform the agent of what to expect.

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?

It's a single sentence, which is concise, but it lacks substantive content. The brevity is not harmful, but the sentence could be more informative without much extra length (e.g., 'Creates a new Google Tag Manager environment within a specified container.'). It's not front-loaded with any critical context.

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

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

Given that this is a create operation, the description should explain the purpose (e.g., for previewing changes), prerequisites (container must exist), and any constraints (e.g., environment name uniqueness). The output schema is present, but the description lacks guidance on the operation's significance in the broader workflow. Multi-line schema example helps, but still incomplete.

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

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

Schema description coverage is 100%, so the input schema already documents all parameters including the environment object's example. The description adds no additional parameter meaning; it's a simple 'Create' verb that aligns with the schema. Baseline 3 is appropriate since the schema carries the load.

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

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

The description states the verb 'create' and resource 'environment', but is too generic — 'Create an environment in a container' doesn't specify that this is a Google Tag Manager environment or how it differs from sibling tools like 'create_workspace' or 'create_container'. The purpose is clear at a basic level but lacks specificity.

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. The description does not mention that environments are typically used for version testing, nor does it clarify that this is for creating a new environment rather than updating or listing them. An agent might incorrectly consider it for similar create actions.

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, but it only says 'create' and offers no detail on side effects, permissions, duplicate handling, or workspace scoping. For a mutation tool, this is a noticeable gap.

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

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

The description is a single, front-loaded sentence with no filler. It is appropriately brief, though its brevity leaves usage and behavioral context to other dimensions.

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

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

An output schema exists and all required parameters are documented in the input schema, so an agent can construct a valid call. However, the description lacks prerequisite, side-effect, and selection context, making it only minimally complete.

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

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

Schema description coverage is 100%, and the folder parameter already documents the required name and gives an example. The description itself adds no parameter-level meaning beyond the phrase 'in a workspace,' so it remains at the schema-heavy baseline.

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

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

The description states a clear action ('Create'), resource ('folder'), and context ('in a workspace'), so it is not tautological and is distinguishable from folder update/list/delete tools. It does not explicitly call out a sibling alternative, but the verb and object make the core 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?

There is no guidance about when to use this tool versus alternatives such as update_folder, delete_folder, or move_entities_to_folder. No prerequisites, exclusions, or caveats are mentioned; usage is only implied by the verb.

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?

Annotations are absent, so the description carries the full burden of disclosing behavior. 'Create' implies a write operation, but the description does not state permissions needed, whether the operation is additive and non-destructive, or any side effects. For a mutation tool with no annotation coverage, this is a meaningful gap.

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

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

The description is a single front-loaded sentence with no wasted words. It states the action and target immediately and does not repeat schema details.

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 schema fully documents inputs, an output schema is present, and the purpose is clear, so the call can probably be constructed. However, without annotations and with no usage or behavioral context, the description is only minimally complete for a write operation. The agent has to assume standard create semantics.

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 already provides 100% coverage for all four parameters, including a descriptive gtag_config example. The description itself adds no parameter-level meaning, but under the baseline for high schema coverage this is acceptable.

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 ('Create'), a specific resource ('Google tag configuration'), and a scope ('in a workspace'), so an agent can tell it apart from update/delete/get variants. It is not explicitly contrasted with sibling create_tag, but the resource type is distinct enough. It could earn a 5 by explicitly saying it creates a GtagConfig entity as opposed to a tag.

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

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

No when-to-use, prerequisites, or alternatives are mentioned. The description simply states what it does, leaving the agent to infer that it is appropriate whenever a new Google tag configuration is needed in a workspace. There is no guidance about when to use create_tag instead.

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 for behavioral disclosure, but it only repeats the basic action. It does not mention that this mutates a workspace, that invalid tag types may be rejected, that the tag is associated with a container/workspace, or any possible side effects or failure modes. It is not misleading, but it is far too sparse.

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

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

The description is a single, front-loaded sentence with no filler. It effectively communicates the core action in minimal words narr. However, it borders on tautology with the tool name, and the added 'in a workspace' is the only structural differentiation, making it slightly too sparse.

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 rich schema description for the 'tag' parameter and the full parameter coverage compensate for many gaps, and the output schema likely covers return values. Still, the tool description omits usage context, prerequirements, and behavioral side effects. Given the absence of annotations, this is a minimally viable definition but not a complete one.

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

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

Schema description coverage is 100%, so the baseline is 3 even without parameter explanations in the tool description. The tag parameter's description adds substantial meaning with a full example, required fields, and an explanation of internal type codes. The tool description itself adds no parameter semantics, so it does not exceed the baseline.

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

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

The description states a clear verb and resource: 'Create a tag in a workspace.' It identifies the object type (tag) and scope (workspace), which distinguishes it from sibling operations like create_trigger or create_variable. However, it does not explicitly differentiate itself from other tag-related operations such as update_tag or get_tag.

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 is no mention of prerequisites, such as needing an existing workspace/container, or conditions that would make create_tag preferable to update_tag. The only indirect hint is the parameter-level suggestion to copy shape from get_tag, but that is buried in the schema, not the tool 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 are provided, so the description carries the full behavioral burden. It only states the basic create action and workspace, omitting side effects, permission requirements, duplicate/overwrite behavior, and the relationship of account_id and container_id to the workspace.

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

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

The description is a single sentence with no filler and front-loads the action and resource. It is efficient, though its brevity means it contributes little beyond the tool name.

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?

Combined with a complete input schema and an output schema, the definition is workable for basic invocation. However, it lacks usage routing and behavioral caveats, which is a noticeable gap for a mutation tool that creates complex sandboxed template definitions.

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

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

Schema description coverage is 100%: all four parameters have descriptions, including a detailed template object format with sandboxed JavaScript sections. The description adds no parameter-level detail, so the baseline of 3 applies.

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

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

The description states a clear action (create), a specific resource (custom template), and a scope (workspace). This distinguishes it from sibling mutation tools like update_template and delete_template, though it does not explicitly contrast it with import_template_from_gallery.

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

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

There is no guidance about when to use this tool versus alternatives such as import_template_from_gallery or update_template. No prerequisites like workspace existence or permissions are mentioned; the only context is the workspace scope in the one-line 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose one key behavior (failure on web containers), but it does not mention other aspects such as required permissions, side effects, or what happens on success. This is a minimal but non-trivial disclosure, so a 3 is appropriate.

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

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

The description is exceptionally concise: two sentences with no filler. The primary purpose is front-loaded, and the critical constraint follows immediately. Every word earns its place.

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

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

Given the nested transformation object and the presence of an output schema, the description covers the most critical contextual factor (container type). However, it does not mention any prerequisites, permissions, or side effects of creation, and since there are no annotations to fill these gaps, the description is only partially 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 100% description coverage, so the parameters are fully documented there. The description adds no additional meaning or examples beyond what the schema already provides, meeting the baseline of 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 the action ('Create a transformation') and the resource ('in a workspace'), with a specific verb and object. It also includes a critical constraint (server containers only) that distinguishes this from generic create operations and adds meaningful context beyond the name.

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

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

The description provides a clear condition for use ('Only server containers accept transformations') and warns that web containers fail, which implicitly tells the agent when not to use it. However, it does not explicitly name alternatives or state when to prefer this over other create_* tools, so the guidance is incomplete.

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 of disclosing behavior. It only says 'Create a trigger in a workspace,' which implies a mutating operation, but it does not mention permissions, reversibility, validation behavior, or side effects. The extra trigger-type explanation is about parameter construction, not runtime 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 compact and front-loaded: the first sentence states the purpose, and the second paragraph adds only high-value parameter guidance without fluff. Every sentence earns its place.

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

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

For a 4-parameter create operation with an output schema and fully described parameters, the description is largely complete. It adds trigger-type context and a fallback for shape uncertainty. It could additionally mention permissions or uniqueness constraints, but the combination of schema and description covers the essential invocation knowledge.

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 already covers all 4 parameters with examples (100% coverage), so the baseline is 3. The description adds meaningful guidance by enumerating valid trigger type codes and recommending get_trigger for copying the shape, which goes beyond the schema's JSON example.

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 sentence uses a specific verb and resource ('Create a trigger in a workspace'), unambiguously identifying the action and object. It is clearly differentiated from sibling tools like list_triggers, update_trigger, and delete_trigger by the 'create' verb.

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 establishes the tool's core use case, creating a trigger, and provides practical guidance for the trigger shape: 'Copy the shape from an existing trigger via get_trigger when unsure.' While it doesn't explicitly list when not to use this tool or compare with update_trigger, the context is clear and the get_trigger pointer offers an alternative for shape uncertainty.

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, yet it only reveals that access is granted. It does not disclose what happens if the permission already exists (error vs. overwrite), whether granting is additive or replaces existing permissions, whether authorization is required, or how the operation affects the account.

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

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

A single sentence with zero wasted words, front-loaded with the action verb and resource. It is appropriately sized and immediately scannable, though its brevity does sacrifice behavioral detail captured in other dimensions.

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 presence of an output schema and a richly detailed input schema (with examples and enum values) means return values and parameter construction are covered elsewhere. The gap is behavioral context: an agent gets no information about idempotency, duplicate handling, or prerequisites, which is notable for a permission-granting mutation.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly, including a detailed JSON example with enum values for account and container permissions. Per the baseline rule for high schema coverage, a 3 is appropriate; the description itself adds no parameter-level meaning.

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

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

The description states a specific verb ('Grant') with a clear resource ('user access to a Tag Manager account'), making the tool's function obvious. It is distinguishable from siblings like create_container or create_workspace by naming the permission domain, though it does not explicitly differentiate itself from update_user_permission or delete_user_permission.

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 the closely related siblings update_user_permission, delete_user_permission, or list_user_permissions. There are no exclusions, prerequisites, or alternative-routing hints, leaving the agent to infer the usage context entirely from the tool's 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?

With no annotations, the description carries the full burden, but it only states that the operation creates and documents variable type codes. It does not disclose side effects, required permissions, idempotency, validation behavior, or any other consequences of the mutation beyond the obvious 'create' semantics.

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

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

The description is compact: one leading purpose sentence followed by a dense reference for type codes. Every sentence earns its place, and the most important action is front-loaded before the technical detail.

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 full schema coverage and output schema, the definition covers the required IDs and the nested variable shape, and the description compensates for the one tricky area (type codes and payload shape). It is not exhaustive about when to prefer an existing variable or built-in variable, but an agent has enough to invoke it correctly in common cases.

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 is fully covered (100%), but the description adds real value by explaining Tag Manager's internal type codes 'v', 'c', 'jsm', 'k', and 'u', which are not semantics in the schema. The advice to copy an existing variable's shape via get_variable also directly helps agents construct the nested 'variable' parameter correctly.

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 opens with a specific verb and resource, 'Create a variable in a workspace', so an agent can tell it is for creating a variable. It does not explicitly differentiate from sibling create tools like create_tag or create_built_in_variable, but the resource name and title make the target clear.

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 type-code list and the pointer to 'get_variable ... when unsure' give useful context about how to construct the variable payload. However, the description never directly states when to choose create_variable over update_variable or create_built_in_variable, leaving usage conditions mostly implied.

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 states the destructive side effect ('the API deletes it'), the post-condition ('makes the new version the container's latest'), and the non-publishing behavior. This is exactly the kind of critical behavioral context an agent needs before invoking a workspace-consuming call.

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

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

The description is two short sentences, with the core action front-loaded and the two most important caveats (deletion and non-publishing) placed immediately after. Every sentence earns its place; there is no fluff or repetition of schema information.

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 moderate-complexity mutation tool, the description covers the destructive effect, the resulting state, and the publish workflow. An output schema exists, so return values need no explanation. A small gap is that it does not mention any prerequisites or failure behaviors, but the combination of the explicit destructive warning and the sibling routing makes this adequately complete.

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

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

Schema description coverage is 100%, with each parameter (account_id, container_id, workspace_id, version_options) having a description. The description itself does not add parameter-level detail, but the schema already handles that, so the baseline of 3 applies. The only slight extra is that the workspace deletion behavior gives additional meaning to workspace_id, but this is not a parameter explanation.

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 opens with a specific verb and resource pair: 'Turn a workspace into a container version.' It then clarifies the transformation by stating the workspace is deleted and the new version becomes the container's latest. It also explicitly distinguishes itself from publish_version, so an agent can tell it apart from closely related version tools without opening schemas.

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

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

The description gives clear when-to-use context by explaining the workspace is consumed and the version becomes latest. It also gives an explicit when-not-to-use and an alternative: 'Creating a version does not publish it; use publish_version for that.' This directly routes the agent to the correct sibling when publishing is needed.

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 of behavioral disclosure. It only says 'Create a workspace in a container' and gives no information about side effects, duplicate-handling, permissions, idempotency, or whether creation is reversible. Nothing contradicts annotations because there are none.

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

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

The description is a single six-word sentence with no filler or repetition. It is front-loaded and easy to parse, though it is arguably too terse to carry the behavioral and usage information an agent needs.

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 input schema fully documents parameters and an output schema exists, so return-value documentation is not the description's job. However, with no annotations and no usage guidance, the description alone leaves gaps around when to create a workspace, what constraints apply, and what creating one implies for subsequent operations.

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

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

Schema description coverage is 100%, so all three parameters are already documented with useful context, including an example for the nested 'workspace' object. The description adds no additional parameter-level meaning beyond 'in a container,' which loosely aligns with container_id. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description states a clear verb ('Create'), a specific resource ('workspace'), and a location/scope ('in a container'). It is not a bare tautology because it adds the container context, which helps distinguish it from sibling tools like create_container or create_version. However, it does not explain what a workspace is or explicitly differentiate it from workspace-related siblings.

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

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

There is no guidance about when to use this tool versus alternatives such as list_workspaces, update_workspace, or publish_version. The description also omits prerequisites, such as whether the account and container must already exist or whether a workspace is typically created before adding tags and variables.

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 disclosure burden. It adds genuinely valuable behavioral context beyond the bare operation: the Tag Manager 360 prerequisite and the failure mode in standard containers. However, it does not disclose other behavioral traits such as permission requirements, side effects, or idempotency, leaving gaps for a mutating 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 two tight sentences with zero waste. The primary purpose is front-loaded first, and the critical constraint and failure condition follow immediately. Every sentence earns its place.

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

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

An output schema exists and all parameters are fully documented in the input schema, so those burdens are already met. The description supplies the two missing pieces: the core purpose and the critical 360 prerequisite/failure mode. It is complete enough for correct invocation, though it omits alternative routing for non-360 containers.

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

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

Schema description coverage is 100% across all four required parameters, including a rich example showing the nested zone object structure with name, childContainer, and boundary fields. Per the baseline rule, the description earns a 3 since it adds no parameter meaning beyond what the schema already provides, and the schema fully covers the ground.

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 opens with 'Create a zone in a workspace,' a specific verb+resource+location construction that clearly identifies the operation. The zone resource is distinct from every sibling create_* tool (create_container, create_workspace, create_folder, etc.), and the Tag Manager 360 note adds distinguishing context.

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

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

The description gives clear, actionable guidance: 'Zones require Tag Manager 360' and 'Creating one in a standard container fails.' This is an explicit when-not condition that helps the agent avoid a doomed call, though it does not name a specific alternative tool to use instead.

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 discloses that referencing stops resolving, but does not clarify whether the operation is reversible (though a revert sibling exists), what permissions are needed, or the exact nature of 'disable' vs. permanent deletion. This is a significant gap for a destructive 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?

Two sentences, front-loaded with the action and scoping, followed by a crucial warning. No filler or redundancy. Excellent structure for quick comprehension.

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?

While the output schema exists and parameters are fully documented, the description lacks critical context for a delete-like tool: whether it is reversible, what happens to dependent entities beyond resolution failure, and any prerequisites. The presence of revert_built_in_variable suggests reversibility but is not stated, leaving an agent uncertain about consequences.

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

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

Schema description coverage is 100%, so all parameters are documented in the schema. The description adds no extra semantic meaning to the parameters themselves, which meets the baseline for full coverage. No additional context needed.

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

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

The description clearly states the action ('Disable') and the resource ('built-in variables') scoped to a workspace. It distinguishes from siblings like list_built_in_variables and create_built_in_variable by the action. Minor inconsistency between title 'Delete' and description 'Disable' but not misleading.

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?

Provides a warning to check for uses first, implying when not to use (if there are active references). However, it does not explicitly compare to alternatives like revert_built_in_variable or delete_variable, nor state when this tool is preferred. The guidance is implicit rather than explicit.

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 explicitly reveals that the delete is scoped to the workspace only and that the client remains in production until a version without it is published, which is a high-value side-effect warning. It could add reversibility or permission details, but the core destructive behavior is well explained.

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

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

The description is two sentences with no filler. The first sentence states the action, and the second adds a critical behavioral nuance. Information is front-loaded and every sentence earns its place.

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

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

The parameters are fully described by the schema, an output schema exists, and the description provides the most important operational context: the deletion is workspace-only and not immediately reflected in production. The main omission is guidance about reversibility or alternatives, but overall the tool is sufficiently described for correct 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?

Schema description coverage is 100%, so every parameter—client_id, account_id, container_id, and workspace_id—is already documented in the schema. The description adds no additional parameter-level meaning, which is acceptable because the IDs are self-explanatory and fully covered.

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

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

The description states a specific verb and resource: 'Delete a client from a workspace.' It clearly identifies the client as the object and scopes the deletion to the workspace, distinguishing it from sibling tools like delete_workspace or delete_container. The extra detail about workspace-only impact removes ambiguity.

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

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

The description implies when this tool is relevant by clarifying that deletion affects only the workspace and not production until a version is published. However, it does not explicitly state when to use this tool instead of alternatives such as revert_client, nor does it mention any exclusions or prerequisites. The guidance is useful but indirect.

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 and does so well. It discloses irreversibility ('cannot be undone through the API'), cascading deletion of workspaces/tags/versions, and the live impact on sites loading the container's snippet.

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

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

Three short sentences, front-loaded with the core action and scope, followed by the most important caveats. Every sentence contributes meaningful information with no redundancy.

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

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

For a destructive top-level operation, the description covers the essential consequences: cascade scope, irreversibility, and snippet/tag impact. It does not mention permissions or error conditions, but the output schema and parameter descriptions cover invocation details.

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

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

Schema description coverage is 100%, so account_id and container_id are already adequately documented. The description adds no extra meaning or format details for the parameters, which is acceptable given the schema coverage.

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

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

The description names a specific verb and resource ('Delete a container') and immediately communicates the cascading scope ('every workspace, tag and version'). This clearly distinguishes it from sibling delete_* tools that target lower-level 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?

The intended use is explicit: this is the tool for deleting a container. It does not explicitly contrast with alternatives or state prerequisites, but the container-level scope makes the usage context 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 carries the disclosure burden. It adds a useful non-obvious rule—built-in Live/Latest cannot be deleted—but it does not state whether deletion is irreversible, whether it cascades, or what authorization is required. This is partial, not full, 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?

Two short sentences with no filler. The core action is front-loaded, and the caveat is separated into its own focused sentence.

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 and all required parameters are documented in the schema, the remaining context is mostly satisfied. The built-in caveat is valuable; what's missing is an explicit statement of side effects or when to choose another environment operation, but this is a minor gap for a simple delete 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?

The input schema already describes all three parameters (account_id, container_id, environment_id) at 100% coverage, so the baseline is 3. The description adds no parameter-specific semantics, but none are necessary given the clear numeric IDs.

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 names the exact operation ('Delete') and resource ('container environment'), which immediately distinguishes it from sibling environment operations like create/update/list/get and from delete_container/delete_workspace. The built-in exception adds clarity rather than 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?

It clearly implies use when a custom environment should be removed and warns that Live/Latest are not eligible. However, it does not explicitly direct an agent to alternatives such as update_environment or reauthorize_environment, nor does it state preconditions like required permissions.

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

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

With no annotations provided, the description carries the full behavioral burden. It does disclose a critical side effect (entities left unfiled) which is valuable, but it does not mention reversibility, permission requirements, or any other side effects. The description adds useful context but is 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 extremely concise: two sentences, the first delivering the core action and the second adding the crucial nuance about entity behavior. It is front-loaded and contains no superfluous 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?

For a delete operation with 4 parameters and an existing output schema, the description covers the most important contextual detail—what happens to contained entities. It does not explain return values (likely covered by output schema) or error cases, but given the simplicity of the action, this is adequate. It could benefit from noting whether the folder must exist or any deletion restrictions, but the core behavior is clear.

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

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

Schema description coverage is 100% for all 4 parameters, each described as numeric IDs. The description adds no additional meaning about parameter relationships or usage constraints, so it meets the baseline for high schema coverage without enhancing it.

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

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

The description clearly states the action (delete) and resource (folder from a workspace), and uniquely distinguishes itself from other folder operations like update_folder or move_entities_to_folder by specifying that contained entities are not deleted but left unfiled. This is a specific and non-tautological 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 implies a use case (deleting a folder while preserving its contents) but does not explicitly state when to use this tool over alternatives like move_entities_to_folder or update_folder. It does not mention any exclusions or prerequisites, leaving some inference to the agent.

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

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

With no annotations provided, the description carries the full behavioral burden, and it does disclose the most important behavior: deletion is irreversible and cannot be undone short of discarding the workspace. It does not cover permissions or side effects like references to the config, but the critical destructive trait is clearly and prominently stated.

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

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

Two short sentences: the first states the operation and the second adds the crucial irreversible caveat. The description is front-loaded, contains no filler, and every sentence earns its place.

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

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

For a focused delete tool with all four required parameters documented in the schema and an output schema present, the description covers the key operational fact an agent needs: the action is irreversible. It lacks explicit prerequisite or permission context, but nothing essential to basic invocation 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?

The input schema already documents all four required parameters with 100% coverage, so the baseline is 3. The description adds no parameter-specific detail beyond identifying the entity type, but it does not need to compensate for any schema gap.

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

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

The opening sentence states the exact action ('Delete') and resource ('a Google tag configuration from a workspace'), so an agent knows precisely what the tool does. The follow-up note about no revert method clearly marks this as the destructive GTM config deletion tool, distinguishing it from delete_tag and other sibling delete 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 a caution context: because configs have no revert method, the tool should only be used when permanent deletion is intended. However, it never explicitly says when to prefer this over update_gtag_config or names alternative revert tools for other entities, so usage guidance remains implied rather than explicit.

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

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

With no annotations present, the description carries the full burden of behavioral disclosure. It adds valuable non-obvious information: the deletion affects the workspace only, and the tag continues running in production until a version without it is published. This meaningfully explains the tool's side effects beyond what the schema or title convey.

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

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

The description is two short sentences with no filler or redundant restatement of the name. The core action is front-loaded, and the important behavioral caveat follows immediately in a clear, separate statement.

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 straightforward delete operation with fully documented parameters and an output schema, the description covers the necessary context: what is deleted, the workspace-scoped effect, and the production behavior. An agent has enough information to correctly invoke the tool and set expectations about the result.

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 already provides 100% description coverage for all four parameters, so the schema handles parameter semantics. The description adds no additional parameter-level detail, which matches the baseline expectation for fully documented schemas.

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 and resource: 'Delete a tag from a workspace.' This clearly identifies the operation and differentiates it from sibling deletes like delete_workspace, delete_container, and delete_trigger. The workspace scoping further refines what the tool acts on.

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 clear context about when the tool is appropriate: deleting a tag within a workspace. It also signals an important usage nuance—that deletion does not stop the tag in production until a new version is published—which helps an agent avoid assuming immediate production impact. It does not explicitly name alternatives or exclusions, but the resource-specificity and behavioral context make selection 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly warns that 'Tags and variables using the template stop working,' which is a significant side-effect. It could additionally state irreversibility or permission requirements, but the consequence warning is substantive and valuable.

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

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

The description is compact and front-loaded: the action is stated first, followed by a critical warning. Every sentence earns its place with no filler or repetition of schema fields.

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 simple 4-parameter shape, complete schema coverage, and an output schema, the description is nearly sufficient. It supplies the key domain consequence and a pre-deletion safety step. It could mention whether deletion is permanent or how to find usages, but these are minor given the low 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?

The input schema already documents all four parameters with 100% coverage, so the baseline is 3. The description adds no further parameter-level meaning, but none is necessary because the schema descriptions are complete.

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 a specific verb and resource: 'Delete a custom template from a workspace.' It distinguishes this tool from sibling delete tools like delete_tag and delete_variable by explicitly naming 'template' as the target.

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 clear context: use this tool to delete a custom template. It also gives a practical prerequisite by warning to 'check for uses before deleting,' which guides when the action is safe. It does not explicitly name alternative tools, but the resource type makes the intended use unambiguous.

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 reveals a non-obvious and important behavior: the deletion is workspace-scoped and does not immediately affect production. This adds substantive context beyond the plain verb 'Delete', though it does not address reversibility or permission requirements.

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

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

The description is two sentences with no filler. The primary action is front-loaded, and the critical caveat about production impact is placed immediately after, earning its place by conveying essential operational nuance.

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 simple flat parameter list (4 IDs) and the presence of an output schema, the description covers the essential context: what is deleted and the important workspace-vs-production distinction. It omits minor details like reversibility, but the core decision-relevant information is present.

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

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

Schema description coverage is 100%, with all four parameters documented as 'Numeric ... ID'. The description adds no additional parameter-level meaning, which is acceptable given the complete schema. The baseline of 3 applies because the schema already handles parameter semantics fully.

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 ('Delete') and resource ('a transformation from a workspace'), clearly distinguishing this from the many other delete_* tools in the sibling list. It goes beyond a tautology by adding scope ('from a workspace'), and the name 'delete_transformation' is accurately expanded without ambiguity.

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

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

The description provides clear context about when to use this tool: it explicitly states that deletion affects the workspace only and that the transformation remains in production until a new version is published. This tells an agent the operational consequence and implies that production removal requires a separate publish step, though it does not explicitly name alternative tools or exclusion conditions.

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

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

With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: the deletion is workspace-scoped and does not affect production until a new version is published. This is valuable context beyond the schema. It doesn't mention reversibility or permissions, but the production-impact clarification is significant.

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

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

The description is two sentences with no wasted words. The core action is front-loaded, and the important scoping caveat follows immediately. Every sentence earns its place.

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

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

For a delete operation with no annotations, the description covers the essential context: what is deleted, the scope, and the production impact. It doesn't mention whether the deletion is reversible or what the response contains, but the output schema exists and the core behavioral caveat is present. Slightly more detail on reversibility would make it complete.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds no parameter-specific meaning beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description clearly states the verb and resource: 'Delete a trigger from a workspace.' This distinguishes it from sibling tools like update_trigger, revert_trigger, and list_triggers. However, it doesn't explicitly name a sibling or contrast itself with a similar delete operation, so it falls short of a 5.

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

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

The description implies usage context by specifying the scope ('from a workspace') and the effect on production ('stays in production until a version without it is published'). This gives some guidance on when deletion takes effect, but it doesn't explicitly state when to use this tool versus alternatives like delete_version or revert_trigger, nor does it mention prerequisites or conditions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It simply states what the operation does ('Revoke') but does not mention whether the action is permanent, whether special permissions are required, or any side effects. For a destructive/delete-type operation, this is a notable gap.

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

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

The description is a single, direct sentence with no filler or redundancy. It communicates the essential purpose immediately.

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

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

The tool is simple with two fully documented parameters, and an output schema exists, so return values do not need explanation. However, with no annotations and no behavioral caveats, the description is not fully complete for a revocation operation that presumably removes access.

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

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

Schema description coverage is 100%, with both account_id and permission_id clearly described in the input schema. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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 ('Revoke') and identifies a clear resource ('a user's access to a Tag Manager account'). This distinguishes it from sibling tools like create_user_permission, update_user_permission, and list_user_permissions without needing to inspect those definitions.

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 clearly implies the tool is for removing access, providing enough context for when to use it. However, it does not explicitly name alternatives or state when not to use it, so it falls short of full guidance.

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

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

With no annotations provided, the description carries the full behavioral disclosure. It reveals a non-obvious behavior: the variable stays in production until a version without it is published. This adds significant value beyond the schema, though it does not cover permissions or reversibility.

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

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

Two concise sentences, front-loaded with the primary action and a crucial behavioral note. No filler or redundant information.

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 delete operation with four straightforward parameters and an output schema, the description covers the essential nuance about production persistence. It is complete enough for an agent to call correctly, though it could explicitly mention the variable is immediately removed from the workspace.

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 provides 100% coverage with clear descriptions for all four parameters (account_id, container_id, workspace_id, variable_id). The description adds no additional parameter-specific meaning, so the baseline of 3 is appropriate.

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 'Delete a variable from a workspace' with a specific verb and resource. It distinguishes from sibling deletion tools like delete_built_in_variable by specifying 'a variable' (user-defined) in the context of a workspace.

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 context on the effect (workspace-only, persists in production) but does not explicitly state when to use this tool over alternatives like revert_variable or delete_built_in_variable. It implies usage for user-defined variables but lacks explicit exclusions or alternative routing.

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 behavioral disclosure burden. It discloses that deletion is reversible, implying a soft-delete model, and warns that the live version is protected from deletion. This is meaningful behavioral context beyond the bare 'Delete' verb, though it does not address permissions or downstream 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 two short sentences with no filler. The core action is front-loaded, and the two behavioral caveats (reversibility and live-version restriction) are placed immediately after without 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?

The description covers the essential operational constraints: what is deleted, that deletion is reversible, and the one prohibited case. The presence of an output schema reduces the need to explain return values, and the parameter list is simple. Minor omissions such as prerequisites or permission requirements do not undermine usability.

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

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

Schema description coverage is 100%, so the parameters are already documented in the input schema. The description adds minimal parameter-specific meaning beyond calling the entity a container version, which is sufficient given the high schema coverage.

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

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

The description states a specific verb and resource: 'Delete a container version.' It clearly distinguishes this tool from the many other delete_* siblings by naming the target as a container version, and the title aligns with the action. No ambiguity remains about what the tool does.

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 clear usage context by noting that deletion is reversible via undelete_version and explicitly states the live version cannot be deleted. It names a relevant sibling tool, though it stops short of fully enumerating alternative tools or conditions for when deletion should be chosen.

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 of behavioral disclosure. It clearly warns that deleting a workspace discards all changes and permanently loses unversioned work, and it recommends a pre-check. It does not mention permission requirements or whether versions themselves are recoverable, but the core destructive behavior is transparently conveyed.

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 only two sentences, with the primary action and its most important consequence ('discarding every change in it') front-loaded. The second sentence adds the critical warning and actionable pre-check without any filler or repetition.

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

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

Given a simple delete operation with three fully documented parameters and an output schema present, the description fully covers the necessary behavioral context: what is deleted, what is lost, and what to check beforehand. Nothing essential is missing for an agent to invoke this tool safely in the context of the sibling list.

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

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

Schema description coverage is 100%, with each parameter clearly described as a numeric ID in the input schema. The description adds no parameter-specific details beyond what the schema already provides, so it neither improves nor harms parameter understanding—meeting the baseline for full schema coverage.

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

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

The description states a specific verb ('Delete'), a specific resource ('workspace'), and a crucial scope qualifier ('discarding every change in it'). It further clarifies the semantics by noting unversioned changes are lost, which distinguishes this from update_workspace or sync_workspace among the many sibling 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 explicitly instructs the agent to 'Check get_workspace_status first', establishing a clear precondition before invoking the destructive operation. It does not name a non-deletion alternative or state when to avoid deletion, but the status-check directive provides enough context for safe usage.

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. It discloses a critical behavioral trait: the deletion is scoped to the workspace and production is unaffected until a new version is published. This is non-obvious and highly valuable. It doesn't cover reversibility or error handling, but the key side effect is well disclosed.

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 three short sentences with zero waste. The core action is front-loaded, and the critical behavioral nuance is presented immediately after. Every sentence earns its place.

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

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

For a delete operation with four required parameters and an existing output schema, the description covers the essential behavior (workspace-only effect). It doesn't mention prerequisites or error conditions, but those are likely covered by the schema and output schema. It is adequately 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?

Schema coverage is 100%, so the schema already documents each parameter (e.g., 'Numeric zone ID'). The description adds no extra meaning to parameters beyond what the schema provides. Per the rubric, a baseline of 3 is appropriate when schema does the heavy lifting.

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

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

The description states a specific verb ('Delete'), resource ('zone'), and scope ('from a workspace'). It clearly differentiates from sibling delete tools (e.g., delete_workspace, delete_container) by naming the resource and scoping it to the workspace. The phrase 'Delete a zone from a workspace' is 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 gives clear context on when to use this tool: when you want to delete a zone from a workspace. It further clarifies that the deletion does not affect production until a version is published, which is essential for decision-making. However, it doesn't explicitly mention alternatives like revert_zone or contrast with update_zone, so it falls short of a 5.

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

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

With no annotations, the description carries the behavioral transparency burden. It discloses that the API lacks search, so the tool reads each collection and filters locally, which is meaningful behavioral context beyond the function name. It does not detail performance implications or side effects, but as a read/filter operation the transparency is reasonably complete.

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 three sentences with the core purpose front-loaded. Every sentence earns its place: the operation, the implementation context, and the practical use case. There is 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?

The description is complete enough given that an output schema exists and the schema documents all parameters. It explains what is searched, how the search works, and why the tool exists. It could be slightly stronger by noting potential cost of scanning multiple collections, but overall the essential context is 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 100%, so the parameters are already well documented in the schema. The description adds contextual guidance about using a human-readable name for the query, but it does not add new parameter-level semantics 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 the tool finds tags, triggers, and variables by name, which is a specific verb plus resource list. It also explains the purpose is to convert a human-used name into the ID needed by other tools, distinguishing it from list/get tools for individual 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 explicitly tells the agent when to use it: when a human has provided a name and an ID is needed. It does not explicitly mention when not to use it or name alternative tools, but the 'API has no search' context implies this is the only name-based lookup mechanism.

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 of behavioral disclosure. It only repeats the verb 'Get' without describing auth needs, whether this is purely a read operation, or any response characteristics beyond what the output schema already provides.

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

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

The description is a single sentence with no waste, front-loads the verb and resource, and exactly matches the tool's scope. Every word earns its place.

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

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

With only one parameter and an output schema present, the description is minimally sufficient to invoke the tool, but it lacks any context for choosing this tool over the large set of sibling getters. The absence of usage or exclusion guidance is a clear gap, though the tool's simplicity keeps the gap moderate.

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

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

Schema description coverage is 100%—the single required parameter account_id is already well described as a numeric ID. The tool description adds no parameter-level meaning, so the baseline of 3 applies.

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

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

The description states a clear action ('Get') and a specific resource ('one Tag Manager account'), and the singular 'one' implies this is for a single account rather than all accounts. It does not explicitly name sibling alternatives like list_accounts, so it misses the top score for 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?

The description gives no guidance on when to use get_account instead of list_accounts or get_user_permission, and no mention of prerequisites or alternative tools. An agent must infer usage solely from the tool name and schema.

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 bears the full burden of behavioral disclosure. It only states the action (get one client) and implies a read operation, but omits details on authorization, error behavior (e.g., not found), or any side effects. It does not add value beyond the basic action.

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

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

A single, front-loaded sentence with no wasted words. It directly states the purpose without extraneous detail, making it appropriately sized for a simple retrieval tool.

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

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

Given the hierarchical context (account, container, workspace, client) and all parameters required, the description is too sparse. It does not explain what a client is, the necessity of all IDs, or how to obtain them. While the output schema exists, the description lacks sufficient guidance for an agent to correctly invoke the tool in 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 100%, so the schema already documents each parameter as a numeric ID. The description adds the context 'from a workspace' but does not clarify relationships between parameters or usage order. Since the schema carries the meaning, a baseline of 3 is appropriate.

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

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

The description states a clear verb ('Get') and resource ('one client') from a 'workspace', which distinguishes it from list operations. However, it does not explicitly differentiate from siblings like list_clients or get_workspace, relying on the singular vs. plural distinction.

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. It does not mention that this retrieves a single client by ID, when to prefer it over list_clients, or any prerequisites such as obtaining the IDs first.

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 verb 'Get' clearly indicates a read-only operation, which is a key behavioral trait. However, with no annotations, the description does not disclose error behavior, permission requirements, or that it returns the full container entity, leaving some burden unmet.

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

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

The description is a single, front-loaded sentence with no wasted words. 'Get one Tag Manager container' efficiently captures the core operation and scope.

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

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

Despite having an output schema and a simple two-parameter input, the description lacks usage context and behavioral warnings. Given the large sibling set and no annotations, an agent cannot tell when to choose this over lookup_container or get_container_snippet.

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

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

Schema description coverage is 100%, with both account_id and container_id described in the input schema. The description adds no additional parameter semantics, so the baseline of 3 applies.

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

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

The description 'Get one Tag Manager container' states a specific verb (Get) and a singular resource (one Tag Manager container), which distinguishes it from list_containers. However, it does not clarify how it differs from lookup_container or summarize_container, so sibling differentiation is incomplete.

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

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

There is no guidance about when to use this tool versus alternatives. It does not mention that it is appropriate for retrieving a single container by ID or that list_containers should be used for enumeration.

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 of behavioral disclosure. It clearly signals a read-only 'get' operation and states the returned artifact, but it does not mention authentication needs, whether the snippet reflects the live/published version, or any access prerequisites. The read-only nature is reasonably apparent, though not fully elaborated.

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

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

The description is a single short sentence that is front-loaded and free of filler. Every word contributes to identifying the tool's purpose and return 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?

For a simple two-parameter read operation with a complete input schema and an output schema, the description provides enough to invoke the tool correctly. It could be slightly richer about when to choose this over get_container, but that nuance is minor for an otherwise self-contained definition.

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

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

Schema coverage is 100%, and both parameters already have descriptive definitions ('Numeric Tag Manager account ID' and 'Numeric container ID'). The description adds no additional guidance about parameter semantics, so the baseline of 3 applies.

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

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

The description states a specific verb ('Get') and an exact resource ('the HTML install snippet for a container'). This is clearly distinct from sibling tools like get_container, which return container metadata, or list_containers, which enumerate containers. An agent can tell what this tool returns without opening the schema.

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

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

The phrase 'HTML install snippet' implies the tool is used when an embedding/install code is needed, and it implicitly steers away from metadata-focused tools. However, it gives no explicit when-to-use guidance, exclusions, or alternatives, so an agent must infer the appropriate 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 present, so the description carries the full burden of behavioral disclosure. The verb 'Get' conveys a read-only operation, but it does not explicitly state that no modifications occur, what happens if the destination is not found, or any access requirements. It provides basic transparency but leaves room for more explicit safety information.

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

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

The description is a single front-loaded sentence: 'Get one destination linked to a container.' It contains zero filler and each word contributes to the meaning. No redundant detail, ideal length for a simple retrieval tool.

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

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

Given the low complexity, 100% schema coverage, and the presence of an output schema, the description is complete enough for an agent to invoke correctly. The agent needs only the three IDs, all documented in the schema, and the output format is covered elsewhere. No critical information 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?

Schema description coverage is 100%, with each parameter (account_id, container_id, destination_id) already documented in the input schema. The description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

The description clearly states 'Get one destination linked to a container' – a specific read verb with a resource and scope. The singular 'one' and 'linked to a container' differentiate it from sibling tools like list_destinations and link_destination. An agent can tell what this tool does without opening the schema.

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

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

The phrase 'Get one destination' implies use when a single destination is needed, contrasting with list_destinations. However, it does not explicitly mention when to prefer this over list_destinations or link_destination, nor does it provide any 'when not to use' guidance. The usage is implied but not 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 itself must convey behavior. The verb 'Get' clearly indicates a read-only retrieval with no side effects, but the description does not disclose any additional behavioral traits such as return format, error conditions, or scoping constraints beyond the parameter names.

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

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

The description is a single, compact sentence that is front-loaded with the action and resource. It contains no filler or repetition of the title.

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 presence of an output schema and the simplicity of a single get operation with three well-documented parameters, the description is essentially sufficient. It could have mentioned that list_environments can be used to discover environment IDs, but nothing critical 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?

Schema description coverage is 100% with clear descriptions for all three IDs. The tool description adds no additional meaning to the parameters, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Get') and resource ('one container environment'), clearly distinguishing this from sibling tools like list_environments, create_environment, or delete_environment. The singular 'one' signals a single-object retrieval as opposed to a list 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 implies the tool is for retrieving a single container environment, contrasting with list_environments or update_environment, but it does not explicitly state when to use it over alternatives or any conditions. No exclusions or alternative routing are given.

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

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

With no annotations, the description carries the burden of disclosing behavior, but it only restates the operation implied by the tool name. It does not mention permissions, error conditions, or whether the operation is a read-only lookup, so the agent gains little beyond the name.

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

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

A single, focused sentence with no wasted words. The core operation and scope are 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?

This is a simple fetch with a complete input schema and an output schema, so the minimal description is sufficient for call construction. It could be more complete only by naming the distinguishing sibling or noting a read-only profile, but nothing call-critical 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?

Schema coverage is 100%, so the schema fully documents all four parameters. The description adds only the general context that one folder is scoped to a workspace, not parameter-specific meaning, so the baseline of 3 applies.

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

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

The description states a specific operation ('Get one folder') and a scope ('from a workspace'), which is clear. It implicitly distinguishes from list_folders and get_folder_entities by emphasizing singular retrieval, but it does not explicitly name the sibling alternatives.

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

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

No guidance is given about when to use this tool versus list_folders, get_folder_entities, or update_folder. The singular phrasing weakly implies single-object lookup, but there is no explicit context, prerequisite, or exclusion.

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?

There are no annotations, so the description carries the behavioral burden. 'List' implies a read-only operation and the scope is stated, but the description does not disclose pagination behavior (though page_token exists in the schema) or what happens for empty or invalid folders. It is adequate for a simple listing but omits some behavioral 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 a single concise sentence with no filler. It front-loads the action and enumerates the exact entity types covered, making it both compact and immediately informative.

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 straightforward listing tool with a 100%-covered schema and an output schema, the description is nearly complete. It lacks only explicit mention of pagination or result size limits, but the page_token parameter already signals pagination to an agent.

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

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

Schema description coverage is 100%, so the parameters are already well-documented in the input schema. The description adds no parameter-level detail beyond the fact that the listing is 'inside a folder,' which maps to folder_id. Baseline 3 is appropriate.

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

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

The description states a specific action ('List'), a precise resource scope ('tags, triggers and variables inside a folder'), and makes the tool's purpose immediately distinguishable from siblings like get_folder or list_tags. The verb+resource+scope pattern gives an agent a clear idea of what this tool does.

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 clearly implies when to use this tool: when you need to enumerate the tags, triggers, and variables within a specific folder. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to choose this over sibling list/get 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 burden of conveying safety. The verb 'Get' strongly implies a read-only operation and no destructive side effects, but the description does not explicitly state that it only fetches data or address not-found/error 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 one short, front-loaded sentence with no filler. Every word contributes meaning: verb, resource, cardinality, and scope.

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

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

Given the complete parameter schema and the presence of an output schema, the description is nearly complete for a simple read-by-ID tool. It only lacks an explicit read-only/no-side-effect clarification, though the 'Get' verb largely covers this.

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

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

Schema description coverage is 100%, with all four parameters already documented in the input schema. The description adds no parameter-level meaning, so the baseline score of 3 applies.

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

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

The description uses a specific verb ('Get'), names the exact resource ('Google tag configuration'), and states singular scope ('one') and location ('from a workspace'). This clearly distinguishes it from list_gtag_configs and other entity-specific getters.

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 it is for retrieving a single configuration by ID, but it never explicitly says when to prefer this over list_gtag_configs or how to obtain the required gtag_config_id. No alternatives or exclusions 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 the behavioral burden. It discloses the key non-obvious nuance that the most recently created version is not necessarily the published one, and points to the correct tool for live content. It does not discuss permissions or error cases, but for a simple read-type operation the main behavior is clarified.

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

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

The description is compact and front-loaded with the core action, followed by a one-line caveat and sibling-tool pointer. Every sentence earns its place with no redundancy.

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

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

For a two-parameter, low-complexity read operation with a complete input schema and an output schema present, the description covers the essential decision: latest-created versus live. Nothing critical is missing for an agent to select and 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?

Schema description coverage is 100%, so the schema already fully explains account_id and container_id as numeric IDs. The description adds no parameter-level detail, but none is needed beyond the schema; baseline 3 is appropriate.

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 names a specific verb and resource: getting the header of a container's most recently created version. It also distinguishes this from the live/published version by naming get_live_version as the alternative, so an agent can tell sibling tools apart.

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 tool: when you need the latest-created version header. It also gives a clear exclusion: do not use this for what production is serving; use get_live_version instead. This is direct routing 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. The verb 'Get' signals a read operation, and the production context adds meaning, but the description does not explicitly state that there are no side effects, what permissions are needed, or any other behavioral constraints. For a simple getter this is minimally adequate but not rich.

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

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

Two short sentences with no filler; the core operation is front-loaded and the second sentence adds a practical use cue. Everything present earns its place.

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

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

The tool is simple, has fully documented parameters, and has an output schema, so the description does not need to explain return values. It covers the key contextual distinction from other version tools; only an explicit pointer to alternatives would make it fully complete.

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

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

Schema description coverage is 100% and both parameters are individually documented in the schema, so the description does not need to repeat their meanings. It adds no direct parameter-level detail beyond naming the container and account context, which matches the baseline for fully covered schemas.

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 names a specific verb and resource: retrieving the container version currently published to production. It further distinguishes itself from generic version tools by clarifying that this is what visitors to the site are actually running, which makes its purpose unambiguous among many sibling version-related 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?

It gives a clear use case: the right starting point for 'what is live right now.' It does not explicitly name alternatives or state when not to use it, so it stops short of full routing guidance, but the intended context is evident.

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 of behavioral disclosure. It only says 'Get one tag,' which implies a read operation but does not explicitly state that it is non-mutating, what happens if the tag is not found, or whether permissions are required. The description adds minimal behavioral context beyond the tool's name.

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

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

The description is a single concise sentence with no redundant wording. It is front-loaded with the core action and resource. It could be slightly more informative without losing conciseness, but as written it is 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?

The tool is a straightforward getter with a complete input schema and an output schema, so the description does not need to explain return values. However, the description lacks any guidance about when to use this tool, how to locate tag_id, or the relationship to workspace/container/account IDs. It is minimally adequate but has clear 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?

The input schema has 100% description coverage, so all four parameters are already documented as numeric IDs. The description adds no extra meaning about the parameters, but the schema compensates fully. This matches the baseline of 3 for high schema coverage.

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

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

The description states a specific verb and resource: 'Get one tag from a workspace.' This clearly distinguishes it from list-oriented or mutation tools like list_tags, create_tag, and update_tag. However, it does not explicitly contrast it with siblings like get_workspace or get_trigger, and the phrase is close to the tool name, so it lacks full differentiation.

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

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

The description gives no guidance on when to use this tool versus alternatives such as list_tags or get_workspace. There is no mention of prerequisites, fallback behavior, or exclusions. The usage context is only weakly implied by the verb 'get,' so an agent receives little decision 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?

With no annotations, the description carries the burden of behavioral disclosure. It conveys that this is a read operation returning the template along with its source, but it does not disclose permissions, failure behavior, or any other side effects. This is adequate but 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 a single front-loaded sentence with no filler. Every word earns its place, and the qualifiers 'custom' and 'sandboxed JavaScript source' add real 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?

The output schema exists and all parameters are fully documented, so the description only needs to clarify what is fetched. It does that well, though it could go further by explicitly naming list_templates as the alternative for broader queries.

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

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

Schema description coverage is 100%, with each of the four IDs already described by the schema. The tool description adds no parameter-specific meaning, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Get') and a specific resource ('one custom template'), and additionally names what is included ('sandboxed JavaScript source'). This clearly distinguishes it from list_templates, create_template, update_template, and delete_template.

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

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

The description implies the tool is for fetching a single custom template, especially when its JavaScript source is needed. However, it does not explicitly mention alternatives like list_templates for retrieving multiple templates or create_template for creating one.

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