A prompt can write a product requirements document once. What separates this is that both halves are persisted and editable: templates are created, revised through update, and moved between machines as JSON, while validation rules are pattern-based and extensible, with list_all_rules showing yours next to the defaults. That turns "how we write PRDs" into something enforced rather than remembered. health_check covering the database and the providers together is a candid acknowledgement that generation depends on an external service that can be down.
A PRD server built around three managed collections — templates, validation rules and AI provider configuration — with generation, rendering and validation running over them.
- generate_prd, producing a document from a named template given the product name, description, target audience, core features and constraints
- render_template, the same placeholder substitution without the generation step
- validate_prd, checking a document against best-practice rules, with the rule set listable first
- Custom validation rules added, updated and deleted by pattern, and list_all_rules showing defaults and custom rules together
- Template management: create, list, get by ID or name, update, soft-delete, and export or import the whole set as a JSON file
- AI provider handling: the available providers with their status, the stored configuration overrides, and updates to providerId, apiKey, baseUrl and model
- Operational tooling: usage metrics per operation, a health check covering the database and the providers, and recent log entries read from disk
For the generation tools, a configured AI provider — list_ai_providers reports which are available and update_provider_config takes the providerId, apiKey, baseUrl and model. The template and validation-rule tools work without one.
One command — npx -y prd-creator-mcp