Privacy-first, cookieless web analytics hosted in the EU. Ask about visitors, pages, traffic sources, countries, goals, funnels and live traffic for your sites, and set up sites, goals and funnels. 25 tools. OAuth 2.1 sign-in in the browser, or an API key as a Bearer token.
Realtime count of unique visitors active in the last 5 minutes for a site. Returns {"site_id":123,"visitors":N}.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Numeric site_id (preferred, from list_sites) or a domain, e.g. example.com — scheme, www. and path are ignored when matching. If several sites share the domain the call fails and lists their site_ids. Omit for a single-site key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint:true already signals a safe read operation, lowering the bar. The description adds useful context by specifying the realtime nature and the exact return format, which is not redundant. However, it does not mention potential failure modes or rate limits, but these are not critical given the annotation.
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 two concise sentences: one for the function, one for the return shape. The parameter description is also succinct but informative. No redundant or verbose wording is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of an output schema, the description provides enough context: it states the input parameter's format, the return object, and that it is realtime. The absence of error handling or response status details is acceptable for a straightforward read-only metric.
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 sole parameter 'site' is described in detail: preferred numeric site_id, alternative domain format, handling of scheme/www/path, and failure behavior when multiple sites share a domain. This goes beyond the schema and provides complete guidance for correct usage, so the parameter semantics are excellent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: counting unique visitors active in the last 5 minutes for a site. It specifies the resource (visitors), the timeframe (realtime, 5 minutes), and the return shape. This distinguishes it from other analytics tools like query_stats or top_pages.
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 does not explicitly state when to use this tool over alternatives. It mentions 'realtime' but does not provide guidance such as 'Use this for current visitor counts, and query_stats for historical data.' An agent could infer, but the instruction is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a saved conversion funnel and return its per-step result (NON-tabular). Returns {"funnel":{"id","name","scope"},"entering":N,"all_visitors":N,"steps":[{"index":0,"name":"Visited /pricing","kind":"page","visitors":N,"conversion_rate":percent0to100,"dropoff":N}, ...]}. steps are ORDERED; conversion_rate is cumulative vs the first step (entering), NOT step-to-step; dropoff is visitors lost vs the previous step. Get funnel_id from list_funnels first.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Numeric site_id (preferred, from list_sites) or a domain, e.g. example.com — scheme, www. and path are ignored when matching. If several sites share the domain the call fails and lists their site_ids. Omit for a single-site key. | |
| period | No | "7d"/"30d", or any "Nd" = last N full days (N = 1..90); "month" = current calendar month to date. Default 30d. Or a custom ["YYYY-MM-DD","YYYY-MM-DD"] pair. | |
| filters | No | Optional SEGMENT filters (session-level only: country/browser/os/device/source/channel/utm_*/entry_page/exit_page/hostname). Event-level fields are rejected. | |
| funnel_id | Yes | Funnel id from list_funnels. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safety, and the description adds substantial behavioral detail: steps are ordered, conversion_rate is cumulative vs the first step, dropoff is vs previous step, and the exact JSON response shape is provided. This goes well beyond the annotation and leaves little ambiguity about output semantics.
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 front-loaded with the core purpose, then delivers the exact return shape, key ordering rules, and the prerequisite in a compact, information-dense format. Every sentence earns its place; there is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema present, the description fully explains the return value, including field-level semantics, ordering, and formulas for conversion_rate and dropoff. It also provides the critical prerequisite for obtaining funnel_id and notes a relevant edge case for site disambiguation. The description is complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mostly reinforces the schema's parameter guidance (e.g., funnel_id from list_funnels) but does not add meaningful new meaning beyond what the schema descriptions already provide. The main added value is about output interpretation, not parameter semantics.
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 ('Run'), a specific resource ('a saved conversion funnel'), and the precise output ('per-step result (NON-tabular)'). It also distinguishes itself from table-style query tools by emphasizing NON-tabular and from funnel management tools like list_funnels by focusing on execution and report generation.
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 a clear prerequisite: 'Get funnel_id from list_funnels first.' It also conveys that this is the tool for running a saved funnel and getting per-step results, which differentiates it from query_stats and funnel creation/update tools. It does not explicitly list 'when not to use' alternatives, but the context is strong enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who gets counted on a site, and who may look at the stats. Response: {"site_id":123,"hostnames":{"allowed":[],"blocked":[]},"blocked_ips":["1.2.3.4"],"countries":{"allowed":[{"code":"UA","created_at":"RFC3339"}],"blocked":[]},"public_dashboard":false}. An empty allowed list means "no restriction", not "nothing allowed". public_dashboard true means the stats are readable by anyone with the link.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | site_id from list_sites. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint: true, and the description adds meaningful behavioral context beyond that. It explains the semantics of empty allowed lists ('no restriction') and public_dashboard meaning ('readable by anyone with the link'), which are non-obvious behaviors. This adds value without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with a clear purpose, then a detailed response example, and finally critical semantic clarifications. The response example is somewhat verbose but earns its place given the absence of an output schema. Overall, it is concise without unnecessary 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?
With no output schema, the description compensates by providing a complete response structure and explaining field meanings. It covers all relevant aspects an agent needs to interpret the results correctly. Combined with the single parameter and readOnly annotation, this is fully sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single parameter 'site', described as 'site_id from list_sites.' The description adds no additional parameter semantics beyond what the schema already provides. Baseline of 3 is appropriate since the schema carries the load.
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 retrieves site filters: 'Who gets counted on a site, and who may look at the stats.' It specifies the resource (site filters) and the verb (get). It also distinguishes itself from the sibling update_site_filters by describing a read operation, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a read operation but does not explicitly state when to use this tool versus update_site_filters or other siblings. No explicit 'use when' or 'use instead' guidance is provided. However, the context of siblings and the readOnlyHint annotation make the intended use reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The account's plan state — not a site's. Response: {"status":"trialing"|"active"|"past_due"|"expired"|"trial_expired"|"none","is_trial":true,"ends_at":"RFC3339","only_hobby":false}. ends_at is when the CURRENT state stops being true (trial end while trialing, period end otherwise) and is omitted when unknown. status "none" with only_hobby true means a free account, not a missing one. Takes no arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly explains the response structure, including all possible status values, the meaning of ends_at, and the interpretation of only_hobby. It also states that the tool takes no arguments, fully disclosing its behavior.
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 somewhat lengthy due to the embedded JSON and explanatory notes, but it is well organized and each part adds necessary detail. It could be more concise, but it remains efficient for conveying critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description fully compensates by specifying the response shape and semantics. It covers all field meanings and edge cases, making it complete for an agent to understand the tool's output.
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?
There are no parameters, and the description explicitly notes 'Takes no arguments.' This is sufficient and leaves no ambiguity about input expectations.
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 returns the account's plan state and distinguishes it from site-level data. It explicitly mentions it is not about a site, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It does not explicitly state when to use this tool, but the clarification that it is 'not a site's' helps differentiate it from site-related tools in the sibling list. This implicitly guides selection, though it lacks an explicit 'use when' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The script tag to install on a site, and the url it loads. Response: {"site_id":123,"type":"default","script_url":"https://...","snippet":"<script ...>"}. Install snippet verbatim; do not rebuild a tag from script_url. A hobby site's snippet also carries data-id, which is the only place the counter in its bundle reads the site id. Read-only: it reports the code, it does not install or verify anything.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | site_id from list_sites. | |
| type | No | Optional bundle variant; omit for the default script. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses non-obvious behavior: the tool does not install or verify anything, the snippet must be installed verbatim (not rebuilt), and the hobby site's data-id is the only place the counter reads the site ID. This is exactly the kind of added context an agent needs.
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 tight and front-loaded with the core purpose, then provides a response example and important caveats. It packs several instructions efficiently without fluff, though it is a bit long due to the embedded JSON example and multiple caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description is very complete: it includes a full response example, explains the read-only nature, advises on verbatim installation, and highlights the hobby-site gotcha. An agent has enough information to invoke the tool and interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the schema already documents the site and type parameters. The description adds a response example showing type='default' and a data-id note about the snippet, but it does not substantially enrich the meaning of the parameters beyond what the schema provides, so the baseline 3 is appropriate.
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 returns the script tag and the URL it loads, which is a specific verb-resource pairing. It is distinguishably about the install snippet rather than tracking settings or reports, so an agent can separate it from siblings like get_tracking_settings without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage instructions: install the snippet verbatim, do not rebuild from script_url, and note the hobby-site data-id caveat. It also states the tool is read-only and does not install or verify, giving useful context, though it does not explicitly name alternatives or 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.
List the conversion funnels configured for a site (discovery — get a funnel_id for funnel_report). Returns {"funnels":[{"id":45,"name":"Signup flow","scope":"visitor","steps_count":3}]}.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Numeric site_id (preferred, from list_sites) or a domain, e.g. example.com — scheme, www. and path are ignored when matching. If several sites share the domain the call fails and lists their site_ids. Omit for a single-site key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already discloses the read-only nature, and the description's verb 'List' is consistent with that. The description adds value by including a concrete example of the return payload, which helps the agent understand the shape and fields of the result. It does not contradict annotations, and while it doesn't discuss rate limits or auth, those are not expected for a simple list operation with this level of annotation coverage.
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 two sentences: the first states the purpose and intended use, the second provides a compact example of the return structure. Every element earns its place, with no filler or redundancy. The purpose is front-loaded, and the example is succinctly formatted.
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 list tool with one optional parameter and no output schema, the description is complete. It clearly states what the tool does, why it is used, and includes an example of the response structure. The annotation covers the read-only safety aspect, and the schema covers parameter details. There are no missing pieces an agent would need to call it 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 input schema provides a thorough description of the site parameter, covering accepted formats (numeric ID or domain), normalization behavior (scheme/www/path ignored), error handling for shared domains, and the omission rule. Since schema description coverage is 100%, the tool description adds nothing beyond the example output, which pertains to the response rather than the parameter. A baseline of 3 is appropriate because the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'List the conversion funnels configured for a site'. It specifies the resource (funnels) and the scope (per site), and explicitly frames it as a discovery step to obtain a funnel_id for funnel_report. This distinguishes it from sibling tools like create_funnel or funnel_report without ambiguity.
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 includes a parenthetical '(discovery — get a funnel_id for funnel_report)' that explicitly states when to use this tool: as a precursor to funnel_report. The schema further elaborates usage conditions, such as omitting the site parameter for single-site keys and the behavior when multiple sites share a domain. Together, these provide clear guidance on when and how to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The goals CONFIGURED on a site — what it measures, not how those goals performed. Use top_goals for conversion numbers. Response: {"goals":[{"id":7,"name":"Signup","event_name":"Signup"|null,"path":"/thanks"|null,"operator":"e|b|c","scroll_depth":N|null}]}.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | site_id from list_sites. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation, so the description does not need to repeat that. It adds value by explaining the semantic scope (configured goals, not performance) and providing the exact response shape, giving the agent expectations beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: the first differentiates the tool from alternatives, the second gives the complete response shape. No filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter, read-only list operation with no output schema, the description supplies the necessary return shape and disambiguates the semantics. Nothing essential is missing 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter has 100% schema description coverage ('site_id from list_sites'), so the schema carries the semantic load. The description adds only the general context that goals are configured 'on a site,' which aligns with the parameter but does not materially extend its meaning.
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?
States a specific verb ('list') and resource ('goals CONFIGURED on a site'), and immediately clarifies what it does not do ('not how those goals performed'). This cleanly distinguishes it from top_goals without needing 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent when to use this tool versus an alternative: use top_goals for conversion numbers. The phrase 'what it measures, not how those goals performed' frames the appropriate use case clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the custom-property keys a site has recorded (with the event each belongs to) — discovery for the event:props: breakdown in query_stats. Returns {"props":[{"key":"plan","event":"Signup","count":N,"first_seen":"RFC3339"}]}.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Numeric site_id (preferred, from list_sites) or a domain, e.g. example.com — scheme, www. and path are ignored when matching. If several sites share the domain the call fails and lists their site_ids. Omit for a single-site key. | |
| period | No | "7d"/"30d", or any "Nd" = last N full days (N = 1..90); "month" = current calendar month to date. Default 30d. Or a custom ["YYYY-MM-DD","YYYY-MM-DD"] pair. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that the tool is non-mutating, so the description does not need to repeat safety claims. The description adds useful behavioral context by showing the exact return shape, including key, event, count, and first_seen, and clarifies the operation is purely discoverable listing rather than a query or aggregation.
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, information-dense sentence followed by a compact return example. The purpose is front-loaded, the query_stats connection is included, and the output shape is shown without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with two optional, fully documented parameters and no output schema, the description provides the key behavioral context: what is listed, how it relates to query_stats, and the exact response structure. Nothing essential for invoking it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of both parameters, including detailed descriptions for site and period. The tool description does not add parameter-level meaning beyond the schema, so a baseline score of 3 is appropriate: the schema carries the semantic load.
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 uses a specific verb and resource: 'List the custom-property keys a site has recorded,' and clarifies it returns the associated event for each key. It also explicitly positions the tool as discovery for the event:props:<key> breakdown in query_stats, which distinguishes its purpose from the sibling query_stats tool.
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 by stating this is a discovery step for the event:props:<key> breakdown in query_stats, so an agent knows when it is relevant. It does not explicitly name alternatives or exclusions, but the intended use case is strongly implied and specific enough for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the sites this API key can read. Response: {"sites":[{"site_id":123,"name":"<as entered by the owner — often a full URL like https://example.com/>","hash":"07k1eD84d2","timezone":"Europe/Amsterdam","hobby":false,"stats_start_date":"YYYY-MM-DD"|null,"created_at":"RFC3339"}]}. hobby=true is a free-plan site: it counts only through the bundled /t/ script get_tracking_snippet returns, so install that snippet verbatim. Use site_id with the other tools. With date_range each site also carries metrics NESTED under stats.metrics (never flat on the site object). Units: visit_duration = average seconds per visit; bounce_rate = percent 0-100; views_per_visit = pageviews/visits ratio; visitors/pageviews/visits = counts. Stats period boundaries are server-time approximations; use query_stats for timezone-exact numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| date_range | No | Optional. "7d"/"30d"/"month"/"realtime" or "Nd" for the last N days (1-90), e.g. "7d". Each site then gets {"stats":{"date_range":"7d","metrics":{"visitors":N,"pageviews":N,"visits":N,"visit_duration":seconds,"bounce_rate":percent0to100,"views_per_visit":ratio}}}. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint, so the description carries the full burden. It discloses response structure, hobby-plan counting limitations, nested metrics behavior, units, and timezone approximations. This is far beyond what readOnly can convey.
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?
Every sentence earns its place: purpose, response example, hobby caveat, downstream usage, nested-metrics warning, unit definitions, and timezone boundary caveat. The content is dense but well-structured and front-loads the core purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by providing a full response example, unit definitions, and edge-case behavior. Nothing needed to correctly invoke the tool or interpret its result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description already covers 100% of date_range, so the baseline is 3. The description adds meaning by emphasizing that metrics are nested under stats.metrics (never flat), and by warning that time boundaries are server-time approximations requiring query_stats for exact values. This adds behavioral nuance not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('List'), resource ('sites'), and scoping condition ('this API key can read'), which clearly identifies the operation. The resource differntiation from sibling tools like list_funnels and list_goals is implicit but sufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context: date_range behavior, how to use returned site_id with other tools, and when to prefer query_stats for timezone-exact numbers. It also gives actionable guidance for hobby sites. This is strong routing and alternative-avoidance information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a read-only analytics query for one site: aggregate totals, a time series, or a top-N breakdown. Returns {"results":[{"dimensions":{...omitted for aggregates},"metrics":{...}}]}. All dates and time buckets are in the site's own timezone (see list_sites .timezone). The event:name breakdown lists custom events (data-statable-event); its events metric is the raw event count. The event:goal breakdown lists the site's configured goals with visitors (converters), events (conversions) and conversion_rate (percent). events/conversion_rate are breakdown-only (rejected on aggregate/time-series or a dimension that doesn't compute them). Units: visit_duration = average seconds per visit; bounce_rate = percent 0-100; views_per_visit = pageviews/visits ratio; visitors/pageviews/visits = counts.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Numeric site_id (preferred, from list_sites) or a domain, e.g. example.com — scheme, www. and path are ignored when matching. If several sites share the domain the call fails and lists their site_ids. Omit for a single-site key. | |
| limit | No | Breakdown only. Default 100, max 1000. | |
| compare | No | "previous_period" (equal-length window before date_range) or a custom ["YYYY-MM-DD","YYYY-MM-DD"] pair. Adds a compare {value, change%} block: per-metric (aggregate), per-row (breakdown; not event:status_code/event:goal), or per-bucket (time-series). Time-series needs an equal-length range (else compare_length_mismatch). | |
| filters | No | ||
| metrics | Yes | ||
| date_range | Yes | Preset "7d" or "30d" (last N full days), "month" (current calendar month to date; the first bucket may land on the prior month's last day), "realtime" (last ~30 min — pair with the time:minute dimension), "Nd" for the last N days (1..90, e.g. "14d"), or a custom inclusive ["YYYY-MM-DD","YYYY-MM-DD"] pair (over 90 days use a custom pair). | |
| dimensions | No | Zero = aggregate; one time dimension (time, time:hour, time:day, time:week, time:month) = time series; one breakdown dimension = top-N. Besides the enum you may also pass a dynamic 'event:props:<key>' dimension to break a custom event down by one of its property values (metrics visitors + events) — it REQUIRES an 'event' filter to name the event, e.g. dimensions:['event:props:plan'] + filters:[{field:'event',operator:'is',values:['Signup']}]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and the description independently reaffirms this with 'read-only'. It adds meaningful context beyond annotations: timezone behavior, per-metric units, breakdown-only restrictions, event/goal semantics, and compare block structure. This gives an agent useful expectations without contradicting the annotation.
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 dense and front-loaded with the primary purpose. Every sentence adds operational detail, but it is a long single paragraph that packs many distinct behaviors together; clearer structural breaks would improve scannability. Still, nothing is wasted.
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 complex analytics tool without an output schema, the description covers the response shape, units for most metrics, timezone handling, filter encoding, and special event/goal behavior. Minor gaps remain: units for metrics like engagement_time, time_on_page, scroll_depth, and exit_rate are not explained, and no advice on pagination or very large results is given.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 71% schema description coverage, the description adds substantial meaning for parameters: date_range presets and custom pairs, compare's equal-length rule and block shapes, filters' round-trip code semantics, dynamic event:props dimensions, and units for multiple metrics. This goes well beyond what the raw schema alone communicates.
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 opens with a specific verb and resource: 'Run a read-only analytics query for one site', and immediately scopes the three output modes (aggregate totals, time series, top-N breakdown). This clearly distinguishes the tool from specialized siblings like current_visitors, top_countries, or visitors_over_time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: any analytics query for one site with aggregate, time-series, or breakdown needs. It explains key constraints like breakdown-only metrics and compare behavior, though it does not explicitly enumerate alternatives or when-not-to-use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top countries by visitors for a site. Returns {"results":[{"dimensions":{"visit:country":"US"},"labels":{"visit:country":"United States"},"metrics":{"visitors":N}}]} — the dimension value is the ISO alpha-2 code (drops straight into a country filter); the display name is in labels.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Numeric site_id (preferred, from list_sites) or a domain, e.g. example.com — scheme, www. and path are ignored when matching. If several sites share the domain the call fails and lists their site_ids. Omit for a single-site key. | |
| limit | No | Default 100, max 1000. | |
| period | No | "7d"/"30d", or any "Nd" = last N full days (N = 1..90); "month" = current calendar month to date. Default 30d. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beond the readOnlyHint annotation, the description discloses the exact return shape, the meaning of the dimension value (ISO alpha-2 code), and the distinction between the code and display label. This is high-value behavioral context, especially since there is no output schema.
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 short, front-loaded with the purpose, and the included JSON example earns its place by compensating for the missing output schema. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With all three optional parameters fully documented in the schema, the only material gap is the return contract, which the description supplies completely and precisely. An agent can invoke this tool and interpret the result without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameter descriptions, including defaults, patterns, and site_id vs domain behavior. The tool description adds no further parameter semantics, so the baseline of 3 applies.
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 phrase 'Top countries by visitors for a site' clearly names the resource (countries) and metric (visitors). It is readily distinguishable from sibling tools like top_pages, top_sources, and top_custom_events without needing to open the schema.
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 makes the use-case clear: a site's visitor rankings by country. It does not explicitly name alternative tools or say when not to use it, but the context is unambiguous enough that an agent can select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top custom events (data-statable-event) by count for a site — pageview/engagement excluded. Returns {"results":[{"dimensions":{"event:name":"Signup"},"metrics":{"events":N,"visitors":N}}]}, where events is the raw occurrence count and visitors is unique users who triggered it.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Numeric site_id (preferred, from list_sites) or a domain, e.g. example.com — scheme, www. and path are ignored when matching. If several sites share the domain the call fails and lists their site_ids. Omit for a single-site key. | |
| limit | No | Default 100, max 1000. | |
| period | No | "7d"/"30d", or any "Nd" = last N full days (N = 1..90); "month" = current calendar month to date. Default 30d. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the output format in detail, including the meaning of 'events' and 'visitors', and notes that pageview/engagement are excluded. This provides transparency beyond the schema. However, it does not mention any potential side effects or error scenarios, though the readOnlyHint annotation covers safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, presenting the output example and metric definitions in a single sentence. It avoids unnecessary verbosity while conveying essential information effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description provides a concrete example and explains the metrics. It covers the key aspects an agent needs to understand the response. It might be improved by mentioning potential error conditions or limits, but for the given complexity, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not discuss parameters at all. The schema already provides full coverage for site, limit, and period, each with descriptions. Since schema coverage is 100%, the description adds no extra parameter semantics, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Top custom events by count for a site' and explicitly excludes 'pageview/engagement'. This distinguishes it from sibling tools like top_pages and top_sources, making the intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies usage for retrieving custom event counts, but there is no direct guidance on choosing it over other top_* tools. The context from the sibling list helps, but it's not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The site's configured goals ranked by conversions. Returns {"results":[{"dimensions":{"event:goal":"Signup"},"metrics":{"visitors":N,"events":N,"conversion_rate":percent0to100}}]}, where visitors is unique converters, events is total conversions, and conversion_rate is visitors as a percent of all visitors in the period.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Numeric site_id (preferred, from list_sites) or a domain, e.g. example.com — scheme, www. and path are ignored when matching. If several sites share the domain the call fails and lists their site_ids. Omit for a single-site key. | |
| limit | No | Default 100, max 1000. | |
| period | No | "7d"/"30d", or any "Nd" = last N full days (N = 1..90); "month" = current calendar month to date. Default 30d. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description is consistent with it. It adds genuine value beyond the annotation by fully specifying the return shape and metric semantics (visitors = unique converters, events = total conversions, conversion_rate = converters as a percent of all visitors), plus the period scoping. Minor gaps: no disclosure of empty-result behavior or error cases, but acceptable for a read-only report tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: the first states the purpose, the second defines the return contract. Every element earns its place, and the purpose is front-loaded ahead of the example.
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?
There is no output schema, so the description correctly compensates by fully documenting the return JSON and each metric's meaning. All three optional parameters are schema-documented, and the read-only safety profile is covered by annotations. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents site, limit, and period fully. The description adds only marginal parameter context — tying the conversion_rate definition to 'all visitors in the period', which reinforces the period parameter. This matches the baseline 3 where the schema carries the load.
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+resource: 'The site's configured goals ranked by conversions'. The embedded return-format example with the event:goal dimension and conversion_rate metric makes the purpose unambiguous and clearly distinct from siblings like list_goals (plain listing), create_goal, or query_stats.
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 context — you call this when you want conversion-ranked goal data for a site — but it never explicitly says when NOT to use it or names alternatives among the 25 siblings (e.g., query_stats, funnel_report). No exclusions are given, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top pages by visitors for a site. Returns {"results":[{"dimensions":{"event:page":"/path"},"metrics":{"pageviews":N,"visitors":N}}]}.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Numeric site_id (preferred, from list_sites) or a domain, e.g. example.com — scheme, www. and path are ignored when matching. If several sites share the domain the call fails and lists their site_ids. Omit for a single-site key. | |
| limit | No | Default 100, max 1000. | |
| period | No | "7d"/"30d", or any "Nd" = last N full days (N = 1..90); "month" = current calendar month to date. Default 30d. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds useful behavioral context by showing the exact return shape and implying sort order by visitors, but it does not disclose other behavioral traits such as defaults or edge cases, which are left to 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence plus a compact JSON example, with no filler. The core purpose and expected output shape are front-loaded and immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The inline result shape compensates for the missing output schema, and all parameters are fully documented in the input schema, with the readonly annotation covering safety. The only notable gap is the absence of explicit sibling-selection guidance, making it slightly less complete than a fully self-contained definition.
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 100%, with clear descriptions for site, limit, and period. The tool description adds no additional parameter-level meaning beyond what the schema already provides, so the baseline score applies.
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 the resource ('pages'), the ordering metric ('by visitors'), and the site scope, and the JSON example clarifies it returns a read-only report. It distinguishes naturally from sibling top_countries/top_sources/top_goals, but does not explicitly name or contrast a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as top_countries, top_sources, or query_stats. The description only scopes to 'for a site' without explaining selection conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top traffic sources by visitors for a site. Returns {"results":[{"dimensions":{"visit:source":"Google"},"metrics":{"visitors":N,"bounce_rate":percent0to100}}]}.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Numeric site_id (preferred, from list_sites) or a domain, e.g. example.com — scheme, www. and path are ignored when matching. If several sites share the domain the call fails and lists their site_ids. Omit for a single-site key. | |
| limit | No | Default 100, max 1000. | |
| period | No | "7d"/"30d", or any "Nd" = last N full days (N = 1..90); "month" = current calendar month to date. Default 30d. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds a concrete response shape example showing dimensions and metrics, including bounce_rate, which goes beyond the annotation and gives the agent a clear expectation of the return format. No side effects or destructive behaviors are relevant here.
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 compact: one sentence defining purpose plus a short, illustrative JSON output example. Every part serves a purpose, and the example is valuable because there is no output schema. It is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only query tool, the definition is complete: parameters are fully documented in the schema, annotations communicate safety, and the description supplies the missing return shape through an example. It could additionally mention default ordering or that results are sorted by visitors descending, but this is reasonably implied by the word 'top.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of all three parameters with detailed explanations for site, limit, and period. The description does not add additional parameter-level meaning beyond the schema, so the baseline of 3 applies.
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 identifies the tool as returning top traffic sources ranked by visitors for a site. It states the key resource ('traffic sources') and the metric ('by visitors'), making the tool's intent understandable. It does not explicitly differentiate itself from sibling tools like top_countries or top_pages, but the resource name is sufficiently specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for site-level traffic source analysis, and the context is clear. However, it provides no explicit guidance on when to choose this tool over top_countries, top_pages, or other top_* siblings. The usage context is implied by the name and description rather than stated as a rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily visitors and pageviews time series for a site, in the site's own timezone. Returns {"results":[{"dimensions":{"time:day":"YYYY-MM-DD"},"metrics":{"visitors":N,"pageviews":N}}]}.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Numeric site_id (preferred, from list_sites) or a domain, e.g. example.com — scheme, www. and path are ignored when matching. If several sites share the domain the call fails and lists their site_ids. Omit for a single-site key. | |
| period | No | "7d"/"30d", or any "Nd" = last N full days (N = 1..90); "month" = current calendar month to date. Default 30d. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful context beyond annotations by specifying the site's own timezone and providing the exact JSON response shape, including dimensions and metrics. This is helpful for an agent predicting the output.
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?
A single front-loaded sentence with an inline JSON example makes the description compact and immediately usable. Every element adds value: the daily time-series scope, the timezone note, and the return format. No filler or redundant wording.
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 read-only time-series tool, the description is nearly complete: it defines the resource, the timezone, and the exact return structure via an example. Since there is no output schema, embedding the response JSON is valuable. It could optionally mention period edge cases or multi-site fallback, but those are already covered in the input schema. Overall, an agent can call this tool correctly with high confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the 'site' and 'period' parameters already documented in the schema. The description does not need to repeat parameter details. It adds no extra parameter-level semantics, so the baseline of 3 is appropriate.
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 and resource: 'Daily visitors and pageviews time series for a site.' This clearly distinguishes it from sibling tools like current_visitors (realtime) and top_pages (ranked pages), 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Daily ... time series' gives clear context for when the tool is appropriate: when the agent needs daily historical visitor/pageview data. It does not explicitly name alternatives or state when-not-to-use, but the temporal scope is strong enough for an agent to select it correctly in most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Most tools map cleanly to distinct resources and actions: sites, goals, funnels, tracking settings, filters, and statistics. Some ambiguity exists between the generic query_stats and the many top_* / visitors_over_time convenience queries, but the descriptions mostly clarify when each should be used.
The CRUD tools consistently use create_, get_, list_, and update_ prefixes, but a sizable minority deviate: top_* forms a separate pattern, and current_visitors, funnel_report, and visitors_over_time are noun-phrase names rather than verb_noun.
25 tools sits at the heavy end for an analytics server. Many top_* tools overlap with what query_stats could do, making the count feel somewhat inflated, though the domain is broad enough that the number is not unreasonable.
The tool set covers site management, goals, funnels, tracking, filters, and statistics well. However, there are no delete operations for sites, goals, or funnels, leaving an obvious lifecycle gap and no way to clean up configured resources.