Loading ToolBench
LaunchFrame MCP provides 39 tools across domain-specific knowledge areas. Strengths: consistent naming patterns (verb_noun with get_ prefix), all tools have descriptions (10-200 chars), and input schemas are properly typed with Zod. Weaknesses: many tools lack detailed parameter descriptions; output schemas are not documented (tool responses return loaded Markdown or code snippets without formal schema); no error handling guidance; responses are text-based rather than structured objects; no pagination or result limits for discovery tools. The server is primarily informational (39 of 39 are READ_ONLY or scaffolding tools), which lowers the importance of error recovery and idempotency patterns. However, 11 tools perform write/destructive operations (cli_* and migration_* tools) with minimal safety guardrails.
Get the overall architecture of the LaunchFrame project: services, backend module layout, key patterns, frontend structure, and infrastructure.
Get the exact decorator and import for a specific auth need.
Get the guard class, import path, and decorator combo for a specific guard type.
Get full auth system overview: guard hierarchy, session flow, Better Auth setup, roles, and decorator system.
Execute a SQL query and return the results as text. Workflow: 1. Call database_schema first to learn table/column names. 2. Call this tool with a complete, valid SQL statement. 3. Read the returned text — it is raw psql output (column headers + rows). Local (default): runs against the Docker Compose database on the developer machine. → Requires `launchframe docker:up` to be running. Remote (remote=true): SSHs into the VPS and runs against the production database. → Will ask the user for confirmation before executing. → Only use when the user explicitly asks about production/live data. Supported statements: SELECT, INSERT, UPDATE, DELETE, EXPLAIN, etc. Always end the SQL with a semicolon. Quote identifiers that are reserved words (e.g. "user", "order").
Output schemas not documented. Tools return text content (Markdown, code snippets) without declaring response structure. LLMs cannot reliably parse unstructured text to extract fields for downstream tool calls. Example: cli_docker_logs returns 'last N lines' but type signature and field names are not specified.
Parameter descriptions lack implementation detail. Parameters like 'projectPath' (string), 'service' (string), 'name' (string) are described only by purpose, not by format constraints, example values, or validation rules. Example: cli_migration_create 'name' param says 'Migration name in PascalCase' but does not specify length limits, allowed characters, or fail behavior for invalid names.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 59 | - | v1 |
Build Docker images for a LaunchFrame project (all services or a specific one).
Destroy ALL Docker resources for a LaunchFrame project (containers, volumes, images, network). IRREVERSIBLE — all local data including database volumes will be lost. Will prompt for confirmation before proceeding.
Stop all running Docker services for a LaunchFrame project.
Fetch a snapshot of Docker service logs (non-streaming). Returns the last N lines.
Start Docker services for a LaunchFrame project. Always runs detached (background). Use cli_docker_logs to inspect output afterward.
Create a new empty TypeORM migration file with the given name.
Revert the most recently applied TypeORM database migration.
Run all pending TypeORM database migrations against the local database.
Get the code snippet for programmatically adding credits to a user with a specific transaction type.
Get the decorator + guard pattern for deducting credits on a route.
Get an overview of all monetization strategies (free, subscription, credits, hybrid) and when to use each.
Get the LaunchFrame cron job pattern: where jobs live, available CronExpression presets, and module registration rules.
Scaffold a new cron method to add to CronService (src/jobs/cron.service.ts).
Returns the full database schema (all tables, columns, types, relations) plus ready-made SQL snippets for common questions like user counts, active sessions, subscription plans, credit balances, etc. Call this before running cli_database_query when the user asks a data question.
Get an overview of the LaunchFrame email system: sending patterns (direct vs queue-based), template conventions, built-in templates, and environment setup.
Generate NestJS code to send a transactional email — either by injecting MailService directly (direct) or via the emails Bull queue (queued).
Generate a Handlebars (.hbs) template stub for a new LaunchFrame transactional email, following project conventions.
Get TypeORM entity conventions for LaunchFrame: required decorators, naming strategy, column types, relations, and multi-tenancy.
Generate a TypeORM entity file following LaunchFrame conventions.
Get environment variable conventions for LaunchFrame: single centralized .env location, variable naming rules, full key variable reference, and how to add new variables.
Get a copy-paste TypeScript snippet for checking a feature gate by code and type.
Get the feature gate system overview: how features are stored, how to query them, and the check pattern.
Get the NestJS module folder structure, conventions, and rules used in LaunchFrame.
Generate a NestJS module scaffold (module + service + optional controller + optional entity) following LaunchFrame conventions.
List all available Bull queues in LaunchFrame with their purpose and usage rules.
Get a Bull processor class scaffold for a given queue and job name.
Get the code to inject and use a Bull queue as a producer in a NestJS service.
Get when and how to apply @RequiresPermission, owner bypass rules, cache invalidation patterns, and multi-tenant scoping behaviour.
Get full RBAC model overview: actor responsibilities, data model, default roles, guard evaluation order, and variant axis.
Get the 4-step workflow for adding a new permission: enum → seeder → superadmin assigns → @RequiresPermission().
Get an overview of the subscription plans system: plan groups, annual billing toggle, API response shape, and key files.
Get an overview of LaunchFrame project variants: Base (B2B single-tenant), Multi-tenant, and B2B2C. Explains how to read the active variant from the .launchframe file and what behavioral differences to account for when writing new code.
Get an overview of the LaunchFrame webhook architecture: receipt/processing separation, WebhookLog entity, Bull queue, and retry cron.
Get a scaffold for a new webhook handler: controller receipt + Bull processor for a given provider and event type.
No error handling guidance. Destructive operations (cli_docker_destroy, cli_migration_revert, cli_database_query on production) lack recovery instructions. When cli_docker_destroy fails or cli_database_query executes against the wrong database, the LLM receives no guidance on what to do next or how to undo. Example: cli_docker_destroy says 'Will prompt for confirmation' but does not document what happens if the prompt times out, how long the operation takes, or what partial-failure scenarios look like.
No confirmation/dry-run pattern for destructive operations. cli_docker_destroy and cli_database_query (remote=true) are marked as DESTRUCTIVE or WRITE but lack explicit dry-run, preview, or MUST_CONFIRM_BEFORE_EXECUTE patterns. LLMs can trigger irreversible data loss without multi-step confirmation.
cli_database_query has overly broad risk surface. The tool accepts arbitrary SQL (SELECT, INSERT, UPDATE, DELETE) and remote production access via a 'remote' boolean flag. No per-statement type validation, no query allowlist, and reliance on a user prompt for 'confirmation' before production execution. An LLM could emit 'DELETE FROM user WHERE id = 1' against production without proper guardrails.
Missing tool annotations. No tools are declared with readOnlyHint, destructiveHint, or idempotentHint. The protocol supports these annotations (official capability in spec 2026-07-28) to help clients and agents reason about risk. cli_docker_destroy and cli_migration_revert should declare destructiveHint=true.
No pagination or result-limiting guidance. discovery/informational tools (queue_get_names, database_schema, etc.) do not declare output limits or pagination parameters. If database_schema returns a very large schema (100+ tables), the response could blow the context window.
Tool composition gaps. Several write operations (cli_docker_up, cli_migration_run) lack response documentation about what state was changed. cli_docker_up does not specify what the response looks like, does it return container IDs? Exit codes? Timestamps? This makes it hard for LLMs to chain outputs to downstream tool calls.