Skip to main content
Glama

Anacraft — Google Analytics 4 (GA4)

Set up a site

configure_site

Set up GA4 for a domain the account does not measure yet: creates the property and its web data stream and returns the gtag.js snippet to paste into the site's . Re-running for a domain that already has a stream returns that tag instead of creating a second property. This is the one tool that writes to the Analytics account — and it still never changes which property is the saved default.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYesThe domain to set up, e.g. example.com. A pasted URL is trimmed to its host; ports, paths and emails are refused.
accountNoThe GA4 account to create the property under, by numeric id or display name. Only needed when the login can see more than one.
currencyNoISO 4217 reporting currency for the new property.USD
timezoneNoIANA time zone for the new property, e.g. Europe/London. Otherwise the machine's own is used, and the answer says when it fell back to UTC.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false and openWorldHint=true; the description goes well beyond that by disclosing the two created resources, the returned snippet, idempotent re-run behavior that avoids a second property, and an explicit side-effect boundary ('still never changes which property is the saved default'). For a mutating tool with no output schema, that is rich 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?

Three sentences, all load-bearing: the first covers the create-and-return action, the second the idempotency rule, the third the mutation-scope boundary. The most important facts are front-loaded and there is no filler.

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?

With no output schema and no annotations carrying behavioral detail, the description still covers what is created, what is returned (the gtag.js snippet), re-run semantics, and the boundary of what is not modified. An agent has everything needed to call it correctly and interpret the result.

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 domain, account, currency, and timezone, and the description adds no syntax or format detail beyond it. It only implies the domain parameter's role through the setup narrative, which lands at the baseline for a fully-documented 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?

States a specific verb and resource ('creates the property and its web data stream'), and names the concrete artifact returned ('the gtag.js snippet to paste into the site's <head>'). This clearly separates it from the read-only siblings like list_properties and site_status without opening either schema.

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?

Gives an explicit precondition ('a domain the account does not measure yet') and explains the re-run case, so the agent knows when the tool is idempotent rather than duplicative. It also flags that this is the only writing tool among the siblings, which is a strong routing signal, though it never names a specific alternative tool to use instead when the domain is already measured.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources