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

Annotations indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds transparency by explaining the draft behavior, that changes stay local until publication, and that it returns the created tag with tagId. No contradictions.

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

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

The description is well-structured with a clear purpose statement, a behavior paragraph, and an args section. It is slightly verbose but each sentence adds value. Could be more concise, but remains effective.

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

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

Given the complexity (4 params, nested objects, no schema description) and the existence of an output schema, the description covers key aspects: draft lifecycle, parameter explanations, return value, and a note about built-in triggers. Missing are potential errors or permission requirements, but overall 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?

With 0% schema description coverage, the description fully compensates by explaining all four parameters. It gives specific instructions for workspace_id (find via list_workspaces) and details the tag resource body structure, including required fields and a minimal 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 description clearly states 'Creates a tag in the workspace draft,' specifying the verb, resource, and scope. It distinguishes from sibling tools like create_trigger and create_variable by emphasizing the draft lifecycle and that nothing goes live until publication.

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 when to use (creating tags in draft) but lacks explicit when-not-to-use or alternatives. It implies the tool is for initial creation, not updates, but does not mention update_tag or deletion as alternatives.

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

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

Annotations indicate non-destructive write operations. The description adds that creations are in draft and not live until published, which is valuable context beyond annotations. It does not contradict 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 an Args section. It includes a detailed example for customEventFilter, which adds value but is somewhat lengthy. Overall efficient with minimal 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?

With 4 parameters, nested objects, and an output schema, the description covers the tool's purpose, parameters, behavior (draft-only), and return value (including triggerId). It is complete for an agent to understand 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 0%, but the description provides detailed parameter explanations: account_id, container_id, workspace_id are described with types, and the trigger parameter includes required fields ('name', 'type'), examples, and specifics for customEvent triggers. This fully compensates for the lack of schema descriptions.

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

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

The description clearly states 'Creates a trigger in the workspace draft' using a specific verb and resource. It distinguishes from sibling tools like create_tag, create_variable, etc., by specifying 'trigger' and noting that changes remain in draft until published.

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 usage context by explaining that changes stay in draft and nothing goes live until a version is published. It also instructs how to find workspace_id via list_workspaces. However, it does not explicitly say when not to use this tool or compare with alternatives.

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

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

The description discloses key behavioral traits: changes are not live until a version is published, and it returns the created variable with its ID. This adds significant context beyond the annotations (readOnlyHint: false, destructiveHint: false), which are consistent with a creation operation.

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

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

The description is well-structured with a clear summary and an Args section. It is mostly concise, but the Args section repeats parameter names already in the schema; a slightly more streamlined version could omit the redundant parameter headers.

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 creation workflow, parameter requirements, and includes an example. However, it does not address potential errors (e.g., duplicate names), permission requirements, or details about the output schema (though output schema exists). Overall, it is quite complete but has minor 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 schema has 0% description coverage, but the description compensates by explaining each parameter: account_id/container_id accept numeric or path, workspace_id is found via list_workspaces, and the variable body requires 'name', 'type', and often 'parameter', with a detailed example. This provides essential meaning missing from 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 'Creates a variable in the workspace draft.' It uses a specific verb ('creates') and resource ('variable in the workspace draft'), distinguishing it from sibling tools like update_variable and delete_variable.

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 that changes remain in the workspace until a version is published, providing context for use. However, it does not explicitly state when to use this tool versus alternatives (e.g., update_variable) or when not to use it.

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

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

Annotations already state destructiveHint=true. Description adds detail: workspace deletion, creation of new empty workspace, returned path, and error checks. This exceeds annotation-only 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?

Well-structured: immediate purpose, bold warning, actionable instructions, then parameter list. Front-loaded with critical info. No unnecessary sentences.

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

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

Covers all necessary behavioral context for a destructive tool with 5 params. Even though output schema exists, description explains key return aspects (newWorkspacePath, compilerError, syncStatus). Complete enough for 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?

Schema coverage is 0%, so description compensates by explaining all 5 parameters: account_id (numeric or path), container_id (numeric or path), workspace_id (numeric, find via list_workspaces), name and notes (optional). Missing format details but 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?

