Skip to main content
Glama
Sign In

CiteLadder

by com.citeladder
OverviewDiscussionsAdmin

Read AI traffic by page

read_ai_traffic_pages
Read-onlyIdempotent

Rank the project's own pages by AI activity, to find which pages AI crawlers fetch, AI assistants send visitors to and AI answers cite. Each row is one page (URL, path, folder, resource class) with four measures, each carrying its own coverage: AI crawler requests (server logs), AI referral sessions and key events (GA4), citations in AI answers, and Site Health findings, plus its last crawl. The window defaults to the last 30d; rows come 10 per page (up to 100); pass next_cursor for more. observed_crawl_coverage says how complete the logs are, and a measure without a connected source is missing, not zero. Use read_ai_traffic_url for one page's timeline, read_crawl_logs for crawler-level detail, read_ai_referrals for site-wide referral totals, and read_site_pages for crawl data such as titles and scores.

Input Schema

NameRequiredDescriptionDefault
sortNoRow order by one measure, highest first, or by URL; omit for the default. Filters (folder, resource_class, verification) apply first.
limitNoHow many rows to return; omit for the default page size.
rangeNoA preset window ending today; or pass start_date and end_date instead.
cursorNoThe next_cursor a previous page returned.
folderNoA site path prefix such as /blog/ to read only pages under it.
end_dateNoLast day of a custom window, inclusive.
project_idYesA project id that list_projects returned.
start_dateNoFirst day of a custom window, inclusive.
verificationNoKeep only crawler requests whose claimed identity was verified, could not be verified, or failed verification.
resource_classNoA resource_class a previous row returned, such as page, to read only that kind.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changed
    • addedInput schema / properties / cursor / description
      Added value: +"The next_cursor a previous page returned."
    • changedInput schema / properties / cursor / type
      Previous value: -[
-  "string",
-  "null"
-]New value: +"string"
    • addedInput schema / properties / end_date / description
      Added value: +"Last day of a custom window, inclusive."
    • addedInput schema / properties / folder / description
      Added value: +"A site path prefix such as /blog/ to read only pages under it."
    • addedInput schema / properties / limit / description
      Added value: +"How many rows to return; omit for the default page size."
    • addedInput schema / properties / project_id / description
      Added value: +"A project id that list_projects returned."
    • addedInput schema / properties / range / description
      Added value: +"A preset window ending today; or pass start_date and end_date instead."
    • addedInput schema / properties / resource_class / description
      Added value: +"A resource_class a previous row returned, such as page, to read only that kind."
    • addedInput schema / properties / sort / description
      Added value: +"Row order by one measure, highest first, or by URL; omit for the default. Filters (folder, resource_class, verification) apply first."
    • addedInput schema / properties / start_date / description
      Added value: +"First day of a custom window, inclusive."
    • addedInput schema / properties / verification / description
      Added value: +"Keep only crawler requests whose claimed identity was verified, could not be verified, or failed verification."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare the safe read-only/idempotent profile, and the description still adds genuinely non-obvious behavior: per-measure coverage, the rule that a measure without a connected source is 'missing, not zero', observed_crawl_coverage as a log-completeness signal, default 30d window, and 10-per-page/100-cap pagination via next_cursor. These are the traps an agent would otherwise fall into.

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?

Front-loads purpose, then row shape, then windowing/pagination, then sibling routing — a sensible information order with no filler sentences. It is dense and slightly long, but every clause carries operational meaning rather than restating the name.

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?

No output schema exists, so the description carries the return-value burden — and it does, naming the row fields (URL, path, folder, resource class), the four measures, and the last crawl. Combined with coverage and pagination semantics, an agent has everything needed to call and interpret this correctly.

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 supplies defaults the schema omits (30d window, 10 rows per page up to 100, pass next_cursor for more). It does not add syntax beyond the schema for sort/filter enums, so it lands just above baseline rather than at the top.

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?

Opens with a specific verb and resource ('Rank the project's own pages by AI activity') and immediately disambiguates the scope: the project's own pages, ranked by AI activity, not site-wide totals. The three sub-questions (crawler fetches, assistant referrals, answer citations) make it unmistakable versus read_ai_referrals or read_crawl_logs.

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

Usage Guidelines5/5

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

Explicitly routes to four named alternatives with the condition that selects each: read_ai_traffic_url for a single page timeline, read_crawl_logs for crawler-level detail, read_ai_referrals for site-wide totals, read_site_pages for titles/scores. This is a complete when-to-use map rather than an implied one.

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

All CiteLadder 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