prompteye-mcp

Official

by PROMPTEYE-SP-Z-O-O

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Generate a public report for a brand

create_report

Instructions

Generates the free visibility report an agency hands to a prospect, and emails it to the address given. A public report is PromptEye's lead magnet, sold to agencies white-label: a prospect fills in a form on the agency's site, PromptEye works out the industry, asks a set of assistants how visible that brand is, and emails back a page in the agency's branding — a visibility score, the competitors ahead of them, and quotes from what the assistants actually said. It is a one-off sample, not tracking: nothing is measured again until the report is converted into a project, which happens in the PromptEye app. leadStatus and the conversion are the agency's sales pipeline, and contactCount is how many times the brand asked to be contacted from the page.

The report is booked to the account the configured API key belongs to, and spends that account's lead-magnet quota. Nothing has to be asked for or passed in: the account's own id is what the public endpoint calls agencyId, and this tool reads it from the account itself. The call to PromptEye is the one that carries no API key — the endpoint is public, which is what lets an agency's website post to it straight from a form. Reach for get_report_integration when the question is how to wire that form up.

A report for the same domain and account generated in the last 30 days is not built again; it is sent to the address once more, and the result says which of the two happened. A new one comes back as processing with no score — the figures land minutes later, so read them with get_report rather than promising them straight away.

Input Schema

Name	Required	Description
`utm`	No	Campaign the lead came from; kept on the report and in its link.
`brand`	Yes	The brand the report is about.
`email`	Yes	Where the finished report is sent. The prospect's address.
`reach`	No	How wide the brand competes, which decides the questions asked: local, regional or national. Defaults to national.
`country`	No	Market as an ISO 3166-1 alpha-2 code, e.g. PL.
`website`	No	The brand's domain, without protocol. It is what a cached report is matched on.
`language`	No	Language of the prompts, as a two-letter code.

Output Schema

Name	Required	Description
`id`	Yes
`url`	Yes
`brand`	Yes
`reach`	Yes	How far the brand sells: local, regional or national.
`score`	Yes	Visibility of the brand in whole percent 0-100. null = the report is not ready yet.
`domain`	Yes	Website without `www.`. null = the form carried no website.
`reused`	Yes
`status`	Yes	processing until the assistants have answered, then ready, or error.
`country`	Yes	Market the report was taken in, ISO 3166-1 alpha-2.
`readyAt`	Yes	When it finished, ISO 8601 in UTC. null = not finished yet.
`language`	Yes
`createdAt`	Yes	When the report was ordered, ISO 8601 in UTC.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv1.0.28Oct 23, 2026

removedOutput schema / properties / contactCount

Removed value: -{
-  "description": "How many times the brand asked to be contacted from the report page.",
-  "type": "number"
-}

removedOutput schema / properties / email

Removed value: -{
-  "type": "string"
-}

removedOutput schema / properties / leadStatus

Removed value: -{
-  "description": "new, in_progress or done; moved in the PromptEye app, not through the API.",
-  "type": "string"
-}

removedOutput schema / properties / projectId

Removed value: -{
-  "description": "The project the report was converted into. null = still only a sample.",
-  "type": [
-    "string",
-    "null"
-  ]
-}

removedOutput schema / properties / utm

Removed value: -{
-  "type": [
-    "string",
-    "null"
-  ]
-}

changedOutput schema / required

Previous value: -[
-  "id",
-  "brand",
-  "domain",
-  "email",
-  "status",
-  "score",
-  "reach",
-  "country",
-  "language",
-  "utm",
-  "leadStatus",
-  "projectId",
-  "contactCount",
-  "createdAt",
-  "readyAt",
-  "url",
-  "reused"
-]New value: +[
+  "id",
+  "brand",
+  "domain",
+  "status",
+  "score",
+  "reach",
+  "country",
+  "language",
+  "createdAt",
+  "readyAt",
+  "url",
+  "reused"
+]

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": {
+    "brand": {
+      "type": "string"
+    },
+    "contactCount": {
+      "description": "How many times the brand asked to be contacted from the report page.",
+      "type": "number"
+    },
+    "country": {
+      "description": "Market the report was taken in, ISO 3166-1 alpha-2.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "createdAt": {
+      "description": "When the report was ordered, ISO 8601 in UTC.",
+      "type": "string"
+    },
+    "domain": {
+      "description": "Website without `www.`. null = the form carried no website.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "email": {
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "language": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "leadStatus": {
+      "description": "new, in_progress or done; moved in the PromptEye app, not through the API.",
+      "type": "string"
+    },
+    "projectId": {
+      "description": "The project the report was converted into. null = still only a sample.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "reach": {
+      "description": "How far the brand sells: local, regional or national.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "readyAt": {
+      "description": "When it finished, ISO 8601 in UTC. null = not finished yet.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "reused": {
+      "type": "boolean"
+    },
+    "score": {
+      "description": "Visibility of the brand in whole percent 0-100. null = the report is not ready yet.",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "status": {
+      "description": "processing until the assistants have answered, then ready, or error.",
+      "type": "string"
+    },
+    "url": {
+      "type": "string"
+    },
+    "utm": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "id",
+    "brand",
+    "domain",
+    "email",
+    "status",
+    "score",
+    "reach",
+    "country",
+    "language",
+    "utm",
+    "leadStatus",
+    "projectId",
+    "contactCount",
+    "createdAt",
+    "readyAt",
+    "url",
+    "reused"
+  ],
+  "type": "object"
+}

Addedv1.0.16Sep 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only flag that this writes and is non-idempotent; the description adds the real consequences — it spends the account's lead-magnet quota, binds the report to the API key's account without any agencyId parameter, sends an email, uses the keyless public endpoint, and returns 'processing' with no score until figures land minutes later. None of this is recoverable from 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.

Conciseness4/5

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

Purpose and the most important caveat (cached resend, then 'processing') are front-loaded and each paragraph carries operational weight. There is some drift into report-field jargon (leadStatus, contactCount, sales pipeline) that does not help invoke this tool, and the prose could be tightened by a few sentences.

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?

For a quota-spending, email-sending, publicly-postable endpoint with an output schema and annotations already present, this covers the remaining gaps: who owns the spend, why no auth/account argument exists, what a repeat call does, and what state the immediate response can be in.

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 genuinely new semantics: website is the cache-match key, reach changes which questions are asked, and the calling account's id is injected server-side so nothing account-related needs to be passed. It stops short of explaining the utm/language/country interplay, which keeps it at 4 rather than 5.

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?

Opens with a specific verb and resource ('Generates the free visibility report... and emails it to the address given') and makes the lead-magnet/white-label nature of the artifact explicit. It is trivially distinguishable from siblings like get_report, list_reports and get_report_integration even before reading the 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?

Gives explicit routing: use get_report_integration for wiring the form, and read the figures with get_report rather than promising a score immediately. It also states the 30-day same-domain/same-account dedup rule that decides whether a new report is built or the cached one is resent, so the agent knows what a repeat call actually does.

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

Deploy Server