MantleKit Launch Planner

Recommend MantleKit Setup

recommend_setup

Read-onlyIdempotent

Recommend the best MantleKit tier, theme, and built-in feature set for a new app idea.

Input Schema

TableJSON Schema

Name	Required	Description
`appIdea`	Yes	Plain-English description of the app idea.
`needsCms`	No	Whether structured content management is needed.
`needsAuth`	No	Whether authentication is needed.
`needsAdmin`	No	Whether a serious admin/dashboard surface is needed.
`businessType`	No	Business model or category, for example B2B SaaS or agency.
`commercialUse`	No	Whether client delivery or commercial usage matters.
`needsPayments`	No	Whether hosted payments or checkout are needed.
`needsEcommerce`	No	Whether products, orders, and customers are needed.
`targetAudience`	No	Primary audience for the product.
`needsSupportTickets`	No	Whether support ticketing is needed.
`preferredThemeStyle`	No	Desired visual direction or brand adjectives.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`why`	Yes
`links`	Yes
`summary`	Yes
`nextSteps`	Yes
`confidence`	Yes
`assumptions`	Yes
`alternatives`	Yes
`installCommand`	Yes
`recommendedTier`	Yes
`recommendedTheme`	Yes
`recommendedFeatures`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context beyond restating the purpose, such as what inputs it relies on or what the recommendation process involves. This is acceptable but not additive.

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 fluff. Every word contributes to the tool's purpose.

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?

With 11 parameters, the schema documents them all and an output schema exists. The description explains the overall goal and context, though it could have explicitly noted that it considers the user's needs (as captured by the boolean fields). Still, the combination is adequate for a recommendation tool.

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?

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description itself does not elaborate on parameters, but the schema handles them well, so no additional compensation is needed.

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 the tool's function with a specific verb ('Recommend'), a specific target ('best MantleKit tier, theme, and built-in feature set'), and context ('for a new app idea'). This makes it distinct from sibling tools like compare_build_vs_custom or match_theme.

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 phrase 'for a new app idea' implies the appropriate use case, but there is no explicit guidance on when not to use it or how it differs from sibling tools. It provides enough context to infer usage, but no exclusions or alternatives are mentioned.

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?