Skip to main content
Glama
PROMPTEYE-SP-Z-O-O

prompteye-mcp

Official

List which bot asked for which page

list_crawls
Read-only

Check crawl history per page and bot to see which paths AI assistants and search engines fetched, when, and their last status code.

Instructions

One row per path and bot: when that bot first and last asked for the path, how many times, and the status it got the last time. Unlike list_bot_visits this covers everything since tracking began rather than a period, and is ordered by the last visit.

Coverage rather than volume. A page a bot has never fetched does not appear here at all, and cannot be quoted by that bot however well it answers the question. A lastStatusCode outside the 2xx range is worse than silence: the last thing that bot recorded about the page is that it was broken, and it carries that until it comes back.

Paths are in the same form get_sitemap reports, so an address listed there with no row here is a page nothing has ever come for.

Only the 3 000 most recently visited rows are searched, unless path names one page, which reads all of its rows.

A bot visit is a machine fetching a page, not a person reading one. It is the supply side of visibility: an assistant can only quote a page its bot was able to fetch, so this says whether the site is reachable and readable to them at all. It is a different measurement from being named in an answer (list_prompts, list_competitors), from being cited as a source (list_sources), and from somebody arriving afterwards (get_ai_traffic). kind=ai is the assistants; kind=seo is classic search engines and SEO tools.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNo`ai` for AI assistants and their bots, `seo` for search engines and SEO tools. Omit it for both.
pathNoOnly this exact path, without the domain and starting with `/`, e.g. `/pricing`.
botIdNoOnly this one bot, by the id the other traffic tools report — `chatgpt-user`, `gptbot`, `googlebot` and so on. An unknown id is rejected by the API rather than ignored.
limitNoHow many entries to return, at most 200. Defaults to 50.
cursorNoThe nextCursor of the previous page. Omit it to start from the first one.
vendorNoOnly bots run by this company, spelled as the API spells it: OpenAI, Anthropic, Google, Perplexity, Meta, Amazon, Apple, Microsoft, ByteDance, Yandex, DuckDuckGo, Ahrefs, Semrush, Moz, CommonCrawl, Mistral, Cohere and others. This is not the `assistant` of get_ai_traffic, which matches a referrer instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.16

TDQS

A5/5.0
Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses key behaviors: pages never fetched are absent, the 3,000-row search limit unless a single path is specified, and the interpretation of lastStatusCode outside 2xx as worse than silence. It also clarifies that bot visits are machine fetches, not human reads. This adds substantial context beyond annotations.

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

Conciseness5/5

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

The description is long but every sentence serves a purpose. It is front-loaded with the core output definition, then systematically covers exclusions, limits, and comparisons. The structure is logical and dense without redundancy, making it appropriately sized for the tool's complexity.

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?

Given 6 parameters, no output schema, and many sibling tools, the description is remarkably complete. It describes the row format, pagination via cursor and limit, the 3,000-row restriction, and the conceptual distinction from related tools. Nothing an agent needs to correctly call and interpret the tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema description coverage is 100%, the description enriches parameter understanding: it clarifies that `kind` distinguishes AI vs SEO bots, that `vendor` is not the same as `assistant` in get_ai_traffic, and that `path` must match get_sitemap's format. It also explains how `path` affects the search scope, adding semantic meaning not in the schema.

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?

The description states precisely what the tool does: it returns one row per path and bot with first/last request timestamps, count, and last status. It also explicitly distinguishes itself from list_bot_visits by coverage scope, making its purpose unambiguous and clearly differentiated from siblings.

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?

The description gives clear when-to-use and when-not-to-use guidance. It contrasts with list_bot_visits (period vs all-time), and explains how it differs from list_prompts, list_competitors, list_sources, and get_ai_traffic, providing explicit alternatives and the conceptual role of the tool.

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