Skip to main content
Glama

PlanExe

by io.github.PlanExeOrg

plan_create

Idempotent

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 Schema

TableJSON Schema
NameRequiredDescriptionDefault
promptYes
start_dateNoOptional 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.
model_profileNoModel profile: baseline, premium, frontier, custom. Call model_profiles to inspect options.baseline

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
plan_idYesPlan UUID returned by plan_create. Stable across plan_status/plan_stop/plan_file_info.
sse_urlNoOptional 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, use plan_status instead.
created_atYes
deduplicatedNoTrue 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.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • addedInput schema / properties / start_date
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "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.",
+  "title": "Start Date"
+}
  2. Changed1 schema field changed
    • changedOutput schema / properties / sse_url / description
      Previous value: -"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). For structured progress data, use plan_status instead."New value: +"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, use plan_status instead."
  3. Changed1 schema field changed
    • addedOutput schema / properties / deduplicated
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "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.",
+  "title": "Deduplicated"
+}
  4. Changed1 schema field changed
    • changedOutput schema / properties / sse_url / description
      Previous value: -"GET endpoint returning text/event-stream with real-time plan progress. No API key required — the plan_id UUID serves as the access token. Usage: `curl -N <sse_url>`. Emits 'status' events on progress changes, 'heartbeat' every ~20 s, and a final 'complete' event (state completed/failed) then auto-closes. Alternative to polling plan_status."New value: +"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). For structured progress data, use plan_status instead."
  5. Changed1 schema field changed
    • changedOutput schema / properties / sse_url / description
      Previous value: -"GET endpoint returning text/event-stream with real-time plan progress. Usage: `curl -N -H 'X-API-Key: <same key>' <sse_url>`. Emits 'status' events on progress changes, 'heartbeat' every ~20 s, and a final 'complete' event (state completed/failed) then auto-closes. Alternative to polling plan_status."New value: +"GET endpoint returning text/event-stream with real-time plan progress. No API key required — the plan_id UUID serves as the access token. Usage: `curl -N <sse_url>`. Emits 'status' events on progress changes, 'heartbeat' every ~20 s, and a final 'complete' event (state completed/failed) then auto-closes. Alternative to polling plan_status."
  6. Changed1 schema field changed
    • addedOutput schema / properties / sse_url
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "GET endpoint returning text/event-stream with real-time plan progress. Usage: `curl -N -H 'X-API-Key: <same key>' <sse_url>`. Emits 'status' events on progress changes, 'heartbeat' every ~20 s, and a final 'complete' event (state completed/failed) then auto-closes. Alternative to polling plan_status.",
+  "title": "Sse Url"
+}
  7. Changed3 schema fields changed
    • addedOutput schema / properties / plan_id
      Added value: +{
+  "description": "Plan UUID returned by plan_create. Stable across plan_status/plan_stop/plan_file_info.",
+  "title": "Plan Id",
+  "type": "string"
+}
    • removedOutput schema / properties / task_id
      Removed value: -{
-  "description": "Task UUID returned by plan_create. Stable across plan_status/plan_stop/plan_file_info.",
-  "title": "Task Id",
-  "type": "string"
-}
    • changedOutput schema / required
      Previous value: -[
-  "task_id",
-  "created_at"
-]New value: +[
+  "plan_id",
+  "created_at"
+]
  8. Added

TDQS

A4.8/5.0
Behavior5/5

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

Despite idempotent/open-world annotations, description adds rich behavioral detail: async ~10-20 min generation, deduplication on repeated prompts, SSE stream auto-close, and credit/api_key handling. No contradiction with 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?

A long description, but the section list and operational details are purposeful for a high-stakes async creation tool. It opens with the most critical prerequisite and keeps related considerations in logical order, though a structured layout would improve scannability.

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?

Covers return value (plan_id), subsequent steps (plan_status, plan_retry, etc.), error codes, dedup behavior, and SSE completion detection. Despite no visible output schema, the description gives enough operational context to invoke and monitor the tool successfully.

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?

Input schema covers prompt, start_date, and model_profile with descriptions; description adds selection guidance for model_profile ('call model_profiles first') and credential handling (user_api_key for credits). This exceeds schema baseline but doesn't deeply explain start_date or prompt formatting.

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?

States a specific action: PlanExe turns the approved prompt into a strategic project-plan draft with 20+ sections. It explicitly differentiates the tool from siblings by requiring prior example_prompts and by returning a plan_id for downstream plan_* tools.

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?

Explicitly says 'Call only after example_prompts and after you have completed prompt drafting/approval.' Also tells when to use model_profiles, plan_status, and plan_list alternatives. Provides strong when-to-use and fallback guidance.

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

All PlanExe toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool has a distinct, non-overlapping purpose within the PlanExe workflow. For example, example_plans and example_prompts serve different preparatory functions, while plan_create, plan_status, plan_stop, plan_resume, and plan_retry handle distinct lifecycle stages of plan generation. No tools appear to duplicate functionality, making selection clear for an agent.

Naming Consistency5/5

Tool names follow a highly consistent verb_noun pattern throughout, with all tools using snake_case and clear action-object pairs (e.g., plan_create, plan_status, plan_stop). The naming is predictable and readable, with no deviations in style or convention across the set.

Tool Count5/5

With 11 tools, the server is well-scoped for its purpose of generating and managing strategic project plans. Each tool serves a specific role in the workflow, from preparation (example_prompts, model_profiles) to creation (plan_create), monitoring (plan_status), lifecycle management (plan_stop, plan_resume, plan_retry), and feedback (send_feedback). The count is appropriate and avoids bloat or gaps.

Completeness5/5

The tool set provides complete coverage for the plan generation domain, including CRUD-like operations (create, list, status, stop, resume, retry) and supporting functions (examples, model selection, file retrieval, feedback). There are no obvious gaps; agents can handle the entire lifecycle from prompt drafting to plan retrieval and error recovery without dead ends.

Resources