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

prompteye-mcp

Official
by PROMPTEYE-SP-Z-O-O
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List the requests bots made to the site

list_bot_visits
Read-only

Check which AI assistants and search engine bots fetched your site, what they requested, and what status they got. See bot requests as evidence of site reachability.

Instructions

The individual requests AI assistants and search engines made to the active project's site, newest first — which bot, which path, what the site answered and how long it took.

This is the evidence layer: call it to show what actually happened, or to see what a bot got when a page moved. For totals call count_bot_visits instead — paging through this to add requests up gives a wrong number, because only the newest 4 000 requests of the period are searched and a rarely matching filter comes back short of what the period held.

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.

A request carries the name of the bot in its User-Agent, which is free text anybody can send, so each one is marked verified or not. The API has no filter for it and counts cannot be split by it, so any total here includes requests that only claimed to be that bot. Report a count as an upper bound and say so; never present it as measured reach without the caveat.

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.
statusNoAn exact HTTP status code, or a class such as `4xx` to see only the failures.
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.
endDateNoLast day to report on, inclusive. Defaults to today, and must be within 31 days of startDate — these endpoints read a month at a time, not a year.
startDateNoFirst day to report on, inclusive. Defaults to 30 days before today.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.16

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds substantial behavioral detail beyond them: the 4,000-newest-request search window, under-reporting with rare filters, the unverifiable User-Agent problem, and the directive to present counts as upper bounds. There is no contradiction with the 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 front-loaded with a one-sentence definition, then moves through use case, alternatives, conceptual framing, and caveats in a logical order. It is long, but every sentence earns its place given 9 parameters and several sibling tools to disambiguate.

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?

Even without an output schema, the description tells the agent what a result contains ('which bot, which path, what the site answered and how long it took'), how results are ordered, and what limits and caveats apply. Combined with the schema's detailed parameter descriptions, the agent has everything needed to call and interpret this tool 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 description coverage is 100%, so the schema already documents every parameter; the baseline is 3. The description adds meaning beyond the schema by explaining that summing pages yields a wrong total due to the 4,000-request cap and that counts cannot be split by verified status, plus it clarifies kind/vendor in the context of sibling tools.

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 opening sentence names the exact resource ('individual requests AI assistants and search engines made to the active project's site'), specifies ordering ('newest first'), and lists what each record contains (bot, path, site answer, duration). It also clearly distinguishes this tool from siblings like count_bot_visits, list_prompts, list_sources, list_competitors, and get_ai_traffic.

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 explicitly says when to call it ('this is the evidence layer') and when not to: 'For totals call count_bot_visits instead — paging through this to add requests up gives a wrong number.' It also names the neighboring measurement concepts it is not, with sibling tool names, leaving no ambiguity about selection.

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

Deploy Server

Other Tools