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

prompteye-mcp

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

Check which integrations the project has

get_integrations_status
Read-only

Whether Search Console, Google Analytics, the bot tracker and the sitemap are connected to the project, in one call. Call it before reporting a zero or an empty list from get_search_performance, get_ai_traffic, list_bot_visits…

Instructions

Whether Search Console, Google Analytics, the bot tracker and the sitemap are connected to the project, in one call. Call it before reporting a zero or an empty list from get_search_performance, get_ai_traffic, list_bot_visits, count_bot_visits or list_crawls: a project with nothing connected answers those with zeros and empty lists, which reads exactly like a site nobody visits.

connected: false means the integration is missing, never that the site had no traffic. reason: sync_failing means it is connected but its last sync failed, so its figures are stale; get_google_status and get_sitemap say when and why. Integrations are connected in the PromptEye app.

PromptEye has no CMS integration. The WordPress and Laravel collectors are ways of installing the bot tracker and are reported under botLogs.

Input Schema

NameRequiredDescriptionDefault
projectIdYesThe project to work on — its id from list_projects. Required on every call, so that parallel conversations never read or write each other's project.

Output Schema

NameRequiredDescriptionDefault
botLogsYes
sitemapYes
analyticsYes
searchConsoleYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.0.28
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / projectId
      Added value: +{
+  "description": "The project to work on — its id from list_projects. Required on every call, so that parallel conversations never read or write each other's project.",
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / required
      Added value: +[
+  "projectId"
+]
  2. Addedv1.0.22

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond them. It decodes the return semantics (`connected: false` = integration missing, `reason: sync_failing` = connected but stale), points to get_google_status/get_sitemap for the why, names where integrations are connected (the PromptEye app), and pre-empts a CMS misconception by mapping the WordPress/Laravel collectors to `botLogs`.

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?

The scoping sentence comes first and the diagnostic guidance follows, but it runs to four paragraphs with mild redundancy ('reads exactly like a site nobody visits' restates 'answers with zeros and empty lists'). Every idea earns its place; the phrasing could be tighter.

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?

Output schema exists, yet the description still explains the meaning of the key fields (connected, reason, botLogs), which an agent needs in order to interpret rather than merely read the response. Nothing needed to call or interpret it is missing.

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

Parameters3/5

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

A single parameter with 100% schema description coverage, so the schema already explains projectId fully. The description adds no format or sourcing detail for it, so the baseline 3 applies.

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: reports whether Search Console, Google Analytics, the bot tracker and the sitemap are connected to the project, in one call. It also delimits itself against the per-integration siblings (get_google_status, get_sitemap) that drill into detail.

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?

Gives an explicit trigger: call it before reporting a zero or empty list from get_search_performance, get_ai_traffic, list_bot_visits, count_bot_visits or list_crawls, and explains the failure mode that makes this necessary. The alternatives are named directly.

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