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

prompteye-mcp

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

Generate a public report for a brand

create_report

Generates a free brand visibility report and emails it to a prospect, helping agencies capture leads with a white-label sample.

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

TableJSON Schema
NameRequiredDescriptionDefault
utmNoCampaign the lead came from; kept on the report and in its link.
brandYesThe brand the report is about.
emailYesWhere the finished report is sent. The prospect's address.
reachNoHow wide the brand competes, which decides the questions asked: local, regional or national. Defaults to national.
countryNoMarket as an ISO 3166-1 alpha-2 code, e.g. PL.
websiteNoThe brand's domain, without protocol. It is what a cached report is matched on.
languageNoLanguage of the prompts, as a two-letter code.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.16

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the boolean annotations, the description discloses the public no-API-key endpoint, account quota spending, attribution to the configured account, the async 'processing with no score' result, and the cached resent behavior for repeats. None of this contradicts the annotations; it substantially enriches them.

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?

The first sentence front-loads the action, and the later paragraphs are logically organized into product context, operational/auth behavior, and caching/async behavior. Some background sentences about white-labeling and the sales pipeline are useful but could be tightened without losing essential call guidance.

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?

With no output schema, the description supplies the critical return behavior: a new report returns as processing with no score, results land minutes later, and get_report should be used to read them. It also covers auth, quota, and repeated-call semantics, making the tool safe to invoke correctly with the two required parameters.

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 seven parameters. The description mainly restates or contextualizes them (e.g. website matching for cache, email as prospect address) rather than adding new parameter-level meaning beyond a baseline.

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 opens with a concrete verb and object: it generates a public visibility report and emails it to a given address. It also names what the report contains and explicitly contrasts itself with get_report_integration, so an agent can tell it apart from siblings without opening schemas.

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 gives explicit routing instructions: use get_report_integration to wire the form, and read finished results with get_report rather than expecting scores immediately. It also clarifies that this is a one-off lead-magnet sample and not a tracking tool, and describes the 30-day cache/resend behavior on repeat calls.

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