NSTOK AI Software Factory MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

create_app_plan

Turn a PRD into a structured application implementation plan by applying SEARCH, REUSE, ADAPT, and CREATE to identify and reuse existing features, UI components, models, and templates.

Instructions

Generate a structured application implementation plan following the SEARCH -> REUSE -> ADAPT -> CREATE principle.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "appName": "<appName>",
      "prd": "<prd>"
    },
    "name": "create_app_plan"
  }
}

Input Schema

Name	Required	Description
`prd`	Yes	PRD specifications or requirements
`appName`	Yes	Target application name (e.g. "nstok-app-w")
`template`	No	Custom baseline template (defaults to Nstok-app-template)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 11, 2026

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It hints at a structured output and a methodology, but does not describe permissions, side effects, whether the plan is persisted, or what the response contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It states the tool's purpose immediately and keeps the supporting methodology brief.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There are no annotations and no output schema, so the description should explain more about usage context, expected output, and side effects. For a plan-generation tool that likely interacts with many sibling search, analysis, and creation tools, the definition is too terse to be complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no parameter-level semantics, which is acceptable under the high-coverage baseline, but it also provides no extra meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: generating a structured application implementation plan. It distinguishes itself from the sibling create_feature_plan by specifying an application-level plan, although it does not explicitly name that sibling or other related tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It says what to generate but gives no guidance on when to use this tool versus alternatives such as analyze_prd, create_feature_plan, or create_app. There are no prerequisites, exclusions, or contextual triggers mentioned.

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