gtm_create_trigger

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

With no annotations, the description carries the full behavioral burden, but it mostly documents parameters rather than the tool's runtime behavior. It omits side effects such as whether creation is immediate, whether confirmation is required, whether the trigger is saved to a specific workspace, or what the return shape is. The only genuine behavioral note is the built-in variable prerequisite, which is useful but insufficient.

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

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

The description is compact, well-organized into an Args format, and contains no filler. Each line adds value, and the condition example is concrete and helpful.

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 eight parameters and zero schema description coverage, the description is incomplete. It covers three important parameters well but omits the context and purpose of ID parameters and the behavior of confirm, which are necessary for correct invocation. The output schema exists, so return value details are less critical, but the input side still has major gaps.

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

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

Schema description coverage is 0%, so the description must compensate, and it does provide meaning for trigger_type, conditions, and event_name, including valid operators and an example. However, it says nothing about the other five parameters—name, confirm, account_id, container_id, and workspace_id—which remain undocumented in both the schema and the 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 states 'Create a trigger' with a concrete resource and immediately lists supported trigger types, making the tool's purpose specific and distinct from sibling tools like gtm_create_workspace, gtm_create_entity, and gtm_create_ga4_event_tag. The trigger-type catalog helps an agent know exactly what kind of object this creates.

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

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

The description clearly implies the tool is for creating GTM triggers, and it gives a direct usage rule: call enable_built_in_variables first when creating click or form triggers. However, it does not explicitly compare against alternatives like gtm_create_entity or state when 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.