prompteye-mcp

Official

by PROMPTEYE-SP-Z-O-O

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

List the addresses in the connected sitemap

get_sitemap

Read-only

The sitemap connected to the project, how its last sync went, and the addresses it found — what the site says it wants read.

Instructions

The sitemap connected to the project, how its last sync went, and the addresses it found — what the site says it wants read.

Each address carries path in the same form list_crawls reports, so the two can be compared: an address here with no crawl row is a page published into silence. active is false for an address that has dropped out of the sitemap while bots may still be asking for it.

sitemap is null when none is connected, and the list is then empty — a missing integration rather than an empty site. Sitemaps are connected in the PromptEye app. The first 5 000 addresses can be paged to.

Input Schema

Name	Required	Description
`limit`	No	How many entries to return, at most 200. Defaults to 50.
`active`	No	Only the addresses the sitemap still lists, or only those that dropped out of it.
`cursor`	No	The nextCursor of the previous page. Omit it to start from the first one.
`projectId`	Yes	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.

Output Schema

Name	Required	Description
`data`	Yes
`sitemap`	Yes	null = no sitemap is connected; data is then empty.
`nextCursor`	Yes	Pass as cursor to read the next page. null = this was the last page.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.0.28Oct 23, 2026

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"
+]
```

Changed1 schema field changedv1.0.22Oct 2, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "data": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "active": {
+            "description": "Whether the sitemap still lists it.",
+            "type": "boolean"
+          },
+          "firstSeenAt": {
+            "description": "When the address first appeared in the sitemap, ISO 8601 in UTC.",
+            "type": "string"
+          },
+          "lastModified": {
+            "description": "The lastmod the sitemap gives, as written there. null = none given.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "lastSeenAt": {
+            "description": "When the address was last found in the sitemap, ISO 8601 in UTC.",
+            "type": "string"
+          },
+          "path": {
+            "description": "The path in the form the other traffic tools use, so the two can be joined.",
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "url",
+          "path",
+          "lastModified",
+          "firstSeenAt",
+          "lastSeenAt",
+          "active"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "nextCursor": {
+      "description": "Pass as cursor to read the next page. null = this was the last page.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "sitemap": {
+      "anyOf": [
+        {
+          "additionalProperties": false,
+          "properties": {
+            "error": {
+              "description": "Why the last sync failed. null = it works.",
+              "type": [
+                "string",
+                "null"
+              ]
+            },
+            "lastSyncedAt": {
+              "description": "When the last sync finished, ISO 8601 in UTC. null = before the first one.",
+              "type": [
+                "string",
+                "null"
+              ]
+            },
+            "nextSyncAt": {
+              "description": "When the next sync is due, ISO 8601 in UTC.",
+              "type": "string"
+            },
+            "status": {
+              "description": "Where the last sync stands.",
+              "enum": [
+                "active",
+                "syncing",
+                "error"
+              ],
+              "type": "string"
+            },
+            "url": {
+              "type": "string"
+            },
+            "urlCount": {
+              "description": "How many addresses the last sync found.",
+              "type": "number"
+            }
+          },
+          "required": [
+            "url",
+            "status",
+            "lastSyncedAt",
+            "nextSyncAt",
+            "urlCount",
+            "error"
+          ],
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "null = no sitemap is connected; data is then empty."
+    }
+  },
+  "required": [
+    "sitemap",
+    "data",
+    "nextCursor"
+  ],
+  "type": "object"
+}

Addedv1.0.16Sep 23, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the readOnly/openWorld annotations, it discloses the null-sitemap behavior, the 5,000-address paging ceiling, and the non-obvious meaning of `active` (dropped from sitemap while bots may still request it). It also explains the practical consequence of an address with no crawl row, which is genuine behavioral context an agent cannot infer from the schema.

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 what is returned, then layered with the comparison to list_crawls and the null/active edge cases. Some phrasing is literary ('published into silence', 'what the site says it wants read') but each paragraph still carries distinct information; slightly more rhetorical flourish than strictly needed.

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-shape explanation is unnecessary, yet the description still covers the edge cases an agent must handle (no sitemap connected, inactive addresses, paging cap) plus the sibling comparison needed to use the data. Nothing material is missing for correct invocation and interpretation.

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 real meaning: it clarifies that `active` reflects dropout from the sitemap rather than general liveness, and that only the first 5,000 addresses can be paged, which contextualizes `cursor` and `limit` behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description precisely names the resource — the connected sitemap, its last sync status, and the addresses it found — and explicitly contrasts it with list_crawls by noting the shared `path` form. The only shortfall is that the verb is implicit (a nominal phrase describing the payload rather than 'lists/returns'), though the meaning is unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear operating context: sitemaps are connected in the PromptEye app, a null sitemap means missing integration rather than an empty site, and the address list is meant to be cross-read with list_crawls. It stops short of explicit when-to-use/when-not routing against siblings like list_crawls or get_crawl_health.

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

Deploy Server