Skip to main content
Glama
Sign In
prompteye-mcp

prompteye-mcp

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

Add prompts by hand (not the recommended way)

add_prompts

Add user-written prompts verbatim to a project's tracking, bypassing PromptEye's generated suggestions. Use only for migrations or client-mandated prompt lists that must be measured as written.

Instructions

Tracks prompts written by hand in the project, in one call.

This is not the recommended way to add prompts, and it should not be the first thing you reach for. 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. Call list_prompt_suggestions and work from what it returns.

A prompt added here skips all of that. It is not weighed against what the project already tracks, so it can duplicate an existing prompt; it carries no demand, priority, purchase intent or fit until PromptEye computes them; and a question phrased the way a person writes rather than the way people actually ask assistants will quietly measure nothing — it will sit in the project at 0% visibility and look like a brand problem when it is a prompt problem. Every prompt also counts against the workspace plan.

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.

Groups are handled by name: a groupName that does not exist yet is created after the existing groups, and one that does is reused. upsert_prompt_group renames or describes a group afterwards.

Use it only when the user has prompts of their own that must be tracked verbatim — migrating from another tool, or a list a client insists on — and has said as much. If the user simply wants more prompts, or better coverage, use list_prompt_suggestions instead. When unsure, ask the user before calling this; do not decide on their behalf.

Input Schema

NameRequiredDescriptionDefault
promptsYesThe prompts to track, at most 200. Send them in one call rather than one call per prompt.
projectIdYesThe project to work on — its id from list_projects. Required on every call, so that parallel conversations never read or write each other's project.
confirmBypassPromptIntelligenceYesMust be true, and only set it once the user has knowingly chosen hand-written prompts over the ones PromptEye would generate. It is an acknowledgement that this call skips the demand, duplicate and fit checks behind list_prompt_suggestions.

Output Schema

NameRequiredDescriptionDefault
dataYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.0.28
    • addedInput schema / properties / projectId
      Added value: +{
+  "description": "The project to work on — its id from list_projects. Required on every call, so that parallel conversations never read or write each other's project.",
+  "minLength": 1,
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "prompts",
-  "confirmBypassPromptIntelligence"
-]New value: +[
+  "projectId",
+  "prompts",
+  "confirmBypassPromptIntelligence"
+]
  2. Changed2 schema fields changedv1.0.22
    • changedInput schema / properties / prompts / items / properties / groupName / description
      Previous value: -"Name of the group the prompt joins. The group is created when it does not exist yet and reused when it does — there is no separate group-creation step — so match the spelling reported by list_prompt_groups to land in an existing group. Left out, the prompt is ungrouped and appears in no group's figures."New value: +"Name of the group the prompt joins. The group is created when it does not exist yet and reused when it does, ignoring case, so match the spelling reported by list_prompt_groups to land in an existing group. Left out, the prompt is ungrouped and appears in no group's figures."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "data": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "groupName": {
+            "description": "The group it was filed under. null = ungrouped.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "id": {
+            "type": "string"
+          },
+          "prompt": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "prompt",
+          "groupName"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}
  3. Addedv1.0.11

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses that duplicates are possible, that demand/priority/purchase-intent/fit are unset until computed, that a poorly phrased prompt yields 0% visibility and looks like a brand problem, that every prompt counts against the plan, and that the prompt is measured immediately rather than at nextScanAt with answers in tens of minutes. It also instructs not to poll — non-obvious operational behavior the annotations (readOnly=false, openWorld=true, idempotent=false, destructive=false) cannot convey.

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 warning is front-loaded and the consequences paragraph is high-value, but there is some redundancy — 'not the recommended way' and the pointer to list_prompt_suggestions appear twice, and the scheduling paragraph is dense. Length is justified by the risk profile, though a trim would help.

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 an output schema present, return values need no explanation. The description covers the remaining gaps an agent needs: cost to the plan, duplicate risk, immediate measurement timing, the do-not-poll rule, group creation order, and the consent requirement — nothing material is missing for a correct call.

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 baseline is 3. The description adds real meaning to confirmBypassPromptIntelligence by tying it to a user-consent precondition rather than a bare boolean, and reiterates group-by-name creation/reuse semantics. Some of the group handling repeats what groupName's schema description already says, so it is not fully additive.

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?

States a specific verb and resource ('tracks prompts written by hand') and immediately positions it against the recommended path, naming list_prompt_suggestions as the alternative. An agent can distinguish this from accept_prompt_suggestion or upsert_prompt_group without opening any 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?

Explicit when-not-to-use ('not the recommended way', 'should not be the first thing you reach for'), the alternative to use instead, the narrow condition that justifies it (verbatim migration or client-mandated list), and an escalation rule ('When unsure, ask the user before calling this'). This is the full when/when-not/alternative triad.

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