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

prompteye-mcp

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

Create a category to file prompts under

create_category

Adds a category the project can file prompts under. Pass an existing top-level category as parentCategoryId to create a subcategory instead; only one level of nesting is supported.

Instructions

Adds a category the project can file prompts under. Pass an existing top-level category as parentCategoryId to create a subcategory instead; only one level of nesting is supported. Every category made this way is recorded as written by hand (source manual), never as one PromptEye proposed. update_prompt with categoryId files an existing prompt under it. A category with the same name at the same level is refused.

Input Schema

NameRequiredDescriptionDefault
nameYesName for the category.
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.
parentCategoryIdNoAn existing top-level category to file this one under, as list_categories reports it, which makes it a subcategory. Left out, a top-level category is created.

Output Schema

NameRequiredDescriptionDefault
idYes
nameYes
sourceYesai = proposed by PromptEye, manual = written by hand.
parentIdYesThe category this one sits under. null = top-level.

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

TDQS

A4.6/5.0
Behavior4/5

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

Beyond the annotations, the description discloses that created categories are always source `manual` and never AI-proposed, that nesting is capped at one level, and that same-name-same-level creation is refused — genuinely useful behavioural facts for a non-idempotent write. It does not mention permission or error-response behaviour, but the output schema and annotations cover the return and safety profile.

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?

Four tight sentences, front-loaded with what the tool creates before branching into subcategory, source labelling, and the update_prompt alternative. Every sentence carries information, though the alternative-tool note could sit slightly earlier for faster routing.

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 a rich input schema, full annotations and an output schema, the description supplies exactly the missing pieces — nesting limit, source tagging, duplicate refusal, and the update_prompt cross-reference. Nothing an agent needs before calling is absent.

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 baseline is 3, but the description adds real meaning on top: parentCategoryId must be an *existing top-level* category and produces exactly one level of nesting, and `name` is constrained by sibling uniqueness at that level. That is semantic depth the schema alone does not convey.

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 opening sentence states a specific verb and resource ('Adds a category') and its purpose ('file prompts under'), which immediately separates it from list_categories and update_prompt. The subcategory behaviour is spelled out in the same breath, so an agent knows exactly which sibling is not the right choice.

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 routing: use parentCategoryId for a subcategory, omit it for top-level, and use update_prompt with categoryId to move an existing prompt instead of creating a new category. The one-level nesting limit and the duplicate-name refusal are stated as conditions, 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