Clear specific verb 'snapshots' and resource 'workspace into a new container version'. Distinguishes from siblings like publish_version and list_versions by explaining the lifecycle step.

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?

Explicit warning that the workspace is consumed and alternative path returned. Tells when to use (create version) and when not to publish with errors. Mentions troubleshooting steps for compilerError and syncStatus.

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

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

The description explains that the deletion is reversible until publication and requires confirmation, adding context beyond the destructiveHint annotation. It aligns with the annotation and provides useful behavioral details.

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

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

The description is concise and front-loaded with purpose and key requirement (confirmation). It then lists parameters efficiently. Slightly more brevity could be achieved, but it is well-structured.

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 tool with 5 parameters and an output schema (not shown), the description covers the key behavioral and parameter context. It doesn't explain the output, but that is covered by the output schema. The draft lifecycle and confirmation are well explained.

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

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

With 0% schema description coverage, the description compensates by explaining each parameter: types (numeric or path), sources (list_workspaces, list_tags), and the special confirm parameter requirement. This adds significant meaning beyond the schema.

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

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

The description clearly states that the tool deletes a tag from the workspace draft, using specific verbs and the resource. It distinguishes from sibling tools like create_tag, update_tag by focusing on deletion and mentioning the draft scope.

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 explicit guidance: ask user first, then call again with confirm=True. It also notes that removal is not final until publishing. It doesn't mention alternatives or when not to use, but the context 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-read-only. The description adds that deletion persists only in the draft until published and requires explicit confirmation, offering behavioral context beyond 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 (approx. 100 words) and well-structured with a clear statement of action, usage notes, and parameter explanations. 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?

For a destructive tool with an output schema, the description covers the deletion process, preconditions, and effect on drafts. No additional information is needed for proper tool 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?

Despite 0% schema description coverage, the description's Args section explains each parameter (e.g., resource path options, how to find IDs via list_* tools), fully compensating for the lack of parameter descriptions in 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 'Deletes a trigger from the workspace draft.' It specifies the verb 'delete' and the resource 'trigger', distinguishing it from sibling tools like delete_tag or delete_variable.

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

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

Explicitly instructs the agent to ask the user for confirmation and then call again with confirm=True. Also advises checking via list_tags to ensure no tag references the trigger, providing clear when-to-use guidance.

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

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

Beyond the destructiveHint annotation, the description explains the need for explicit confirmation, the soft-delete nature until publishing, and prerequisite checks. Adds significant behavioral context.

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

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

Well-structured with a clear opening, followed by usage notes and parameter descriptions. Slightly verbose but every sentence adds value; could be tightened slightly.

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, the description covers all necessary aspects: purpose, safety, parameters, and behavioral nuances. No gaps remain.

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

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

With 0% schema coverage, the description fills the gap by detailing each parameter's purpose, including how to find IDs via other tools (list_workspaces, list_variables) and the confirm parameter's role.

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

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

The description clearly states it deletes a variable from the workspace draft, distinguishing it from other delete tools like delete_tag and delete_trigger. It specifies the scope (workspace draft) and confirmation requirement.

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

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

Explicitly instructs to ask user first, then call with confirm=True. Also advises checking for references to prevent unintended issues. Provides clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true; description adds that it returns 'slimmed contents' and compares to get_version, but no further behavioral context (e.g., no mention of pagination or error states).

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 concise paragraphs: purpose, comparison, use case, then clear Args list. No wasted sentences.

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

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

With an output schema present, the description need not detail return format. It covers purpose, parameters, and usage context fully. Could mention read-only nature explicitly, but annotations cover 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?

Both parameters are described beyond the schema (e.g., 'Numeric account ID or full resource path') despite 0% schema description coverage, fully compensating for the 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?

Clearly states 'Gets the container version currently published (live)', specifies return type ('metadata plus slimmed contents'), and compares to get_version, distinguishing it from 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?

