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

prompteye-mcp

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

Delete an empty prompt group

delete_prompt_group
DestructiveIdempotent

Deletes one prompt group of the project, but only when it has no prompts — paused prompts count too. A group that still has prompts is refused: move each of them with update_prompt (groupId of another group, or null to leave it ungrouped)…

Instructions

Deletes one prompt group of the project, but only when it has no prompts — paused prompts count too. A group that still has prompts is refused: move each of them with update_prompt (groupId of another group, or null to leave it ungrouped) and then delete the group. Deleting cannot be undone: a group recreated under the same name is a new group and its prompts have to be filed into it again.

Never empty and delete a group on your own initiative, not even while restructuring a project or freeing capacity. Ask the user first, name the group and its prompts, and only go ahead on an explicit yes. To set a group aside for later, pause its prompts with update_prompt and keep the group.

Input Schema

NameRequiredDescriptionDefault
groupIdYesId of the group to delete, as list_prompt_groups reports it.
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.

Output Schema

NameRequiredDescriptionDefault
idYes

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

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare destructiveHint/idempotentHint, but the description adds much more: the empty-only refusal rule, that paused prompts count toward non-emptiness, irreversibility, and that a recreated group with the same name is a new entity. It also imposes an explicit human-consent protocol before deletion, which is behavioral guidance nothing in the structured fields conveys.

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 and its precondition, and the three paragraphs map cleanly onto what/to-do-instead/safety. It is longer than typical, but nearly every sentence carries a distinct rule; only the consent paragraph could be tightened slightly.

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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. What remains — preconditions, failure behavior, remediation steps, and consent requirements — is fully covered for a destructive two-parameter mutation.

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% and both parameters (projectId, groupId) are documented inline, including where the ids come from, so the schema does the heavy lifting. The description only indirectly references group identity through the 'groupId of another group' example, adding little parameter-specific meaning beyond the schema.

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 ('Deletes one prompt group of the project') plus the defining precondition ('only when it has no prompts — paused prompts count too'). This clearly separates it from upsert_prompt_group (creation/editing) and update_prompt (moving prompts out), so an agent can choose 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives the trigger condition, the blocking condition ('A group that still has prompts is refused'), and the exact alternative path (update_prompt with another groupId or null). It also names a when-not case ('to set a group aside for later, pause its prompts with update_prompt and keep the group'), which is rare and genuinely useful.

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