# PlanExe (remote · mcp.planexe.org)

MCP server for generating rough-draft project plans from natural-language prompts.

- Trust score: 66/100 (medium)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `mcp.planexe.org`: 66/100 (this document), [markdown](https://verifymcp.io/servers/planexeorg-planexe/mcp.md), [page](https://verifymcp.io/servers/planexeorg-planexe/mcp)

## Channel facts

- Endpoint: `https://mcp.planexe.org/mcp`
- Transports: `streamable-http`
- Auth: `required`
- Version: `1.0.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 57/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation not fully verified: this server exposes a tool marked destructive (plan_stop) and its handshake is open, but we could not confirm whether a tool call is gated, so we do not assert it is callable unauthenticated.
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 74/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 3054 tokens (~277/item across 11 items; 11 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 98/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 94% of tool parameters carry a description.
  - Structured output schemas are declared (82% of tools); any adoption earns full credit.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http planexeorg-planexe https://mcp.planexe.org/mcp
```

### Codex

```toml
[mcp_servers.planexeorg-planexe]
url = "https://mcp.planexe.org/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "planexeorg-planexe": {
      "type": "remote",
      "url": "https://mcp.planexe.org/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add planexeorg-planexe --url https://mcp.planexe.org/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  planexeorg-planexe:
    url: "https://mcp.planexe.org/mcp"
```

### Other

```json
{
  "mcpServers": {
    "planexeorg-planexe": {
      "type": "http",
      "url": "https://mcp.planexe.org/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-02 (score 66, +1)

No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 65, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 65, +1)

No change was recorded against any check on this day. Stability & Change Management went from 10 to 13. That category is still filling its 30-day observation window: 3 days of observed history at the previous scan, 4 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-28 (score 64, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 63, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 62)

First indexed and scored.

## MCP tools (11)

### `example_plans` (~63 tokens)

Returns a curated list of example plans with download links for reports and zip bundles. Use this to preview what PlanExe output looks like before creating your own plan. Especially useful when the user asks what the output looks like before committing to a plan. No API key required.

Output parameters:

- `message` (string)
- `plans` (array): Curated example plans with download links for reports and zip bundles.

### `example_prompts` (~185 tokens)

Call this first. Returns example prompts that define what a good prompt looks like. Do NOT call plan_create yet. Optional before plan_create: call model_profiles to choose model_profile. Next is a non-tool step: formulate a detailed prompt (typically ~300-800 words; use examples as a baseline, similar structure) and get user approval. Good prompt shape: objective, scope, constraints, timeline, stakeholders, budget/resources, and success criteria. Write the prompt as flowing prose, not structured markdown with headers or bullet lists. Weave technical specs, constraints, and targets naturally into sentences. Include banned words/approaches and governance preferences inline. The examples demonstrate this prose style — match their tone and density. Then call plan_create. PlanExe is not for tiny one-shot outputs like a 5-point checklist; and it does not support selecting only some internal pipeline steps.

Output parameters:

- `message` (string)
- `samples` (array): Example prompts that define the baseline for what a good prompt looks like. Take inspiration from these when writing your own prompt for plan_create (typically ~300-800 words). Good prompt shape: obj…

### `model_profiles` (~45 tokens)

Optional helper before plan_create. Returns model_profile options with plain-language guidance and currently available models in each profile. If no models are available, returns error code MODEL_PROFILES_UNAVAILABLE.

Output parameters:

- `default_profile` (string): Default model profile used when plan_create.model_profile is omitted/invalid.
- `message` (string): Caller guidance for selecting plan_create.model_profile.
- `profiles` (array): Available profile options and their model inventory.

### `plan_create` (~449 tokens)

Call only after example_prompts and after you have completed prompt drafting/approval (non-tool step). PlanExe turns the approved prompt into a strategic project-plan draft (20+ sections) in ~10-20 min. Sections include: executive summary, interactive Gantt charts, investor pitch, project plan with SMART criteria, strategic decision analysis, scenario comparison, assumptions with expert review, governance structure, SWOT analysis, team role profiles, simulated expert criticism, work breakdown structure, plan review (critical issues, KPIs, financial strategy, automation opportunities), Q&A, premortem with failure scenarios, self-audit checklist, and adversarial premise attacks that argue against the project. The adversarial sections (premortem, self-audit, premise attacks) surface risks and questions the prompter may not have considered. Returns plan_id (UUID); use it for plan_status, plan_stop, plan_retry, and plan_file_info. To track progress, poll plan_status at reasonable intervals (e.g. every 5 minutes). Optionally, run `curl -N <sse_url>` in a background shell as a completion detector — the stream auto-closes on terminal state (completed/failed/stopped). If you lose a plan_id, call plan_list to recover it. If the same prompt + model_profile is submitted by the same user within a short window, the existing plan is returned (with deduplicated=true) instead of creating a new one. If you are unsure which model_profile to choose, call model_profiles first. If your deployment uses credits, include user_api_key to charge the correct account. Common error codes: INVALID_USER_API_KEY, USER_API_KEY_REQUIRED, INSUFFICIENT_CREDITS.

Input parameters:

- `model_profile` (string): Model profile: baseline, premium, frontier, custom. Call model_profiles to inspect options.
- `prompt` (string, required)
- `start_date`: Optional plan start date in ISO 8601 format with timezone offset (e.g. '2025-06-15T09:00:00+02:00'). When omitted, the plan starts now. Use this to set a past or future start date for the plan.

Output parameters:

- `created_at` (string)
- `deduplicated`: True when this response returns an existing plan instead of creating a new one (duplicate prompt + model_profile by the same user within the dedup window). Absent or None for newly created plans.
- `plan_id` (string): Plan UUID returned by plan_create. Stable across plan_status/plan_stop/plan_file_info.
- `sse_url`: Optional completion detector. Run `curl -N <sse_url>` in a background shell — the stream auto-closes when the plan reaches a terminal state (completed/failed/stopped). For structured progress data, u…

### `plan_status` (~459 tokens)

Returns status and progress of the plan currently being created. This is the primary way to check progress — it returns structured JSON with all progress fields. Poll at reasonable intervals (e.g. every 5 minutes): plan generation typically takes 10-20 minutes (baseline profile) and may take longer on higher-quality profiles. State contract: pending/processing => keep polling; completed => download is ready; failed => terminal error; stopped => user called plan_stop (consider plan_resume). progress_percentage is 0-100 (integer-like float); 100 when completed. Note: steps vary in duration — early steps complete quickly while later steps (review, report generation) take longer. Do not use progress_percentage to estimate time remaining. steps_completed and steps_total give the number of plan generation steps completed and expected (both nullable). current_step is the human-readable label of the most recently completed step (e.g. 'SWOT Analysis'). timing.last_progress_at is an ISO 8601 timestamp of the last progress update (null until the first worker update); use it to compute time-since-last-progress and detect stalls — a gap > 10 minutes with no progress change is a strong stall signal. files lists the most recent 10 intermediate outputs produced so far (files_count gives the total); use their updated_at timestamps as a secondary stall signal. When state is 'failed', the response includes an error dict with failure diagnostics: error.failure_reason (category: generation_error, worker_error, inactivity_timeout, internal_error, version_mismatch), error.failed_step (pipeline step active at failure), error.message (human-readable message), and error.recoverable (true => plan_resume may work, false => use plan_retry). The error dict is absent for non-failed states. Unknown plan_id returns error code PLAN_NOT_FOUND. Troubleshooting: pending for >5 minutes likely means queued but not picked up by a worker. processing with timing.last_progress_at unchanged for >10 minutes l…

Input parameters:

- `plan_id` (string, required): Plan UUID returned by plan_create.

### `plan_stop` (~109 tokens)

Request the plan generation to stop. Pass the plan_id (the UUID returned by plan_create). Stopping is asynchronous: the stop flag is set immediately but the plan may continue briefly before halting. A stopped plan will transition to the stopped state. If the plan is already completed or failed, stop_requested returns false (the plan already finished). Unknown plan_id returns error code PLAN_NOT_FOUND.

Input parameters:

- `plan_id` (string, required): Plan UUID returned by plan_create. Use it to stop the plan creation.

Output parameters:

- `error`
- `state`: Current plan state after stop request.
- `stop_requested`: True when stop request flag was set for a pending/processing task.

### `plan_retry` (~112 tokens)

Retry a plan that is currently in failed or stopped state. Pass the plan_id and optionally model_profile (defaults to baseline). The plan is reset to pending, prior artifacts are cleared, and the same plan_id is requeued for processing. Returns PLAN_NOT_FOUND when plan_id is unknown and PLAN_NOT_FAILED when the plan is not in failed or stopped state.

Input parameters:

- `model_profile` (string): Model profile used for retry. Defaults to baseline.
- `plan_id` (string, required): UUID of the failed plan to retry.

Output parameters:

- `error`
- `model_profile`: Model profile assigned to the retry request.
- `plan_id`: Plan UUID that was retried (same ID as the failed or stopped plan).
- `retried_at`: UTC timestamp when the retry request was accepted.
- `sse_url`: Optional completion detector. Run `curl -N <sse_url>` in a background shell — the stream auto-closes when the plan reaches a terminal state (completed/failed/stopped). For structured progress data, u…
- `state`: Current plan state after retry request.

### `plan_resume` (~183 tokens)

Resume a failed or stopped plan without discarding completed intermediary files. Plan generation restarts from the first incomplete step, skipping all steps that already produced output files. Use plan_resume when plan_status shows 'failed' or 'stopped' and plan generation was interrupted before completing all steps (network drop, timeout, plan_stop, worker crash). For a full restart or to change model_profile, use plan_retry instead. Only failed or stopped plans can be resumed. Returns PLAN_NOT_FOUND when plan_id is unknown and PLAN_NOT_RESUMABLE when the plan is not in failed or stopped state. Returns PIPELINE_VERSION_MISMATCH when the snapshot was created by a different pipeline version; use plan_retry instead.

Input parameters:

- `model_profile` (string): Model profile used for the resumed plan. Defaults to baseline.
- `plan_id` (string, required): UUID of the failed plan to resume.

Output parameters:

- `error`
- `model_profile`: Model profile assigned to the resumed run.
- `plan_id`: Plan UUID that was resumed (same ID as the failed or stopped plan).
- `resume_count`: Number of times this plan has been resumed.
- `resumed_at`: UTC timestamp when the resume request was accepted.
- `sse_url`: Optional completion detector. Run `curl -N <sse_url>` in a background shell — the stream auto-closes when the plan reaches a terminal state (completed/failed/stopped). For structured progress data, u…
- `state`: Current plan state after resume request.

### `plan_file_info` (~230 tokens)

Returns file metadata (content_type, download_url, download_size, expires_at) for the report or zip artifact. Use artifact='report' (default) for the interactive HTML report (~700KB, self-contained with embedded JS for collapsible sections and interactive Gantt charts — open in a browser). Use artifact='zip' for the full pipeline output bundle (md, json, csv intermediary files that fed the report). While the task is still pending or processing, returns {ready:false,reason:"processing"}. Check readiness by testing whether download_url is present in the response. Once ready, present download_url to the user or fetch and save the file locally. Download URLs expire after 15 minutes (see expires_at); call plan_file_info again to get a fresh URL if needed. Terminal error codes: generation_failed (plan failed), content_unavailable (artifact missing). Unknown plan_id returns error code PLAN_NOT_FOUND.

Input parameters:

- `artifact` (string): Download artifact type: report or zip.
- `plan_id` (string, required): Plan UUID returned by plan_create. Use it to download the created plan.

### `plan_list` (~103 tokens)

List the most recent plans for an authenticated user. Returns up to `limit` plans (default 10, max 50) newest-first, each with plan_id, state, progress_percentage, created_at (ISO 8601), and a prompt_excerpt (first 100 chars). Use this to recover a lost plan_id or to review recent activity.

Input parameters:

- `limit` (integer): Maximum number of plans to return (1–50). Newest plans are returned first.

Output parameters:

- `message` (string): Human-readable summary (e.g. how many plans were returned).
- `plans` (array): Plans for the authenticated user, newest first.

### `send_feedback` (~258 tokens)

Submit feedback about PlanExe — issues, impressions, or suggestions. Callable at any point in the workflow; fire-and-forget, never blocks. Use category to classify: mcp (MCP tools, SSE, plan_status, workflow), plan (the generated output files), code (PlanExe source), docs (documentation), other. Optionally attach to a plan via plan_id. Use rating (1-5) for sentiment: 1=strong negative, 3=neutral, 5=strong positive. Especially useful for reporting: SSE streams that close before plan completion, plan_status returning stale or inconsistent data, queue delays where workers are slow to pick up plans, and impressions of plan output quality after reviewing reports. Include specific details (plan_id, percentages, timestamps) when reporting issues.

Input parameters:

- `category` (string, required): Feedback category: mcp, plan, code, docs, or other.
- `message` (string, required): Free-text feedback. Include environment context if reporting an issue.
- `plan_id`: Optional plan UUID to attach this feedback to.
- `rating`: Sentiment: 1=strong negative, 2=weak negative, 3=neutral, 4=weak positive, 5=strong positive.

Output parameters:

- `feedback_id` (string): Server-generated UUID for this feedback entry.
- `message` (string): Confirmation message.
- `received_at` (string): UTC timestamp when the feedback was received (ISO 8601).

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/planexeorg-planexe/mcp#diagnostics

## Score history

- 2026-08-03: 66
- 2026-08-02: 66
- 2026-08-01: 65
- 2026-07-31: 65
- 2026-07-30: 65
- 2026-07-29: 64
- 2026-07-28: 64
- 2026-07-27: 63
- 2026-07-26: 62

## Links

- Remote endpoint: https://mcp.planexe.org/mcp
- Authorisation metadata: https://mcp.planexe.org/.well-known/oauth-protected-resource/mcp
- Repository: https://github.com/PlanExeOrg/PlanExe
- Website: https://mcp.planexe.org/
- Changelog RSS feed: https://verifymcp.io/servers/planexeorg-planexe/mcp/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/planexeorg-planexe/mcp/changelog.json
- HTML version of this page: https://verifymcp.io/servers/planexeorg-planexe/mcp