Provides a specific use case ('useful to see what is live before publishing a new version') and implies get_version for historical versions, but lacks explicit when-not-to-use or alternative descriptions.

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 include readOnlyHint=true, consistent with the 'Gets' verb. The description adds that it retrieves 'full configuration including parameters,' providing useful context beyond the annotation. No contradictions.

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

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

The description is extremely concise: one sentence for the purpose followed by clear parameter definitions. No redundant words, and the important information 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 output schema exists and the tool is a simple read with 4 parameters, the description covers all necessary information: what it does, how to get required IDs, and it leverages the output schema for return spec. No 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?

With schema coverage at 0%, the description fully documents each parameter, adding details like numeric ID or full resource path and how to obtain workspace_id and tag_id from other tools. This adds significant meaning beyond the schema's basic types and titles.

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

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

The description clearly states 'Gets the full configuration of one tag, including parameters.' This is a specific verb-resource combination and distinguishes from sibling tools like list_tags or create_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 context by advising to find workspace_id via list_workspaces and tag_id via list_tags, implying when to use this tool (when you have IDs). However, it does not explicitly state when not to use it or contrast with alternatives.

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

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

Annotations already declare readOnlyHint=true, so the description adds value by specifying 'full configuration' and 'including filters'. No contradictions.

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

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

Single efficient sentence followed by a structured parameter list. Front-loaded with purpose, no 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?

Given the presence of an output schema, the description doesn't need to explain return values. It covers inputs, purpose, and provides lookup hints, making it fully complete for a read tool with rich 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?

With 0% schema coverage, the description compensates by explaining each parameter: account_id and container_id can be numeric or full resource path; workspace_id and trigger_id are numeric with lookup hints. This adds significant meaning beyond the schema's anyOf type.

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

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

