@prompteden/mcp-server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PROMPTEDEN_API_KEY | Yes | PromptEden API key from Settings > API Keys. Required. The server reads it from the environment and does not write it to disk. | |
| PROMPTEDEN_BASE_URL | No | Optional API origin. Defaults to https://app.prompteden.com. Any other origin is rejected. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_accountA | Get PromptEden team, plan, and usage details via GET /api/v1/account. Does not use credits. |
| list_monitorsA | List PromptEden monitors for the authenticated team via GET /api/v1/monitors. Does not use credits. |
| get_resultsA | Get monitor results by monitor UUID via GET /api/v1/monitors/:monitorId/results. Does not use credits. |
| list_providersA | List the answer engines available for monitors, with key, name, category, and costTier. Coding-agent providers are omitted. Use a returned key when creating a monitor target. Does not use credits. |
| list_projectsB | List projects via GET /api/v1/projects. Does not use credits. |
| get_projectA | Get a single project by id, UUID, or slug via GET /api/v1/projects/:projectId. Does not use credits. |
| agent_statusA | Get the authenticated agent/key status via GET /api/v1/agent/status. Requires account:read scope. Does not use credits. |
| analytics_get_propertyA | Get the analytics property for a project via GET /api/v1/analytics/property: hostname, property state, collector state (six-state enum: not_set_up, awaiting_first_collection, healthy_zero, healthy_data, stale, failed) and the latest verification run. Never returns the site key. 409 property_scope_ambiguous if the project has more than one property. Does not use credits. |
| analytics_get_verificationA | Poll the latest snippet verification run for a project's analytics property via GET /api/v1/analytics/property/verification. Read-only: never starts or retries a run. Statuses: queued, running, succeeded, failed, expired; checks cover script load and collector endpoint. Does not use credits. |
| analytics_get_trafficA | Get the AI-referral Traffic report via GET /api/v1/analytics/traffic: totals, per-engine series, landing pages, channel split, evidence provenance and sampling flags. HONESTY: |
| analytics_get_overviewA | Get the GA Overview via GET /api/v1/analytics/overview: visits · AI visits · goal completions chain, top engines and landing pages, goals summary, instrumentation card, six-state collector + freshness. HONESTY: |
| analytics_list_goalsA | List destination-URL goals via GET /api/v1/analytics/goals: per-goal completions and per-source split, with the attribution disclosure (within-visit model, one completion per goal per visit, prospective counting from goal creation). Goal names are customer-authored data; use the stable numeric id to act on a goal. Does not use credits. |
| analytics_create_goalA | Create a destination-URL goal via POST /api/v1/analytics/goals. The destination is a PATH starting with '/' (e.g. /thanks) — absolute URLs are rejected with invalid_goal; the goal always belongs to the property's own hostname. Counting is prospective from creation (within-visit attribution), no history backfill. 409 goal_exists on a duplicate destination; 409 property_not_set_up when the project has no analytics property yet. This changes live tracking on the user's site. Does not use credits. |
| analytics_archive_goalA | Archive a goal via DELETE /api/v1/analytics/goals/:goalId. Archival preserves history (state becomes 'archived'); it does not delete data. Idempotent by state. This changes live tracking on the user's site. Does not use credits. |
| analytics_add_property_hostA | Add a public collection hostname via PATCH /api/v1/analytics/property. Target by propertyId alone. Keeps the canonical host and site key. This changes live tracking on the user's site. Does not use credits. |
| analytics_create_propertyA | Create the analytics property for a project via POST /api/v1/analytics/property and receive the site key for the tracking snippet. The siteKey field in the result is shown EXACTLY ONCE — install it immediately; it cannot be re-read (recovery: analytics_rotate_key mints a fresh one). 409 property_exists (with propertyId) if the project already has a property. Does not use credits. |
| analytics_rotate_keyA | Rotate a property's ingest site key via POST /api/v1/analytics/property/key/rotate. Target with propertyId ALONE (primary), or a project reference plus expectedPropertyId (409 analytics_property_changed on mismatch). The new siteKey is shown EXACTLY ONCE; the old key keeps working through overlapExpiresAt. NOT idempotent and never auto-retried: a manual retry performs a fresh rotation (safe — install the latest returned key). Does not use credits. |
| analytics_verify_propertyA | Start a live verification run for a project's analytics property via POST /api/v1/analytics/property/verification (202). The run checks script load and collector endpoint asynchronously; poll analytics_get_verification for the outcome. Never fabricate a pass/fail — report the run's actual status. 429 with retryAt when retried too soon. This starts an async live-site check. Does not use credits. |
| create_monitorA | Create a PromptEden monitor via POST /api/v1/monitors. Requires projectSlug or projectId. Defaults: type='search', language='en', country='US' (applied by the shared client). Only provider keys present in the filtered list_providers catalog are accepted. This starts recurring metered runs and uses credits. |
| create_projectC | Create a project via POST /api/v1/projects. Does not use credits. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 20 tools
Most tools target clearly distinct resources and actions across monitors, projects, analytics reports, and goals. The 11 analytics tools are separated by specific endpoint purpose, though several 'get' analytics reports could be momentarily confused without reading descriptions; overall boundaries remain clear.
Names are consistently snake_case and mostly follow a verb_noun pattern, with an analytics_ prefix grouping analytics tools. Minor deviations include agent_status (noun_status) and get_results (no monitor prefix), but the pattern remains readable.
20 tools is heavy for a single MCP server, even though they are grouped across monitors, analytics, projects, account, and providers. Each appears to map to a distinct API endpoint, but the count sits in the borderline heavy range of 16–25.
Core create/list/get coverage exists for projects, monitors, and analytics, but update and delete operations are missing for projects and monitors. These notable CRUD gaps could force agents to work around missing lifecycle operations.