get_analyticsThe site's private first-party traffic: pageviews/visitors/sessions/clicks totals, top pages, referrers, devices. Windows: 24h, 7d, 30d.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| window | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that the tool is read-only, and the description adds that the data is 'private first-party traffic', which is useful context. However, it does not disclose return format, pagination, or any rate-limiting beyond what is implied by 'windows'. With the annotation covering safety, the description adds moderate behavioral value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose ('The site's private first-party traffic') followed by the metrics and windows. Every word adds value, with no redundancy. It is efficiently structured for quick agent parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set (two parameters, one required) and the readOnly annotation, the description provides a clear scope of what data is returned (metrics and windows). Since there is no output schema, it goes partway by enumerating the returned metrics, though it does not explicitly describe the response format (e.g., whether it is a flat object or nested). For a read-only analytics tool, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It explains the 'window' parameter by listing the allowed values (24h, 7d, 30d), which aligns with the enum. The 'slug' parameter is only implied as the site identifier ('The site's...'), with no explicit definition. This partial compensation is adequate but not thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('get') and resource ('site analytics'), and enumerates the exact metrics returned (pageviews, visitors, sessions, clicks, top pages, referrers, devices) and available windows (24h, 7d, 30d). This clearly distinguishes it from sibling tools like get_site or get_build_status, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when site traffic analytics are needed, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusion conditions or prerequisites. For instance, there is no guidance about needing a site slug from a prior call or whether this works for unbuilt sites. Usage is inferred from context but not made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool maps to a distinct action/resource, with create, edit, file access, publishing, status, analytics, domains, and account clearly separated. The only possible ambiguity is edit_site vs write_site_files, since both modify a draft, but the descriptions clarify AI edit vs direct file push.
Most tools follow a predictable verb_noun snake_case pattern (create_site, list_sites, publish_site), which makes the set easy to navigate. Minor deviations: whoami doesn't follow the pattern, and get_analytics omits the site qualifier.
Twelve tools is a well-scoped size for a hosted website builder; the set covers creation, editing, file management, publishing, build status, analytics, domains, and account access. Each tool earns its place without bloating the surface.
The surface covers the core lifecycle well: create, draft/file read/write, publish, status, listing/details, analytics, and account. Missing delete/unpublish and a tool for reading form submissions are gaps, but they are minor relative to the covered workflows.