draftlytic-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| validate_specA | Validate a project spec against the schema and return structured issues. A project spec: name, overview, target_audience, platforms[], tech_stack[], features[] ({title, description, priority: must-have|nice-to-have|future, acceptance_criteria?[]}), screens[]? ({name, purpose}), data_model[]? ({entity, fields[]: {name, type, notes?}}), constraints[]?, non_goals[]?, revenue_model?. Checks for missing/empty required sections, placeholder text (e.g. "TBD", "lorem ipsum", "fixme"), and features without a priority — all reported as errors. Also returns non-blocking quality hints, e.g. "none of your must-have features have acceptance_criteria" or "no non_goals listed". |
| render_prdA | Render a project spec into a deterministic, Draftlytic-style Markdown PRD. A project spec: name, overview, target_audience, platforms[], tech_stack[], features[] ({title, description, priority: must-have|nice-to-have|future, acceptance_criteria?[]}), screens[]? ({name, purpose}), data_model[]? ({entity, fields[]: {name, type, notes?}}), constraints[]?, non_goals[]?, revenue_model?. Output includes: title, overview, target audience, platforms, tech stack, features grouped by priority (must-have / nice-to-have / future) with acceptance-criteria checklists, screens & navigation, data model tables, constraints, and non-goals. Run validate_spec first — this tool renders whatever it's given, even an incomplete spec. |
| spec_checklistA | Return a planning checklist grouped by category (platform, tech stack, target audience, features, competitors, revenue, constraints, data model, notifications, external services, design & UX), each with 2-4 concrete questions. Use this to interview the user before drafting a spec — you don't need to ask every question, just enough per category to fill in the schema meaningfully. |
| open_in_draftlyticA | Build a link that opens this idea in the full Draftlytic app (free account, no card), which runs its own guided flow: AI-tailored questions, full project generation, an editable structured spec, and PRD export (plus scan-for-gaps, logo drafts, and GitHub push on paid plans). Pass either the spec drafted here (it gets compressed into a starting brief) or a plain-text idea. Show the returned URL to the user as a clickable link — this tool only builds it; nothing is sent anywhere. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| plan_project | Interview the user about their project idea, then draft, validate, and render a structured spec. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clear, distinct purpose: generating links, rendering PRDs, providing checklists, and validating specs. No overlap or confusion.
Names use underscores but mix verb_noun (render_prd, validate_spec), verb_preposition_noun (open_in_draftlytic), and noun_noun (spec_checklist), lacking a uniform pattern.
Four tools cover the essential workflow of gathering requirements, validating, rendering PRD, and linking to external app. No extraneous tools; each earns its place.
The surface covers the key stages from requirements gathering to PRD generation and external integration. A minor gap is the lack of a tool to edit or update a spec, but the pipeline is functional.