Skip to main content
Glama
Sign In

CiteLadder

by com.citeladder
OverviewDiscussionsAdmin

Read AI crawler visits

read_crawl_logs
Read-onlyIdempotent

Read the AI crawler requests your server logs recorded, to see which crawlers actually visited, what they fetched and what they got back. View summary (the default) gives totals: requests, pages, active crawlers, error share and a daily series by purpose. View crawlers gives one row per crawler with status codes and verification. View coverage says how complete each day of logs is. View requests lists individual requests. The window defaults to the last 30d, except that requests without range or dates reads every retained day. The paged views return 10 rows by default (up to 100) with a top-level next_cursor; changing a filter needs a new first page, while a continuation may change limit. Failed-verification requests are left out unless verification asks for them. connection not_connected or missing coverage means unknown, not zero. Use read_ai_crawlability for robots permission and read_ai_traffic_pages for activity per page.

Input Schema

NameRequiredDescriptionDefault
viewNosummary is totals; crawlers is one row per AI crawler; coverage is how complete each day of logs is; requests lists individual requests, paged.summary
limitNoHow many rows to return; omit for the default page size.
rangeNoA preset window ending today; or pass start_date and end_date instead.
bot_idNoA bot_id the crawlers view returned; keep only that crawler.
cursorNoThe next_cursor a previous page returned.
folderNoA site path prefix such as /blog/ to read only pages under it.
statusNoAn HTTP status code; keep only requests answered with 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. Changed14 schema fields changed
    • addedInput schema / properties / bot_id / description
      Added value: +"A bot_id the crawlers view returned; keep only that crawler."
    • changedInput schema / properties / bot_id / type
      Previous value: -[
-  "string",
-  "null"
-]New value: +"string"
    • 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 / start_date / description
      Added value: +"First day of a custom window, inclusive."
    • addedInput schema / properties / status / description
      Added value: +"An HTTP status code; keep only requests answered with it."
    • addedInput schema / properties / verification / description
      Added value: +"Keep only crawler requests whose claimed identity was verified, could not be verified, or failed verification."
    • addedInput schema / properties / view / description
      Added value: +"summary is totals; crawlers is one row per AI crawler; coverage is how complete each day of logs is; requests lists individual requests, paged."
  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 cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely non-obvious behavior: the 30d default window with the exception that requests without range/dates reads every retained day, failed-verification requests being silently excluded unless requested, and the caveat that 'not_connected or missing coverage means unknown, not zero' — a real misinterpretation trap.

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-loaded with purpose then view-by-view breakdown, and nearly every sentence carries operative information. It is dense and long for a description, but the length is driven by four distinct modes and pagination rules rather than filler.

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?

For a 12-parameter tool with no output schema, the description supplies what is otherwise missing: the shape of each view's result (totals and daily series, one row per crawler, per-day completeness, individual requests) plus pagination and cursor behavior. Nothing material needed to call it correctly is absent.

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 per-parameter meaning is already documented; the description nonetheless adds cross-parameter rules the schema cannot express (changing a filter requires a new first page, a continuation may change limit, range vs start/end date alternation, bot_id sourced from the crawlers view). It does not restate every filter, but the added interaction semantics are the valuable part.

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 ('Read the AI crawler requests your server logs recorded') and immediately enumerates the four views and what each returns. It also names the two nearest siblings (read_ai_crawlability, read_ai_traffic_pages) and the distinct question each answers, so an agent can route without opening schemas.

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 maps intent to view: totals → summary (the default), per-crawler status → crawlers, log completeness → coverage, individual hits → requests. It adds exclusions ('Use read_ai_crawlability for robots permission and read_ai_traffic_pages for activity per page') so the agent knows 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.

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