prompteye-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Create a project

create_project

Starts tracking one brand in one market, creating the project that holds its prompts, answers, competitors and visibility. Returns a projectId to pass to other tools.

Instructions

Starts tracking one brand in one market. The project is the unit everything else hangs off — prompts, answers, competitors and the visibility computed from them. Pass the id it returns as projectId to the following tools.

A brand tracked in several markets needs one project per market: the same brand with a different country. Check list_projects first; creating a second project for a brand and market already tracked is refused.

Creating a project counts against the workspace plan. Nothing is asked of the assistants until the project has prompts — PromptEye generates the prompts a project tracks: it works out which questions carry demand and phrases them the way people actually put questions to AI assistants, then proposes each one with the gap in the funnel it fills, the demand behind it, how close to a purchase it is asked and how well it fits the brand. list_prompt_suggestions returns those, ready to be accepted.

A new prompt does not wait for the schedule: it is put to every assistant as soon as it is added, and its first answers come back over the following tens of minutes. get_account's nextScanAt is the next scheduled run, which asks every active prompt again; it is not when a new prompt is first measured, so never tell the user a new prompt waits for it. Do not wait or poll for results after adding prompts: tell the user the first answers usually appear within tens of minutes and carry on with other work.

Input Schema

Name	Required	Description
`name`	No	Display name of the project. Defaults to the brand name.
`brand`	Yes	The brand name as it is written in answers. Visibility is measured against this name, so write it the way an assistant would, not as a legal entity.
`label`	No	Short label used to group projects in listings.
`domain`	Yes	Primary domain of the brand, without protocol or path, e.g. prompteye.com.
`country`	Yes	Market to track the brand in, as an ISO 3166-1 alpha-2 code such as PL, DE or US. GLOB is kept only for projects created earlier; a new project with it is rejected with 400.
`workspaceId`	No	Workspace to create the project in, as list_workspaces reports it. Defaults to the personal workspace of the account behind the key, or to its only workspace when it has no personal one; an account that belongs to several and has no personal one must name one.
`alternativeDomains`	No	Further domains owned by the brand; citations of them count as its own.
`excludedCompetitors`	No	Brands to keep out of the competitor set — agencies, resellers or anything that is not a rival, so share of voice is not diluted by them. Each name becomes one exclusion without aliases; list_competitor_exclusions reads them back and set_competitor_exclusions adds aliases.
`alternativeBrandNames`	No	Other spellings that count as naming the brand — a space, a suffix, a common misspelling. Without these, answers using them read as the brand being absent.

Output Schema

Name	Required	Description
`id`	Yes
`name`	Yes
`brand`	Yes
`label`	Yes	Grouping label. null = the project has none.
`domain`	Yes
`country`	Yes
`createdAt`	Yes	When the project was created, ISO 8601 in UTC.
`publicUrl`	No	Link anyone can open without logging in to view the project. null = the project is not shared.
`accessRole`	Yes	OWNER manages the project, FULL_ACCESS edits it, READ_ONLY reads it.
`alternativeDomains`	Yes
`alternativeBrandNames`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.0.28Oct 23, 2026

changedInput schema / properties / country / description

Previous value: -"Market to track the brand in, as an ISO 3166-1 alpha-2 code such as PL, DE or US. GLOB stands for the global answer set rather than one country."New value: +"Market to track the brand in, as an ISO 3166-1 alpha-2 code such as PL, DE or US. GLOB is kept only for projects created earlier; a new project with it is rejected with 400."

addedOutput schema / properties / publicUrl

Added value: +{
+  "description": "Link anyone can open without logging in to view the project. null = the project is not shared.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

Changed3 schema fields changedv1.0.22Oct 2, 2026

changedInput schema / properties / excludedCompetitors / description

Previous value: -"Brands to keep out of the competitor set — agencies, resellers or anything that is not a rival, so share of voice is not diluted by them."New value: +"Brands to keep out of the competitor set — agencies, resellers or anything that is not a rival, so share of voice is not diluted by them. Each name becomes one exclusion without aliases; list_competitor_exclusions reads them back and set_competitor_exclusions adds aliases."

addedInput schema / properties / workspaceId

Added value: +{
+  "description": "Workspace to create the project in, as list_workspaces reports it. Defaults to the personal workspace of the account behind the key, or to its only workspace when it has no personal one; an account that belongs to several and has no personal one must name one.",
+  "minLength": 1,
+  "type": "string"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "accessRole": {
+      "description": "OWNER manages the project, FULL_ACCESS edits it, READ_ONLY reads it.",
+      "type": "string"
+    },
+    "alternativeBrandNames": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "alternativeDomains": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "brand": {
+      "type": "string"
+    },
+    "country": {
+      "type": "string"
+    },
+    "createdAt": {
+      "description": "When the project was created, ISO 8601 in UTC.",
+      "type": "string"
+    },
+    "domain": {
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "label": {
+      "description": "Grouping label. null = the project has none.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "name": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "name",
+    "brand",
+    "domain",
+    "country",
+    "label",
+    "alternativeBrandNames",
+    "alternativeDomains",
+    "accessRole",
+    "createdAt"
+  ],
+  "type": "object"
+}

Addedv1.0.11Sep 19, 2026

TDQS

A4.5/5.0

Behavior4/5

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

The annotations already tell the agent this writes, is not idempotent and is not destructive, but the description adds the real behavioral facts: creation counts against the workspace plan, duplicates are rejected, the returned id must be passed as projectId to downstream tools, and newer prompts surface within tens of minutes rather than at the next scheduled scan. The only weak spot is that the middle paragraph describes how the prompt pipeline works internally, which goes beyond this tool's own behavior.

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 key scoping constraint is front-loaded and easy to find. The third paragraph drifts into how PromptEye phrases and ranks prompts, and into nextScanAt semantics, which is useful onboarding material but not needed to invoke create_project.

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?

Nine parameters, full schema coverage and an output schema mean the structured data already carries the field details. The description covers the remaining gaps an agent needs: duplicate handling, plan cost, the id handoff to downstream tools, and post-creation polling guidance.

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 beyond the schema by explaining that the same brand in several markets needs a different country and how the returned id is reused as projectId. It does not explain syntax or defaults for the remaining optional fields.

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 first sentence states a specific verb and resource with scope: 'Starts tracking one brand in one market.' It also says what a project is the unit for (prompts, answers, competitors, visibility), which cleanly separates it from update_project and list_projects.

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 says explicitly to check list_projects first and that a duplicate brand/market project is refused. It also defines the use case where one brand spans several markets: one project per market, differing only by country.

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

Deploy Server