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

prompteye-mcp

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

How to wire a website into public reports

get_report_integration
Read-only

Retrieve the agency ID, endpoint, example body, and cURL request for integrating public reports into an agency's website.

Instructions

Everything a developer needs to post a form on the agency's own site straight to public reports: the agency id, the endpoint, a filled-in example body, a cURL line and the request typed out. 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.

Call this whenever the question is how to set up, configure or integrate public reports, what the agency id is or where to find it, or what to hand a developer — and hand the answer over as the example, rather than describing it. The agency id is simply the id of the account this API key belongs to; it is what the public endpoint identifies the account by, since the call carries no key. That is also why the snippet is safe in a browser, and why the PromptEye API key must never be put in it.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
curlYes
methodYes
agencyIdYes
endpointYes
typescriptYes
exampleBodyYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.22
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "agencyId": {
+      "type": "string"
+    },
+    "curl": {
+      "type": "string"
+    },
+    "endpoint": {
+      "type": "string"
+    },
+    "exampleBody": {
+      "additionalProperties": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "method": {
+      "type": "string"
+    },
+    "typescript": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "agencyId",
+    "endpoint",
+    "method",
+    "exampleBody",
+    "curl",
+    "typescript"
+  ],
+  "type": "object"
+}
  2. Addedv1.0.16

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses the critical security constraint (the PromptEye API key must never be placed in the snippet, since the public call carries no key and is browser-safe) and explains the data semantics of leadStatus, contactCount, and the one-off (non-tracking) nature of the report.

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 deliverable is front-loaded in the first sentence, but the middle paragraph is a lengthy digression on PromptEye's white-label lead-magnet business model that is not strictly needed to call the tool, making the overall definition bloated.

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 zero-param, read-only integration helper it covers everything an agent needs: when to invoke, what it returns, how to present the answer, the meaning of the agency id, and the security caveat about the API key. The presence of an output schema makes the extra return-value prose supplementary rather than required.

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?

The tool takes zero parameters, so the baseline is 4. The description usefully characterizes the returned payload (agency id, endpoint, example body, cURL, typed request) and explains what the agency id actually is, adding meaning even though no parameters exist to document.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names the concrete deliverables (agency id, endpoint, example body, cURL line, typed request), which clearly distinguishes this as an integration-documentation tool from siblings like create_report or get_report. It is specific about the resource but never explicitly contrasts itself with those siblings.

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 trigger conditions: 'Call this whenever the question is how to set up, configure or integrate public reports, what the agency id is or where to find it, or what to hand a developer.' It even prescribes the response format ('hand the answer over as the example, rather than describing it'), leaving nothing to inference.

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