Skip to main content
Glama
Sign In
prompteye-mcp

prompteye-mcp

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

Create, rename, describe or reorder a prompt group

upsert_prompt_group

Creates a prompt group in the project or, given a groupId, changes the name, description or order of an existing one. Only the fields sent are changed, and the prompts of a group keep their history when it is renamed or moved.

Instructions

Creates a prompt group in the project or, given a groupId, changes the name, description or order of an existing one. Only the fields sent are changed, and the prompts of a group keep their history when it is renamed or moved.

Without groupId a new, empty group is created: name is required, and the group goes after the existing ones unless order says otherwise. Prompts join a group through update_prompt (groupId) or through a matching groupName in add_prompts.

Input Schema

NameRequiredDescriptionDefault
nameNoName of the group. Required when creating one.
orderNoWhere the group sits in the project's ordering, lowest first.
groupIdNoId of the group to change, as list_prompt_groups reports it. Left out, a new group is created.
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.
descriptionNoWhat the group is for. Null clears it.

Output Schema

NameRequiredDescriptionDefault
idYes
nameYes
orderYesWhere the group sits in the project's own ordering, lowest first.
descriptionNoWhat the group is for. null = nobody described it.
promptCountYesPrompts in the group, paused ones included.

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"
+}
    • addedInput schema / required
      Added value: +[
+  "projectId"
+]
  2. Addedv1.0.22

TDQS

A4.7/5.0
Behavior4/5

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

With annotations already declaring a non-destructive, non-idempotent, open-world write, the description adds useful behavioral detail: only sent fields are changed and prompt history survives rename or move. It does not discuss permissions, rate limits, or failure modes, but the key mutation semantics are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is front-loaded with the create/update split, then gives the create-specific constraints and prompt-membership routing. The two paragraphs are compact and every sentence carries operational information.

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 five-parameter upsert tool with full schema coverage, annotations, and an output schema, the description covers the crucial conditional behavior and side effects. It leaves return values to the output schema and gives enough context to call the tool correctly.

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 the schema already explains each parameter. The description still adds conditional meaning beyond the schema, notably that omitting groupId creates a new empty group and that order defaults to after existing groups unless supplied.

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 names a specific verb and resource and splits the operation precisely: create without groupId, update name/description/order with groupId. It also distinguishes prompt-group management from prompt membership by pointing to update_prompt and add_prompts.

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 explicitly states the condition that selects creation versus update, that name is required only when creating, and how prompts are attached to groups through other tools. This gives an agent clear routing guidance rather than implied usage.

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