MantleKit Launch Planner

Generate Project Blueprint

generate_project_blueprint

Read-onlyIdempotent

Turn an app idea into a launch-ready MantleKit project blueprint with pages, dashboard sections, entities, and MVP scope.

Input Schema

TableJSON Schema

Name	Required	Description
`appName`	Yes	Name of the planned product.
`adminNeeds`	No	Whether the product needs dashboard/admin workflows.
`oneLineIdea`	Yes	Short description of the product.
`authRequired`	No	Whether users need accounts, login, or protected areas.
`contentNeeds`	No	Whether the product needs CMS, blog, docs, or SEO content.
`coreFeatures`	No	Core user-facing features to include in the MVP.
`supportNeeds`	No	Whether the product needs tickets, chat, or support workflows.
`commercialUse`	No	Whether this is for client delivery or commercial agency use.
`ecommerceNeeds`	No	Whether the product needs products, orders, carts, or fulfilment.
`targetAudience`	No	Primary audience or buyer segment for the product.
`themePreference`	No	Desired MantleKit theme style or brand direction.
`paymentsRequired`	No	Whether the app needs checkout, subscriptions, or paid plans.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`links`	Yes
`appSummary`	Yes
`installCommand`	Yes
`suggestedPages`	Yes
`recommendedTier`	Yes
`recommendedTheme`	Yes
`recommendedMvpScope`	Yes
`recommendedLaunchPlan`	Yes
`suggestedDatabaseEntities`	Yes
`suggestedDashboardSections`	Yes
`recommendedMantleKitFeatures`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare read-only and idempotent behavior, so the description does not need to repeat safety traits. It adds useful context about the blueprint contents but does not disclose additional behavioral traits such as processing details or limitations. 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.

Conciseness5/5

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

The description is a single sentence, front-loaded with the action verb, and contains no redundant information. It conveys the core purpose in an efficient, well-structured manner.

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

Completeness4/5

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

For a generation tool with a comprehensive schema and an output schema, the description provides sufficient context about the tool's role and deliverables. It does not explain return values or edge cases, but the output schema handles that, making this adequately 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 baseline is 3; the description does not add parameter-level meaning beyond what is already in the schema. It only references 'app idea' generally, which maps to required parameters but offers no additional clarity.

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?

The description clearly states a specific verb ('Turn') and resource ('app idea into a MantleKit project blueprint') and enumerates concrete outputs (pages, dashboard sections, entities, MVP scope). This distinguishes it from sibling tools like match_theme or compare_build_vs_custom, which focus on different aspects.

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

Usage Guidelines3/5

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

The description implies use cases (when you have an app idea and need a blueprint) but does not explicitly state when to use this tool over siblings or provide exclusions. The context is clear but there is no direct comparison with alternatives.

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

All MantleKit Launch Planner tools Inspect

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.1/5.0

Disambiguation4/5

Tools are mostly distinct: compare_build_vs_custom focuses on cost/time comparison, generate_project_blueprint creates a detailed blueprint, match_theme specifically selects a theme, and recommend_setup combines tier, theme, and features. There is slight overlap between match_theme and recommend_setup since both involve theme selection, but descriptions differentiate their scope.

Naming Consistency5/5

All tool names follow a clear verb-first pattern: compare, generate, match, recommend. Although 'compare_build_vs_custom' is not a simple verb_noun, it still begins with an imperative verb and the naming style is consistent across the set.

Tool Count5/5

With only 4 tools, the set is tightly scoped for its purpose as a launch planner. Each tool addresses a distinct planning need, and there is no bloat or redundancy. This size is well within the ideal range.

Completeness4/5

The tools cover the core planning lifecycle: comparing options, generating a blueprint, selecting a theme, and recommending a full setup. Minor gaps exist such as no explicit cost breakdown beyond the comparison or no subsequent implementation steps, but these are workable and not critical to the stated purpose.

Resources

Need Help?