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

prompteye-mcp

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

Tell the PromptEye team about a missing capability

report_missing_capability

Sends the PromptEye team a short, user-approved report when the server or API cannot do what the user needs, including the details required to reproduce the gap.

Instructions

Sends the PromptEye team a short note from the user: something this server or the PromptEye API cannot do today, something that does not work, or any other feedback, praise included.

Use it when something does not work, the user cannot find something they expected, the server cannot do what they asked, or they want to share feedback with the team. Ask first and send nothing until the user agrees in this conversation.

Describe the need and what you were trying to do. When something does not work, include the details the team needs to reproduce it: the project, prompt or report ids involved, the period, and the figures you saw next to the figures you expected. Never include conversation transcripts, quoted messages or personal data such as names, email addresses or phone numbers.

Input Schema

NameRequiredDescriptionDefault
needYesWhat the user needs or what does not work, in plain sentences, with the ids and figures that reproduce it. No transcripts and no personal data.
attemptedActionYesWhat you were trying to do for the user when you hit the gap, in one short sentence.
confirmedByUserYesMust be true, and only set it once the user has explicitly agreed in this conversation to send this report to the PromptEye team.

Output Schema

NameRequiredDescriptionDefault
idYes
receivedAtYesWhen PromptEye received the report, ISO 8601 in UTC.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.30
    • changedInput schema / properties / need / description
      Previous value: -"What the user needs that the server cannot do, in a few plain sentences. No transcripts and no personal data."New value: +"What the user needs or what does not work, in plain sentences, with the ids and figures that reproduce it. No transcripts and no personal data."
  2. Changed2 schema fields changedv1.0.28
    • changedInput schema / properties / attemptedAction / maxLength
      Previous value: -500New value: +5000
    • changedInput schema / properties / need / maxLength
      Previous value: -2000New value: +20000
  3. Addedv1.0.22

TDQS

A4.8/5.0
Behavior5/5

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

Annotations flag this as a non-read-only, open-world write; the description goes well beyond that by stating the consent gate, that the note leaves the server to a human team, and privacy constraints (no transcripts, quoted messages, names, emails, phone numbers). It also prescribes reproduction data, which is behavior an agent cannot infer from annotations.

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?

Three short blocks: purpose, when to use plus consent gate, then content requirements and privacy rules. Front-loaded and skimmable; the privacy sentence is slightly repetitive of the schema's 'no transcripts and no personal data' note, so it is not perfectly lean.

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 not be described. Everything an agent must know before firing an external, irreversible message — consent, content shape, redaction rules — is present, matching the risk profile of an open-world non-idempotent write.

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; the description earns more by specifying what 'need' should contain for a bug report — project/prompt/report ids, the period, and observed versus expected figures — plus the explicit prohibition on personal data. 'confirmedByUser' is reinforced with the same consent language, though the description does not restate that it is a const true.

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?

Names a specific verb and resource — sends a short note to the PromptEye team about a capability gap, a bug, or feedback — and explicitly widens the scope to include praise. This is unmistakable against siblings like create_report or get_account.

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?

Enumerates the triggering conditions (something broken, expected item missing, server can't do what was asked, user wants to share feedback) and adds a hard precondition: ask first and send nothing until the user agrees in this conversation. No alternative tool competes, so routing is unambiguous.

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