Skip to main content
Glama
Sign In
prompteye-mcp

prompteye-mcp

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

Accept a suggested prompt

accept_prompt_suggestion

Accept a prompt suggestion as a tracked project prompt, optionally edit its wording, and start collecting assistant answers without waiting for the next scheduled scan.

Instructions

Turns one suggestion from list_prompt_suggestions into a tracked prompt of the project, the same way accepting it in the PromptEye app does. promptText edits the wording before it starts being asked; leave it out to accept the suggestion exactly as written.

The suggestion leaves the pending list; its siblings from the same cycle are left untouched. The new prompt 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.

Input Schema

NameRequiredDescriptionDefault
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.
promptTextNoWording to track instead of the suggestion as written. Left out, the suggestion is tracked verbatim.
suggestionIdYesId of the suggestion, as list_prompt_suggestions reports it.

Output Schema

NameRequiredDescriptionDefault
trackerIdYesId of the prompt the suggestion became, as list_prompts reports it.

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: -[
-  "suggestionId"
-]New value: +[
+  "projectId",
+  "suggestionId"
+]
  2. Addedv1.0.22

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare the generic write profile (readOnlyHint=false, openWorldHint=true). The description adds the effects that matter: the suggestion leaves the pending list, siblings from the same cycle are untouched, the new prompt counts against the workspace plan, and it is measured immediately rather than on the schedule, with expected first-answer latency.

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?

Front-loaded with the action, then consequences, then timing caveats in priority order. The final paragraph repeats the 'tens of minutes' and 'do not wait' points, which is mild redundancy rather than wasted space.

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 non-idempotent mutation with an output schema and fully documented params, nothing an agent needs is missing: side effects, plan impact, scheduling behavior, and polling guidance are all stated.

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 coverage is 100%, so all three parameters are already documented in the schema, including promptText overriding the suggestion wording. The description only restates that override plus the timing nuance ('before it starts being asked'), adding little beyond the structured text.

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 precise verb and resource ('Turns one suggestion from list_prompt_suggestions into a tracked prompt of the project') and names the sibling that produces the input, so the agent can place it exactly in the workflow without opening a schema.

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?

Gives clear operational guidance: leave promptText out to accept verbatim, do not poll for results, and never tell the user a new prompt waits for nextScanAt. It stops short of explicitly contrasting with add_prompts for creating prompts from scratch, so the routing against that sibling is left implicit.

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