Skip to main content
Glama
Sign In

Convika

by com.convika
OverviewDiscussionsAdmin

Diagnose page performance

analyze_site_performance
Read-onlyIdempotent

Analyze a landing page's aggregate analytics and return a compact diagnosis with prioritized next actions.

Use when the user asks what to improve, why conversions changed, whether traffic quality is healthy, or what to test next. This tool does NOT return raw event logs or form submission payloads. It returns aggregate metrics, top drivers, findings, evidence, and recommendations. Periods: 7d (default), 30d, 90d | 180d, 365d, all (Pro/MAX only). With 90d, a timeZone other than the workspace's leaves the change figures null, except for form submissions: the previous 90 days come only from daily summaries kept in the workspace's time zone. Leave timeZone out for 90d changes. Dates and hours are in the workspace's time zone, UTC when the workspace has none set. Pass timeZone, an IANA name such as America/New_York, for days in another zone; it changes only this response, never the workspace's time zone. The result's timeZone field names the zone used, and timeZoneSource says where it came from (argument, workspace, or default). A row for today's date in that zone counts only the hours so far. When timeZonePending is set, the workspace is switching to that zone once its history is recomputed. 180d, 365d, and all come from daily summaries kept in the workspace's time zone, so a different timeZone isn't used there: the result stays in the summaries' zone and names the zone you passed as requestedTimeZone.

Input Schema

NameRequiredDescriptionDefault
periodNoTime period for the diagnosis. 180d/365d/all require Pro or MAX plan.7d
siteIdYesThe ID of the page to analyze
timeZoneNoIANA time zone name for the days in this response, such as America/New_York, Europe/Berlin, or Asia/Tokyo. Leave it out for the workspace's time zone (UTC when none is set). It affects only this response: the workspace's time zone stays as it is, and only the workspace's owner changes it, in the dashboard's Settings. Abbreviations such as EST and offsets such as +09:00 aren't accepted.
botFilterNoWhether to exclude known bots and vulnerability scanner traffic. Defaults to exclude. Use include only for diagnostics.exclude

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / siteId / description
      Previous value: -"The ID of the site to analyze"New value: +"The ID of the page to analyze"
  2. Changed1 schema field changed
    • addedInput schema / properties / timeZone
      Added value: +{
+  "description": "IANA time zone name for the days in this response, such as America/New_York, Europe/Berlin, or Asia/Tokyo. Leave it out for the workspace's time zone (UTC when none is set). It affects only this response: the workspace's time zone stays as it is, and only the workspace's owner changes it, in the dashboard's Settings. Abbreviations such as EST and offsets such as +09:00 aren't accepted.",
+  "maxLength": 64,
+  "type": "string"
+}
  3. Changed1 schema field changed
    • changedInput schema / properties / period / description
      Previous value: -"Time period for the diagnosis. 180d/365d/all require Pro or Max plan."New value: +"Time period for the diagnosis. 180d/365d/all require Pro or MAX plan."
  4. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive, closed-world, so the description spends its budget on genuinely non-obvious behavior: what the response contains (aggregate metrics, top drivers, findings, evidence, recommendations), the Pro/MAX plan gate for long periods, and that the response echoes timeZone/timeZoneSource/timeZonePending. The 90d caveat that change figures come back null with a mismatched timeZone, and that 180d/365d/all ignore the passed zone and echo it as requestedTimeZone, are exactly the surprises an agent would otherwise trip over.

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?

Purpose and usage are correctly front-loaded, but the time-zone material sprawls across two long paragraphs with overlap ("it changes only this response" restated as "affects only this response: the workspace's time zone stays as it is"). The IANA-name examples are repeated in both the description and the schema's timeZone description. Tightening to roughly half the length would lose no 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?

With no output schema, the description carries the return-value burden and does so by enumerating the diagnosis sections and ruling out raw events. Plan gating and time-zone edge cases are covered. Minor gaps: botFilter's diagnostic use case and whether recommendation/finding counts are bounded are untouched.

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, and the description earns above that by explaining interactions the schema does not: period and timeZone are coupled (90d null changes; summary-based periods ignore the zone), and today's row is partial. botFilter is left entirely to the schema, which does cover it adequately.

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?

Opens with a specific verb+resource ("Analyze a landing page's aggregate analytics") and names the distinct deliverable ("compact diagnosis with prioritized next actions"). It also carves out what it is not ("does NOT return raw event logs or form submission payloads"), which separates it from get_analytics_detail-style siblings. It stops short of naming which sibling to use for raw metrics or timeseries.

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?

"Use when the user asks what to improve, why conversions changed, whether traffic quality is healthy, or what to test next" gives four concrete triggering intents an agent can match against a user request. The exclusion of raw logs/payloads adds a clear when-not condition. There is no explicit routing to get_analytics_summary, detect_trend, or query_timeseries for the adjacent cases.

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

All Convika toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources