Skip to main content
Glama

devtune_get_visits_per_answer_fetch

Read-onlyIdempotent

Get AI-referred visits per answer fetch for each page and for the whole project over a fixed window of completed UTC days ending the day before yesterday. answerFetches counts AI systems retrieving the page while building an answer; aiReferralVisits counts visits that arrived from an AI answer; visitsPerAnswerFetch is visits divided by fetches. An answer fetch is not a citation: the answer may not have linked or named the page. A page's coverage is covered when its visits come from GA4 or PostHog and that provider has synced the whole window, or from the traffic snippet and it reported on the page's host for every full UTC day of the window (running the day before it starts and the day after it ends); referralSource says which (ga4, posthog or snippet). Other pages are no_referral_data (no complete referral data for this window), with aiReferralVisits and visitsPerAnswerFetch null, never 0; read referralSource only on covered pages. visitsPerAnswerFetch is also null when answerFetches is 0. summary is the project total over every page with activity, returned only when all are covered; otherwise it is null and summaryWithheldReason is partial_coverage (excludedAnswerFetches counts the answer fetches on uncovered pages), page_limit (the total could not be checked for every page) or no_activity. Covered pages are ranked by visitsPerAnswerFetch, highest first, with pages that have no ratio after them; no_referral_data pages follow, by answerFetches. The list is capped at pageLimit; pageLimitReached is true when the cap was reached. A cursor from an earlier read is rejected once a late import changes the ranking; start again without it.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "devtune_get_visits_per_answer_fetch"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoThe same setting as pageSize. Send either.
cursorNoOpaque cursor from the previous response; cursors expire after ~48 hours.
pageSizeNoResults per page (1-100). Defaults to 25.
windowDaysNoFixed rolling window in days: 7, 30, or 90. Defaults to 30.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / cursor / maxLength
      Added value: +1024
  2. Changed1 schema field changed
    • addedInput schema / properties / limit
      Added value: +{
      +  "$ref": "#/properties/pageSize",
      +  "description": "The same setting as pageSize. Send either."
      +}
  3. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description goes far beyond: it defines coverage rules per provider, null-vs-zero semantics, ranking/ordering, summary withholding reasons (partial_coverage, page_limit, no_activity), and cursor invalidation on late imports.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first sentence and every subsequent sentence carries substantive contract detail. It is long, but the density is largely justified by the complex null/coverage semantics, with only minor over-explanation.

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, the description carries the full burden and delivers: it documents the return fields (summary, summaryWithheldReason, referralSource, pageLimitReached, excludedAnswerFetches), ordering, and null conditions, so an agent can interpret results without additional context.

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, but the description adds real meaning: windowDays is a fixed rolling window of completed UTC days, and the cursor is rejected once a late import changes the ranking (beyond the schema's ~48h expiry note).

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 (AI-referred visits per answer fetch) with explicit scope: per page and whole project, over a fixed window of completed UTC days ending the day before yesterday. It defines a distinctive metric (visitsPerAnswerFetch) that clearly separates it from siblings like get_ai_referrals or get_recent_answer_fetches.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description heavily explains interpretation semantics but never explicitly says when to choose this tool over siblings, nor names an alternative. Usage is implied by the metric definition rather than routed.

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