PlanExe
REMOTE · MCP.PLANEXE.ORG · SCANNED AUG 3
MCP server for generating rough-draft project plans from natural-language prompts.
Available components
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. How we score →
Endpoint Security57
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- 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. View diagnostics → Unverified
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability74
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (excellent).Pass
- 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. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management27
- Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage98
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 94% of tool parameters carry a description.Partial
- Structured output schemas are declared (82% of tools); any adoption earns full credit.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Add this component to your MCP client. Where a client-specific snippet is available, pick your client below and copy it straight into your config; otherwise use the connection detail shown.
remote · mcp.planexe.org
claude mcp add --transport http planexeorg-planexe https://mcp.planexe.org/mcp
[mcp_servers.planexeorg-planexe] url = "https://mcp.planexe.org/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"planexeorg-planexe": {
"type": "remote",
"url": "https://mcp.planexe.org/mcp",
"enabled": true
}
}
} openclaw mcp add planexeorg-planexe --url https://mcp.planexe.org/mcp --transport streamable-http
mcp_servers:
planexeorg-planexe:
url: "https://mcp.planexe.org/mcp" {
"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.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 2 Aug 26 +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.
- 31 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 30 Jul 26 +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.
- 28 Jul 26 +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.
- 27 Jul 26 +1
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 26 Jul 26 62
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 3 Aug 2026 · Probed https://mcp.planexe.org/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=mcp.planexe.org | CN=YR2,O=Let's Encrypt,C=US | 9 Jun 2026 | 7 Sept 2026 | RSA 2048 | SHA256-RSA | 54b5e684f2a4c3e9611b0b1ecfafd233db7 |
| SANs: mcp.planexe.org | ||||||
| CN=YR2,O=Let's Encrypt,C=US (CA) | CN=Root YR,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | RSA 2048 | SHA256-RSA | 4ebd24947e24d394802d84a52fd5b319 |
| CN=Root YR,O=ISRG,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | RSA 4096 | SHA256-RSA | f24b6d17f9d9ad7cb1c9fea78782699f |
DNSSEC insecure
Validation of mcp.planexe.org. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| org. | present | 26974 | 8 | Verified |
| planexe.org. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://mcp.planexe.org/mcp | Verified | 200 | |
| http (plaintext) | http://mcp.planexe.org/mcp | HTTPS enforced | 301 | https://mcp.planexe.org/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability.
example_plans ~63
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.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| message | string | yes | — |
| plans | array | yes | Curated example plans with download links for reports and zip bundles. |
No examples provided.
example_prompts ~185
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.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| message | string | yes | — |
| samples | array | yes | 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… |
No examples provided.
model_profiles ~45
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.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| default_profile | string | yes | Default model profile used when plan_create.model_profile is omitted/invalid. |
| message | string | yes | Caller guidance for selecting plan_create.model_profile. |
| profiles | array | yes | Available profile options and their model inventory. |
No examples provided.
plan_create ~449
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.
| Name | Type | Req | Description |
|---|---|---|---|
| model_profile | string | — | Model profile: baseline, premium, frontier, custom. Call model_profiles to inspect options. |
| prompt | string | yes | — |
| 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| created_at | string | yes | — |
| 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 | yes | 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… |
No examples provided.
plan_file_info ~230
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.
| Name | Type | Req | Description |
|---|---|---|---|
| artifact | string | — | Download artifact type: report or zip. |
| plan_id | string | yes | Plan UUID returned by plan_create. Use it to download the created plan. |
No output schema declared.
No examples provided.
plan_list ~103
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.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | — | Maximum number of plans to return (1–50). Newest plans are returned first. |
| Name | Type | Req | Description |
|---|---|---|---|
| message | string | yes | Human-readable summary (e.g. how many plans were returned). |
| plans | array | yes | Plans for the authenticated user, newest first. |
No examples provided.
plan_resume ~183
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.
| Name | Type | Req | Description |
|---|---|---|---|
| model_profile | string | — | Model profile used for the resumed plan. Defaults to baseline. |
| plan_id | string | yes | UUID of the failed plan to resume. |
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
No examples provided.
plan_retry ~112
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.
| Name | Type | Req | Description |
|---|---|---|---|
| model_profile | string | — | Model profile used for retry. Defaults to baseline. |
| plan_id | string | yes | UUID of the failed plan to retry. |
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
No examples provided.
plan_status ~459
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…
| Name | Type | Req | Description |
|---|---|---|---|
| plan_id | string | yes | Plan UUID returned by plan_create. |
No output schema declared.
No examples provided.
plan_stop ~109
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.
| Name | Type | Req | Description |
|---|---|---|---|
| plan_id | string | yes | Plan UUID returned by plan_create. Use it to stop the plan creation. |
| Name | Type | Req | Description |
|---|---|---|---|
| error | — | — | — |
| state | — | — | Current plan state after stop request. |
| stop_requested | — | — | True when stop request flag was set for a pending/processing task. |
No examples provided.
send_feedback ~258
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.
| Name | Type | Req | Description |
|---|---|---|---|
| category | string | yes | Feedback category: mcp, plan, code, docs, or other. |
| message | string | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| feedback_id | string | yes | Server-generated UUID for this feedback entry. |
| message | string | yes | Confirmation message. |
| received_at | string | yes | UTC timestamp when the feedback was received (ISO 8601). |
No examples provided.