The description clearly states 'Gets the full configuration of one trigger, including filters', using a specific verb and resource. It distinguishes from siblings like list_triggers (which lists triggers) and get_tag (for tags).

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 (to get a single trigger's configuration) and provides lookup hints for IDs via list_workspaces and list_triggers. It doesn't explicitly exclude other cases but is clear enough.

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

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

The annotations already declare readOnlyHint=true, and the description's 'Gets' aligns with that. Beyond annotations, the description adds the detail 'full configuration' to hint at the output scope, but does not disclose any other behavioral traits (e.g., authorization needs, rate limits). With annotations covering the safety profile, this is adequate but not enriched.

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 highly concise: a single sentence stating the purpose followed by a terse parameter list. No wasted words, and the purpose is front-loaded. 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?

Given the tool's complexity (4 required parameters) and the presence of an output schema, the description covers purpose, parameter meanings, and ID retrieval hints. It lacks explicit error conditions or prerequisite permissions, but the read-only nature and parameter guidance make it largely complete. The sibling set is large, and the description adequately differentiates the 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?

Despite 0% schema description coverage, the description compensates thoroughly. For each parameter it clarifies acceptable types ('Numeric account ID or full resource path') and provides actionable guidance on how to obtain values ('find it via list_workspaces', 'find it via list_variables'). This goes well beyond the minimal schema, making the tool easily usable.

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 'Gets the full configuration of one variable,' specifying the verb and resource. Among sibling tools that also begin with 'get_', it uniquely targets 'variable', distinguishing it from gets for tags, triggers, versions, etc.

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

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

The description provides implicit usage guidance by listing required parameters and hints on obtaining IDs (e.g., 'find it via list_workspaces'). However, it does not explicitly state when to prefer this tool over alternative getters or exclude cases, leaving usage context somewhat 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?

Beyond the readOnlyHint annotation, the description discloses that returned contents are slimmed to avoid large outputs and that other get functions read the workspace draft. It adds meaningful context about what the tool does and does not do, though it could mention potential error 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 extremely concise with no redundant sentences. It front-loads the main purpose, then adds necessary context and alternative guidance in a well-structured paragraph, making efficient use of space.

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

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

Given the read-only nature and existence of an output schema, the description covers the key behavioral aspects: what is returned, why it's slimmed, and alternative tools. It could mention error handling for missing version or invalid IDs, but overall it's sufficiently 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?

With 0% schema description coverage, the description provides basic parameter clarification: each can be numeric ID or full resource path, and version_id can be found via list_versions. However, it lacks specifics on resource path format or examples, leaving some ambiguity.

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

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

The description explicitly states the tool retrieves a single container version with metadata and slimmed contents, using clear verb 'Gets' and specific resource. It distinguishes from siblings like get_live_version and get_tag by noting the scope and the slimmed 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?

The description provides explicit guidance on when to use alternatives (get_tag/get_trigger/get_variable) and notes their difference (reads workspace draft vs this version). It also advises finding version_id via list_versions, which is helpful for 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?

Annotations already indicate readOnlyHint: true, so the description does not carry the full burden. However, it adds no additional behavioral traits beyond what is stated (e.g., no mention of potential costs, permissions, or data freshness). This is acceptable 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?

Extremely concise: a single sentence for purpose followed by a parameter list. No wasted words, front-loaded effectively.

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

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

Given the complexity (3 required params, read-only tool, output schema exists), the description is minimally adequate. It does not explain what 'unpublished changes' or 'merge conflicts' entail, nor error conditions. The presence of an output schema mitigates the need to describe return values, but more context would help.

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

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

The description's Args section adds some value by explaining that account_id and container_id accept numeric or full resource path, and hints to find workspace_id via list_workspaces. This partially compensates for the 0% schema coverage, but the parameter descriptions are still minimal and mostly repeat schema info.

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 shows unpublished changes and merge conflicts in a workspace, which is a specific verb+resource. However, it does not explicitly differentiate it from sibling tools like get_live_version or get_version, though its focus on workspace status makes it unique enough.

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. It does not mention prerequisites, context, or exclusions, leaving the agent to infer usage solely from the purpose.

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 provide readOnlyHint=true, so the description does not need to reiterate safety. It adds the parameter behavior but no additional traits like permissions or limits. This is adequate but not beyond what is expected.

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 core purpose, followed by parameter explanation. No 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 simple list tool with one optional boolean parameter and an output schema, the description covers the purpose and the parameter meaning completely. No 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 coverage is 0%, but the description explains the only parameter (include_google_tags) in plain language, stating it 'Also include Google Tag accounts in the results'. This fully compensates for the missing schema 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 action 'Lists' and the resource 'all Google Tag Manager accounts', with scope 'accessible to the caller'. This distinguishes it from sibling tools that operate on lower-level resources like tags or 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 implies usage when needing to see accounts, but lacks explicit guidance on when not to use or alternatives. However, the context of siblings makes the purpose clear enough for an 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?

Annotations declare readOnlyHint=true, so the description adds no new safety information. It explains parameter format but does not disclose pagination, limits, or ordering behavior. This is adequate given the read-only nature, but lacks additional 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 extremely concise with two sentences, front-loaded with the core purpose. No unnecessary words 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 list tool with an output schema, the description is complete. It identifies the parameter and its formats. No additional details are needed.

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

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

Schema description coverage is 0%, so the description must compensate fully. It explains the account_id parameter with examples of numeric ID and full path, adding significant meaning beyond the schema's type definition.

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

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

The description clearly states the tool 'Lists all containers in a Google Tag Manager account,' specifying the verb and resource uniquely. It distinguishes from sibling tools like list_tags and list_workspaces, which target different resources.

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

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

The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use it, or comparisons to siblings like list_accounts or list_workspaces.

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 readOnlyHint annotation is consistent with the listing behavior. The description adds detail by listing exactly which fields are returned (skeleton fields), which goes beyond the annotation's safety implications.

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

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

The description is very concise, with the main action front-loaded. It lists return fields, provides an alternative tool, and documents arguments in a clear bullet-like format. Every sentence adds value.

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

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

Given that an output schema likely exists (context says true), the description still lists the return fields. Parameter documentation is thorough, including how to obtain workspace_id. The guidance to use get_tag for full details completes the context for a listing tool.

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

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

Even though the input schema has no descriptions (0% coverage), the description explains each parameter: account_id, container_id, workspace_id, clarifying that they accept numeric IDs or full resource paths, and workspace_id can be found via list_workspaces. This is highly informative beyond the schema's type constraints.

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 tags in a workspace and returns skeleton fields. It explicitly distinguishes itself from the sibling get_tag by noting that get_tag provides full configuration. The verb 'lists' and resource 'tags' are specific.

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 recommends using get_tag for full tag details, providing clear guidance on when to use an alternative. However, it does not include explicit exclusions or guidance for all siblings, but the context is clear enough for an AI 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?

Discloses that only skeleton fields are returned, adding value beyond the readOnlyHint annotation; 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?

Three concise sentences, each adding value: purpose, return details with alternative, and parameter descriptions. 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?

Adequately covers all aspects for a listing tool: skeleton fields, parameter types, and cross-reference to get_trigger and list_workspaces. Output schema handles return format.

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?

Despite 0% schema coverage, the Args section explains each parameter (numeric ID or resource path) and gives guidance for workspace_id, adding meaning beyond the schema.

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

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

Clear verb 'lists' and resource 'triggers in a workspace,' specifies 'skeleton fields only,' and distinguishes from 'get_trigger' which provides full configuration.

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

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

Explicitly recommends 'get_trigger' for full config and mentions finding workspace_id via 'list_workspaces,' providing clear context, though does not exclude other 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?

Annotations already declare readOnlyHint=true. The description adds context that the tool returns skeleton fields only and lists the specific fields, which is beyond what annotations provide. No contradictions.

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

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

The description is highly concise, front-loads the purpose, and includes parameter details in a clear format. Every sentence contributes useful information 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?

Given the output schema exists, the description does not need to explain return structure. It covers purpose, parameter usage, and alternatives. Missing pagination or ordering info, but acceptable for a list tool.

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

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

Schema has 0% description coverage. The description adds value by clarifying that parameters can be numeric IDs or full resource paths, and for workspace_id, suggests finding it via list_workspaces. This significantly aids correct parameter usage.

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: listing variables in a workspace with skeleton fields only. It specifies the returned fields (variableId, name, type, fingerprint) and distinguishes itself from get_variable.

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 directs to use get_variable for full configuration, providing an alternative. It also hints at finding workspace_id via list_workspaces. However, it does not clarify when to use this tool over other list tools like list_tags or list_triggers.

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 detail about returning skeleton fields and entity counts, but the readOnlyHint annotation already covers non-destructive behavior. No contradictions; good additional 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?

Two concise paragraphs: first summarizing behavior and results, second detailing arguments. No unnecessary words, front-loaded with key 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 output schema exists and annotations cover read-only nature, the description is complete. It explains what is returned and provides alternatives, fully meeting the needs 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?

Despite 0% schema description coverage, the description fully explains both parameters, including acceptable formats (numeric ID or full resource path), which adds significant meaning beyond the type definition.

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

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

The description clearly states it lists container version headers with skeleton fields only, and specifies the returned fields. It distinguishes itself from get_version and get_live_version, making the tool's purpose unique and 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?

Explicitly directs to use get_version for full contents and get_live_version for the published version, providing clear when-to-use guidance and alternatives.

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

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

Annotations already declare readOnlyHint=true, so the description does not need to restate that. However, it adds no behavioral context (e.g., pagination, defaults, or output format).

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?

Extremely concise: one-line purpose followed by parameter docs. No wasted words, front-loaded with the action.

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

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

Output schema exists, so return values are covered elsewhere. The description covers core functionality and parameter format well. Missing minor details like authentication or rate limits, but sufficient for a simple read-only list tool.

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

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

Schema coverage is 0%, but the description fully compensates by explaining the parameter types (numeric ID or full path) with examples, adding significant meaning beyond the schema.

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

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

The description clearly states 'Lists workspaces in a container' with a specific verb and resource. It distinguishes from sibling list tools like list_tags, list_containers, etc.

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

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

No guidance on when to use this tool vs alternatives. No mention of prerequisites or context beyond parameter types.

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 this as destructive; description adds context about making content live, requiring confirmation, and needing prior compiler error checks—no contradictions.

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

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

Efficiently structured with clear opening sentence, safety note, and bulleted args—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?

Covers prerequisites, confirmation step, and effect on live site; output schema not shown but present, so return values need not be detailed.

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?

Zero schema coverage, but description explains each parameter: confirm must be True, others accept numeric IDs or resource paths, and version_id found via list_versions.

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

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

Clearly states it publishes a container version to make it live, and distinguishes itself from siblings by noting it's the only operation that changes what runs on the live site.

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 explicit confirmation requirement ('ask the user first, then call again with confirm=True') and prerequisites (check for compiler errors using create_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 discloses merge semantics (shallow merge, null removes keys, lists replaced whole), concurrent edit handling (fingerprint prevents clobbering), and that changes stay in a workspace draft until published. These details go well beyond the annotations (readOnlyHint=false, destructiveHint=false).

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

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

The description is well-structured with a summary, detailed merge behavior, and args section. It is slightly lengthy but every sentence adds value; minor tightening could improve conciseness.

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

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

Given the complexity (5 parameters, nested object, no schema descriptions) and the presence of an output schema (so return values need less detail), the description covers merge semantics, error handling, draft workflow, and parameter guidance adequately for an agent to use the tool correctly.

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

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

With 0% schema description coverage, the description fully compensates by explaining each parameter (account_id, container_id, workspace_id, tag_id, changes) with examples and guidance (e.g., 'find it via list_tags'), adding significant meaning beyond the raw 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 'Updates a tag by merging changes into its current configuration.' It identifies the verb (update) and resource (tag), and the merge semantics distinguish it from create_tag (new) and delete_tag (removal).

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

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

The description implicitly indicates when to use this tool (for modifying an existing tag) but does not explicitly contrast with alternatives like create_tag or delete_tag. The context is clear, but explicit when-not guidance is missing.

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 indicate not read-only and not destructive. Description adds valuable context: atomic concurrency handling via fingerprint, shallow merge behavior, and persistence in workspace draft until publish. No contradictions 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?

Front-loaded with main purpose, then concise details and bulleted parameter list. Every sentence adds value 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?

Covers merge behavior, concurrency, and draft lifecycle. Minor ambiguity: the fingerprint mechanism is described as 'sent along' but not represented as a parameter in the schema, which might confuse. Overall, sufficient for 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 has 0% description coverage, but the description provides a bullet list explaining each parameter with type hints and example for 'changes'. Fully compensates for missing schema descriptions.

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

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

The description clearly states it updates a trigger by merging changes, distinguishing it from create and delete siblings. The verb 'updates' plus resource 'trigger' is specific, and the merge detail adds precision.

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

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

Implies use for modifying existing triggers, and mentions draft/publish lifecycle. However, lacks explicit when-not-to-use or direct comparison with create_trigger/delete_trigger, but the context of sibling tools and the merge semantics provide sufficient 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?

The description goes well beyond annotations, detailing shallow merge behavior, null value handling, list replacement, concurrent edit detection via fingerprint, and that changes stay in draft until publishing. Annotations were minimal (readOnlyHint=false, destructiveHint=false), so the description adds significant value.

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

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

The description is well-structured: a concise one-line summary, followed by a clear explanation of merge behavior, then an ordered Args list. Every sentence adds value without unnecessary verbosity.

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 5 required parameters and no schema descriptions, the description covers parameter semantics and output behavior (returns updated variable). It also notes draft persistence and concurrent edit safety. However, it could include error handling details or more on return structure, but overall it's fairly complete.

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

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

The input schema has 0% coverage (no descriptions), but the description's Args section explains each parameter, especially changes as a partial variable body with an example. While it doesn't fully enumerate allowed fields (since changes is flexible), it adds meaningful context 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 'Updates a variable by merging changes into its current config.' It specifies the verb (updates) and resource (variable), and distinguishes it from sibling tools like create_variable and delete_variable. The merge semantics are explained, 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 implies usage is for modifying existing variables, and provides context like requiring variable_id from list_variables and workspace_id from list_workspaces. However, it does not explicitly state when to use this tool versus alternatives (e.g., create_variable for new variables) or when not to use it.

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