Samarth GTM MCP Server

Official

by samarthanalytics-sj

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.473.4
Disambiguation4/5
Tools are clearly separated by domain (GTM vs GA4) via prefixes, and within each domain follow resource_action naming. However, 173 tools across two large APIs still present some risk of confusion between similar operations (e.g., tags_update vs tags_add_ga4_event_parameters), and the sheer volume can make it hard for an agent to quickly pick the right tool.
Naming Consistency4/5
The naming convention is largely consistent: lowercase, snake_case, resource_action pattern. GTM tools use 'resource_action' (e.g., tags_create), GA4 tools use 'ga4_action_resource' (e.g., ga4_create_audience). A few tools have slightly longer, more specific names (e.g., workspace_create_version_and_publish) but still follow the pattern. Minor deviations do not cause significant confusion.
Tool Count1/5
With 173 tools, the server is extremely heavy and arguably over-engineered. While it aims to cover both GTM and GA4 APIs comprehensively, this results in an unwieldy tool surface that is difficult for an agent to navigate efficiently. A more focused or modular approach would improve coherence.
Completeness4/5
The tool set appears to cover a vast majority of GTM and GA4 management operations, including CRUD for most resources, reporting, auditing, and configuration. A few niche operations might be missing, but for the stated purpose of managing GTM/GA4, the surface is very thorough.
Average 3.8/5 across 173 of 173 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1751 commits in the last 12 weeks
- Last stable release on August 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits (e.g., read-only, idempotent, error conditions, permissions). The description carries the full burden but fails to convey even that this is a safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly terse (one sentence). Conciseness should not sacrifice necessary information; here, critical details are omitted, making it under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 required parameters, no output schema, and no annotations, the description is grossly incomplete. It does not explain the concept of a GTM folder, the relationship between IDs, or the expected response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the four required parameters (folderId, accountId, containerId, workspaceId). The agent receives no guidance on what each parameter represents or how to obtain them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a specific GTM folder' clearly states the verb (Get) and resource (GTM folder), distinguishing it from sibling tools like folders_list (list all) and folders_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., folders_list for multiple folders, folders_create for new ones). No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'get,' implying a read operation, but does not disclose any behavioral traits such as permissions, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one short sentence), which is efficient but lacks necessary detail. It could be expanded slightly without losing conciseness to include key context like parameters or return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description does not explain what is returned. For a simple get tool, it misses the opportunity to mention the trigger object structure or that it requires a specific triggerId.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters. The agent receives no hints about what the four IDs represent or their role beyond being required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get a specific GTM trigger,' clearly indicating the action (get) and resource (trigger). It distinguishes itself from siblings like 'triggers_list' by specifying 'specific,' but could be more explicit about requiring a triggerId.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'triggers_list'. The description only states what it does, without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'Get', implying a read operation but lacking details about behavior (e.g., returns full object, permissions needed, error handling). Minimal disclosure beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence, front-loaded with the key action. However, the brevity sacrifices necessary detail for completeness in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large set of sibling tools and the lack of output schema, the description should provides more context (e.g., what uniquely identifies a variable, return value shape). It only meets the bare minimum.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% parameter description coverage, and the description adds no explanation of the four required parameters (accountId, containerId, workspaceId, variableId). The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a specific GTM variable' with a specific verb and resource, distinguishing it from sibling tools like variables_list, variables_create, etc. It effectively communicates the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., when to use variables_list instead). The description provides no context for selecting this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only mentions that the tool is a write operation and requires a confirm parameter, but fails to describe side effects, error handling, idempotency, or what happens if creation fails or duplicates are attempted. This is insufficient for safe agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence front-loaded with the write indicator. While it is efficient and to-the-point, it sacrifices necessary detail, making it borderline under-specified. It earns high marks for brevity but loses on completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, nested parameter structure, no output schema, low schema coverage), the description is woefully incomplete. It does not explain how to construct the parameter array, variable types, or required structure, leaving an agent without sufficient context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 27%, so the tool description should compensate. However, the description contains no parameter information at all. The schema itself provides some descriptions for 'type', 'parameter', and nested structures, but the tool description adds no value in explaining parameter meanings, usage, or examples, leaving many parameters underdocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a GTM variable and marks it as a write operation. It identifies the resource and action, which distinguishes it from read or update sibling tools. However, it lacks detail about what a GTM variable is or the variety of types it supports, which would enhance clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies prerequisites (GTM_MCP_ENABLE_WRITES=true and confirm=true), indicating when this tool can be used. It does not, however, provide guidance on when to choose this tool over alternatives like variables_update or the possibility of duplicate creation, nor does it outline exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It notes '[WRITE]' and required confirm flag, but does not explain the move process (e.g., deletion, copy behavior), side effects, or authorization details beyond the generic prerequisite.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, minimal waste. Could include destination info but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter tool with no output schema, the description is too brief. It omits explanation of 'move' semantics, destination container (missing from schema), and the role of copy* parameters. Incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 89%, so the schema already documents most parameters. The description only reinforces the 'confirm' requirement, adding no new semantic value. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Move') and resource ('Tag ID'), and distinguishes from sibling tools (e.g., tags_create, containers_combine). However, it lacks clarity on the destination container, which is not in the schema, potentially causing confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like tags_create or containers_combine. Prerequisites are mentioned (ENABLE_WRITES, confirm) but no usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral context. It only says 'get details' with no mention of read-only nature, side effects, or required permissions. The schema implies required IDs but the description adds no behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words. It is front-loaded and efficient, though it could include a bit more context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema fully documents the parameters and there is no output schema, the description is minimally adequate. However, it lacks information about return data, authentication, or error conditions, which would be helpful for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all three required parameters. The description adds no additional meaning beyond the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'details of a specific GTM destination', making the purpose unambiguous. It distinguishes from sibling tools that operate on different resources (e.g., accounts, containers) but does not explicitly differentiate from destinations_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like destinations_list or other 'get' tools. The description lacks context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states 'get a specific GTM gtag config,' with no mention of authentication, rate limits, side effects, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It could be slightly expanded to include return value hints, but it is efficient for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is incomplete. It does not explain what the tool returns (e.g., the gtag config object) or any edge cases. For a simple read, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described in the input schema. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a specific GTM gtag config, using a verb+resource pattern. However, it does not differentiate from the sibling tool gtag_config_list, which lists configs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like gtag_config_list or when to use other getter tools. No usage context or prerequisites provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions automatic pagination but fails to disclose other behaviors such as read-only nature, required permissions, rate limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two focused sentences, no wasted words, and front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no output schema, the description is insufficient. It does not describe return values, truncation behavior, or the meaning of required parameters, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40% (descriptions for maxPages and pageToken). The description adds no additional meaning beyond the schema; it does not explain accountId, containerId, workspaceId, or how they relate to the listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all GTM triggers in a workspace,' specifying the verb (list), resource (triggers), and scope (workspace). It also distinguishes from sibling tools like triggers_get (single trigger) by implying a bulk listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives like triggers_get or triggers_list with filters. No explicit when-not-to-use or prerequisite conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states it is a DELETE operation and requires confirmation, but does not mention permanence, error conditions, or side effects beyond prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the action and prerequisites. No wasted words, though slightly more context could be added without breaking conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 required parameters, no output schema, and no description of return values or deletion behavior, the description is incomplete for a delete operation. It lacks details about what happens after deletion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only adds meaning for 'confirm' (requires true) and the env var. It does not explain parameters like accountId, containerId, workspaceId, or variableId, failing to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a GTM variable', which is a specific verb+resource. It indicates the HTTP method [DELETE]. However, it does not differentiate from sibling tools like variables_create or variables_update beyond stating the verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisites: 'Requires GTM_MCP_ENABLE_DELETES=true and confirm=true'. This implies when it can be used but does not compare to alternatives or state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description warns that the action immediately makes the version live in production, indicating potential impact. However, with no annotations, it omits details on reversibility, idempotency, or failure modes. Some transparency is present via the warning emoji, but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with a [PUBLISH] tag. It conveys essential details without verbosity. Slightly more structure could improve readability, but it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a publishing action with production impact, the description lacks context on return values, error handling, prerequisites (e.g., version must exist and be unpublished), and environment setup. It feels incomplete for a tool that can alter live environments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 50% schema description coverage, the description does not add meaning for the undocumented parameters (accountId, containerId). It only reiterates the confirm parameter's requirement already present in the schema. No additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool publishes a specific GTM container version to live, using the verb 'Publish' and specifying the resource. However, it does not explicitly differentiate from sibling tools like workspace_create_version_and_publish, which may also publish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions required prerequisites (environment variable and confirm=true) but provides no guidance on when to use this tool versus alternatives. It lacks context on scenarios where other version or workspace tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a write operation and a config requirement, but does not disclose behavior like what is created, idempotency, or effects on existing data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the critical verb and resource. Every sentence adds value, but room exists for more detail without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should at least hint at return value; it does not. It also omits context about the confirm parameter or how accountId/containerId are used. Given 5 parameters and sibling tools with similar patterns, more detail is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds no extra parameter information beyond the schema, but does not contradict it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'workspace', plus the '[WRITE]' prefix reinforces the action. However, it does not differentiate from sibling tools beyond the resource name, lacking explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite ('Requires GTM_MCP_ENABLE_WRITES=true'), but gives no guidance on when to use this tool versus alternatives like workspaces_list or containers_create. No when-not-to-use or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'Get details', omitting whether the operation is read-only, what permissions are required, or what response is expected. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it is too sparse and could include more helpful context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the tool's simple retrieval function, the description should indicate what 'details' are returned (e.g., properties of the workspace). It fails to provide sufficient context for an agent to understand the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with documented parameters (accountId, containerId, workspaceId). The description adds no extra meaning beyond the schema's property descriptions, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific GTM workspace' uses a specific verb ('Get') and resource ('specific GTM workspace'), clearly differentiating from sibling tools like workspaces_list or workspaces_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as workspaces_list for multiple workspaces, workspace_get_status for status, or workspace_quick_preview. The description does not specify any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden. It states a read operation ('Get details') but does not disclose permissions, side effects, or any constraints. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation, the description suffices to indicate a read. However, without an output schema, the agent does not know what details are returned, leaving some incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions for accountId and containerId. The description adds little beyond implying the need for both IDs. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'details of a specific GTM container', making the purpose clear. However, it does not differentiate from sibling tools like accounts_get or clients_get, which follow the same pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as containers_list or containers_lookup. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only mentions a prerequisite and confirm parameter, omitting details about side effects, reversibility, permissions, or behavior when confirm is false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the action, no wasted words. Slightly more structure could improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description is too brief. It lacks details on return values, confirmation mechanism, and broader usage context for Google Tag Manager.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the schema ('Move tags/triggers/variables'), but schema coverage is 50%, so partial value is provided. It doesn't explain parameter relationships or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move tags/triggers/variables into a folder') and resource, distinguishing it from sibling read tools. However, it could be more specific by explicitly mentioning Google Tag Manager and the entity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage conditions (writes enabled, confirm=true) but lacks strategic guidance on when to use this tool versus alternatives like folders_create or other move operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It only states that it is a write operation and requires confirm=true, but does not disclose side effects (e.g., whether it creates a new metric or replaces an existing one), return value, or idempotency. The '[GA4 WRITE]' prefix and prereq are minimal 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. It efficiently conveys the core action and a key prerequisite. However, it might be too terse given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, 6 required, no output schema, and no annotations, the description is insufficient. It fails to explain what the tool returns, how errors are handled, or how this tool relates to other GA4 custom metric tools (e.g., archiving, updating). A more complete description would include return format and common use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (6 of 8 parameters have descriptions), so the schema already explains most parameters. The tool description does not add any additional parameter meaning beyond the schema, but it does reiterate the confirm requirement. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and resource 'custom metric', and includes a '[GA4 WRITE]' prefix indicating write operation. The name itself distinguishes from sibling tools like ga4_archive_custom_metric and ga4_update_custom_metric, but the description does not elaborate on what a custom metric is or how it differs from a custom dimension.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisites (GA4_MCP_ENABLE_WRITES=true and confirm=true), implying when to use. However, it provides no guidance on alternatives (e.g., ga4_update_custom_metric) or exclusions. Usage is implied by the tool name rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description relies solely on '[GA4 WRITE]' to indicate a write operation and the 'confirm=true' requirement. It does not disclose side effects, permissions, or other behavioral traits beyond the basic write nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence for purpose plus a note on requirements. It is front-loaded and wastes no words, though it could include more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a nested 'body' parameter, the description does not explain what the body should contain, what the advertiserId is, or what the tool returns. It is insufficient for an agent to use correctly without referencing additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so the schema already documents most parameters. The description adds no extra parameter semantics, leaving the agent to rely on schema descriptions alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Search Ads 360 link, with a specific verb ('Create') and resource ('Search Ads 360 link'), distinguishing it from sibling tools like ga4_create_google_ads_link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions required conditions (GA4_MCP_ENABLE_WRITES=true, confirm=true) but provides no guidance on when to use this tool versus alternatives like ga4_update_search_ads_360_link or other link creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the returned fields but does not disclose pagination behavior (truncated, nextPageToken) which is only described in the parameter schema. No side effects, permissions, or rate limits are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. However, it could be improved by briefly mentioning pagination or filtering capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions the returned fields but does not explicitly confirm that the result is a list or describe the structure. Pagination details are only in the schema. For a list tool with no output schema, additional context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all parameters have descriptions). The description does not add value beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List), the resource (GTM accounts), and the scope (accessible to the authenticated user). It also lists the returned fields, distinguishing it from the sibling tool 'accounts_get' which retrieves a single account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool versus alternatives like 'accounts_get' or other listing tools. No prerequisites, conditions, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It correctly indicates a read operation ('Get') but offers no additional behavioral details such as rate limits, authentication requirements, or error handling. The simplicity keeps it from being misleading but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, containing no wasted words. It is efficiently front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a getter tool with 4 required parameters and no output schema, the description is incomplete. It does not mention what the tool returns (the client resource) or common error conditions (e.g., not found). Given the complexity of the GTM API, more context is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 4 parameters have descriptions), so the description does not need to compensate. However, it adds no extra context beyond the schema, such as how parameters relate (e.g., clientId is unique within workspace). The baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a specific GTM client' clearly states the action (get) and resource (GTM client). It is distinguishable from siblings like 'clients_list' by implying a single entity, though it does not explicitly mention the identifier parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives like clients_list or clients_create. There are no prerequisites or context given for invoking this tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It indicates a write operation and mentions requirements, but lacks details about side effects (e.g., environment state changes, propagation to preview), optimistic locking via fingerprint, or error conditions. The [WRITE] label is helpful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with a clear [WRITE] label and essential requirements. No unnecessary words; every part earns its place. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no output schema, no annotations), the description is too minimal. It does not explain return behavior, error handling, optimistic locking, or what happens after a successful update. An agent lacks sufficient context to use this tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds context that 'confirm' must be true, reinforcing its role as a safety check. However, it does not add meaningful semantics beyond the schema for other parameters, such as the purpose of fingerprint or the optional fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and resource 'GTM environment', with a [WRITE] prefix indicating it's a mutation. This distinguishes it from read-only environment tools like environments_list and environments_get, but does not explicitly differentiate from environments_create or environments_reauthorize.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides prerequisite conditions: requires GTM_MCP_ENABLE_WRITES=true and confirm=true. This gives guidance on when the tool can be invoked but does not explain when to use this tool vs. alternatives like environments_create for new environments or environments_reauthorize for token refresh.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a write operation and required confirm flag but does not disclose success/failure behavior, idempotency, side effects, rate limits, or permissions beyond the environment variable. Minimal 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence with a clear structure. It front-loads '[GA4 WRITE]' and immediately states the action and resource. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about return values (no output schema), what happens on success/failure, and does not mention advanced features via the body parameter. For a create tool, it is minimally complete; more detail on the response or next steps would improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds no extra meaning beyond confirming the confirm parameter must be true, which is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Display & Video 360 advertiser link, with the verb 'Create' and the specific resource. It distinguishes from sibling tools like update and delete by the action. The [GA4 WRITE] prefix adds context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisites (GA4_MCP_ENABLE_WRITES=true and confirm=true) but provides no guidance on when to use this tool versus other GA4 create links (e.g., Google Ads, Search Ads 360) or what conditions justify its use. No alternative tools are suggested.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Only declares 'Read-only' but lacks disclosure of pagination behavior, rate limits, authentication requirements, or error handling. With no annotations, the description should provide more 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus 'Read-only.' Front-loaded with key purpose and output details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks description of return format beyond field names, no mention of pagination (maxPages default, pageToken), and no error scenarios. Incomplete for an agent to reliably handle all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema documentation covers all parameters fully (100% coverage). Description adds minimal semantic value beyond listing some output fields; does not explain parameter usage beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (List), resource (custom dimensions), and provides specifics: parameter name, display name, scope types. It distinctly identifies the tool among siblings like ga4_custom_metrics_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., ga4_custom_metrics_list). The description does not provide context for prerequisites, typical workflow, or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description only states 'Read-only,' indicating no side effects. It does not disclose pagination behavior, rate limits, or other operational characteristics, leaving the agent with limited behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus 'Read-only,' front-loading the action and key details. Every element serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation with no output schema, the description is sparse. It mentions returned fields but does not specify that the response is a list, include pagination details, or confirm the structure of the output, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 parameters. The description adds a list of returned fields but does not elaborate on parameter semantics beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('custom metrics on a GA4 property'), and includes specific fields returned. It distinguishes from siblings like ga4_custom_dimensions_list by listing metric-specific attributes in parentheses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites beyond the property ID (which is in the schema), and no exclusions or context about 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not disclose behavioral traits such as read-only nature, authentication needs, error behavior, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loaded, but could include more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with no output schema and no annotations, the description is adequate but lacks completeness regarding return values or permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all four parameters. The description adds no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'specific GTM transformation', distinguishing it from siblings like transformations_list, transformations_create, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, or any prerequisites. The description is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions automatic pagination, but fails to disclose other important aspects such as authentication requirements, rate limits, idempotency, or error behavior. For a list operation, more detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with no filler: 'List all GTM transformations in a workspace. Automatically follows pagination.' It is front-loaded and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should help the agent understand the return format or any filtering/sorting capabilities. It does not mention what fields are returned, that results are an array, or any ordering. This is incomplete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema—parameters are already well-described in the input schema. No extra semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'all GTM transformations', and the scope 'in a workspace'. This effectively distinguishes it from sibling tools like transformations_get (single) and transformations_create (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like tags_list or triggers_list, nor does it mention prerequisites or context. It only states what it does, leaving the agent to infer usage from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry full burden. It only mentions the requirement for confirm and env var, but does not disclose any behavioral traits such as irreversibility, permissions needed, or error conditions. For a destructive action, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the action and requirements. While concise, it omits important details; however, it does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 required parameters, no output schema, and a destructive operation, the description is incomplete. It fails to specify what happens after deletion, return values, or parameter formats. For a delete tool, more context is expected to ensure safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema), and the description does not explain any parameters beyond mentioning 'confirm=true'. The meaning of accountId, containerId, workspaceId, triggerId, and confirm are not clarified, leaving the agent uninformed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a GTM trigger' with a specific verb ('Delete') and resource ('GTM trigger'). It is unambiguous and distinguishes from sibling tools like triggers_create, triggers_update, triggers_get, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists prerequisites: requires GTM_MCP_ENABLE_DELETES=true and confirm=true. This provides clear when-to-use guidance. However, it does not explicitly state when not to use or mention alternatives, leaving some gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds one behavioral detail: automatic pagination. However, with no annotations, it does not disclose read-only nature, permission requirements, or other side effects. This is minimal transparency beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no redundancy. Purpose is stated first, followed by a key behavioral trait. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool, the description is adequate but minimal. It explains what the tool does and pagination, but lacks information about the response format or what fields are returned. Given no output schema, a hint about the return structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description mentions pagination behavior, which relates to maxPages and pageToken, but does not add significant meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists GTM clients in a workspace. The verb 'list' and resource 'GTM clients' are specific, and the scope 'in a workspace' is narrow. It implicitly distinguishes from single-resource tools like clients_get, but doesn't explicitly differentiate from other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., clients_get for a single client, or other listing tools). No prerequisites or context for usage are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Get details,' implying a read operation, but lacks explicit statements about side effects, rate limits, or required permissions. The simplicity of the operation partially mitigates this, but the description misses an opportunity to be transparent about its non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 8 words, efficiently conveying the tool's purpose without redundancy. It is front-loaded with the action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a get operation with three required parameters and no output schema, the description provides minimal context. It does not explain what 'details' includes or any error conditions. While sufficient for a straightforward GET, it lacks completeness for an agent to fully understand the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a brief description (e.g., 'The GTM account ID.'). The tool's description does not add any additional meaning or context for the parameters, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('details of a specific GTM environment'). It effectively distinguishes this tool from sibling tools like environments_list (list all) and environments_create (create new), 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not specify when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It simply states what the tool does without any guidance on appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses automatic pagination handling, which is a key behavioral trait. However, no information about performance, rate limits, or that it's a read-only operation. Without annotations, this is acceptable but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each providing essential information. Front-loaded with purpose, no redundant or extra words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 params, no output schema, no annotations), the description is minimal. It lacks details on output format, error handling, expected behavior when no folders exist, or how the pagination token works.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 40% (2 of 5 parameters described). The description does not add meaning to the undocumented parameters (accountId, containerId, workspaceId), which are required but not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List all GTM folders in a workspace' with a specific verb and resource. It distinguishes from sibling tools like folders_get (single folder) and folders_entities (entities within a folder).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., folders_get for a single folder). Implied by 'all folders' but lacks when-not or prerequisite info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states the write nature and requirement, omitting details on idempotency, error handling, or effects of incomplete parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, front-loaded with [WRITE], efficient and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, no output schema, no annotations), the description lacks completeness. It fails to describe return values or parameter roles beyond confirm.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 8 parameters, the description adds no value for most parameters. It only mentions confirm but not name, notes, fingerprint, or required IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates a GTM folder, distinguishing it from sibling tools like create, delete, or list by using 'Update' and the [WRITE] prefix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly requires GTM_MCP_ENABLE_WRITES=true and confirm=true, providing necessary usage constraints. However, it does not contrast with alternatives like folders_create, though the context implies modification of existing folders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It flags write intent and confirm requirement, but does not disclose side effects, idempotency, or error conditions. Partial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence effectively conveys purpose and key requirements. No superfluous words, but fails to include additional context that would improve usability without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with 7 parameters and no output schema or annotations, the description is too sparse. It omits return value, error handling, property dependency, and what happens on conflict with existing metric ID.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 71% leaving some parameters like metricUnit and displayName undocumented. The description adds emphasis on required confirm and calculatedMetricId, but does not explain the 'body' nested object or other fields beyond schema. Adequate but not compensating for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a calculated metric, a specific resource, and includes the required `calculatedMetricId`. The [GA4 WRITE] tag and mention of confirm flag further clarify its operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over siblings like ga4_update_calculated_metric or ga4_delete_calculated_metric. It only mentions prerequisites (MCP_ENABLE_WRITES, confirm=true) but no context for alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description only mentions required flag and confirmation. Does not disclose irreversibility, side effects, permissions, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence with all essential information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and key prerequisites, but lacks details on return values, error handling, or permission requirements. Adequate for a simple delete tool with good schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds minimal context: 'Full resource name' for name and 'Must be true to delete' for confirm, but does not elaborate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Delete a Google Ads link', providing a specific verb and resource. Though it does not explicitly distinguish from sibling tools like 'ga4_create_google_ads_link', the action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage through prerequisites (requires GA4_MCP_ENABLE_DELETES=true and confirm=true), but does not provide guidance on when to use versus alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'Get', implying a read operation, but does not disclose behavioral traits such as idempotency, required permissions, or whether the record must exist. More detail is needed for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. It is front-loaded with the action and resource, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation, the description is minimally adequate. However, given the absence of an output schema and the large number of sibling tools, additional context about return format or use case would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters with adequate descriptions. The tool description adds no additional parameter meaning, thus baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'a specific user permission record' within the scope of 'a GTM account'. This distinguishes it from siblings like user_permissions_list (list all) and user_permissions_create (create), 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like user_permissions_list. The description does not specify that this is for retrieving a single record by ID, nor does it mention any prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose that the operation is read-only, whether pagination is required (though hinted via parameters), or any other behavioral traits like rate limits or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the key action. However, it could be slightly more detailed without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description is too sparse. It does not explain the return format, pagination behavior, or the concept of 'version headers', leaving the agent partially informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60%, with descriptions for maxPages, pageToken, and includeDeleted. The description does not add any parameter-specific meaning beyond what the schema already provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'container version headers (summary)', and the scope 'for a GTM container'. It distinguishes from sibling tools like versions_get (full details) and versions_delete by focusing on listing summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like versions_get. The description implies usage for listing version headers, but does not provide context for when this is appropriate or when to use other version tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Get a specific GTM zone.' It does not disclose that this is a read-only operation, any required permissions, or what happens if the zone does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with 4 required parameters and no output schema, the description is minimally adequate but could benefit from additional context, such as the role of zones in GTM.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add any further meaning to the parameters beyond what the input schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and resource 'specific GTM zone', clearly indicating what the tool does. It distinguishes itself from associated tools like zones_list, zones_create, and zones_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., zones_list) and does not mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states it's a list (read) operation but does not mention auth requirements, rate limits, pagination beyond schema, or side effects. The description adds minimal transparency beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that concisely communicates the tool's purpose without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool, the description covers the basic purpose but lacks details on return format and pagination behavior. Without an output schema, the description should at least hint at the structure of results. It is minimally complete but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 40% (only maxPages and pageToken have descriptions). The tool description does not explain any parameters or add meaning beyond the schema. For a tool with three required parameters (accountId, containerId, workspaceId), the description offers no guidance on their purpose or values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), the resource (built-in variables), and the context (enabled, in a GTM workspace), distinguishing it from sibling tools like variables_list or built_in_variables_enable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing enabled built-in variables but does not explicitly guide when to use this tool versus alternatives like variables_list or built_in_variables_enable. No when-not-to-use or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals automatic pagination, which is a key behavior, but does not address safety, idempotency, rate limits, or error handling. The description adds value beyond the schema but is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the primary action and a key feature. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the core functionality (listing with pagination) and leverages the schema for parameter details. It could mention the output format or error conditions for completeness, but the current content is largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds no extra meaning beyond the schema: it does not explain parameter usage or relationships beyond what is already in the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists all environments in a GTM container and automatically handles pagination, which is a specific verb+resource combination. While it distinguishes from sibling list tools by specifying 'environments', it does not explicitly contrast with other environment-related tools like environments_get or environments_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus alternatives such as environments_get (for a single environment) or environments_create. No exclusions or prerequisites are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description correctly indicates this is a write/mutation operation via the [WRITE] prefix and specifies required environment variable and parameter conditions, but lacks details on side effects, idempotency, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with a clear prefix, achieving brevity, but it omits important details that could be added without significant length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description is insufficient for an agent to understand the full context, especially with many sibling creation tools that require differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description only clarifies the 'confirm' requirement for safety, leaving the meaning of 'name', 'notes', 'accountId', 'containerId', and 'workspaceId' unexplained. The description fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a GTM folder') with a write indicator, differentiating from read-only folder tools like folders_get and folders_list that also exist among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite (GTM_MCP_ENABLE_WRITES=true and confirm=true) but offers no guidance on when to use this tool over other create tools (e.g., tags_create, triggers_create) 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the destructive nature (DELETE), prerequisites, and that folder contents are unfoldered, not deleted. This adds significant behavioral context beyond the name, but misses details like reversibility or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every sentence provides essential information (action, prerequisites, consequence on contents). No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a destructive tool with 5 required params and no output schema or annotations, the description lacks detail on return values, error handling, pre-deletion checks, or idempotency. It only covers basic behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It only clarifies the 'confirm' parameter (must be true) but ignores other required params (accountId, containerId, workspaceId, folderId), leaving their purpose implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a GTM folder', specifying the verb and resource. It distinguishes from read or update tools but does not explicitly compare to other folder deletion tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides prerequisites (GTM_MCP_ENABLE_DELETES=true, confirm=true) and notes that contents are unfoldered, implying when to use. However, it lacks explicit guidance on when not to use or alternatives like folders_move_entities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only notes the write nature and the need for confirmation, but omits details on idempotency, side effects, rate limits, or what happens upon creation (e.g., immediate vs. async).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a clear prefix, no extraneous information, and front-loads the write context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high schema coverage, the description does not explain the concept of custom dimensions, the role of scope, or the disallowAdsPersonalization parameter. For a tool with 7 parameters and no output schema, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86% (6/7 parameters have descriptions), so the baseline is 3. The description adds no additional parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a custom dimension with the prefix '[GA4 WRITE]' indicating a write operation. It distinguishes itself from sibling ga4_update_custom_dimension and ga4_archive_custom_dimension by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies prerequisites: GA4_MCP_ENABLE_WRITES=true and confirm=true. However, it does not provide guidance on when to use this tool versus alternatives like ga4_create_custom_metric or when to use which scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states it is a write operation and requires confirm=true, but it does not mention what happens upon creation (e.g., return value, idempotency, side effects, rate limits, or permissions beyond GA4 360). This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose and flags. It is concise with no wasted words, though the '[GA4 WRITE]' tag is somewhat redundant. It earns a 4 because it is efficient but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, nested body, no output schema), the description covers the essential creation context and prerequisites but omits the return value or any post-creation behavior. It is adequate but not fully complete for an agent to confidently use without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60% (3 of 5 params have descriptions). The description adds value for the 'body' parameter by specifying which fields to pass (dimensionNames, metricNames, dimensionFilterExpression), but does not elaborate on 'description' or 'displayName'. The extra info is helpful but not extensive, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'expanded data set (GA4 360 only)', distinguishing it from sibling tools like update and delete. The purpose is immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions requirements (GA4 360 only, GA4_MCP_ENABLE_WRITES=true, confirm=true) but does not provide guidance on when to use this tool vs alternatives (e.g., update, or other create tools). No explicit when-not or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses the prerequisite flags but does not explain behavioral outcomes such as creation effect, idempotency, or error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with two sentences that are front-loaded and free of unnecessary detail, effectively communicating the core purpose and a key requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 5 parameters with a nested body, the description lacks completeness. It does not mention return behavior, error handling, or optional parameter usage, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 extra meaning beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'key event (conversion) on a GA4 property', distinguishing it from sibling tools like update, delete, and list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions required flags (GA4_MCP_ENABLE_WRITES=true, confirm=true) but does not provide guidance on when to use this tool versus alternatives like ga4_update_key_event or ga4_key_events_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly identifies the operation as destructive and specifies necessary guardrails (env variable and confirm param). However, it does not disclose irreversibility, permission requirements, or what happens to associated data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action. Every word is necessary, with no filler. The format is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with two parameters and no output schema, the description covers the core action and critical requirements. It would benefit from a brief explanation of what an expanded data set is, but the tool remains functional as-is. The completeness is adequate given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema; it reiterates the confirm requirement already present. No examples or additional context are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'expanded data set (360)', making the tool's purpose unambiguous. It distinguishes from sibling tools like ga4_create_expanded_data_set and ga4_update_expanded_data_set through its focus on deletion. However, it does not explicitly differentiate from other delete tools like ga4_delete_account, but the resource name is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisites (GA4_MCP_ENABLE_DELETES=true and confirm=true) but provides no guidance on when to use this tool versus alternatives like ga4_delete_account or ga4_delete_channel_group. It lacks context for selecting between similar delete tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It reveals the write nature and need for confirm=true, but omits details like whether the update is partial or full replacement, the effect of omitting boolean fields, or rate limits. This is insufficient for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the write tag, and contains essential information without fluff. It is 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and prerequisites but lacks details on parameter interactions (e.g., how emailRedactionEnabled and queryParameterRedactionEnabled relate) and validation (e.g., web-only requirement). Given no output schema and missing annotations, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%; two boolean parameters lack schema descriptions. The description adds meaning by naming email and URL query-parameter redaction, but does not clarify their relationship with queryParameterKeys or whether they are toggles. The description compensates partially but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a WEB data stream's client-side data redaction, specifying email and URL query-parameter redaction. It distinctly differentiates from sibling tools like ga4_update_data_stream by focusing on redaction settings, and includes the write requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating data redaction on web data streams, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., ga4_update_data_stream). No when-not-to-use or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly labels it as a write operation with '[WRITE]' and mentions the confirm safety mechanism. Without annotations, it covers basic behavioral traits but lacks details on success response, error conditions, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence plus a prefix. It front-loads the write nature and prerequisites. Every word is earned, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 required parameters, no output schema, and many sibling tools, the description covers prerequisites and basic purpose but lacks expected output, error handling, or resource structure beyond schema examples. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 5 parameters at 100% coverage. The description adds minimal value beyond the schema, stating to pass the resource as JSON string in bodyJson, which is already in the schema description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new GTM gtag config with the prefix '[WRITE]'. The verb 'Create' and resource 'gtag config' are specific, and it distinguishes from siblings like gtag_config_update or gtag_config_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the required environment variable and confirm flag, providing necessary conditions for use. However, it does not explicitly state when to use this tool versus alternatives like gtag_config_update, though the name implies creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral transparency. It only states 'get details', implying a read-only operation. However, it does not disclose authentication requirements, rate limits, error cases, or what exactly 'details' encompasses. The description is insufficient for an agent to fully understand behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at just one sentence, front-loading the key action and resource. While it lacks structure (no bullet points or sections), the brevity is appropriate for a simple get operation. Every word serves a purpose, but some additional context (like what is returned) could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should hint at what 'details' includes. It does not. For a straightforward get-by-ID operation, the description is minimally adequate—the agent can infer it returns tag properties—but it could be more complete by mentioning that it returns the full tag object or listing key fields. The parameter schema is complete, partially compensating.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all four parameters (tagId, accountId, containerId, workspaceId) fully described in the schema itself. The description adds no additional semantic meaning beyond what the schema already provides. Baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific GTM tag' clearly states the action (get details) and the specific resource (GTM tag). It distinguishes this tool from sibling tools like tags_list (list tags) or tags_create/tags_update/tags_delete, making it easy for the agent to select it when needing to retrieve details of a single tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like tags_list or tags_get for other resources. The description implies usage when needing details of a specific tag, but lacks any conditions, prerequisites, or exclusion criteria. There is no context about 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('get'), which is correct for a retrieval tool. However, with no annotations provided, it does not disclose any potential side effects, permission requirements, or rate limits—though none are expected for a simple GET.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately concise for a straightforward retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the return value (e.g., the full template object). Given no output schema, the agent may need to infer the response structure from the resource type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, meaning the schema already explains each parameter's purpose adequately. The description adds no additional semantic value beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'specific GTM template', making the function unambiguous. It effectively distinguishes from siblings like templates_list (listing) and templates_create (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., templates_list for browsing, templates_get for a known ID). The agent must infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions requirements. It does not disclose what happens after undeleting (e.g., version becomes active, effects on container) or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a requirement note, front-loaded with the [WRITE] tag. Efficient but could benefit from structured param details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 0% schema coverage, the description lacks return value information and prerequisite details beyond the flag. Incomplete for a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description does not explain accountId, containerId, containerVersionId. Only confirm is mentioned as requiring true. Minimal addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Undelete' and the resource 'previously deleted GTM container version', distinguishing it from siblings like versions_delete, versions_publish, and versions_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites: GTM_MCP_ENABLE_WRITES=true and confirm=true. It implies usage for recovering deleted versions but does not compare with alternatives like versions_create.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and the description does not disclose behavioral traits such as idempotency, authorization needs, or rate limits. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence that directly states the tool's purpose with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter, the description is adequate but lacks details about return format or any behavioral context. No output schema to supplement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'accountId' parameter with sufficient detail. The description adds no extra meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific GTM account' clearly states the verb 'Get' and the resource 'details of a specific GTM account'. It differentiates from sibling 'accounts_list' by focusing on a single account retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'accounts_list'. The context is straightforward but lacks exclusions or usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states 'Delete a GTM client' and requires confirmation, but does not disclose irreversibility, side effects on related entities, or required permissions. For a destructive operation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the operation and key requirements. It is front-loaded with the action and immediately useful for the agent, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and 5 required parameters, the description covers the core action and prerequisites but omits details on response behavior, error cases, or permanence. It is minimally viable but leaves gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, setting a baseline of 3. The description adds value only for 'confirm' (must be true), but other parameters (accountId, containerId, etc.) have self-explanatory names and no additional context from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Delete a GTM client,' which is a clear verb+resource pair. The HTTP method and requirement are noted, distinguishing it from sibling tools like clients_list or clients_get by the delete verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisites (GTM_MCP_ENABLE_DELETES=true and confirm=true) but provides no guidance on when to use this tool versus alternatives like clients_revert or clients_get. It lacks explicit when/ when-not context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks details on read-only behavior, error handling (e.g., if destination ID not found), or permissions. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter and no output schema; description adequately explains lookup purpose but does not mention what the function returns or if multiple containers can share a destination ID.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with property description. Description adds contextual context like 'linked' and examples, but baseline 3 applies as schema already documents parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Look up', the resource 'GTM container', and the unique parameter 'linked destination ID' with examples. Distinguishes from sibling tools like containers_get which use container ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when you have a destination ID rather than a container ID, but does not explicitly state when to use versus alternatives like containers_get, containers_list, etc.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. The description only states the action without mentioning any side effects, authorization requirements, rate limits, or output format. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Front-loaded with the essential information. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is minimal. It provides the basic purpose but lacks details about return format, prerequisites, or behavior. For a simple retrieval tool it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides, but it does not detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource 'GTM installation snippet (HTML/JS tagging code)'. It distinguishes from sibling tools like 'containers_get' which retrieve container metadata, not the snippet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or when not to use this tool versus alternatives. However, the action is straightforward and the name clearly indicates its purpose, so usage is implied. Lacks exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states 'list all destinations' without disclosing whether it's read-only, permissions needed, pagination, or side effects. For a listing tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required params, no nested objects, no output schema), the description is minimally adequate but lacks details on return format, pagination, or any behavioral notes that would help an agent use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with clear descriptions for accountId and containerId. The description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'destinations', specifies context 'for a GTM container', and distinguishes from siblings like destinations_get and destinations_link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when listing all destinations, but provides no explicit guidance on when to use this tool versus alternatives like destinations_get or destinations_link, nor any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It declares read-only, which is helpful, but does not discuss pagination, truncation behavior, or other side effects. The mention of 'Returns full property records' adds some transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with no wasted words. It front-loads the core purpose and then adds useful output details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters with pagination logic and a showDeleted option, the description does not address these behavioral details. For a list operation, missing pagination context reduces completeness. No output schema exists, so description could compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond summarizing the output fields. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List GA4 properties under a given parent account' with a specific verb (list) and resource (GA4 properties). It distinguishes from sibling tools like ga4_property_get and ga4_create_property by focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives, such as when to use ga4_property_get for a single property. The description only implies usage by stating it lists properties, but does not set boundaries or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full responsibility. It indicates a write operation and lists updatable fields, but it does not disclose whether updates are partial (patch) or replacement, or any side effects, rate limits, or authorization details beyond the environment variable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a requirement note, with no wasted words. It front-loads the action and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, 2 required, no output schema, and no annotations, the description covers key updatable fields and the requirement flag but lacks details on other parameters like updateMask, return values, or error handling. It is adequate but has notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (only property has a description). The description adds meaning by listing the updatable fields (displayName, timeZone, currencyCode, industryCategory) but does not cover all parameters (e.g., updateMask). It partially compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Update), the resource (GA4 property), and lists specific updatable fields (displayName, timeZone, currencyCode, industryCategory). The [GA4 WRITE] prefix distinguishes it as a write operation among many read tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisites (GA4_MCP_ENABLE_WRITES=true and confirm=true) which gives context, but it does not explicitly state when to use this tool versus alternatives like ga4_update_account 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions automatic pagination but does not address other important aspects such as read-only nature, required permissions, rate limits, or response format. The behavior is partially transparent but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with no extraneous information. The first sentence clearly states the purpose, and the second adds a key behavioral detail about pagination. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description provides basic purpose and pagination behavior. However, it omits details about what is returned, error conditions, and permission requirements. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described in the input schema. The description adds no additional meaning to parameters beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all GTM zones in a workspace' which clearly identifies the verb (list) and resource (zones in a workspace). This distinguishes it from other zone-related sibling tools like zones_get (single zone) or zones_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. While it implies usage by describing the action, it lacks guidance on when not to use it or contrasts with zones_get for individual zone retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a write operation and required confirm parameter, but lacks details on idempotency, limits, or consequences of re-enabling already enabled variables.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loaded with the action, but could be better structured to include return value or error behavior without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 5 parameters, the description does not explain what the tool returns, error conditions, or further context about GTM workspace identification, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (20%), with only 'types' having a description. The description adds minimal meaning beyond the schema, not explaining the confirm boolean or the ID parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Enable' and the target 'one or more built-in variables in a GTM workspace', which is specific and differentiates from siblings like built_in_variables_disable and built_in_variables_revert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisites ('GTM_MCP_ENABLE_WRITES=true and confirm=true'), giving clear context for when it's appropriate to use, but does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses the write nature, required enable flag, and confirm parameter, but omits details like optimistic locking (fingerprint), error behavior, or response format. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus a pragmatic note. The '[WRITE]' tag front-loads the operation type. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no output schema, the description is too sparse. It does not explain critical aspects like the full resource requirement, fingerprint usage for concurrency, or what the response contains. Incomplete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description repeats schema info about bodyJson and does not add new semantics beyond what properties already convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and resource 'existing GTM client', with a '[WRITE]' prefix that distinguishes it from read-only tools. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating an existing client but does not explicitly contrast with related siblings like clients_create or clients_delete. It provides important prerequisites but lacks 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that the operation is destructive and requires a feature flag and confirm parameter, but lacks details on reversibility, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus bracket prefix) with no wasted words. While efficient, it could benefit from a slightly more structured format (e.g., listing requirements separately).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with 4 well-documented parameters and no output schema, the description covers the essential prerequisites but lacks details on success/error behavior or permissions, which would be helpful given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond what the schema provides, resulting in baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a GTM environment' with the HTTP method [DELETE], providing a specific verb and resource. Among sibling environments_* tools, only this one performs deletion, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisites (GTM_MCP_ENABLE_DELETES=true and confirm=true) but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or context for 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful information about automatic pagination ('Automatically follows pagination to return all entities'), but it does not disclose read-only nature, required permissions, or output format. The pagination detail is a positive, but overall disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the primary action and entity types, then add the pagination behavior. Every word adds value, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 required parameters, no annotations, no output schema, and only 33% schema coverage, the description is moderately complete. It covers the core action and pagination, but lacks parameter context, return value structure, and permission requirements. It is acceptable for a simple list operation but leaves room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description does not explain any parameters. It mentions 'specific GTM folder' which implies folderId, but accountId, containerId, and workspaceId are left undocumented. maxPages and pageToken have schema descriptions, but the tool description does not provide additional meaning or compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List), the resource (entities: tags, triggers, variables), and the scope (within a specific GTM folder). This distinguishes it from sibling tools like tags_list, triggers_list, and variables_list, which list individual entity types without folder filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need all entity types within a folder, but it does not explicitly state when to use it versus alternatives, nor does it mention exclusions or prerequisites. The context is clear enough for a basic understanding, but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure. It indicates the tool is destructive and requires a confirmation flag, but does not mention permanence, permissions, or side effects beyond deletion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that includes a category prefix and key requirements. It is concise and front-loaded, with no wasted language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with no output schema, the description covers purpose and prerequisites. However, it could include that the action is irreversible or mention the confirmation parameter more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description does not add additional meaning beyond what the schema already provides. The baseline of 3 applies because the schema fully documents both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'Search Ads 360 link', and the prefix '[GA4 DELETE]' reinforces the action. It distinguishes the tool from sibling tools by specifying the exact link type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists the required conditions: 'Requires GA4_MCP_ENABLE_DELETES=true and confirm=true.' This tells the agent when the tool is usable, though it does not mention alternatives or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is 'Read-only' and mentions the API version ('Admin API v1alpha surface'). With no annotations provided, these behavioral traits are valuable, but the description lacks details on authentication needs, rate limits, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loading the main purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately lists the types of settings retrieved (scrolls, outbound clicks, etc.) and states it is read-only and web-only. It could mention the return format or structure but is still fairly complete for a getter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the two parameters. The description does not add further semantic details beyond mentioning the tool is for web streams, which is a condition, not a parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'enhanced measurement settings', and specifies it is for WEB data streams. It lists examples of settings retrieved. While it distinguishes from a potential sibling like ga4_update_enhanced_measurement, it does not explicitly differentiate from other getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading enhanced measurement settings and notes the constraint 'Only valid for web streams'. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternative tools for other data stream types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states that the tool deletes (which is already implied) and requires confirmation, but fails to mention irreversible consequences, side effects, or whether the deletion is permanent, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only two short clauses. It efficiently conveys the action and a key requirement, but the brevity sacrifices completeness. Every component earns its place, though more detail could be included without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with 5 required parameters and no output schema, the description covers the bare minimum: what it does and a prerequisite. It does not describe return behavior or implications (e.g., permanent removal), leaving the agent to infer context from the parameter schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add any meaning beyond the schema; it only references the confirm parameter indirectly. No additional semantics for accountId, containerId, workspaceId, or transformationId are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'a GTM transformation', making the tool's purpose unmistakable. It implicitly distinguishes from sibling tools like transformations_get or transformations_revert by specifying deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists two prerequisites (environment variable and confirm parameter), guiding when the tool can be used. However, it does not state when to avoid using this tool or compare it to alternatives like transformations_revert for undo operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the operation is a write requiring confirmation, implying it is potentially destructive. However, it does not detail other behavioral traits like effects on other entities or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence with a [WRITE] prefix to immediately signal the operation type. Every phrase is purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description is too brief. It omits any mention of return values, the role of the 'fingerprint' parameter, and does not compensate for the absence of annotation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are already described in the schema with 100% coverage, so the description adds minimal value by reiterating the confirm requirement. It does not enhance understanding of other parameters like fingerprint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('revert') and resource ('GTM transformation'), and distinguishes it from sibling tools like transformations_update or transformations_delete by specifying the revert operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (when to revert) and prerequisites (GTM_MCP_ENABLE_WRITES=true, confirm=true), but does not explicitly exclude alternatives or advise when not to use this tool compared to other transformations tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions automatic pagination but does not disclose truncation behavior (maxPages default and truncation flag) or permissions. The schema covers pagination details, but the description omits them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, first states purpose, second adds key behavior. No extraneous words, front-loaded with core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description covers purpose and pagination but lacks parameter details and output format. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 40% (only maxPages and pageToken described). The description adds no semantic meaning to the required parameters (accountId, containerId, workspaceId), leaving them undocumented. The tool's name implies workspace but not account/container.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all user-defined GTM variables in a workspace, distinguishing it from sibling tools like variables_get (single variable) and variables_create. The scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing all variables due to automatic pagination, but lacks explicit when-to-use vs alternatives, such as comparing to variables_get or built_in_variables_list. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It explains the wrapping of the entity body in an envelope and the confirm parameter, but does not detail success/failure outcomes, side effects, or destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise yet informative: three sentences covering purpose, wrapping mechanism, and a cautionary note. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, 7 required, no output schema), the description provides key behavioral context but lacks information on error handling, return values, and post-conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds value by clarifying the entityJson parameter expects raw entity body (not envelope) and the confirm parameter must be true. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves a merge conflict for a workspace entity, using a specific verb and resource. It distinguishes from other workspace tools like workspace_get_status and workspace_sync by focusing on conflict resolution, but does not explicitly compare to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises reviewing the GTM UI first, implying complex usage and a prerequisite. However, it lacks explicit guidance on when not to use the tool or alternatives for conflict resolution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses that the tool is a write operation and requires a confirmation parameter, which is good. However, it does not discuss rate limits, error behaviors, or idempotency, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a brief note about requirements. It is front-loaded with the action and includes only necessary information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a creation tool with no output schema. It does not explain the expected structure of the JSON body or what the response contains. Missing guidance on the zone resource format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already described. The description adds no new semantic information beyond what the schema provides (e.g., it repeats 'bodyJson' as a JSON string). The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new GTM zone' with a specific verb and resource. It distinguishes from sibling tools like zones_list or zones_update by explicitly indicating creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisites (GTM_MCP_ENABLE_WRITES=true and confirm=true) but provides no explicit guidance on when to use this tool versus alternatives like zones_update or zones_delete. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must disclose behavioral traits like side effects (discarding workspace changes) or permissions, but only states it's a write operation requiring confirmation. No mention of return value, destructiveness, or user permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence plus requirement line with zero wasted words. Properly front-loaded with [WRITE] tag.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with no output schema and no annotations, the description should explain the return format or success/error behavior. It only covers prerequisites, not expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds no additional meaning beyond the schema; baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the verb 'revert' on the resource 'GTM zone', distinguishing it from update and delete siblings. The [WRITE] tag further clarifies it's a write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly lists prerequisites (GTM_MCP_ENABLE_WRITES=true, confirm=true) for use, but does not mention when to avoid this tool or suggest alternatives like zones_update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly states it's a read-only operation and never modifies anything, which is good. However, it omits details like authentication needs or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that efficiently convey the tool's purpose and key behavior. No superfluous information, and the read-only note is placed prominently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations. The description gives a high-level purpose but lacks details about the output structure, what specific issues are checked, or how the results are formatted. Agents may not know what to expect from the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only includeInfo has a description). The description does not explain accountId, containerId, or workspaceId, forcing agents to infer from names. With low coverage, the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it inspects a GTM workspace for analytics implementation issues and returns structured findings with severity levels. It distinguishes itself from sibling tools like workspace_get_status and other read-only tools by focusing on auditing common issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It describes when to use (to inspect for analytics issues) and declares it's read-only, but does not explicitly mention when not to use or suggest alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only flags write operation and required flags but omits behavioral details like idempotency, error cases, or effects of relinking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with a clear [WRITE] tag front-loaded; no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers requirements but lacks details on success behavior, error handling, or how to obtain destinationId; adequate for a simple mutation but could be richer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 4 of 5 params; description adds example for destinationId and reinforces confirm flag, but leaves allowUserPermissionFeatureUpdate unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies verb 'Link' and resource 'destination to GTM container', clarifying it's a write operation distinct from read siblings like destinations_get and destinations_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisites (GTM_MCP_ENABLE_WRITES=true and confirm=true), though it doesn't mention when not to use or alternatives for reading links.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only labels the operation as a WRITE and mentions prerequisites, but fails to describe side effects, idempotency, error conditions, or what happens on success. This is insufficient for a mutation tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is immediate and to the point, with a clear tag upfront. It contains no fluff and efficiently conveys the core purpose and key requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no output schema, and no annotations, the description is minimal. It covers the basic purpose and requirement but does not explain parameter dependencies (e.g., which parameters apply to which stream type) or describe the response format. Context is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 88%, so the schema already documents most parameters well. The description adds value by listing the supported stream types (web, Android, iOS) and reiterating the confirm requirement, but does not provide new parameter semantics beyond what the schema offers. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create a data stream' with the specific resources web, Android, and iOS, clearly defining the tool's action and target. The [GA4 WRITE] tag further clarifies the operation type, and the tool name itself distinguishes it from sibling tools like ga4_update_data_stream and ga4_delete_data_stream.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes clear prerequisites: 'Requires GA4_MCP_ENABLE_WRITES=true and confirm=true.' This tells the agent when the tool can be used. However, it does not explicitly mention when not to use it (e.g., for updates) or list alternative tools, though the sibling list provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates a write operation and a confirmation requirement, but lacks details on side effects, idempotency, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys key information (write operation, requirements, body content). It is concise and front-loaded, but could be slightly more structured with separate sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is missing details about return values (no output schema), and does not explain that body is effectively required despite not being marked required in schema. It also lacks context about the effect of the filter on the subproperty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by specifying 'applyToProperty + filterClauses via body', which provides practical guidance beyond the raw schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create', resource 'subproperty event filter', and context 'GA4 360'. It distinguishes from sibling tools like ga4_update_subproperty_event_filter and ga4_delete_subproperty_event_filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisites (ENABLE_WRITES=true, confirm=true) and what to supply via body. However, it does not explicitly state when to use this tool versus alternatives 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present. The description warns about required confirm flag and environment variable, implying destructive nature, but lacks details on outcomes, reversibility, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences: states purpose and critical usage condition. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation, the description is adequate but lacks return value info and error handling. Given no output schema, more detail could help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents parameters. The description adds no extra meaning beyond the tool's purpose and requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes an AdSense link, with a distinct verb-resource pair and requirement info. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes prerequisites (env var and confirm=true) but does not provide guidance on when to use this tool versus alternatives like creating or updating links, nor any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It indicates a write operation and a confirmation requirement, but does not discuss reversibility, side effects, or rate limits. It discloses the mutating nature but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and ending with requirements. Every sentence is informative, no fluff. It is 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters (4 enums) and no output schema, the description covers the main purpose and requirements but does not explain parameter optionality, default behaviors, or what the response contains. It is adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33%, so the description needs to compensate. It lists categories like 'reporting model, acquisition/other conversion lookback windows, and the Ads web-conversion export scope,' which map to parameters but add no detail on allowed enum values or parameter interactions. This is helpful but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool updates a property's attribution settings, listing specific aspects like reporting model, lookback windows, and export scope. The '[GA4 WRITE]' prefix distinguishes it from read-only tools, and among sibling tools like ga4_update_property or ga4_update_data_retention, this tool's focus on attribution is unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions requirements (GA4_MCP_ENABLE_WRITES=true, confirm=true) but provides no explicit guidance on when to use this tool versus alternatives like ga4_update_property or when not to use it. The purpose is clear, but usage context is limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses write operation with GA4 tag and allowed retention values (including 360-only constraint). With no annotations, description carries burden but lacks details on side effects, permissions, or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with parenthetical specifics, front-loaded action, no fluff. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core behavior and constraints, but omits explanation of confirm parameter's necessity and return value. Could include note that confirm must be true to proceed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds context for eventDataRetention (enum durations in months) and resetUserDataOnNewActivity flag. Schema coverage is 25% (only property described), so description compensates partially; but confirm and property are not further elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action: 'Update a property's event data retention' with explicit values (2/14/26/38/50 months) and reset flag. Distinguishes from siblings like ga4_data_retention_get and other ga4_update_* tools by naming and constraint details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes prerequisites (writes enabled, confirm=true) but does not specify when to prefer alternatives (e.g., ga4_data_retention_get for reads) or mention non-use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the write nature and required confirmation, but does not mention side effects, return value, or idempotency. The behavior is partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. The [WRITE] prefix immediately conveys the operation type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 required params, no output schema, no annotations), the description lacks details on the expected resource structure beyond a generic JSON string. It does not explain what a 'template' resource consists of or what the response will be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds only marginal value by reiterating that bodyJson should be a JSON string containing the full resource. Other parameters are standard IDs with sufficient schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new GTM template' with a specific verb and resource. The [WRITE] prefix further distinguishes it from read-only siblings like templates_list and templates_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the prerequisites (GTM_MCP_ENABLE_WRITES=true and confirm=true) but does not provide guidance on when to use this tool versus templates_update or templates_delete. No comparison to siblings is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the write nature via [WRITE] and the confirm requirement, but does not mention irreversibility, error behavior, success response, or other side effects. This is useful but limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with [WRITE], and every word earns its place. No wasted text or redundant restating of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 19-parameter write tool with no output schema and no annotations, the description is quite thin. It gives a prerequisite but no guidance on parameter selection, expected results, or failure modes. The schema provides substantial detail, but the description leaves the agent without high-level usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond the schema. Schema coverage is 68% with detailed descriptions for most meaningful fields (e.g., filter, parameter, interval), but ID fields and confirm lack descriptions. Since coverage is moderate and the description is silent, it neither compensates nor repeats schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a GTM trigger' with a specific verb and resource, distinguishing it from sibling tools like triggers_update, triggers_get, and triggers_delete. The [WRITE] marker further clarifies its mutation nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite (GTM_MCP_ENABLE_WRITES=true and confirm=true) but does not explicitly state when to use this tool vs alternatives like triggers_update for existing triggers. Usage context is implied by the resource name rather than explicitly described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It identifies the tool as a write operation and lists prerequisites, but does not detail the revert behavior (e.g., overwriting, reversibility, or side effects). This is adequate but could be more comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. Action is front-loaded, prerequisites follow. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 required params, a destructive write, and no output schema, the description covers purpose and prerequisites but lacks parameter details and fuller behavioral context. It is minimally complete but has notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'type' described). The description mentions 'confirm' but not the other four parameters. It adds some meaning for confirm (requires true) but insufficiently compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reverts changes to a built-in variable, specifying the action and resource. It distinguishes from siblings like list, enable, disable through the revert action and write indicator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions prerequisites (GTM_MCP_ENABLE_WRITES=true, confirm=true) and implies when to use (when reverting built-in variable changes). However, it does not explicitly state when not to use or mention alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It discloses the write operation, needed permission (analytics.manage.users), and required flags (writes enabled, confirm). However, it does not describe idempotency, error behavior, or what happens if binding already exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence with three clauses, front-loading the core action and then providing essential prerequisites. No wasted words; every part is meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 required params, no output schema, and no annotations, the description covers the write nature, permissions, and confirm flag. But it omits response format, success/failure signals, and doesn't explain the 'user' or 'roles' parameters. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (accountId and confirm have descriptions; user and roles do not). The description does not add any extra meaning beyond the schema, missing the opportunity to clarify 'user' format or valid 'roles' values. It fails to compensate for the uncovered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with '[GA4 WRITE] Grant a user access to a GA4 account', providing specific verb (Grant), resource (user access), and scope (GA4 account). This clearly distinguishes it from sibling tools like ga4_create_property_access_binding which operate at property level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description states prerequisites: 'Requires GA4_MCP_ENABLE_WRITES=true and confirm=true.' This gives explicit context for when to use, but lacks direct exclusions or alternatives compared to other access binding tools. The confirm parameter is highlighted as a required safety mechanism.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry behavioral disclosure. It declares write operation and required conditions but omits details on side effects, error states, or return values. Minimal but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear structure: action verb, resource, and requirements. Front-loaded with write indicator. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should address expected return. It does not mention what the tool returns after creation. For a write tool with moderate complexity, coverage is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add meaning beyond schema; it repeats the confirm requirement already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action 'Create' and resource 'AdSense link'. Explicitly notes 'no update', distinguishing from potential update operations. Siblings include ga4_delete_adsense_link, so create vs delete is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides prerequisites (GA4_MCP_ENABLE_WRITES=true and confirm=true) needed to use the tool. No explicit when-to-use vs alternatives, but given no update sibling exists, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates this is a write operation ('[GA4 WRITE]') and requires explicit confirmation ('confirm=true'). However, it does not disclose what happens on success/failure, whether the operation is idempotent, or any rate limits. The confirmation requirement adds transparency but more context could be given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and crucial requirements. No redundant words. It could include a brief note on return value but remains efficient for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with no output schema and well-documented parameters, the description covers the key prerequisites. However, it lacks information about expected output, error scenarios (e.g., duplicate link), or required permissions beyond the environment variable. Given the complexity (4 parameters, no output schema), it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 of 4 parameters documented). The tool description repeats the confirmation requirement but adds no new parameter-specific information beyond the schema. Since the schema already covers most parameters, the description adds minimal value here. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'a Google Ads link'. The prefix '[GA4 WRITE]' distinguishes it as a write operation. It differentiates from sibling tools like ga4_update_google_ads_link and ga4_delete_google_ads_link by specifying creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions prerequisites: 'Requires GA4_MCP_ENABLE_WRITES=true and confirm=true.' This tells the agent when to use it (when writes are enabled and confirmation is provided). However, it lacks explicit guidance on alternatives or when not to use this tool (e.g., if link already exists, use update instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the response contains a secretValue to store securely and that confirm must be true to apply changes. However, it lacks details on authorization requirements, rate limits, or side effects beyond creating the secret.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence followed by a critical note. It front-loads the purpose and uses explicit tags like '[GA4 WRITE]'. Every word serves a purpose; there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description compensates by mentioning the secretValue and its sensitivity. It also covers prerequisites and the confirm flag. However, it omits error scenarios or response structure beyond the secret value, leaving some gaps for a complex operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with detailed descriptions for each parameter. The description adds minimal extra: only the security note about the secret in the response. Since the schema does the heavy lifting, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('Measurement Protocol secret') with context ('on a data stream'). It uses '[GA4 WRITE]' to signal the operation type. However, it does not differentiate from numerous sibling ga4_create_* tools, leaving potential ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states required prerequisites: 'GA4_MCP_ENABLE_WRITES=true and confirm=true'. This helps the agent decide when invocation is valid. There is no discussion of alternatives or when not to use the tool, but the specificity of the use case reduces ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the write nature and required conditions, but does not detail potential errors, side effects, idempotency, rate limits, or return values. It is somewhat transparent but lacking depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys purpose and prerequisites efficiently. It is front-loaded and concise, though it could be expanded slightly without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a write operation with 6 parameters and no output schema, the description covers the essentials but omits response format, post-creation behavior, and parameter details beyond prerequisites. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% with most parameters described. The description reinforces 'confirm=true' but does not add new information beyond the schema. Baseline is 3 for high coverage; description adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new GA4 property under an account.' This is a specific verb+resource pair, and the sibling list includes distinct tools like ga4_delete_property, ga4_update_property, and other ga4_create_* tools, so it differentiates well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists prerequisites: 'Requires GA4_MCP_ENABLE_WRITES=true and confirm=true.' This guides the agent on when the tool is usable. However, it does not mention when not to use it or provide direct alternatives, but the prerequisites are actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states it's a write operation and requires a confirmation flag, implying potential destructiveness. However, it does not disclose what happens on success (e.g., overwriting existing bindings) or other behavioral aspects like rate limits or notifications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with key information front-loaded via the bracketed '[GA4 WRITE]' tag. It is concise and includes critical prerequisites without extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 required parameters and no output schema, the description covers the basic purpose and prerequisites. However, it lacks details about return values, error handling, and behavioral specifics, leaving gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds context about required flags but does not elaborate on individual parameter semantics beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with '[GA4 WRITE] Grant a user access to a GA4 property', clearly identifying the action (grant) and resource (user access to GA4 property). This distinguishes it from sibling tools like ga4_delete_property_access_binding and ga4_update_property_access_binding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides necessary prerequisites: required scope (analytics.manage.users), and the need to set GA4_MCP_ENABLE_WRITES=true and confirm=true. It clearly implies when to use this tool (granting access), but does not explicitly mention when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It explains the write nature and partial update behavior (via updateMask derivation) and required env var/confirmation. But it lacks details on side effects, error handling, idempotency, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, then usage details. Every sentence adds value with no redundancy. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage pattern, and requirements, but lacks return value description (no output schema) and handling of body vs flat fields interaction. Adequate for a moderately complex tool but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 57%; the description adds meaning by listing changable fields (formula/displayName/unit), explaining update mask logic, and noting that 'body' is for advanced fields. This compensates for undocumented schema parameters, though it doesn't detail format or allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates a calculated metric, listing specific fields (formula/displayName/unit) and indicating it's a write operation with '[GA4 WRITE]'. It distinguishes from create/delete siblings by using 'update' and listing modifiable attributes, but does not explicitly contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance: 'Pass only the fields to change; updateMask is derived from them' and mentions prerequisites ('GA4_MCP_ENABLE_WRITES=true and confirm=true'). However, it does not explicitly state when not to use this tool or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses it is a WRITE operation and lists affected toggles, but does not explain side effects (e.g., what happens to unmentioned settings), required permissions, or confirm semantics beyond 'must be true'. Limited behavioral detail beyond basic intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with a requirement line. No wasted words, efficiently conveys purpose and prerequisites. Ideal conciseness for a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, no output schema, no annotations), the description is too brief. It omits crucial details: update semantics (partial vs full overlay), return values, error cases, and validation of data stream type. Lacks completeness for a safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (31%), requiring the description to compensate. The description groups toggles and mentions 'site search + query params' correlating to parameters, but does not explain each parameter individually or clarify update semantics (PATCH vs PUT). Adds some semantic value but not enough to fully compensate for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it updates Enhanced Measurement for a WEB data stream, listing specific toggles (scrolls, outbound clicks, etc.). It distinguishes itself from siblings like ga4_enhanced_measurement_get (read-only) and other GA4 update tools by specifying the exact resource and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states preconditions: requires GA4_MCP_ENABLE_WRITES=true and confirm=true. It provides context that this is a write operation, but does not explicitly compare to siblings or state when not to use it (e.g., read-only use case). The context is sufficient but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it is a write operation, requires permissions, and describes updateMask derivation behavior. However, no details on success/failure, idempotency, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with [GA4 WRITE], and conveys essential usage and constraints in two sentences with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites and updateMask behavior well, but omits return value/response format and error handling, which is important for a write operation with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 75% of parameters with descriptions, but the 'roles' parameter lacks both schema description and any hint in the tool description about valid roles (e.g., accepted values). The description does not compensate for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it changes a user's roles on a property via GA4 WRITE, matching the tool name and distinguishing it from related tools like create/delete access bindings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies required permissions (analytics.manage.users), required configuration (GA4_MCP_ENABLE_WRITES=true, confirm=true), and provides guidance on using updateMask. Lacks explicit exclusion of alternatives like delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this is a write operation and requires confirmation and an environment flag, which is useful. However, it does not mention side effects (e.g., tag created in draft state, needing publishing) or what the API returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a clear [WRITE] marker, making it efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters, no output schema, and no annotations, the description is too sparse. It omits important context like the need to publish the tag after creation and possible behavior of nested parameters, leaving the agent to rely entirely on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with detailed parameter descriptions, including a complex example for the 'parameter' field. The description adds only a generic instruction to pass the full tag configuration, so it doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new GTM tag' with a [WRITE] prefix, using a specific verb and resource. It distinguishes from sibling tools like tags_update and tags_delete by explicitly targeting creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It notes the prerequisite GTM_MCP_ENABLE_WRITES=true and confirm=true, which is clear context for when the tool can be used. However, it does not explicitly discuss alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the destructive nature (DELETE), environment requirement, and the 'cannot delete live' rule. However, it does not mention what happens to associated entities or if the deletion is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The first sentence states the purpose, the second provides constraints. All content is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 required params, no output schema, and no annotations, the description covers prerequisites and a constraint but lacks details on return behavior, error handling, or how to obtain version IDs. It is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains the 'confirm' parameter (must be true) and hints at 'containerVersionId' as the version to delete. It fails to explain 'accountId' and 'containerId', leaving ambiguity for agents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'GTM container version', with a [DELETE] prefix for HTTP method. This distinguishes it from sibling tools like versions_publish and versions_undelete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites: requires GTM_MCP_ENABLE_DELETES=true and confirm=true, and warns that live versions cannot be deleted. It does not, however, explicitly state when to use this tool instead of alternatives like versions_undelete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses automatic pagination behavior, which is useful. However, it does not mention other traits like read-only nature, authentication requirements, or rate limits. The single behavioral trait prevents a lower score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no unnecessary words. The key information is front-loaded: verb, resource, scope, and pagination behavior. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description adequately conveys the main function and pagination handling. It could mention that results include a workspaces array, but the simplicity of the operation keeps the information reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description's mention of automatic pagination aligns with the maxPages parameter but does not add new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'workspaces', and the scope 'within a GTM container'. It distinguishes from sibling tools like workspaces_create and workspaces_get by focusing on listing all workspaces with automatic pagination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a full list of workspaces is needed, but does not explicitly state when to use this tool versus alternatives like workspaces_get or workspace_sync. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the action (updating unmodified entities) and return value (merge conflicts), but omits details like whether modified entities are skipped, permissions required, or reversibility. The confirm parameter is in schema but not mentioned in description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. It front-loads the action and quickly covers scope and return value. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 required params, no output schema, and lack of annotations, the description adequately covers the tool's purpose and outcome. It mentions return value, scope (unmodified entities), and the sync action. Minor gaps: no mention of prerequisites or error conditions, but generally complete for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond what is in the schema; it does not explain parameter values or usage beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Syncs' and clearly identifies the resource (workspace) and scope (to latest container version, updating only unmodified entities). It also states the return value (merge conflicts), which distinguishes it from sibling tools like workspace_get_status or workspace_resolve_conflict.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for syncing a workspace to the latest version but does not provide explicit guidance on when to use this tool versus alternatives. No when-not or alternative tool mentions are present, leaving the agent to infer context from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden. It notes that deletion requires a feature flag and confirmation, but does not mention the irreversible nature of deletion or any side effects. This is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a one-liner with a bracketed prefix. It front-loads the action and includes key requirements. It is efficient, though slightly sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 required parameters and no output schema, the description covers the essential prerequisites but lacks details about the response or post-deletion state. For a simple delete operation, it is functional but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add any additional meaning beyond the schema's parameter descriptions. It mentions the confirm parameter implicitly but provides no extra semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with '[DELETE]' and states 'Delete a GTM zone', clearly specifying the verb and resource. It distinguishes from sibling tools like zones_list, zones_get, zones_create, zones_update, and zones_revert by focusing on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes prerequisites: 'Requires GTM_MCP_ENABLE_DELETES=true and confirm=true', guiding when the tool can be used. It does not explicitly state when to use it over alternatives, but the conditions are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the DELETE operation, required feature flag, and confirm parameter. However, it lacks details on side effects, reversibility, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a crucial prerequisite note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description covers the core action and preconditions. It could be more complete by describing the effect of disabling variables, but it is sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% (only 'types' has a description). The description adds minimal parameter insight beyond confirming the 'confirm' flag. Other parameters (accountId, containerId, workspaceId) are left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Disable'), the resource ('built-in variables in a GTM workspace'), and includes a precondition note. It distinguishes from siblings like built_in_variables_enable and built_in_variables_revert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to disable built-in variables) and mentions prerequisites (GTM_MCP_ENABLE_DELETES and confirm). However, it does not explicitly state when not to use it 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description attempts to disclose behavioral traits by marking it as [WRITE] and warning with a hazard symbol, but it does not explain the full impact (e.g., whether the source container is deleted or remains) or required permissions beyond the environment variable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two clear, front-loaded sentences that convey the action, requirements, and a warning without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a merge operation and no output schema, the description lacks details on post-merge behavior (e.g., what happens to the source container, how conflicting settings are resolved) and does not fully compensate for missing annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds little value beyond what the schema already provides. It mentions key parameters like containerIdToCombine and confirm but does not elaborate on settingSource or allowUserPermissionFeatureUpdate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('combine/merge'), the resource ('another container into this one'), and specifies the source and target by ID, distinguishing it from sibling tools like containers_create or containers_move_tag_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates prerequisites (requires GTM_MCP_ENABLE_WRITES=true and confirm=true) and provides a clear context for when to use the tool, but does not explicitly state when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses it's a write operation requiring confirmation but lacks details on side effects, response format, or permissions beyond the prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one line with action and requirement. The [WRITE] prefix front-loads important context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with 7 parameters and no output schema, the description could include what the response contains or link to retrieval tools like environments_get. Current description is minimal but not insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds no additional parameter information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Create' and resource 'GTM environment'. The [WRITE] prefix and name clearly distinguish from read tools like environments_get or update tools like environments_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisites (GTM_MCP_ENABLE_WRITES=true and confirm=true), guiding the agent on when to invoke. No mention of alternatives, but the resource-specific name makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It correctly flags the tool as a write operation and specifies required environment variables and confirmation. However, it does not disclose potential error conditions (e.g., if the source property is already linked) or whether the operation is idempotent, so transparency is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a requirement line. It front-loads the category '[GA4 WRITE]' and includes only essential information. Every word contributes to understanding, with no redundancy or extraneous details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters (including a nested body) and no output schema. The description covers the core purpose and key prerequisites but omits details about the 'body' parameter, error handling, or return behavior. While the schema fills some gaps, the description alone leaves an agent with incomplete operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all four parameters have descriptions). The description adds no additional meaning beyond the schema; it only mentions 'confirm' being required, which is already in the schema. Thus, the description provides no extra semantic value, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a source property to a rollup property'), identifies it as a GA4 WRITE operation, and specifies the scope (GA4 360). It distinguishes from the sibling 'ga4_delete_rollup_property_source_link' by mentioning 'no update', making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites ('Requires GA4_MCP_ENABLE_WRITES=true and confirm=true') and notes that the tool does not support updates, guiding the agent when to use it. It lacks explicit alternatives for modification, but since no update tool exists, this is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description bears full burden. It correctly flags deletion as destructive and states required conditions, but omits details like irreversibility or impact on other resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with a tag, front-loaded, no wasted words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete with two parameters and no output schema, description is adequate but lacks behavioral nuance (e.g., return value, consequences). Could elaborate on post-deletion effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. Description adds no extra meaning, merely restating confirm=true. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a calculated metric' using a specific verb and resource, distinguishing it from sibling create/update tools for the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists prerequisites (GA4_MCP_ENABLE_DELETES=true and confirm=true), telling when to use the tool. It does not mention when not to use it, but context from siblings clarifies its deletion-only role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the destructive nature ('delete') and the safety mechanism (confirm flag and config). However, it does not clarify irreversibility, permissions, or error states, which are relevant for a delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that includes all necessary elements: action, resource, and prerequisites. It is efficient and front-loaded with the action, leaving no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with two parameters, the description is adequate but lacks details on post-deletion behavior, error handling, or permissions. Given no output schema and no annotations, the description could provide more context to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add any parameter information beyond what the schema already provides, so it neither adds nor detracts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'event-create rule', distinguishing it from other sibling delete tools by specifying the exact resource type. The '[GA4 DELETE]' prefix and the prerequisite details add clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions the required environment variable and confirm parameter, providing clear context for usage. However, it does not discuss alternatives or when not to use this tool relative to other delete tools, though the resource name itself differentiates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses destructive nature, necessary configuration, and confirmation requirement. Lacks details on reversibility or cascading effects on related entities, but given simplicity, it is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with critical prerequisites in parentheses. Front-loaded purpose, but the bracket format could be cleaner. Efficiently conveys necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete action, the description covers purpose, permissions, configuration, and parameter requirement. No output schema is expected; context signals indicate low complexity, so completeness is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description repeats the parameter purpose without adding new semantics. Baseline score of 3 is appropriate as schema already describes parameters sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it revokes a user's access to a property, distinguishing it from other delete tools (e.g., ga4_delete_account, ga4_delete_property) by specifying the resource type (property access binding).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the required permission (analytics.manage.users), environment variable (GA4_MCP_ENABLE_DELETES=true), and confirmation flag (confirm=true). However, it does not provide 'when not to use' or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses it is a write operation requiring confirmation, but does not detail potential side effects, permissions, or whether the update is destructive or reversible. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence and a requirement statement. No filler words, every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not mention return value or success indication. For a simple update, it covers basic purpose and prerequisites but lacks completeness regarding outcome or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. The description adds meaning for 'displayName' and 'confirm' but omits 'accountId', which is self-explanatory. Provides some value beyond schema, but misses opportunity to clarify format or constraints for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates a GA4 account's displayName, with the tag '[GA4 WRITE]' and explicit mention of the field. It distinguishes from numerous sibling update tools targeting different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly requires GA4_MCP_ENABLE_WRITES=true and confirm=true, providing clear context for when to use. Does not explicitly state when not to use, but the specificity makes it unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses write operation, immutability constraints, and configuration requirements. No annotations provided, so description carries burden but omits side effects, auth beyond flags, and error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence with clear prefix [GA4 WRITE]. Every part adds necessary information; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key update behavior and prerequisites, but lacks return value description (no output schema) and error handling details. Adequate for experienced users but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (3 of 6 params described). Description adds value by explaining updateMask derivation and immutable fields, but does not elaborate on undocumented params (description, displayName, measurementUnit).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it updates a custom metric, distinguishes from create (sibling ga4_create_custom_metric) and archive. Specifies immutable fields, making purpose precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisites (GA4_MCP_ENABLE_WRITES=true, confirm=true) and updateMask derivation guidance. Lacks explicit when-not-to-use but context implies update vs. create/archive alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full burden. It explicitly states the destructive nature (delete) and the requirement for confirmation, signaling the need for caution. However, it does not discuss irreversibility or side effects, but the confirmation mechanism adds a layer of safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loading the HTTP method and action. Every word adds value; no redundant information. It fits in a single sentence without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action and prerequisites but lacks information about post-delete behavior, such as return values or error states. Since there is no output schema, additional context would help the agent understand what to expect after a successful deletion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described in the input schema. The description adds no additional detail about parameters; it only restates the confirmation requirement already in the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'GTM gtag config', making the purpose unambiguous. The '[DELETE]' prefix reinforces the action, and the tool name is self-explanatory, distinguishing it from sibling tools that operate on other entities 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisites 'GTM_MCP_ENABLE_DELETES=true and confirm=true', which is necessary but does not provide guidance on when to use this tool versus alternative delete tools for other GTM resources. No context on when not to use or comparison to siblings is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the write nature and confirm requirement, but does not disclose details like whether the update is full replacement (implied by 'full resource'), idempotency, or behavior of the fingerprint parameter. Some behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. The [WRITE] prefix immediately signals a mutation. Every sentence serves a purpose: action, prerequisites, and input format. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity (7 params), the description lacks details about return values or error handling. It covers prerequisites and input format but omits behavioral aftereffects. Adequate but not complete for a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema, just noting the full resource requirement for bodyJson. Other parameters are adequately described in the schema, so no deduction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing GTM gtag config, with verb 'update' and resource specified. Among sibling tools like gtag_config_create and gtag_config_delete, this is unambiguously distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states required conditions: GTM_MCP_ENABLE_WRITES=true and confirm=true. This gives clear guidance on when the tool can be used, though it does not explicitly mention 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions automatic pagination, which is a key behavior, but does not disclose read-only nature, potential resource usage, or other traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no unnecessary words, effectively front-loading the purpose and key behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and pagination but does not mention the expected output format (e.g., array of tag objects) since there is no output schema. This is a minor gap for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing a baseline of 3. The description adds value by explaining automatic pagination, which clarifies the purpose of pageToken and maxPages parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all GTM tags in a workspace, distinguishing it from sibling tools like tags_get (single tag) and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all tags but does not provide explicit guidance on when to use this tool versus alternatives like tags_get or other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description identifies the operation as a write ([WRITE]) and mentions the revert action. However, it does not elaborate on behavioral traits such as whether the operation is irreversible, what permissions are needed, or the effect on concurrent edits. The fingerprint parameter hints at optimistic locking but is not explained. With no annotations provided, the description could provide more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a requirement note. It is extremely concise, front-loads the action type [WRITE], and avoids any extraneous text. Every part serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters (5 required) and no output schema. The description explains the core operation and prerequisites but does not mention the return value (likely the reverted template or a success indicator) or how the fingerprint parameter is used for optimistic locking. Given the complexity, the description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds no additional parameter-specific information beyond what the schema already provides. It does not explain the purpose of confirm or fingerprint beyond the schema's own minidescriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '[WRITE] Revert workspace changes to a GTM template back to its last container-version state.' It identifies the specific action (revert), resource (template), and scope (workspace changes to container version). This distinguishes it from sibling revert tools like clients_revert or zones_revert which apply to different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies prerequisites: 'Requires GTM_MCP_ENABLE_WRITES=true and confirm=true.' This tells the agent when the tool can be invoked and the required confirm parameter. It does not explicitly mention when not to use it or compare to alternatives, but the context is clear enough for the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions prerequisites but does not explain whether updates are full replacement or partial, irreversible consequences, error handling, or authorization beyond the environment variable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Critical information is front-loaded: operation, resource, prerequisites, and input format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters (5 explicit), no output schema, and no annotations, the description covers the key points but omits details like fingerprint usage, return value, or error scenarios. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by specifying that bodyJson must contain the full resource as a JSON string, which goes beyond the schema description. This clarifies the update semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with '[WRITE] Update an existing GTM template,' clearly stating the verb and resource. It distinguishes from sibling templates_create, templates_get, templates_delete, templates_revert, and templates_list by focusing on update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is a write operation requiring GTM_MCP_ENABLE_WRITES=true and confirm=true. It does not explicitly state when not to use it or list alternatives, but the write and confirm flags give sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a write operation and requires confirm=true, but does not explain whether permissions are appended or overwritten, or what happens to existing user permissions. More detail on behavioral impact would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys core information. It is front-loaded with '[WRITE]' for immediate recognition, and every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and no output schema, the description is adequate but incomplete. It covers the basic purpose and a key requirement, but does not explain the interplay between account-level and container-level permissions, nor specify the response format. More detail would help an agent understand the full scope of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add parameter-specific meaning beyond what the schema provides. It references confirm as a prerequisite but doesn't elaborate on accountPermission or containerAccess semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Grant' and the resource 'user access to a GTM account (and optionally containers)', immediately distinguishing it from sibling tools like user_permissions_get/update/delete. The prefix '[WRITE]' further clarifies the action type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies prerequisites (GTM_MCP_ENABLE_WRITES=true and confirm=true), providing clear context for when to use this tool. However, it does not explicitly exclude use cases or mention alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It implies a read-only operation ('Get'), but does not explicitly state side-effects or permissions. The behavioral disclosure is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and an immediate usage tip. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with 3 string parameters and no output schema, the description is adequate. It specifies the input parameters concisely and adds a useful tip. Lacks details on return shape or error conditions, but these are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33% (only containerVersionId has a description). The tool description adds value for containerVersionId by repeating the special 'live' hint, but accountId and containerId remain undocumented. Description does not compensate for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get' and the resource 'full contents of a specific GTM container version', distinguishing it from sibling tools like versions_list or versions_delete. The special value 'live' is explicitly mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on using 'live' as containerVersionId for the current live version. Does not explicitly state when not to use or compare with alternatives, but the context is sufficient for a simple retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It mentions it enables preview mode without publishing and returns errors, but does not cover side effects (e.g., whether preview persists, impacts other users), idempotency, or required permissions. Adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key information, no redundancy. Every sentence adds value: purpose, non-publish behavior, and return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions return value (preview container version and compilation errors), which is sufficient. It could clarify that the link is part of the response, but for a simple tool this is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no meaning to the three required parameters (accountId, containerId, workspaceId). It does not explain their purpose, format, or valid values, forcing the agent to rely solely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a quick-preview link for a GTM workspace, explicitly distinguishing it from publishing. It specifies a specific verb (generate) and resource (preview link), which differentiates it from sibling workspace tools like workspace_get_status or workspace_sync.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it does NOT publish, telling the agent when to use this tool (for preview mode) and when not (for actual publishing). It lacks explicit alternative references, but the clear purpose and limitation provide adequate usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a write operation and requires confirm and an environment variable. However, it does not mention side effects, idempotency, or the optimistic locking mechanism involving the fingerprint parameter, which is a behavioral aspect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the operation type, and each sentence adds essential information: what it does, prerequisites, and how to pass data. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain return values or error handling. For an update tool, agents may need to know if the updated resource is returned. The description covers basic usage but lacks return and error context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by specifying that bodyJson should contain the full resource as a JSON string, which reinforces the schema. It does not add meaning to other parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '[WRITE] Update an existing GTM zone' with a specific verb and resource. It distinguishes from sibling tools like zones_create, zones_delete, and zones_read tools, as 'update' is unique among zones operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states prerequisites: 'Requires GTM_MCP_ENABLE_WRITES=true and confirm=true.' This tells the agent when the tool is usable. It implies it should be used for updating an existing zone, not for creating or deleting, though it does not explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It adds write context and prerequisites, but does not disclose destructive nature, scope of reverted changes, or handling of fingerprint parameter. Lacks details about what exactly gets reverted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first describes action and resource, second states prerequisites. No fluff, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides high-level purpose and prerequisites. Lacks details about return value (no output schema) and potential failure conditions. However, given the simple parameter set and no nested objects, it is mostly adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 6 parameters. The description adds no additional parameter-level info beyond the schema, hence baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'revert' and resource 'GTM client', and clearly distinguishes from other revert tools for different entities (e.g., built_in_variables_revert, templates_revert). The '[WRITE]' prefix further clarifies the operation type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisites: GTM_MCP_ENABLE_WRITES=true and confirm=true. It implies the tool is for undoing client workspace changes, but does not compare with alternatives like clients_update or other revert tools for different entities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description proactively discloses automatic pagination handling ('Automatically follows pagination to return all containers'), which is a key behavioral trait beyond the input schema. With no annotations, this adds significant transparency about expected behavior and limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, each essential. The first states the core purpose, the second adds a critical behavioral detail. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 3 parameters and no output schema, the description covers the main function and pagination behavior. It could mention the output structure or field set, but overall it is sufficiently complete given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains each parameter (accountId, maxPages, pageToken). The description adds no additional meaning beyond what is in the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all GTM containers within a GTM account' with a specific verb ('list'), resource ('containers'), and scope ('within a GTM account'). It distinguishes from sibling tools like containers_get or containers_create by focusing on listing all containers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all containers in an account but lacks explicit guidance on when not to use it or comparison with alternatives like containers_lookup or containers_get. No exclusions or context-switching cues are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden and explicitly states 'This is a read-only operation', which is a key behavioral disclosure. It also describes what is returned, but does not mention pagination or potential truncation, though the schema's maxPages description covers some of that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, return contents, and use cases. No fluff, every sentence adds value, and key info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a solid overview of purpose, output, and read-only nature, but lacks details about the JSON structure, truncation semantics, or pagination behavior. The schema partially covers maxPages, but without an output schema or annotations, the description could provide more complete guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, and the description adds no parameter context. The required IDs (accountId, containerId, workspaceId) have no documentation in either schema or description. The format and maxPages parameters are explained in the schema, but the description doesn't compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Export'), resource ('full GTM workspace summary'), and output ('structured JSON'), listing all included components (tags, triggers, variables, folders, built-in variables). This distinguishes it from sibling list/get tools that target individual entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases ('documentation, auditing, or feeding container data to other tools') that imply when to use this tool. However, it does not explicitly compare to alternatives like containers_get or audit_container, nor state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It correctly identifies the tool as read-only and provides a 'lightweight' hint about the response. However, it does not disclose potential rate limits, the exact structure of the account summary, or any other behavioral traits beyond what the schema already implies about pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences and a 'Read-only' label. It front-loads the main action and purpose, with no redundant information. Every sentence serves a clear function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 adequately explains the return value: account plus property summaries with IDs and display names. This is sufficient for an agent to understand the response. However, it could be slightly more explicit about the structure of the account part.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its two parameters (maxPages, pageToken). The tool description does not add any additional meaning or context about these parameters, so it meets the baseline expectation without extra contribution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists GA4 account summaries accessible to the user, specifying the content (account + lightweight property summaries with ID and display name). It distinguishes itself as the best starting point for discovering accounts and properties, setting it apart from sibling tools like ga4_properties_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by stating it is the 'best starting point to discover available GA4 accounts and properties.' It also marks the tool as read-only. However, it does not explicitly mention when not to use it or list alternative tools for more detailed property information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that archiving is effectively permanent and irreversible. However, it does not describe side effects on related data or whether the audience is entirely removed from reports. The mention of 'stops collection' is helpful but lacks depth for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver all essential information: purpose, permanence, prerequisites. No extraneous text. The [GA4 DELETE] prefix clearly signals it is a destructive operation. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two required parameters and no output schema, the description covers purpose, permanence, and configuration needs. It does not explain the response or further effects, but the simplicity of the operation makes this acceptable. Slightly better completeness would address what happens to the audience data after archiving.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The tool description reinforces that confirm must be true and that name is a resource name, but adds no new detail beyond schema. Baseline 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool archives an audience, stopping collection, and emphasizes permanence. The verb 'archive' distinguishes it from delete tools like ga4_delete_property, and the parenthetical 'no un-archive' sets clear expectations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly requires GA4_MCP_ENABLE_DELETES=true and confirm=true, giving clear prerequisites. It does not list alternative tools for un-archiving, but the permanent nature inherently advises caution. Could be improved by stating when not to use (e.g., if re-activation might be needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool is a write operation and requires confirmation, but does not mention idempotency, side effects, or error behavior. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and body guidance, then prerequisites. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of creating an audience with nested filterClauses, the description provides essential context (write, confirmation, body reference). However, it lacks details on return format or body structure specifics, and some parameters remain underexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%. The description adds value for the 'body' parameter by referencing the Admin API shape, but other parameters (property, description, displayName, membershipDurationDays) are not elaborated beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create an audience' with a '[GA4 WRITE]' prefix indicating it's a write operation. This distinguishes it from sibling tools like ga4_archive_audience and ga4_update_audience.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific usage guidance: body should include filterClauses per Admin API shape, and prerequisites (GA4_MCP_ENABLE_WRITES=true and confirm=true) are stated. However, it does not explicitly exclude when not to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must cover behavioral traits. It indicates a write operation via '[GA4 WRITE]' and notes the need for confirm=true. However, it lacks details on side effects, idempotency, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the purpose and key constraints. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 output schema), the description covers the essential aspects: what it does, prerequisites, and how to pass grouping rules. It lacks details on return values or error conditions but is mostly adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60% (3 of 5 parameters have descriptions), but the tool description adds value by explaining that the body parameter should contain 'groupingRule[]'. This clarifies usage beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '[GA4 WRITE] Create a custom channel group.' which specifies the verb 'Create' and the resource 'custom channel group'. It distinguishes from sibling tools like ga4_update_channel_group and ga4_delete_channel_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisites ('Requires GA4_MCP_ENABLE_WRITES=true and confirm=true') and hints at usage ('Pass groupingRule[] via `body`'). However, it does not explicitly state when to use this tool versus other GA4 create tools or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It correctly labels the tool as a write operation ('[GA4 WRITE]') and notes required flags. However, it lacks details about side effects, success/failure responses, or irreversible consequences, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence followed by a brief note on requirements. Every word is meaningful, no redundancy, and it front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, nested objects in `body`, no output schema, and no annotations, the description provides essential context: action, target, how to supply complex data, and required flags. It does not describe return values, but for a creation tool without output schema, this is adequate for most uses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters documented), so baseline is 3. The description adds value by explaining that `body` should contain 'eventConditions/parameterMutations,' which is not detailed in the schema's generic description. This clarifies a complex parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Create an event-create rule on a data stream (server-side event creation).' It uses a specific verb ('Create') and resource ('event-create rule on a data stream'), and the sibling tools include update and delete versions, distinguishing this as the creation variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisites (GA4_MCP_ENABLE_WRITES=true, confirm=true) and suggests using the `body` parameter for nested fields. However, it does not explicitly state when to use this tool over alternatives (e.g., update/delete) or provide criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states it is a write operation via '[GA4 WRITE]' and the need for confirm. Does not discuss reversibility, authorization requirements, rate limits, or consequences of creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence front-loads purpose and action. Second sentence covers input and requirements efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 parameters, the description explains the tool's purpose, key requirements, and how to provide settings via body. Could mention response details but not necessary. Adequate for a create tool with good schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds meaning by stating that 'body' is used for 'postbackWindow settings', which helps an agent understand how to use the body parameter beyond its generic schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Starts with '[GA4 WRITE] Create' clearly stating action and resource. 'SKAdNetwork conversion value schema on an iOS data stream' identifies the specific object. Distinguishes from sibling tools like ga4_update_skadnetwork_conversion_value_schema and ga4_delete_skadnetwork_conversion_value_schema by using 'Create'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies input via 'body' and prerequisites: 'Requires GA4_MCP_ENABLE_WRITES=true and confirm=true'. Provides clear context for use, though does not explicitly exclude scenarios or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions destructive nature ('Revoke a user's access') and conditional execution (requires flag and confirm=true). Could elaborate on irreversibility or side effects, but sufficient for basic understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence containing all critical information: action, resource, permissions, flags, and mandatory parameters. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, description covers prerequisites and constraints. Missing return value or error handling info, but acceptable for a delete operation with safety checks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description adds no additional parameter context beyond what schema provides; it only restates confirm requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action (revoke access) and resource (account access binding). The '[GA4 DELETE]' prefix and specific naming distinguish it from sibling tools like ga4_delete_account or ga4_delete_property_access_binding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies required permission (analytics.manage.users), environment flag (GA4_MCP_ENABLE_DELETES=true), and mandatory confirmation parameter. Lacks explicit when-not-to-use or alternatives, but prerequisites are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the consequence of deletion (removes measurement ID / firebase app id) and the required confirm flag. With no annotations, the description does not address permissions, data permanence, or side effects beyond the immediate effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with a clear prefix and all essential information. No superfluous words; every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with two parameters and no output schema, the description covers the core purpose, prerequisites, and effect. Missing return value or error cases are acceptable for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already described in the input schema. The description adds minimal value by repeating the confirm requirement. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action 'Delete a data stream' and specifies what is removed ('measurement ID / firebase app id'). The '[GA4 DELETE]' prefix distinguishes it from other GA4 tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists prerequisites: 'Requires GA4_MCP_ENABLE_DELETES=true and confirm=true'. Does not compare to other delete tools or provide when-not-to-use guidance, but the requirements are clear enough for safe invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates the operation is destructive (delete) and adds the configuration flag constraint. However, it does not disclose permissions needed, irreversibility, or potential side effects on related resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a requirement tag. It is front-loaded with '[GA4 DELETE]' for quick identification. Every word is necessary, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required params, no output schema), the description is mostly complete. It covers the action, resource, and key constraint. However, it lacks information on expected response (e.g., success flag or empty body) and does not clarify what happens if the deletion fails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no additional meaning beyond the schema. The schema already describes the 'name' parameter as a resource path and 'confirm' as a boolean requirement. The description does not compensate with extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a DV360 advertiser link', specifying the action (delete) and the exact resource (Display & Video 360 advertiser link). This is distinct from sibling tools like 'ga4_create_display_video_360_advertiser_link' and 'ga4_update_display_video_360_advertiser_link'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites: 'Requires GA4_MCP_ENABLE_DELETES=true and confirm=true.' This tells the agent when the tool can be invoked. However, it does not mention when to avoid using it or suggest alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. It mentions that deletion 'revokes' the secret and requires explicit confirmation and an environment variable. This is adequate but lacks details on side effects, irreversibility beyond 'revokes', or any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with a bracketed prefix. It conveys the purpose and critical requirements without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with no output schema, the description covers the essential context: what it does, the required confirmation, and the environment variable gate. It could mention whether the action is reversible or impacts downstream data, but overall it's reasonably complete given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no new meaning beyond what the schema provides: it restates that 'name' is a full resource name and 'confirm' must be true. No additional usage hints or format details are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a Measurement Protocol secret (revokes it)', providing a specific verb and resource. The name itself is also self-explanatory. Among sibling tools, it distinguishes itself by targeting measurement protocol secrets specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes prerequisites: 'Requires GA4_MCP_ENABLE_DELETES=true and confirm=true.' This clearly indicates when the tool can be used. However, it does not provide guidance on when not to use it or compare to alternative delete tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It correctly indicates this is a delete/remove action and highlights required safety flags. However, it does not mention irreversibility or permission requirements, which would be valuable for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and prerequisites. It is front-loaded with [GA4 DELETE] and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description adequately covers purpose and usage conditions. It could mention that the source property itself is not deleted, only the link, but the current text is sufficient for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters (name URL format, confirm boolean). The description adds no extra semantic detail beyond the schema, so it earns the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Remove a source property from a rollup (360)" uses a specific verb and resource, clearly distinguishing it from siblings like ga4_delete_property or ga4_delete_firebase_link. The [GA4 DELETE] prefix further aids identification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states prerequisites: requires GA4_MCP_ENABLE_DELETES=true and confirm=true. This gives clear conditions for use. However, it does not mention when not to use or suggest alternatives, such as using the create counterpart for adding a link instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses that the tool is destructive (delete) and requires a confirmation flag and environment variable, but does not detail side effects, permissions, or irreversibility beyond what is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no wasted words. The '[GA4 DELETE]' prefix quickly categorizes the tool. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with full schema coverage and no output schema, the description adequately covers the required conditions. It could be more complete by mentioning return behavior, but overall it provides enough context for the agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both 'name' and 'confirm' are described in the schema). The description adds no additional parameter meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Delete the SKAdNetwork conversion value schema', clearly identifying the verb (delete) and resource. It distinguishes from sibling tools like ga4_create_skadnetwork_conversion_value_schema by its delete action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit requirements: 'Requires GA4_MCP_ENABLE_DELETES=true and confirm=true.' This tells the agent when the tool can be invoked, though it lacks alternatives or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It explicitly declares 'Read-only' and lists included fields, but does not detail pagination behavior or potential errors. Schema provides pagination tokens, partially covering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that front-loads purpose and key details. No verbosity, every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides a reasonable idea of returned data (customer ID, flags). However, lacks structural details for a list tool with many sibling list tools. Still fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds context about returned fields but no additional parameter-specific guidance. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List Google Ads links for a GA4 property' with specifics on what is included (linked customer ID, flags). Clearly distinguishes from sibling create/update/delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions 'Read-only' which implies usage for listing only, but does not explicitly provide when-not-to-use or compare to other list tools among siblings. Adequate but minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It explicitly states 'Read-only' and lists the return fields. However, it does not mention pagination behavior explicitly (though the schema includes pagination parameters). The description adds value beyond the schema by clarifying the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each adding significant information: purpose and naming context in the first, return fields and read-only in the second. No extraneous words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with 3 parameters and no output schema, the description covers purpose, return fields, and safety (read-only). It could mention pagination more explicitly, but overall it is sufficient for an agent to understand the tool's primary function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so the description does not need to explain parameters individually. The description adds context that the tool operates on a GA4 property, which reinforces the property parameter. This meets the baseline expectation for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), resource (key events), and context (GA4 property). It also clarifies naming (formerly conversion events) and specifies return fields. This distinguishes it from sibling tools that create, update, or delete key events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool is read-only, which implies when to use it (for reading), but it does not explicitly compare to other sibling list tools (e.g., ga4_custom_dimensions_list) or provide when-not-to-use guidance. The usage context is implied but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the tool is 'Read-only', which is the key behavioral trait. Since no annotations are provided, this is necessary and sufficient for a simple get operation. Could mention side effects are none, but not required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It front-loads the action and resource immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with one parameter and no output schema, the description provides sufficient context: what is returned and that it's read-only. Could be improved by noting that the property parameter accepts both full and partial IDs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add significant meaning beyond the schema, which already explains the property parameter with examples. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'GA4 property by ID', and lists specific fields returned (display name, time zone, etc.). It distinguishes from sibling tools like ga4_properties_list (which lists multiple properties) and other GA4 tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a single property detail is needed by ID, but does not explicitly state when to use this over alternatives or mention prerequisites. It provides no guidance on 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It explains the effect (turning on/off cross-device and demographics collection) and mentions the confirmation requirement. However, it lacks details on permissions needed, whether changes are immediate, or any side effects on existing data. This leaves some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a leading tag and parenthetical note. It is concise and front-loaded with the action. Every word serves a purpose: action, resource, effect, prerequisites.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema, no annotations), the description covers the essential context: purpose, parameters, and usage requirements. It could mention the return value or that the change is reversible, but overall it is sufficiently complete for an on/off toggle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers property and confirm with descriptions (67% coverage), leaving the state parameter undescribed. The description partially compensates by stating 'on or off', which maps to the two enum values. But it doesn't explain the exact string values (GOOGLE_SIGNALS_ENABLED/DISABLED), so minimal added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Turn Google Signals on or off for a property'. It specifies the resource (property) and the verb (turn on/off), and distinguishes it from other GA4 update tools by focusing specifically on Google Signals. The tag '[GA4 WRITE]' further clarifies the operation type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage prerequisites: 'Requires GA4_MCP_ENABLE_WRITES=true and confirm=true.' It also advises that the user must confirm their privacy disclosures cover the collection. While it doesn't explicitly state when not to use it, the prerequisites sufficiently guide appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral trait of automatic pagination, which is valuable since no annotations exist. However, it does not disclose other traits like permissions, rate limits, or that the operation is read-only, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence immediately conveys purpose, and the second adds key behavior. Very concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool without output schema, the description covers the essential functionality and pagination behavior. It could mention that results include template objects, but that is implied. Overall adequate for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the parameters are already well-described. The description reinforces that pagination is handled automatically (relating to maxPages and pageToken) but adds no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists all GTM templates in a workspace, using specific verb 'list' and resource 'GTM templates', distinguishing it from sibling tools like templates_get or templates_create. The scope 'in a workspace' is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, though the mention of automatic pagination implies it's for full listing. Without exclusion or sibling differentiation, the agent must infer usage context from the name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Discloses automatic pagination and truncated result behavior, but does not mention read-only nature, permissions required, or rate limits. Adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key action and resource, no fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains record structure and pagination behavior. For a list tool, this is sufficient context for an AI agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for all 3 parameters. Description adds context about pagination and record fields (email, access levels), but does not significantly enhance parameter meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'user permissions for a GTM account', and distinguishes from sibling tools like user_permissions_get (single) and user_permissions_create/update/delete (mutations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly indicates use for listing all permissions vs. getting a single one (sibling user_permissions_get). Lacks explicit when-not or alternative conditions, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the production impact and confirmation requirement, but lacks details on side effects (e.g., workspace locking), response behavior, or permission needs beyond the env var. It is adequate but not comprehensive for a high-impact write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with action and critical warnings. Every sentence adds value: purpose, requirements, and caution. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate param coverage, the description covers the core purpose, critical warnings, and requirements. It satisfies the immediate need for selection and invocation, though a bit more detail on the return value or error states could help. Overall, sufficient for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (3 of 6 parameters documented). The description adds no extra parameter information beyond the schema. With moderate coverage, baseline is 3, and no additional value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: creating a new container version from a workspace and immediately publishing it. The verb "create" and resource "container version from workspace" are specific, and the title [PUBLISH] distinguishes it from sibling tools like versions_create (create only) and versions_publish (publish existing). The warning about production impact further clarifies 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit requirements (GTM_MCP_ENABLE_PUBLISH=true, confirm=true) and a strong caution about production impact provide clear usage context. However, no alternative tools are named (e.g., versions_create for non-publishing), so the when-not-to-use is only implied by the warning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses the destructive behavior: 'This rotates the environment auth token; any embedded snippet using the old token stops working until updated.' This is good, but could also mention if the operation is irreversible or any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a warning. Every sentence is essential, and the key points are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers prerequisites and side effects but lacks information about the return value or output. Since there is no output schema, the agent may not know what to expect after successful reauthorization. Otherwise, it's adequate for a high-impact mutation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 4 parameters. The description adds that 'confirm' must be true, but this is already in the schema as required with a description. No additional meaning is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Re-generate the authorization code for a GTM environment' which specifies the verb (re-generate) and resource (authorization code). This distinguishes it from sibling tools like environments_list, get, create, update, delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear prerequisites: 'Requires GTM_MCP_ENABLE_PUBLISH=true and confirm=true.' It also warns about the impact of rotating the token. However, it does not explicitly state when not to use this tool or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the soft-delete nature, the fact that it deletes all properties, the blast radius, recoverability, and prerequisites. It could add details like what happens to sub-accounts or return values, but overall it is informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that is front-loaded with a bracket label, and every sentence adds value. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and lack of output schema, the description covers the key aspects: action, scope, blast radius, recoverability, and prerequisites. It is slightly lacking in details about post-deletion behavior or recovery time limits, but is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only mentions confirm=true but does not explain accountId. The parameters are not described, leaving the agent without necessary detail beyond the schema's type and required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool soft-deletes an entire GA4 account and all its properties, distinguishing it from sibling tools like ga4_delete_property which delete only a property. The verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: it's a high-blast-radius operation, recoverable temporarily, and requires a specific environment variable and confirmation. However, it does not explicitly name alternatives or say when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the soft-delete nature, recoverability window, and eventual permanent removal, plus prerequisites. It could mention side effects on associated data, but the given details are sufficient for agent understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, conveying the action and key details in one sentence plus additional notes. It is efficient but could have better structure (e.g., separate lines for requirements).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 params and no output schema, the description covers purpose, behavior, and requirements comprehensively. Minor gaps: no mention of error conditions or confirmation behavior beyond being required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (property described, confirm not). The description adds meaning by requiring confirm=true, implying it's a safety flag. However, it does not enhance property description beyond the schema's example. Given low coverage, description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Soft-delete (trash) a GA4 property') with a specific verb and resource. It distinguishes from sibling delete tools by focusing on property, and adds details about recoverability and permanent removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists prerequisites ('Requires GA4_MCP_ENABLE_DELETES=true and confirm=true'), providing clear context for when to use. However, it does not explicitly state when not to use or mention alternatives, though none exist directly among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It warns that the operation is irreversible and removes the tag from the workspace, which is key behavioral information. It does not detail error conditions or idempotency, but for a delete operation it is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a brief note, with no unnecessary words. It is front-loaded with the purpose and method, then the essential conditions. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description does not explain the return value (e.g., success message or deleted object). It covers the core action and side effects, but the lack of outcome details leaves some contextual gap for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters. The description adds only that confirm must be true, which is already in the schema description. No additional semantic value beyond baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Delete) and resource (GTM tag), distinguishing it from sibling tools like tags_create, tags_update, tags_get, etc. The [DELETE] prefix reinforces the HTTP method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the prerequisites (GTM_MCP_ENABLE_DELETES=true and confirm=true) and notes irreversibility, but does not explicitly state when not to use or suggest alternatives. However, the conditions are clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the write operation and the need for confirmation, but lacks details about idempotency, optimistic locking (fingerprint role not explained), error handling, or what happens to the existing resource.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with a clear prefix, front-loading the write nature. Every word serves a purpose, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain return values. It covers the environment variable requirement and confirmation but omits details like error states, response format, or the role of the fingerprint parameter. Adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by specifying that bodyJson must contain the full resource as a JSON string, which clarifies usage beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'GTM transformation', and uses '[WRITE]' to signal it's a write operation. It distinguishes from read tools like transformations_get and from transformations_create by implying existing resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisites: requires GTM_MCP_ENABLE_WRITES=true and confirm=true. This guides the agent on when to invoke, but does not explicitly exclude creation scenarios or mention alternatives like transformations_create.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses behavioral traits: it requires an environment variable and a confirm parameter to proceed, indicating a destructive operation with safeguards. It could mention the return value but is moderately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two clear sentences. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers prerequisites and basic purpose, it omits details about the return value and the exact effect of the operation. Given no output schema, this is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The description only adds context for the 'confirm' parameter. No additional meaning is added for accountId or userPermissionId beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Revoke a user's access') and targets a specific resource ('a GTM account'). It distinguishes from sibling tools like user_permissions_create and user_permissions_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states prerequisites (GTM_MCP_ENABLE_DELETES=true and confirm=true), implying that deletion is gated. It does not explicitly exclude alternatives, but context with siblings makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns workspaceChange and merge conflicts, implying a read operation. However, it does not mention any side effects, authorization needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences; first defines purpose, second provides usage guidance. Extremely concise with no wasted words. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description explains what is returned (workspaceChange and merge conflicts) and provides usage context. For a simple status tool with good parameter schema coverage, this is fully sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter (accountId, containerId, workspaceId). The description adds no additional semantics beyond what is already in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets status of a GTM workspace, including changed entities and merge conflicts. It distinguishes from sibling tools like workspace_sync by specifying it reviews change diff before creating version/publishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to review a change diff before creating a version or publishing.' Provides clear context for when to use, though does not explicitly mention when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the write operation, the need for confirmation, and the expected input format. However, it does not describe what happens on success/failure or return value, which is acceptable for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus the [WRITE] label, with no wasted words. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so return value is not documented, but the tool is simple: it creates a client. The required parameters are clear from schema and context. The description covers the key behavioral aspects, making it mostly complete for agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds a brief note about passing the resource as a JSON string in bodyJson, which reinforces the schema, but does not add significant new meaning beyond what the schema already provides through property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a new GTM client' with a verb and specific resource. The [WRITE] prefix and the list of sibling tools like clients_list and clients_get distinguish this creation action from read or update actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states requirements: GTM_MCP_ENABLE_WRITES=true and confirm=true. This guides the agent on when to use the tool and what conditions to meet. Does not explicitly mention alternatives, but the context of siblings implies 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a write operation ('[GA4 WRITE]') and that it is required once for certain operations. However, it does not describe the outcome, reversibility, or response format, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no wasted words. It is front-loaded with the purpose and efficiently provides usage context and requirements. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description covers purpose, usage context, and requirements. It could mention the expected response (e.g., success acknowledgment), but overall it is sufficiently complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 50% coverage (property described, confirm not). The description adds value by noting that 'confirm=true' is required, which goes beyond the schema. The property parameter is standard and the schema description suffices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to acknowledge that the property owner has the required user privacy disclosures/rights. It uses a specific verb ('Acknowledge') and resource, and distinguishes from sibling tools by explaining it's a prerequisite for other operations like creating links or MP secrets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions when to use it: 'Some operations (e.g. creating certain links or MP secrets) require this once.' It also lists prerequisites: 'Requires GA4_MCP_ENABLE_WRITES=true and confirm=true.' However, it doesn't specify when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states 'Read-only,' which is a key behavioral trait. It also explains what data is returned. No mention of auth requirements or rate limits, but for a simple read operation, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus 'Read-only,' which is extremely concise and front-loaded. Every part serves the purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, no annotations, and no output schema, the description is reasonably complete. It explains what the tool does and what it returns. Could optionally detail the output format, but not necessary given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as the only parameter 'property' has a description in the schema. The description adds context by mentioning 'GA4 property' but does not add meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'data retention settings for a GA4 property', specifying what is returned (event data retention duration and whether retention resets on new activity). This is distinct from sibling tools like ga4_update_data_retention and ga4_property_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates this tool is for reading retention settings, and the 'Read-only' label clarifies safe usage. However, it does not explicitly mention when to use this tool versus alternatives like ga4_property_get or ga4_update_data_retention, though the context of sibling tools suggests it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It declares the tool as 'Read-only', implying no side effects. It also mentions pagination behavior (truncated:true, nextPageToken) and the types of data returned per stream. This is good coverage for a listing endpoint, though authentication or rate limits are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and every word adds value. It avoids redundancy, is well-structured, and fits the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description provides key behavioral details (read-only, pagination) and clarifies what each stream type includes. It does not cover error cases or authorization requirements, but for a straightforward list operation, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters. The description does not repeat parameter details but adds value by explaining the output structure (web streams include measurement ID/URI, app streams include package name/bundle ID). Since the schema already documents parameters, a baseline of 3 is appropriate; the description enriches understanding of the return data, not the parameters themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'data streams for a GA4 property', and specifies three stream types (web, Android, iOS). It distinguishes itself from sibling tools like ga4_create_data_stream or ga4_delete_data_stream by focusing purely on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'audit measurement IDs and stream config'. Although it doesn't explicitly list when not to use or compare with alternatives, the read-only annotation and the listing focus imply it's safe and appropriate for inspection. A more explicit exclusion would be ideal, but current guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool performs a deletion and requires explicit configuration and confirmation, adding behavioral safeguards beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states purpose, the second lists requirements. No extraneous information, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-action delete tool with no output schema, the description covers inputs and necessary conditions. It lacks details on return values or error states, but the simplicity of the operation makes it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description for parameters ('Full resource name...' and 'Must be true to delete') repeats the schema descriptions with no additional semantic value. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a custom channel group.' It uses a specific verb and resource, and the '[GA4 DELETE]' prefix distinguishes it from sibling tools like ga4_create_channel_group and ga4_update_channel_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists requirements ('GA4_MCP_ENABLE_DELETES=true and confirm=true'), guiding when the tool is usable. It does not mention alternatives or when not to use, but the required conditions provide clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the destructive nature and the need for both an environment variable and a confirm parameter. This provides adequate transparency for a delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with essential information, no unnecessary words. Requirements are appended clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete tool, the description covers purpose, prerequisites, and parameter hints. Could briefly mention what a Firebase link is or the effect of deletion, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds minimal extra context (full resource name format, confirm must be true) but does not substantially surpass the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Delete' with the specific resource 'Firebase link', clearly differentiating from other delete tools like ga4_delete_property or ga4_delete_data_stream.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States prerequisites (GA4_MCP_ENABLE_DELETES=true and confirm=true), guiding when the tool is usable. Does not explicitly mention when not to use, but the requirements serve as implicit guardrails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that deletion returns the key event to a normal event and requires a confirm parameter and an environment variable. However, it does not detail consequences like irreversibility or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one line with a clear prefix, action, and requirements. Every part is essential and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a delete operation with a confirmation flag and an environment variable requirement, the description covers the key points. No output schema exists, but the return is likely minimal. Could mention success/failure indication, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description reinforces that confirm must be true but does not add meaning beyond the schema. The requirement for GA4_MCP_ENABLE_DELETES is an additional constraint not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a key event') and the effect ('reverts to a normal event'). It distinguishes itself from sibling tools like ga4_create_key_event and ga4_update_key_event by specifying it is a delete operation with a [GA4 DELETE] prefix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists the prerequisites: 'Requires GA4_MCP_ENABLE_DELETES=true and confirm=true.' This guides the agent on when the tool can be invoked. It does not explicitly mention when not to use it, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the destructive nature (delete) and the required confirmation parameter. More detail on irreversibility or side effects would improve, but the essential behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence plus a succinct note. Front-loaded with action and requirements. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple delete operation and no output schema, the description provides adequate context for an agent to use the tool. It explains prerequisites and the confirm flag. Could mention return value, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions (100% coverage). The description only reiterates the confirm requirement, adding no new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Delete a subproperty event filter (360)', with a [GA4 DELETE] prefix. It clearly identifies the specific resource and action, distinguishing it from sibling tools like create/update and other GA4 delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description notes prerequisites: 'Requires GA4_MCP_ENABLE_DELETES=true and confirm=true.' This provides clear context for use. However, it does not explicitly state when not to use it or mention alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description clearly states 'Read-only — never writes' and 'Requires the analytics.readonly scope', effectively communicating safety and authentication needs. It does not mention pagination or rate limits, but the core behavioral traits are well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying essential information: purpose, use case, safety/scope. No wasted words. Front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, no output schema), the description adequately explains return format, use case, and safety. It lacks details on ordering or paging behavior, but these are covered by schema descriptions. Overall, it's sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds minimal parameter-specific value beyond the schema, only giving an example of dimension/metric rows (eventName) and referencing date range. No additional guidance on format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a read-only GA4 Data API report for a property over a date range, using specific verb and resource. It differentiates from sibling ga4_run_realtime_report by focusing on historical date ranges, and provides an example of returned data (event counts by eventName).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions a specific use case: reconciling configured events against reported activity. It implies the tool is for historical analysis, but does not explicitly mention ga4_run_realtime_report as an alternative for real-time needs. Still, the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the updateMask derivation and the requirement for confirm and environment variable, but does not detail auth needs, rate limits, or the non-destructive nature of the update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second covers usage details. No wasted words, front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (body, updateMask, required confirm), the description covers the critical points. It could mention possible errors or return values, but overall is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by pointing to specific fields in the body (groupingRule/displayName) and explaining updateMask behavior, exceeding the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('custom channel group'), and specifies what to supply in the body. It distinguishes this tool from siblings by focusing on channel groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: how to supply fields for update (body), how updateMask is derived, and the need for confirm=true and environment variable. It does not explicitly list exclusions but gives sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clarifies the write nature, partial update behavior, and requirement of confirm flag. However, it does not disclose idempotency, error conditions, or immutable fields. Adequate but not deep.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences and a prerequisite clause. Every phrase carries information: the operation, examples, partial update behavior, and conditions. No fluff, front-loaded with key verb and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description covers the operation type, partial update guidance, and prerequisites. Could mention response format or error handling, but the current level is sufficient for a straightforward update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%. Description adds value by explaining that 'body' merges over typed fields and when to use it (nested/advanced). For updateMask, says 'Omit to derive from the supplied fields'. Provides example parameter 'countingMethod'. Adds context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with '[GA4 WRITE]' and states 'Update a key event', clearly identifying the verb and resource. Examples like 'counting method or default value' specify scope. Distinguishes from siblings like ga4_create_key_event and ga4_delete_key_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Pass only the fields to change' and explains updateMask derivation. Lists prerequisites (GA4_MCP_ENABLE_WRITES=true, confirm=true). Lacks explicit when-not-to-use or alternatives, but the sibling set makes the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adds key behavioral context: it is a write operation (tagged [GA4 WRITE]), renames the secret, uses automatic updateMask derivation, and requires confirmation. However, it does not discuss side effects, rate limits, or error conditions, leaving some behavioral aspects uncovered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. Every phrase adds value, with no redundant or filler text. Efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema and no annotations, the description covers the operation, parameter usage, and prerequisites adequately. It does not explain the return value, but for a simple rename operation that is acceptable. The description is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful guidance beyond the schema: it explains the updateMask derivation logic and the confirm parameter's role as a write guard. Given 75% schema coverage, this complements the existing schema descriptions for name and displayName.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Rename') and the resource ('Measurement Protocol secret'), with a '[GA4 WRITE]' prefix. Among sibling tools that include create and delete operations for the same resource, this description distinguishes the update (rename) functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites ('Requires GA4_MCP_ENABLE_WRITES=true and confirm=true') and usage guidance for the updateMask parameter ('Pass only the fields to change; updateMask is derived from them'). It does not explicitly mention when not to use or name alternatives, making it clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses mutation via '[GA4 WRITE]' and safety requirements (confirm, env variable). However, no annotations exist, and the description does not detail response behavior, error handling, or side effects beyond the bare minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loaded with purpose. Every sentence adds value and the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, parameter hints, and prerequisites. Lacks details on response format and handling of partial updates, but with no output schema and given the complexity, it provides sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds practical guidance beyond the schema: explains how updateMask is derived from supplied fields and when to override it for nested paths. Also reinforces the confirm flag's purpose. Despite 100% schema coverage, the description enhances usability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update', the resource 'Search Ads 360 link', and the scope 'data-sharing flags via body', distinguishing it from create or other update tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance: pass only fields to change, updateMask derived automatically, and explicit requirements for GA4_MCP_ENABLE_WRITES=true and confirm=true. Lacks explicit when-not-to-use but implies create tool for creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses write behavior, updateMask derivation from supplied fields, and the need for explicit confirmation. This adds value beyond the schema, though side effects or error conditions are not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose and key behaviors. No wasted words; every part contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, nested objects, and no output schema, the description covers the essential behavioral context: what to pass, how updateMask works, and prerequisites. Could mention handling of nested fields in body, but schema partially addresses that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about updateMask derivation but does not significantly enhance understanding of individual parameters (e.g., body usage is not elaborated).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'subproperty event filter (360)'. The '[GA4 WRITE]' tag reinforces the action type. This distinguishes it from sibling create and delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on how to use the tool: pass only fields to change, updateMask derivation, and override for nested paths. Also specifies required conditions (GA4_MCP_ENABLE_WRITES=true and confirm=true). Does not explicitly mention when not to use, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Describes pagination behavior (automatic following, truncation with nextPageToken) which adds value beyond schema. Could mention more about ordering or empty results, but current detail is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. No unnecessary words. Key behavioral info in second sentence. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with 5 parameters and no output schema, description covers purpose and pagination behavior. Lacks mention of output format but is sufficient for agent to understand what it returns (list of configs).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds slight context on pagination parameters (maxPages, pageToken) but does not significantly enhance understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (list), resource (GTM gtag configs), and scope (in a workspace). Distinguishes from sibling tools like gtag_config_get or gtag_config_create by indicating it lists all configs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly clear when to use: to list gtag configs. Mentions automatic pagination which guides usage. However, does not explicitly state when not to use or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses write operation and requirements, but does not mention response behavior, idempotency, or error handling (e.g., duplicate names).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence conveying the action, requirements, and parameter guidance. No superfluous information; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 required parameters, no output schema, and no annotations, the description covers the core operation and prerequisites. It omits error scenarios or return value details, but is largely complete for a simple create tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The description adds value by explicitly instructing to pass the full resource as a JSON string in bodyJson and providing an example format, reinforcing parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'GTM transformation', with a '[WRITE]' flag. Among sibling tools like transformations_list, transformations_get, etc., this tool is unambiguously for creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies prerequisites: GTM_MCP_ENABLE_WRITES=true and confirm=true. It lacks explicit when-not-to-use or comparisons to alternatives, but for a create tool, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses read-modify-write semantics, field preservation, and parameter merging by key, plus required flags. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first packs core behavior (write, read-modify-write, merge), second adds prerequisites. Extremely efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key behavior but omits details like return values (no output schema) and error handling. For a 10-param tool with nested schema, it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (10%). Description only mentions parameter merging behavior. No explanation of accountId, containerId, workspaceId, variableId, or other fields. The schema is complex with nested parameters, but description adds minimal value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with "[WRITE] Update a GTM variable" which clearly states the verb and resource. It also explains the read-modify-write behavior and parameter merging, distinguishing it from sibling tools like variables_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit prerequisites are given: "Requires GTM_MCP_ENABLE_WRITES=true and confirm=true." It implies use for updating existing variables, but does not explicitly contrast with creation (variables_create). Still clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It correctly labels the tool as a write operation, explains the effect (taking a snapshot into a versioned checkpoint), and notes prerequisites. It does not contradict any annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that front-load the action and key constraints. Every sentence adds value without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description explains the core action and a critical prerequisite (confirm=true). However, it does not describe what the tool returns or any post-creation behavior, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%), and the description only adds semantic value for one parameter (confirm must be true). It does not elaborate on other parameters beyond what the schema provides, leaving gaps for name, notes, accountId, containerId, workspaceId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new GTM container version from a workspace, using specific verbs and resources. It distinguishes from 'publish' by noting it creates a checkpoint without publishing, which differentiates it from sibling tools like versions_publish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions prerequisites (GTM_MCP_ENABLE_WRITES=true, confirm=true) and notes this creates a snapshot without publishing, implying when to use it versus publishing tools. However, it could more directly compare with siblings like workspace_create_version_and_publish.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It labels the operation as [WRITE], states the requirement for GTM_MCP_ENABLE_WRITES=true and confirm=true, and warns about the data_layer blank-value pitfall. It does not describe error behavior or irreversibility, but it covers the key behavioral requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the core concept and then expands each kind. While lengthy, every sentence contributes useful information and the format mirrors the kind selection decision tree. A bulleted list would improve scannability, but the current structure is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 params, 6 required, no output schema) and no annotations, the description does a strong job of covering the essential usage context: kind definitions, prerequisites, and the special case that event_data and request_header are server-only. It does not explain return values, but that is a minor gap for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds substantial cross-parameter meaning by mapping each kind to its applicable parameters (e.g., dataLayerName for data_layer, javascript for javascript) and explaining the semantic difference, such as dot-notation for nested keys and the requirement that javascript be a full function.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a GTM variable by KIND rather than by GTM's internal type code, so the right shape is guaranteed,' which clearly identifies the tool's specific value proposition and distinguishes it from generic variable creation. It enumerates the supported kinds, making 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance for each kind, such as 'only correct when the site actually pushes that key' for data_layer and 'the right choice for deriving something from the page or the click' for javascript. It also includes an explicit when-not: 'a data_layer variable CANNOT do this and would report blank.' However, it does not explicitly contrast this tool with sibling tools like variables_create.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses read-only nature ('never writes'), time window (roughly last 30 minutes), and required scope (analytics.readonly). No rate limits or error behaviors but sufficient for a read-only report.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences that are front-loaded with purpose, no filler. Every sentence adds value: purpose, use case, and read-only/scope info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (realtime report), the description covers purpose, behavior, use case, and scope. No output schema exists, but the return is standard rows; no further details needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description does not add extra meaning beyond the schema, so baseline of 3 is appropriate. No contradictions or gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a read-only GA4 Data API Realtime report for events in the last 30 minutes, distinct from the sibling 'ga4_run_report' which handles historical data. The use case for live QA is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells when to use the tool (confirming a tag firing during live QA) and states it is read-only. Although it doesn't explicitly mention when not to use, the context implies alternatives like ga4_run_report for non-realtime needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that this is a write operation, requires confirmation, and explains updateMask derivation. Does not describe return values or side effects, but overall transparent about the update process.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words. First sentence states purpose, second gives usage pattern, third lists requirements. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no mention of return values or error handling. Given 4 parameters and nested objects, description covers usage but misses what the agent can expect after a successful update. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds significant meaning: explains how to use body and updateMask fields, and the derivation behavior. This goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'DV360 advertiser link', with scope 'ads personalization / campaign data sharing'. This distinguishes it from sibling create/delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on how to use the tool: 'Pass only the fields to change; updateMask is derived from them'. Also lists requirements (GA4_MCP_ENABLE_WRITES=true, confirm=true). Does not explicitly state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It explains the internal process: fetches tag, appends parameters to eventSettingsTable, and saves full tag. It also notes that values can be GTM variables and that top-level params are ignored by GA4 event tags, providing insight into correct usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently conveys essential information without redundancy. It starts with a [WRITE] marker and is appropriately front-loaded, but could benefit from slight restructuring for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (write operation, 6 required parameters, no output schema), the description covers the action, prerequisites, parameter behavior, and context about where parameters are stored. It is sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds value beyond schema by explaining the significance of the parameters array (appended to eventSettingsTable, variable usage) and the effect of duplicate parameter names (update, not duplicate).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool adds GA4 event parameters to a GA4 Event (gaawe) tag. It specifies the verb 'Add' and the resource 'GA4 event parameters', and distinguishes from other tag-related tools by targeting a specific tag type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes prerequisites (requires GTM_MCP_ENABLE_WRITES=true and confirm=true) and explains behavior on duplicate names (value updated, not duplicated). However, it does not explicitly compare with sibling tools like tags_update, though context implies this tool is specialized for adding parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description marks the tool as [WRITE], explains it synchronizes the default workspace, and clarifies it does not publish. However, it lacks details on error handling or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise two-sentence description that effectively front-loads the purpose, adds a critical note about publishing, and ends with prerequisites. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple write action with no output schema, the description covers the core behavior and prerequisites. It distinguishes from the key sibling versions_publish, making it sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (only containerVersionId has a description). The description merely restates that containerVersionId is the version ID to set as latest, and mentions confirm must be true but doesn't explain its role. Other parameters are left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Set a specific container version as the latest' with specific verb and resource. Distinguishes from sibling versions_publish by explicitly noting it does NOT publish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (to set latest) and when not to (use versions_publish to go live). Also lists prerequisites: GTM_MCP_ENABLE_WRITES=true and confirm=true.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that this is a write operation (mutation) and requires explicit confirmation. Omits details like return value or error handling, but core behavioral traits are stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with two clear parts: action and requirement. No redundancy, front-loaded, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (4 required) and no output schema, the description captures the essential: creation action and critical prerequisite. Schema fully describes parameters, so extra detail is unnecessary. Missing info about post-creation confirmation or return, but adequate for a create tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds no additional meaning beyond the schema; it only mentions the confirmation requirement, which is already in the schema description. No extra semantic depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states '[WRITE] Create a new GTM container'. Verb 'create' and resource 'GTM container' are specific. Distinguishes from sibling tools like containers_get, containers_list, and other create tools (tags_create, etc.) by resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states necessary preconditions: 'Requires GTM_MCP_ENABLE_WRITES=true and confirm=true'. This tells the agent when to use this tool (only with writes enabled) and that confirmation parameter must be true, guiding correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses irreversibility ('no un-archive') and the feature flag requirement. The behavioral traits are well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action, then constraints. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers prerequisites and behavior. However, it doesn't mention what the response looks like or if it's synchronous, which could be useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds no new parameter information beyond what the schema already provides for name and confirm.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive a custom metric') and the resource. It distinguishes from hard delete and notes permanence. Among sibling tools, it differentiates from create/update and archive of dimensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisites: GA4_MCP_ENABLE_DELETES=true and confirm=true. Also notes permanence, implying careful use. However, it does not explicitly compare to alternative tools like update or create.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses write operation, required confirm parameter, and environment variable requirement. Does not mention side effects or return behavior, but adequately warns about mutation constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with '[GA4 WRITE]', no redundant information. Every part adds value: action, limitation, prerequisites.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with 3 required params and no output schema, the description covers purpose, constraints, and key usage notes. Lacks return value details but otherwise complete given tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description does not add meaning beyond schema. The mention of 'confirm=true' aligns with schema's boolean description. Baseline score of 3 applies as description offers no extra parameter insight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a Firebase link'), identifies the resource, and distinguishes from update by noting 'no update; delete + recreate to change'. Sibling tool ga4_delete_firebase_link confirms separation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisites (GA4_MCP_ENABLE_WRITES=true, confirm=true) and indicates when to use this vs. alternative ('no update; delete + recreate to change'). Provides clear context for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses mutation behavior, the need for an environment variable (GA4_MCP_ENABLE_WRITES=true) and confirm=true, and explains the updateMask derivation. It could add response details, but covers key behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loads essential information, and contains no fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides a reasonable level of completeness: it covers mutation behavior, prerequisites, and field constraints. It could mention that the audience must exist and what the response looks like, but is adequate for a simple update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (4 of 6 parameters described). The description adds meaning beyond schema: it clarifies that displayName and description are the only mutable fields, that updateMask is derived from supplied fields, and that the body parameter is for nested/advanced fields. This compensates for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a write operation to update an audience, specifying that only displayName and description are mutable and filters are immutable. This differentiates it from sibling tools like ga4_create_audience and ga4_archive_audience.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes that only displayName and description can be changed, and that filters are immutable, guiding when to use this tool. It also mentions the prerequisite environment variable and confirmation flag. However, it does not explicitly advise using ga4_create_audience for filter changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses immutability of parameterName and scope, updateMask behavior, and required configuration flags. However, it omits error handling or idempotency details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no redundant information, and all sentences are informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description explains the core behavior, prerequisites, and parameter usage. It lacks return value description but is sufficient for an update tool with clear side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (3 of 6 parameters described). The description adds value by explaining that updateMask can be omitted and derived from supplied fields, and that only fields to change should be passed, which helps agents use parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and resource 'custom dimension', and notes that parameterName and scope are immutable, distinguishing it from create and archive siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance to pass only fields to change and explains updateMask derivation. It also specifies prerequisites (GA4_MCP_ENABLE_WRITES=true, confirm=true), but does not explicitly mention when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses the write operation, updateMask behavior (derived vs explicit), and prerequisites. It does not cover error conditions or idempotency, but key behavioral aspects are addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose and scope, second gives usage notes. No filler, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, prerequisites, and updateMask behavior. Lacks mention of return value (no output schema), but for a verified write tool with nested objects, essential context is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value: explains 'body' for nested/advanced fields, updateMask derivation, and that confirm must be true. This helps the agent understand parameter interplay beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with '[GA4 WRITE] Update an event-create rule', clearly specifying the action (Update) and resource. It differentiates from sibling tools like ga4_create_event_create_rule and ga4_delete_event_create_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use: updating an existing rule, with guidance on partial updates and updateMask. It notes prerequisites (GA4_MCP_ENABLE_WRITES=true, confirm=true). It does not explicitly state when not to use or alternatives, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden; it discloses it is a write operation, requires confirm flag, and explains updateMask behavior. It does not cover error handling or response format, but covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, key pattern, prerequisites. No wasted words; every sentence adds necessary information. Well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description covers prerequisites, parameter behavior, and updateMask usage. Missing explanation of return value, but otherwise provides sufficient context 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds semantics by explaining the body parameter is for nested fields, and how updateMask is derived or overridden, providing value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an expanded data set, specifies it's a GA4 WRITE operation, and distinguishes from create/delete siblings by mentioning 'Update'. The resource and action are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides prerequisites (GA4_MCP_ENABLE_WRITES=true, confirm=true) and explains the updateMask derivation pattern. It implies when to use (update) versus create/delete but does not explicitly state when not to use or offer alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates this is a write operation, explains the automatic derivation of updateMask, and states required conditions. It does not detail error handling or exact response, but covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first delivers the core purpose and key parameter guidance, the second adds required conditions. No redundant words, front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description explains the update behavior, updateMask derivation, and prerequisites. It could mention return value or error cases, but the essential information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 of 4 parameters described). The description adds meaning for the adsPersonalizationEnabled parameter by linking it to 'personalized advertising flag', and explains the optional updateMask's derivation behavior. This compensates for the missing schema description of one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with '[GA4 WRITE]' and states 'Update a Google Ads link (personalized advertising flag)', which clearly identifies the action (update) the resource (Google Ads link) and the specific field (personalized advertising flag). This distinguishes it from sibling tools like create, delete, and list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the tool: 'Pass only the fields to change; updateMask is derived from them' and specifies required conditions: 'Requires GA4_MCP_ENABLE_WRITES=true and confirm=true'. However, it does not explicitly state when not to use this tool or provide direct alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full burden. It covers the mutation nature, updateMask behavior, and required confirm flag. It could mention error handling or idempotency but is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: tag, action, usage detail, requirement. Front-loaded with key info, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Good coverage of usage and prerequisites. Missing mention of return value or error cases (no output schema), but given tool complexity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all params described). The description adds value by explaining the updateMask derivation and override, going beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Update the SKAdNetwork conversion value schema,' clearly identifying the verb (update) and resource. The '[GA4 WRITE]' tag and sibling tools for create/delete further differentiate its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to 'Pass only the fields to change' and explains updateMask derivation, along with prerequisites (GA4_MCP_ENABLE_WRITES=true and confirm=true). It does not explicitly state when not to use, but implied by siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It discloses the destructive nature via '[DELETE]' and the requirement for confirmation and an environment variable, which indicates safety guards. This adds value beyond the raw schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence. It front-loads the action and prerequisites with no unnecessary words. Every element serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with 5 parameters and no output schema, the description covers the core behavior and guards. It doesn't mention return values or error scenarios, but given the tool's simplicity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with individual parameter descriptions, but the description adds context that the confirm parameter is mandatory and ties it to a global environment flag. This helps the agent understand the parameter's importance beyond its type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a GTM template') with a specific verb and resource. It distinguishes from sibling delete tools (e.g., tags_delete, triggers_delete) by specifying 'GTM template'. The [DELETE] prefix is redundant but not misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites: requires GTM_MCP_ENABLE_DELETES=true and confirm=true. This guides the agent on conditions for safe usage. However, it does not explicitly contrast with alternatives (e.g., when to use revert instead), but the name and resource type imply the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Described as a write operation with replacement semantics ('API replaces the record'). Prerequisite flags are stated. No annotations provided, so description partially covers behavior, but lacks mention of rate limits or auth details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The purpose and key usage guidelines are immediately clear. The [WRITE] indicator helps quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the write nature, prerequisites, and replacement behavior. No output schema, so return values are not explained, but overall adequate for a simple update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The description adds important context: 'Provide the full intended access...as the API replaces the record,' which clarifies how to use containerAccess and accountPermission.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for updating user account and/or container access levels, with a [WRITE] prefix. It distinguishes from siblings like get, create, delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists prerequisites (GTM_MCP_ENABLE_WRITES, confirm=true) and advises providing the full intended access. However, it does not mention when not to use or compare with alternatives explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: permanent effect, no un-archive, and prerequisite configuration. Lacks detail on potential data impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise—two sentences with no filler, front-loaded with danger signal. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple, 2-param tool with no output schema: covers purpose, usage, behavior, and prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions; description adds helpful example for name and reinforces confirm must be true. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action 'archive' and resource 'custom dimension', and distinguishes from sibling delete tools by noting there is no hard delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions permanence and required environment variable and confirm parameter, but does not contrast with other tools for filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares the tool as 'Read-only', indicating no side effects. It also explains why the check is needed (the Data API rejects incompatible pairs). While no annotations are present, the description adequately covers behavioral aspects. A minor improvement could be mentioning speed or rate limits, but it's sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences with no unnecessary words. It front-loads the purpose and includes essential usage guidance. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple compatibility-check tool. It explains the purpose, usage context (before ga4_run_report), expected behavior (read-only), and action on incompatible results. No output schema is needed given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions (100% coverage). The description adds context by mentioning 'given GA4 dimensions/metrics' but does not provide additional semantic meaning beyond what the schema already offers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to check which GA4 dimensions/metrics can be combined in one report. It uses a specific verb ('check') and resource ('GA4 dimensions/metrics compatibility'), and distinguishes itself from siblings like ga4_run_report by advising to call it before ga4_run_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 the tool ('BEFORE ga4_run_report when combining unusual dimensions/metrics') and what to do if incompatibility is found ('drop or replace anything reported incompatible instead of retrying blind'). This clarifies usage and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that this is a write operation, requires permission 'analytics.manage.users', and explains the updateMask derivation and the necessity of confirm=true. This covers key behavioral aspects, though it could mention outcome details (e.g., success response).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the operation type, and every sentence provides essential information. No redundant text, making it highly efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool, the description covers the necessary context: operation type, required permissions, parameter usage strategy, and configuration requirements. Given the absence of output schema, it is complete enough to guide correct usage without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so baseline is 3. The description adds value by explaining the intention behind the parameters: 'Pass only the fields to change' and dynamic updateMask handling. This complements the schema descriptions and helps the agent understand parameter relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with '[GA4 WRITE]' and states 'Change a user's roles on an account', clearly specifying the action on a distinct resource. It distinguishes from sibling tools like ga4_create_account_access_binding and ga4_delete_account_access_binding by indicating it is an update operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: 'Pass only the fields to change; updateMask is derived from them' and mentions required configuration ('GA4_MCP_ENABLE_WRITES=true and confirm=true'). It does not explicitly specify when not to use this tool versus alternatives, but the guidance is sufficient for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly marks the tool as a write operation with '[GA4 WRITE]', warns about forbidden fields, and explains updateMask derivation. It does not cover rate limits or detailed auth scopes, but the core mutation behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the critical purpose and constraints. Every sentence serves a distinct purpose, though the density could be slightly improved by breaking into shorter points. Still, it avoids unnecessary words effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering the tool's complexity (6 parameters, no output schema), the description adequately covers functionality, restrictions, and prerequisites. It does not describe the return value, but for an update tool this is typically standard. Overall, it is sufficiently complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the high-coverage schema (83%) by clarifying that displayName and defaultUri are the only allowed field changes and that updateMask is derived from supplied fields unless overridden for nested paths. This guides correct usage of parameters together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a GA4 data stream and explicitly lists the only modifiable fields ('displayName and (web) defaultUri ONLY'). This specificity distinguishes it from sibling tools and immediately conveys its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-not-to-use guidance by categorizing other settings as Google tag settings with no API fields, directing users to the manual UI. It also lists required prerequisites (GA4_MCP_ENABLE_WRITES=true and confirm=true), giving clear action criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the write nature, the read-modify-write pattern to preserve other fields, the rejection of non-server containers, the URL recording being config-only (no deployment), and the required flags. This is comprehensive for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the first sentence front-loading the key action and context. Every word adds value: the prefix '[WRITE]', the purpose, the pattern, the constraints, and prerequisites. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple write operation with no output schema, the description covers the essential behavioral aspects, prerequisites, and constraints. It does not specify the return value or error messages, but for a parameterized setter, this is adequate. The missing details are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining serverUrls are 'deployed tagging-server URL' examples (Cloud Run/Stape), and confirms the confirm parameter's role. It also clarifies the containerId must be for a server container, which is not enforced by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: setting taggingServerUrls on a SERVER container. It specifies the resource (SERVER container), the verb (set), and provides context (read-modify-write via containers.update). It also distinguishes from generic updates by noting it rejects non-server containers and only records the URL without deploying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says the tool is for SERVER containers only and rejects others. It also states the prerequisites (GTM_MCP_ENABLE_WRITES=true, confirm=true). However, it does not mention alternative tools like containers_update for directly modifying the resource, leaving the agent to infer when to use this specialized setter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well: it explicitly labels the operation as [WRITE], explains that omitted fields are preserved, and specifies that `parameter` is merged by key. It also discloses the environment flag and confirmation requirement, which are important safety-relevant behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the operation type and packs in the most important behavioral constraints. There is no filler, and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (20 parameters, nested objects, no output schema), the description covers the most critical operational semantics: read-modify-write behavior, field preservation, parameter merge behavior, and write-enablement requirements. It does not explain return values or trigger-type-specific nuances, but the rich input schema supplies field-level detail for those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds crucial parameter-level meaning beyond the schema by explaining that `parameter` is merged by key and that omitted fields are preserved, which is essential for correct read-modify-write calls. It does not enumerate all 20 parameters, but the schema already provides many per-property descriptions, and the merge behavior is more valuable than restating field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: "[WRITE] Update a GTM trigger," and adds a specific read-modify-write model. This unmistakably distinguishes it from sibling tools like triggers_create, triggers_get, and triggers_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states that this is an update operation with a read-modify-write pattern and requires both GTM_MCP_ENABLE_WRITES=true and confirm=true, giving clear conditions for invocation. It does not explicitly contrast with triggers_create, but the update-vs-create distinction is implied by the operation name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and succeeds. It discloses the write nature ('[WRITE]'), requirements (GTM_MCP_ENABLE_WRITES=true, confirm=true), idempotency, return value, and API support. It also warns about the 404 error for Google tags and the need to read the tag type from the container rather than constructing it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but each sentence carries essential information: purpose, exclusions, alternatives, prerequisites, idempotency, return value, and common usage patterns. There is no filler or redundancy; the density is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with no annotations or output schema, the description covers all needed context: operation semantics, exact usage constraints, error expectations, and follow-up steps. It leaves no critical gap for an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all 7 parameters with descriptions (100% coverage), so baseline is 3. The description adds value by providing concrete examples for owner/repository pairs and emphasizing confirm must be true. It also explains how the result's tag type should be used with tags_create, though it doesn't add new parameter descriptions. This elevates it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Install a Community Template Gallery template into a workspace by GitHub owner and repository.' It also distinguishes this tool from siblings by explicitly excluding Google's own tags and targeting third-party pixels, making it unambiguous which tool to invoke.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: 'NOT for Google's own tags', directs users to tags_create with type 'gaawe' for GA4, and lists common repository pairs. It also clarifies the API support, preventing the agent from falsely claiming the operation is UI-only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral disclosure. It declares 'WRITE', explains side effects (enables built-in variables, reuses/creates trigger, creates tag in draft workspace), and reveals important behaviors like refusing placeholder Measurement IDs and resolving them from the container unless allowPlaceholderId is set. It also notes that trigger reuse happens by name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place—each clause adds critical usage or behavioral context. It front-loads the purpose with [WRITE] and PREFERRED, then efficiently explains the single-call benefit, alternatives, and safety guardrails without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 11-parameter tool with nested objects, no annotations, and no output schema, the description is remarkably complete. It covers prerequisites, side effects, parameter semantics, safety caveats (placeholder refusal), and explicitly contrasts with the multi-step alternative. The inclusion of GTM-specific field shapes and resolution behavior makes it self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the schema having 100% coverage with detailed descriptions, the description adds significant semantic value. It explains eventParameters are plain name/value pairs and not the GTM list-of-maps shape, that variable references like {{Click URL}} are enabled automatically, and clarifies the nuanced allowPlaceholderId behavior and Measurement ID validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: '[WRITE] PREFERRED way to create a GA4 event tag that fires on an event.' It clearly states the tool builds a correct GTM resource from plain fields and links it to a trigger in the draft workspace. It also distinguishes itself from siblings like tags_create, triggers_create, and built_in_variables_enable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this instead of tags_create + triggers_create + built_in_variables_enable, which need three round trips and get shapes wrong. It also states prerequisites (GTM_MCP_ENABLE_WRITES=true and confirm=true) and gives trigger kind guidance such as using link_click for <a> clicks and all_clicks for any element.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully discloses behavior: GTM's API replaces the whole tag, so the tool fetches first and overlays fields; parameter is merged by key preserving untouched keys; and the limitation that generic parameters cannot express nested eventSettingsTable. This goes far beyond what annotations would provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place. It front-loads the purpose and write requirement, then explains the critical merge behavior and points to an alternative for a specific case. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 13 parameters and no output schema, the description covers the complete picture: why it performs read-modify-write, what confirm does, how parameters merge, and when to use a different tool. This fully equips the agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 100% parameter descriptions, the tool description adds crucial operational semantics: the parameter merge behavior (by key, replaces same-key, adds new, keeps untouched) and that omitted fields are preserved. This is essential for correct use and not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '[WRITE] Update an existing GTM tag', which is a specific verb+resource. It further clarifies the read-modify-write nature, distinguishing it from tags_create, tags_delete, and tags_add_ga4_event_parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States explicit usage context: updating an existing tag, with required prerequisites (GTM_MCP_ENABLE_WRITES=true and confirm=true). Crucially, it tells the agent when NOT to use it (for GA4 event parameters) and directs to the alternative tags_add_ga4_event_parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![samarth-analytics-mcp MCP server](https://glama.ai/mcp/servers/samarthanalytics-sj/samarth-analytics-mcp/badges/card.svg)](https://glama.ai/mcp/servers/samarthanalytics-sj/samarth-analytics-mcp)

Score Badge

Copy to your README.md:

[![samarth-analytics-mcp MCP server](https://glama.ai/mcp/servers/samarthanalytics-sj/samarth-analytics-mcp/badges/score.svg)](https://glama.ai/mcp/servers/samarthanalytics-sj/samarth-analytics-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/samarthanalytics-sj/samarth-analytics-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server