prompteye-mcp

Official

by PROMPTEYE-SP-Z-O-O

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Score how well bots can crawl the site

get_crawl_health

Read-only

Assess bot crawl health for AI or search engines by analyzing error rates, redirects, and response times to identify access issues.

Instructions

The requests of list_bot_visits for one kind, turned into a verdict by the API: how many were errors or redirects, how fast the site answered, and the worst problems behind those numbers.

assessments holds four fixed checks — the 3xx, 4xx and 5xx rates and the average response time — each scored ok, warning or critical against a fixed threshold the API sets (unknown only for the response-time check, when nothing was ever timed). issues lists up to 20 distinct problems (a bot, a path, a status and, for a redirect, where it pointed), worst first: a 5xx before a 4xx before a 3xx, then the one hit most often, then the one hit most recently. An assistant that cannot fetch a page answers from something else, so each issue is a citation that went elsewhere.

kind is required: ai scores what AI assistants and their bots found, seo what search engines and SEO tools found, and the two are never combined into one score. Only the newest 4 000 requests of the period are read, so narrow the period on a busy project rather than trusting a score built from a partial read.

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 project whose integration is not connected answers this with zeros and empty lists, which reads exactly like a site nobody visits. Call get_integrations_status before reporting a zero or an empty list as a finding: it says whether Search Console, Google Analytics, the bot tracker and the sitemap are connected, and a sync that is failing. Not connected means the figures say nothing about the site, never that it had no traffic; say the integration is missing and that it can be connected in the PromptEye app.

Input Schema

TableJSON Schema

Name	Required	Description
`kind`	Yes	`ai` for AI assistants and their bots, `seo` for search engines and SEO tools. Required: there is no combined health.
`vendor`	No	Only 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.
`endDate`	No	Last 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.
`startDate`	No	First day to report on, inclusive. Defaults to 30 days before today.

Output Schema

TableJSON Schema

Name	Required	Description
`total`	Yes	Requests read for the period.
`issues`	Yes	Up to 20 distinct problems (status 300 or above), worst first: 5xx before 4xx before 3xx, then the most frequent, then the most recent.
`success`	Yes	Requests answered with a 2xx status.
`unknown`	Yes	Requests the site never answered with any status code.
`redirects`	Yes	Requests answered with a 3xx status.
`assessments`	Yes	Four fixed checks: the 3xx, 4xx and 5xx rates, and the average response time.
`clientErrors`	Yes	Requests answered with a 4xx status.
`scanRequests`	Yes	Requests for a path that only a vulnerability scanner would ask for, counted apart from the rest.
`serverErrors`	Yes	Requests answered with a 5xx status.
`averageResponseTimeMs`	Yes	Average response time across the requests that reported one, in milliseconds. null = none reported one.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.0.22Oct 2, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare readOnly/openWorld, so the description carries the real behavioral load: the 4 000-request read cap, the four fixed assessments and their ok/warning/critical scoring (with `unknown` only for response time), the up-to-20 issues with an explicit worst-first ordering rule (5xx > 4xx > 3xx, then most frequent, then most recent), and the zero/empty-list failure mode for disconnected integrations.

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

Conciseness3/5

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

The purpose and the get_integrations_status caveat are well front-loaded and the ordering rules earn their space, but the description is four dense paragraphs and repeats the kind mapping twice ('`kind=ai` is the assistants; `kind=seo` is classic search engines' restating the earlier definition). Trimming that redundancy would tighten it without losing meaning.

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?

An output schema exists, so return values need not be explained, and the description still covers the things the schema cannot: how scores are derived, how issues are ranked, sampling limits, and the misleading-zero failure mode with its recovery path. Nothing an agent needs to call and interpret this tool is missing.

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 meaning the schema does not: why the 31-day window matters (only the newest 4 000 requests are read, so narrow the period rather than trust a partial read) and why `kind` is never combinable. It does not add further detail on `vendor` or the date defaults beyond what the schema already documents.

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 a specific transformation (list_bot_visits requests for one `kind` turned into a verdict by the API) and names what the verdict contains: error/redirect counts, response speed, and worst problems. It explicitly distinguishes itself from adjacent siblings (list_bot_visits as the raw source, list_prompts/list_competitors as being named in an answer, list_sources as citation, get_ai_traffic as arrivals).

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?

It gives explicit when-to-use routing (`kind=ai` for assistants, `kind=seo` for search engines, never combined), a sampling caveat (only the newest 4 000 requests are read, so narrow the period on a busy project), and a hard precondition: call get_integrations_status before reporting a zero or empty list, because an unconnected integration answers with zeros.

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

Deploy Server