Loading ToolBench
MCP server that generates strategic project-plan drafts from a natural-language prompt
PlanExe MCP Cloud provides 11 tools with solid naming (action verbs), consistent descriptions, and complete JSON Schema definitions. Most tools have good parameter typing and validation (enums, defaults, ranges). However, descriptions are somewhat generic and lack LLM-optimized specificity. Output schemas are not documented in the visible source. Error handling guidance is absent, tools do not indicate what to do on failure, retry eligibility, or how to recover. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present, which is a missed opportunity for protocol-current signal. The server follows good structural patterns but falls short of A-grade polish on description depth, error recovery, and output documentation.
Return curated example plans with download links (no arguments).
Return curated example prompts from the catalog (no arguments).
Return model_profile options with currently available models.
Create a new PlanExe task. Use example_prompts first for example prompts.
Get information about plan output files and download URLs.
List the most recent plans for an authenticated user.
Resume a stopped plan creation task.
Output schemas not documented. Tools like plan_status, plan_create, and plan_list do not specify what fields are returned, what structure the response has, or what the LLM should expect. This forces the LLM to infer response structure from context, risking misinterpretation of nested objects, pagination, or status indicators.
Descriptions lack LLM-optimized depth. Descriptions like 'Get the status of a plan creation task.' (50 chars) and 'Return curated example prompts from the catalog (no arguments).' (62 chars) are too terse. They do not answer WHEN to use the tool (vs similar tools), WHAT it returns, or any prerequisites. Baseline for A-grade tools is 50 - 200 chars with actionable context.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 76 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Retry a failed plan creation task.
Get the status of a plan creation task.
Stop a plan creation task.
Submit your feedback about PlanExe.
No error handling or recovery guidance. Tools return errors but do not indicate whether errors are retryable, what the LLM should do next, or how to recover. E.g., if plan_create fails due to invalid prompt or model unavailability, the LLM has no guidance. Pattern requires: error code, classification (retryable/user-fixable/fatal), and recovery action.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools like plan_stop and plan_retry are destructive or modify state, but carry no annotations signaling this to the LLM or client. Per current MCP spec (2026-07-28), these annotations are standard for protocol-current implementations.
Parameter descriptions are minimal. E.g., 'plan_id': 'Plan UUID returned by plan_create.' is clear but does not document format, length, or example pattern. 'start_date': 'Optional plan start date in ISO 8601 format...' is good, but most other params lack this specificity. Rule: every param needs format/type/constraint detail in the description.
Discovery tools (example_prompts, model_profiles, example_plans) lack context on WHEN to call them in a workflow. Are they initialization-only? Can they be called at any time? Do they cache? The LLM needs workflow hints to avoid redundant calls and understand sequencing.