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 exact pages assistants cite

list_source_pages
Read-only

The individual pages behind list_sources — each row is one URL, not a domain, so a host cited on several different pages shows up once per page instead of folded into one domain total.

Instructions

The individual pages behind list_sources — each row is one URL, not a domain, so a host cited on several different pages shows up once per page instead of folded into one domain total. Call this when the domain ranking does not say enough: which page of a review site carries the brand, or which own page the assistants actually quote.

A citation is not visibility: an answer can cite the brand's own domain without naming the brand, and name the brand while citing nobody. Read this beside list_prompts and list_competitors, not instead of them.

The ranking is built by adding up the period, so it answers with the limit most cited pages rather than a list to walk to the end of; share is each page's slice of the occurrences across the pages reported. model narrows it to one assistant.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many pages to return, at most 200.
modelNoReport on this assistant alone instead of all of them.
endDateNoLast day to report on, inclusive. Defaults to today, and must be within 366 days of startDate.
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.
startDateNoFirst day to report on, inclusive. Defaults to 30 days before today.

Output Schema

NameRequiredDescriptionDefault
dataYes
nextCursorYesPass as cursor to read the next page. null = this was the last page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.0.28
    • 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
Behavior4/5

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

Annotations already cover readOnly/openWorld, but the description adds real context beyond them: the ranking is a top-N cutoff rather than a walkable list, plus what `share` measures. The "a citation is not visibility" caveat warns against misreading results. Minor gap: no explicit note on result ordering ties or freshness beyond the period.

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 the defining distinction (page vs. domain), then usage, then the ranking mechanics. Three paragraphs are dense but each carries information; the visibility caveat earns its place, though a sentence or two could be trimmed without loss.

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, so return values need not be explained. Combined with full schema coverage, clear sibling differentiation, and the ranking/citation caveats, the description gives an agent everything needed to call it 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 coverage is 100%, so baseline 3, but the description adds meaning beyond the schema: `limit` is a top-N cutoff of a built-up ranking, `model` narrows to a single assistant, and `share` is defined relative to reported pages. This goes beyond restating parameter descriptions.

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 resource (individual cited pages/URLs, not domains) and explicitly contrasts it with the sibling list_sources, including the concrete difference (one row per URL vs. one row per domain). An agent can tell it apart from list_sources without opening either schema.

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?

"Call this when the domain ranking does not say enough" gives an explicit triggering condition, and it names companions (list_prompts, list_competitors) with "read beside, not instead of." Concrete examples (which review page carries the brand) make the selection clear.

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