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

Adds meaningful behavioral context beyond annotations: discloses that containerId and publicId are server-assigned, and states the required OAuth scope. Annotations already indicate a non-read-only, non-idempotent operation, and the description is consistent with that.

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 sentences with the purpose front-loaded. No filler; each sentence earns its place (purpose, usage_context clarification, return value/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 simple three-parameter schema and no output schema, the description adequately covers what the tool does, return format, and authentication requirement. It could mention if account_id must reference an existing account, but that is implicit. Overall sufficient for an agent to invoke correctly.

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

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

Schema covers all parameters with descriptions (100% coverage), so baseline is 3. The description adds a brief clarification that usage_context declares the platform, but the schema already lists the same documented values. No extra semantics are provided for name or account_id.

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

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

The description clearly states 'Creates a new container in a GTM account' with a specific verb and resource. It distinguishes itself from sibling tools like create_workspace or get_container by naming the resource type and including relevant context about usage_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?

Provides contextual usage guidance by explaining the usage_context parameter values and specifying the required permission scope (tagmanager.edit.containers). It does not explicitly name alternatives, but the context is clear and no exclusionary guidance 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?

The description adds behavioral context beyond annotations: it discloses that the tool returns the created resource with server-assigned id and fingerprint, and requires the tagmanager.edit.containers scope. Annotations already indicate non-read-only and non-destructive, so no contradiction.

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

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

The description is concise, front-loaded with purpose, then systematically explains the body parameter with an example, and ends with return value and auth scope. Every sentence carries needed information with no filler.

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 no output schema, the description covers return value, required scope, and complex nested body structure. It adequately addresses the tool's complexity and pairs well with annotations and sibling context, making it fully complete for the agent to use.

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% for basic params, but the description significantly augments the 'body' parameter by explaining the minimum structure ({ name, type }), type-specific entries, and the firingTriggerId array, with an example. This adds substantial meaning beyond the schema's generic object description.

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

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

The description clearly states the tool creates a tag, trigger, or variable in a workspace, using a specific verb and resource. It distinguishes from siblings like update_entity and delete_entity by focusing on creation of these entity types, and the title reinforces this.

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

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

The description implies when to use this tool (to create tags/triggers/variables) and provides a concrete example of the body structure. It does not explicitly name alternatives or exclusions, but the context of sibling tools makes the usage 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?

Beyond the destructiveHint annotation, the description discloses specific side effects: the source workspace is deleted and replaced, and the response includes a newWorkspacePath. It also reveals the error pattern (compilerError=true with HTTP 200), which is significant 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 focused paragraph that front-loads the primary purpose, then covers side effects, return value, error handling, and scope in order. Every sentence adds unique value without redundancy.

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

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

With no output schema, the description thoroughly explains the return object and error behavior. It also covers side effects and auth scope, making it a complete reference for a complex mutation 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 has 100% description coverage, including the workspace_id deletion note. The description does not add further parameter meaning, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool compiles a workspace into an immutable Container Version, which is the unit that gets published. It distinguishes from siblings like publish_version and delete_entity by specifying the action on the 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?

It provides critical usage guidance: the workspace is deleted and replaced, so the new workspace path must be used for further edits, and old paths will 404. It also states the required OAuth scope. However, it does not explicitly contrast with alternatives like publish_version.

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

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

The description adds valuable behavioral context beyond the annotations by specifying the required OAuth scope (tagmanager.edit.containers) and the return value (the created workspace with its server-assigned workspaceId). It also frames the operation as non-destructive by describing the workspace as an isolated draft. No contradiction with annotations.

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

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

The description is concise and well-structured, with three sentences that front-load the main action and provide essential context without unnecessary verbosity. 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 create tool with no output schema, the description covers the key aspects: purpose, workspace definition, return value, and auth requirement. While the openWorldHint is not elaborated, the description is still complete enough for a straightforward creation 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?

The schema already provides descriptions for all 4 parameters, achieving 100% coverage. The description does not add parameter-level details beyond what the schema states, so a baseline score of 3 is appropriate.

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

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

The description clearly states that the tool creates a new workspace in a container, and further explains that a workspace is an isolated draft where edits occur before compilation into a version. This specific verb+resource combination distinguishes it from sibling tools like create_version or get_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 clear context by explaining that workspaces are used for editing tags, triggers, and variables before compiling into a version, implying when to use this tool. However, it does not explicitly name alternatives or specify conditions where this tool should not be used.

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

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

The description adds valuable behavioral details beyond annotations: the response is empty on success and the operation requires the tagmanager.edit.containers scope. This complements the annotations' destructiveHint and idempotentHint without contradiction.

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, front-loaded with the action, then result and scope. No unnecessary words 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?

For a simple, one-parameter delete tool with full schema coverage and annotations, the description adequately covers action, success behavior, and auth requirement. It is complete for invoking the tool correctly.

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

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

Schema coverage is 100% with a detailed description of the 'path' parameter including format and example. The description's phrase 'by its API path' reinforces but does not add semantic value beyond the schema.

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

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

The description clearly states the tool deletes a tag, trigger, or variable by its API path, specifying the action (delete), resource types, and method. This distinguishes it from sibling tools like create_entity and update_entity.

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: delete via API path, empty response on success, and required scope. While it doesn't explicitly mention alternatives or exclusions, the purpose is unambiguous and sufficient for basic usage decisions.

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 already declare readOnly, idempotent, and non-destructive, covering the safety profile. The description adds the return shape, which is useful, but it does not disclose other behavioral traits like error handling, permissions, or rate limits. With strong annotations, 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 exactly two sentences, with the main action front-loaded and no redundant filler. It includes the return type and its fields efficiently, earning a perfect score for conciseness.

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

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

For a simple get-by-id tool, the description is complete: it states the resource, the ID parameter, and the return resource fields. The annotations cover safety, and there is no output schema to complicate things. The context is fully adequate.

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 the single parameter account_id with a clear description and example. The tool description only repeats 'by id', adding no extra semantic value beyond the schema. With 100% schema coverage, the baseline is 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 verb 'Gets' plus the specific resource 'one Google Tag Manager account by id', which directly distinguishes it from list_accounts and other sibling tools. It also mentions the returned Account resource fields, making the purpose unambiguous.

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

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

The description provides clear context: use this tool when you have a specific account id to fetch a single account, versus listing all accounts. However, it does not explicitly mention alternatives or exclusion criteria, 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context by specifying the returned Container resource includes publicId, usageContext, and fingerprint. No contradiction with annotations.

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

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

The description is a single, focused sentence directly stating the operation and key return fields. Every word earns its place with no fluff.

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 read-only getter, the description adequately covers what it does and what it returns. The lack of an output schema is mitigated by the mention of publicId, usageContext, and fingerprint. It does not discuss error handling, but that is not critical here.

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

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

Schema description coverage is 100% and both parameters are described in the schema. The description adds minimal value beyond the schema, merely restating that lookup is by account id and container id. Baseline 3 applies.

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

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

The description clearly states the action: 'Gets one container by account id + container id' with a specific verb and resource. It also lists key return fields, distinguishing it from sibling tools like list_containers and get_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 clear context: use this tool when you have both account_id and container_id and need a specific container. It does not explicitly state alternatives or exclusions, but the implied use case is 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?

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds that the response includes the full resource JSON and the current fingerprint, explicitly linking it to update_entity. This is valuable behavioral context beyond the annotations.

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

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

Two concise sentences front-load the purpose and immediately follow with actionable usage and output details. No filler or redundant content.

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

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

Given the tool's single parameter, strong annotations, and lack of output schema, the description covers the tool's use cases, return value, and connection to update_entity. It is complete for the tool's simplicity.

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

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

The schema fully describes the path parameter with format and example. The description adds practical advice to echo the path from a previous response, offering semantic guidance beyond the schema's static description.

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

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

The description clearly states the tool's purpose: a generic getter for any GTM resource by API-relative path, listing example resource types. It distinguishes itself from sibling-specific getters by emphasizing the path-based generic nature.

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 clear usage guidance: prefer echoing the path field over manual construction. Implicitly advises using this when a path is already known, contrasting with list operations, but does not explicitly exclude using specific getters where available.

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 already convey the safe, read-only, idempotent nature. The description adds that the Workspace resource is returned with its fingerprint, which is useful, but it does not disclose error conditions, permissions, or other behavioral traits beyond the structured annotations.

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

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

The description is a single, front-loaded sentence that conveys both the operation and the key return detail. No redundant information is present.

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 read operation with complete schema coverage and safety annotations, the description adequately covers purpose and a key return aspect (fingerprint). It could be improved by referencing list_workspaces for alternative use, but it is generally sufficient.

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% with each parameter clearly described (account_id, container_id, workspace_id). The description merely restates these identifiers without adding new semantic detail, 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 clearly states the tool's function: 'Gets one workspace' by three specific identifiers. It distinguishes from list_workspaces by explicitly indicating it retrieves a single resource, and the verb-resource pairing 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 implies usage for fetching a single workspace, but it does not explicitly contrast with alternatives like list_workspaces or get_resource, nor does it state when not to use the tool. Some context is present but lacks direct 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?

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description goes beyond by specifying the exact return object structure, field types (all ids are strings), and pagination token. This adds meaningful behavioral context without contradicting annotations.

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

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

Two sentences, front-loaded with the action, and every clause earns its place: it states the purpose, return shape, type detail, and entry-point role. No redundancy or filler.

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 list operation with one optional parameter and no output schema, the description sufficiently covers the return structure and usage context. Minor details like sorting or error states are not critical for this tool, so the description is complete enough.

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 sole parameter page_token is fully described in the schema (100% coverage), so the baseline is 3. The description adds value by mentioning the response's nextPageToken, which reinforces the pagination cycle, though it doesn't explicitly state to pass nextPageToken as page_token, so it isn't a full 5.

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 'Lists' and names the exact resource 'Google Tag Manager accounts', with a scope qualifier ('the authorized user can access'). It clearly distinguishes itself from sibling tools like list_containers by focusing on accounts, and the 'entry point' remark reinforces its unique role.

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 that this is the entry point and that every other tool needs an accountId/path from here, providing clear usage context. However, it doesn't explicitly mention when not to use it (e.g., if you already have an accountId) or name alternative tools like get_account, so it misses the full 'exclusions/alternatives' bar.

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 already mark the tool as readOnly, idempotent, and non-destructive. The description adds behavioral detail by specifying the exact response shape, including container fields and nextPageToken, which helps the agent anticipate the returned data structure. It does not mention edge cases or rate limits, but the annotation coverage reduces the need for those.

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, front-loaded with the purpose, and efficiently lists the return fields. Every sentence provides value without redundancy or fluff.

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 read/list operation, the description is complete. It states the action, scope, and return shape. Annotations cover safety, schema covers parameters, and the description covers the response structure. Pagination is implicit via nextPageToken, 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%, so the baseline is 3. The description does not add meaning beyond the schema; it only mentions nextPageToken in the response, which correlates with the page_token parameter but does not elaborate on parameter semantics. No extra value beyond the schema.

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

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

The description uses a specific verb 'Lists' with resource 'containers of a GTM account', clearly distinguishing it from sibling tools like list_accounts (accounts), get_container (single container), and list_workspaces (workspaces). It is unambiguous and action-oriented.

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 states the operation scope (list containers for a GTM account). Pagination is implied by mentioning nextPageToken in the return value, but it does not explicitly contrast with get_container or provide alternative selection guidance. This is 'clear context without exclusions' rather than full when/why instructions.

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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds the response shape and nextPageToken, which is useful, but it does not disclose deeper behaviors like ordering, filtering, or error conditions beyond what annotations imply.

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 concise parts: a clear action statement and a compact response structure. It is front-loaded with the main purpose and includes no redundant text. 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?

With no output schema, the description faithfully provides the full return format including the nested tag object and nextPageToken. It covers the essential information an agent needs to invoke the tool and interpret results. Combined with schema and annotations, this is complete for a list operation.

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

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

Schema description coverage is 100%, with each parameter (account_id, page_token, container_id, workspace_id) documented. The description adds no extra parameter semantics; it only repeats the return shape. 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 uses a specific verb ('Lists') with a clear resource and scope ('tags of a workspace'), distinguishing it from sibling list tools like list_variables or list_triggers. It also previews the response structure, which reinforces its 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 usage: use when you need tags in a workspace. However, it does not explicitly state when not to use it or name alternatives (e.g., list_variables for variables). Given sibling tools, this is a missed opportunity but not completely absent.

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 already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to restate these. It adds the return structure, which is helpful given no output schema, but does not disclose additional behavioral traits like rate limits or edge cases.

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: a clear one-line purpose and a compact specification of the return shape. Both sentences earn their place, providing essential information without fluff.

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 return structure is fully described, compensating for the lack of an output schema. However, it does not mention pagination behavior or empty-list cases, though the page_token parameter is documented in the schema.

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

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

Schema coverage is 100% for all 4 parameters, so the descriptions already explain their meanings. The tool description does not add parameter-level detail beyond this, matching the baseline for good 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 tool lists triggers of a workspace, which distinguishes it from sibling list tools like list_tags and list_variables. It uses a specific verb ('Lists') and resource ('triggers').

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 choose this tool over alternatives such as list_tags or list_workspaces. It simply states what it does without any comparative context or exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds valuable behavioral context by specifying the exact return payload structure, including variable fields and the nextPageToken for pagination, which annotations do not provide. No contradiction.

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: the first states purpose and differentiates from an alternative, the second specifies the return format. No unnecessary words, front-loaded with the most important information, and appropriately sized for the tool's complexity.

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

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

Despite lacking an output schema, the description explicitly states the return structure and pagination token, making the response format predictable. It also references manage_built_in_variables for built-in variables, covering the main use-case distinction. All parameters are well-documented in the schema, and the tool is otherwise straightforward.

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% coverage with descriptive text for all four parameters, including examples like workspace_id from list_workspaces. The description adds no additional parameter-level meaning beyond what the schema already provides, 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 the verb 'Lists' with a specific resource ('user-defined variables of a workspace') and explicitly contrasts with 'manage_built_in_variables', distinguishing it from a sibling tool. This makes the tool's purpose unambiguous and well-scoped.

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 that built-in variables live in manage_built_in_variables, providing a clear alternative for a different scenario. This effectively tells the agent when to use this tool (user-defined variables) versus when not to (built-in 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?

Annotations already declare readOnly/idempotent, and the description adds valuable behavioral details: pagination via nextPageToken, the return shape, and the fact that a Default Workspace always exists. No contradiction with annotations.

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

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

Two tight sentences: the first states action and return format, the second explains importance and usage order. No filler or redundancy.

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

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

For a simple list tool with strong annotations and full schema coverage, the description is complete. It includes purpose, usage timing, return format, and pagination—everything an agent needs to invoke it correctly.

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

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

Schema has 100% coverage of all three parameters, so the baseline is 3. The description does not add parameter-specific details beyond what the schema already provides, though it reinforces pagination via the return value.

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

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

The description clearly states 'Lists the workspaces of a container' and includes the exact return structure, distinguishing it from single-workspace retrieval tools like get_workspace. It also provides GTM-specific context that makes the purpose unmistakable.

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 says 'call this first' because workspaces are mandatory for all tag/trigger/variable operations, giving clear when-to-use guidance. It doesn't name alternatives or exclusions but the context is sufficient.

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 (readOnlyHint=false, destructiveHint=false, idempotentHint=true) already signal mutating but non-destructive, idempotent behavior. The description adds important context: these are toggles not records, the 'list' action returns a `{ builtInVariable: [...] }` structure, and enable/disable require the tagmanager.edit.containers scope. This goes beyond the annotations without contradicting them.

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 tight sentences pack all essential information: what the tool does, the toggle nature, action semantics, parameter roles, and scope requirements. No redundancy, front-loaded with the core purpose.

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

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

Given no output schema, the description covers the main return shape for 'list' and the behavioral role of each action. It omits details about the response for enable/disable and potential error conditions, but these are less critical for a toggle-oriented tool with strong annotations and schema descriptions.

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%, but the description enriches parameter understanding significantly: it clarifies that `types` is only relevant for enable/disable and is ignored for 'list', gives an example, and explains that action values map to distinct behaviors. This adds functional meaning beyond the raw schema descriptions.

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

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

The description clearly states the tool 'manages a workspace's built-in variables' and enumerates the three concrete actions (list, enable, disable) with examples. It distinguishes itself from sibling tools like list_variables and create_entity by framing these as toggles rather than records.

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

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

The description explains when to use each action: 'list' returns currently enabled variables, while 'enable'/'disable' require the `types` parameter and switch toggles on/off. It also notes the required OAuth scope for mutating actions, providing clear context though it does not explicitly contrast with related tools like update_entity.

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

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

The description discloses destructive behavior ('replacing the currently published one'), auth requirements ('requires the tagmanager.publish scope'), error semantics ('compilerError=true with HTTP 200 — reported as an error'), and response wrapping. These details go beyond the annotations, which only mark the tool as destructive and non-readonly, and add significant context.

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

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

The description is compact and densely informative, covering all three actions, parameter roles, auth, and response details in about 100 words. It is well-organized by action and then response nuances, with every sentence contributing meaningful 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?

Given the tool's complexity (three modes, variable parameters), the description is remarkably complete. It states prerequisites, exact parameter requirements per action, return type, and special error handling. The rich schema and annotations complement this, making the description sufficient for correct and safe invocation.

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

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

The schema already documents all five parameters with 100% coverage, so the baseline is 3. The description adds value by clarifying action-specific requirements: version_id is required for publish/get and ignored for live, and fingerprint is only for publish. It also explains fingerprint as optimistic-concurrency safety, which enriches the schema's description.

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

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

The description clearly identifies the tool as handling container-version operations with three specific actions: publish, get, and live. It uses strong verbs and differentiates these actions from sibling tools like create_version and get_resource by focusing on publishing and inspecting live container versions.

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 states when to use each action: publish requires version_id and the tagmanager.publish scope, get requires version_id, and live needs no version_id. The fingerprint parameter is also explained as recommended for publish. It does not explicitly mention alternatives to the tool itself, but the internal action guidance is clear.

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

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

Annotations already indicate destructive and non-readOnly behavior. The description adds useful context: requests go through the same OAuth, rate limiter, and retries as other tools. It doesn't explicitly warn about destructive potential, but the annotation covers this, so the added detail earns a 4.

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 four sentences, front-loaded with the core purpose, and every sentence adds value: purpose, path format, query arrays, and shared infrastructure. 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?

For a generic raw API tool, the description covers purpose, usage boundaries, path/query handling, and infrastructure behavior. With no output schema, it doesn't need to specify return values as they vary by endpoint. The examples and openWorldHint provide sufficient context.

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

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

Schema description coverage is 100%, so the schema fully documents all parameters. The description provides examples for path and query, but these largely echo the schema. Baseline 3 is appropriate as the description adds no substantial new parameter 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 clearly states this is an escape hatch for calling any GTM API v2 path directly, with explicit examples of endpoints lacking dedicated tools. It differentiates from siblings by explicitly targeting endpoints without a dedicated tool.

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

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

The description explicitly says 'for endpoints without a dedicated tool', which implies not to use when a dedicated tool exists. It also lists example endpoints, providing clear context for when this tool is the right choice.

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

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

Beyond annotations (destructiveHint, idempotentHint), the description discloses full-replace semantics, the need to fetch first, fingerprint-based optimistic concurrency with failure on mismatch, and required OAuth scope. This is rich behavioral context that annotations alone do not provide.

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 sentences, front-loaded with the core action, then essential semantics, then security/concurrency details. No filler; every sentence adds value.

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

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

The description covers the full workflow (fetch-modify-send), the full-replace semantics, concurrency safety via fingerprint, and the required scope. Despite no output schema, the description provides everything an agent needs to invoke the tool correctly.

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

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

Schema coverage is 100% with detailed parameter descriptions, but the description adds context beyond the schema: it explains that the body must be the complete replacement object, and clarifies the fingerprint's role in concurrency (last-seen, mismatch fails). This lifts it above the baseline 3.

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

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

The description clearly states the tool updates a tag, trigger, or variable by its API path, and specifies PUT semantics as a full replace. This distinguishes it from create_entity, delete_entity, and get_resource, making its purpose unambiguous.

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

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

It gives explicit guidance: fetch the current resource with get_resource, modify it, and send the whole object back. It also explicitly states this is NOT a patch, providing a clear when-not-to-use condition for partial updates.

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