prompteye-mcp

Official

by PROMPTEYE-SP-Z-O-O

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Read the account behind the key

get_account

Read-only

Access your PromptEye account details, including API key ownership, current plan status, and prompt usage against limits. Check the scheduled date for the next comprehensive data scan.

Instructions

Who the configured PromptEye API key belongs to, which plan the workspace is on, how many prompts it tracks against its limit, which assistants those prompts are asked on, and when the next scheduled run starts. Call this to diagnose a key, to check whether a plan covers a feature before promising it, or to answer when the tracked prompts will next be refreshed.

nextScanAt is when the scheduled run begins, not when it is done: the prompts are put to every assistant and the answers are read back over the tens of minutes that follow, so the figures arrive gradually after that time rather than all at once on it. Say the run has started rather than that the numbers are ready.

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

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`id`	Yes
`plan`	Yes	null = no plan assigned.
`email`	Yes
`addons`	Yes
`models`	Yes
`scopes`	Yes
`nextScanAt`	Yes	When the next scheduled run starts, not when it finishes, ISO 8601 in UTC; answers land over the hours after it, so figures keep moving. A newly added prompt is asked straight away and does not wait for this run.
`promptCount`	Yes	Prompts tracked across the workspace, active or pending; paused prompts are not counted.
`promptLimit`	Yes	Prompts the plan allows in total; the room left is promptLimit minus promptCount.
`scanFrequency`	Yes	How often every active prompt is asked, e.g. daily.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.0.30Oct 26, 2026

changedOutput schema / properties / nextScanAt / description

Previous value: -"When the next run starts, not when it finishes, ISO 8601 in UTC; answers land over the hours after it, so figures keep moving."New value: +"When the next scheduled run starts, not when it finishes, ISO 8601 in UTC; answers land over the hours after it, so figures keep moving. A newly added prompt is asked straight away and does not wait for this run."

Changed1 schema field changedv1.0.22Oct 2, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "addons": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "email": {
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "models": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "nextScanAt": {
+      "description": "When the next run starts, not when it finishes, ISO 8601 in UTC; answers land over the hours after it, so figures keep moving.",
+      "type": "string"
+    },
+    "plan": {
+      "anyOf": [
+        {
+          "additionalProperties": false,
+          "properties": {
+            "key": {
+              "type": "string"
+            },
+            "name": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "key",
+            "name"
+          ],
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "null = no plan assigned."
+    },
+    "promptCount": {
+      "description": "Prompts tracked across the workspace, active or pending; paused prompts are not counted.",
+      "type": "number"
+    },
+    "promptLimit": {
+      "description": "Prompts the plan allows in total; the room left is promptLimit minus promptCount.",
+      "type": "number"
+    },
+    "scanFrequency": {
+      "description": "How often every active prompt is asked, e.g. daily.",
+      "type": "string"
+    },
+    "scopes": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "id",
+    "email",
+    "plan",
+    "addons",
+    "scopes",
+    "promptCount",
+    "promptLimit",
+    "models",
+    "scanFrequency",
+    "nextScanAt"
+  ],
+  "type": "object"
+}

First observedv1.0.5Sep 16, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds the non-obvious temporal semantics that an agent would otherwise get wrong: nextScanAt is run start, not completion, results arrive gradually over tens of minutes, and new prompts are measured immediately rather than waiting for the schedule. It also prescribes the user-facing phrasing ('say the run has started'), which is behavior well beyond the 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?

The most important information (what it returns and when to call it) is front-loaded in the first sentence and the timing caveat follows. The nextScanAt explanation is restated across both the second and third paragraphs, which is a small redundancy that costs it a point.

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 detailed, yet the description still tells the agent how to interpret the time-sensitive field it will read back. Combined with the no-polling instruction, an agent has everything needed to call this and to report results 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing to document. The description does not waste space explaining inputs, which is correct here.

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 names a specific resource and enumerates the exact fields returned: key owner, plan, prompt count against its limit, assistants, and nextScanAt. It is immediately distinguishable from siblings like list_prompts or get_prompt_answers, which deal with content rather than account/plan state.

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?

It gives three concrete trigger scenarios (diagnose a key, verify a plan covers a feature before promising it, answer when prompts refresh) plus explicit anti-patterns: never tell the user a new prompt waits for nextScanAt, and do not poll after adding prompts. It stops short of naming a competing sibling tool by name, which keeps it from a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server