list_sitesAll sites on this account, with the public site codes used in their script tags and the ready-to-paste script_tag for each.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| sites | Yes | ||
| account | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful context about the account scope and the included fields, but it does not disclose additional behavioral traits such as pagination, ordering, or any access requirements. With annotations covering the safety profile, this is adequate but not exceptional.
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 and immediately states the account scope and key output fields. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only list tool with an existing output schema, this description is complete. It tells the agent what the tool returns and the scope of the data, which is sufficient 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema leaves no ambiguity. The description adds semantic value by clarifying what will be returned for the account, making it clear that no additional arguments are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all sites on the account and specifies the key output contents: public site codes and ready-to-paste script tags. It is specific about verb and resource, though it does not explicitly differentiate itself from sibling tools like get_site_context or get_overview.
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 gives clear context that this is for retrieving all sites on the account, with no filtering or parameters. It implies the appropriate use case but does not explicitly state when to prefer it over alternatives or mention exclusions.
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 resource or action: site management, site context, annotations, overviews, dimensional queries, funnels, journeys, and anomaly checks. Overlapping pairs like funnel/journeys are explicitly disambiguated in the descriptions, and what_broke vs what_changed cleanly separate problems from notable movements.
Most tools follow a clear verb_noun pattern such as create_site, list_annotations, and update_site_context, but funnel, journeys, portfolio_overview, what_broke, and what_changed break that pattern. The names are still readable and somewhat grouped by intent, but the mixed conventions make it harder to predict a tool's role from its name alone.
At 15 tools this sits at the upper edge of the ideal range, and each tool earns its place: site lifecycle, context, annotation timeline, core analytics, discovery reports, and post-deploy checks are all covered. There is no obvious redundancy or filler.
The set covers site management, context editing, annotations, overview/query/funnel/journeys/portfolio analytics, and what_broke/what_changed checks, so most workflows have no dead ends. Minor gaps exist, such as no way to edit or delete a mistaken annotation and no explicit tool for updating data-retention settings, but these are workaroundable rather than blocking.