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

prompteye-mcp

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

Create a project

create_project

Start tracking a brand's visibility in AI assistant answers for one market. Creates the project that prompts, competitors, and visibility metrics hang off, and sets it as active for subsequent reporting.

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 — and it becomes the active project, so the following tools report on it without another call.

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoDisplay name of the project. Defaults to the brand name.
brandYesThe 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.
labelNoShort label used to group projects in listings.
domainYesPrimary domain of the brand, without protocol or path, e.g. prompteye.com.
countryYesMarket 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.
alternativeDomainsNoFurther domains owned by the brand; citations of them count as its own.
excludedCompetitorsNoBrands 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.
alternativeBrandNamesNoOther 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.11

TDQS

A4/5.0
Behavior4/5

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

Annotations indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds significant behavioral context: creating a project counts against the workspace plan, implies a state change (becoming the active project), and warns that duplicate creation is refused. It also explains the effects on subsequent tools (they report on the active project).

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 description is moderately detailed but includes a lengthy aside about PromptEye's prompt generation, which is tangential to creating a project. While this provides context, it dilutes the main purpose. The key points are front-loaded, but the middle section could be trimmed for conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (8 parameters, 3 required), the description covers the essential context: what a project is, the one-brand-one-market rule, the active project implication, and mention of prompt suggestions. Since there is no output schema, the description doesn't need to explain return values, but it does hint at the project becoming active.

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?

Schema description coverage is 100%, so the schema already documents all 8 parameters. The description adds a little beyond schema, such as emphasizing the 'brand' parameter's matching to how assistants write answers and the 'excludedCompetitors' rationale. However, the added value is modest since the schema already covers parameter meaning well.

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 description clearly identifies the tool's purpose: 'Starts tracking one brand in one market' and explains how a project is the foundational unit. It distinguishes itself from related tools by emphasizing the project creation aspect and references creating 'a second project for a brand and market already tracked is refused,' which differentiates it from list_projects and select_project.

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?

The description provides clear guidance on when to use the tool: create a project before tracking prompts and competitors, and check list_projects first to avoid duplicates. It also implies when not to use it (when project already exists) but does not explicitly compare with alternatives like add_prompts or list_prompt_suggestions.

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