Skip to main content
Glama

FRD Orchestrator - MCP Server

๐Ÿš€ Automated NestJS boilerplate generation powered by MCP and structured FRDs

MCP (Model Context Protocol) server that exposes NestJS boilerplate FRDs so GitHub Copilot can regenerate the complete architecture from scratch in any project, following Clean Architecture, SOLID principles, and best practices.

mcp-vscode

๐Ÿค” What is MCP and why use it?

MCP (Model Context Protocol) is a standardized way for AI assistants like GitHub Copilot to access external tools and data sources. Think of it as a "bridge" that allows Copilot to:

  • ๐Ÿ“– Read live documents (your FRDs) instead of outdated copies

  • ๐Ÿ”ง Access specialized tools beyond basic file operations

  • ๐Ÿ“Š Get structured data with validation and logging

  • ๐Ÿ”„ Always stay updated - changes to FRDs are immediately available

Why FRDs via MCP instead of just reading files?

Traditional File Reading

MCP + FRDs

โŒ Stale content when files change

โœ… Always fresh content

โŒ No validation or error handling

โœ… Built-in validation and logging

โŒ Manual file path management

โœ… Structured ID-based access

โŒ No usage tracking

โœ… Full audit trail of what was read

Related MCP server: Gigaspec

๐ŸŽฏ What does this server do?

This MCP server exposes 5 carefully crafted FRDs that define a complete NestJS boilerplate:

  • FRD-00: ๐ŸŽญ Master orchestration - How GitHub Copilot should execute the 4 phases

  • FRD-01: ๐Ÿ—๏ธ Boilerplate core - Basic NestJS + Products CRUD + Swagger

  • FRD-02: ๐Ÿ—„๏ธ Database layer - TypeORM + migrations + repository pattern

  • FRD-03: ๐Ÿ” Authentication - JWT + Passport + protected endpoints

  • FRD-04: ๐Ÿงช Unit testing - Jest + mocks + coverage for all modules

๐Ÿ”„ How does the orchestration work?

When you tell GitHub Copilot to generate a boilerplate, here's what happens:

  1. ๐Ÿ“‹ Copilot reads FRD-00 (master orchestration) to understand the plan

  2. ๐Ÿ—๏ธ Phase 1: Reads FRD-01 โ†’ Creates basic NestJS + Products CRUD

  3. ๐Ÿ—„๏ธ Phase 2: Reads FRD-02 โ†’ Adds database + TypeORM + migrations

  4. ๐Ÿ” Phase 3: Reads FRD-03 โ†’ Implements JWT auth + protected routes

  5. ๐Ÿงช Phase 4: Reads FRD-04 โ†’ Generates unit tests for everything

  6. ๐Ÿ“ Final: Generates comprehensive README with setup instructions

Each phase is automatic - no manual intervention required. GitHub Copilot follows the FRDs religiously and ensures each phase works before moving to the next.

โœจ Complete workflow example

# 1. You say this to GitHub Copilot:
"folder name: my-api. Start the orchestration."

# 2. GitHub Copilot automatically:
# - Reads FRD-00 to understand the plan
# - Creates `my-api/` directory
# - Executes Phase 1: Basic NestJS setup
# - Executes Phase 2: Database integration  
# - Executes Phase 3: JWT authentication
# - Executes Phase 4: Unit tests
# - Generates final README

# 3. Result: Complete production-ready API with:
# โœ… Products CRUD with validation
# โœ… Swagger documentation at /api
# โœ… Database persistence (SQLite by default)
# โœ… JWT authentication protecting all routes
# โœ… Unit tests with >80% coverage
# โœ… Clean Architecture + SOLID principles
# โœ… Complete setup documentation

The entire process takes 5-10 minutes and results in a production-ready NestJS API that you can deploy immediately.

Requirements

  • Python 3.10+

  • VS Code with GitHub Copilot enabled

  • uv (recommended) or pip

Installation

1. Clone/Copy this folder to your project

# Add this MCP server to your existing project
git clone <your-repo> mcp-server
cd mcp-server

2. Install dependencies

Option A: With uv (recommended)

uv sync

Option B: With pip

pip install fastmcp

3. Verify installation

python main.py

You should see logs like:

[FRD-Orchestrator] 12:34:56 | INFO | Starting MCP FRD-Orchestrator server (stdio)
[FRD-Orchestrator] 12:34:56 | INFO | FRD Directory: /path/to/mcp-server/frd

VS Code + GitHub Copilot Configuration

1. Create MCP configuration in your workspace

Create .vscode/mcp.json in your project root:

{
  "_note": "This configuration is for academic purposes. The command path depends on the execution environment and may vary based on where the UV tool is installed on different systems.",
  "servers": {
    "frd-orchestrator": {
      "type": "stdio", 
      "command": "/Users/[your-username]/.local/bin/uv",
      "args": ["run", "main.py"]
    }
  }
}

โš ๏ธ Important:

  • Adjust the path to UV according to your system

  • Use which uv to find your UV installation path

  • If using Python directly: "command": "python" and "args": ["main.py"]

2. Ensure GitHub Copilot has MCP access

GitHub Copilot in VS Code automatically detects MCP servers configured in .vscode/mcp.json when MCP support is enabled.

3. Test the connection

Open VS Code in your project and ask GitHub Copilot:

"Show me what's available in FRD-00"

If working correctly, you'll see logs in the terminal and Copilot will access the FRD content.

Usage

Once configured, GitHub Copilot automatically has access to the get_frd tool and can read all FRDs on demand.

๐ŸŽฏ Simple commands to get started:

"folder name: my-awesome-api. Start the orchestration."

That's it! GitHub Copilot will:

  1. Create the folder

  2. Read all FRDs automatically

  3. Execute all 4 phases in sequence

  4. Generate a complete, working API

๐Ÿ› ๏ธ Advanced usage:

"Generate just the core boilerplate (Phase 1 only)"
"Add database layer following FRD-02" 
"Implement JWT authentication according to FRD-03"
"Generate comprehensive unit tests per FRD-04"
"Show me what FRD-01 contains"

๐Ÿ” Behind the scenes:

When GitHub Copilot executes, you'll see logs like:

[FRD-Orchestrator] Reading FRD from disk: /path/to/frd/FRD-01-boilerplate-core-products.md
[FRD-Orchestrator] Tool get_frd requested with frd_id=01
[FRD-Orchestrator] FRD read successfully: FRD-01-boilerplate-core-products.md (15,432 characters)

This means GitHub Copilot is actively reading the latest version of your FRDs and following them exactly.

โšก What makes this powerful:

  • ๐ŸŽฏ Zero configuration - Just one command and everything works

  • ๐Ÿ“‹ Structured approach - Each phase builds on the previous

  • ๐Ÿ”„ Always updated - FRDs are read fresh every time

  • ๐Ÿ—๏ธ Production ready - Not just demos, real deployable code

  • ๐Ÿ“š Self-documenting - Generated README explains everything

  • ๐Ÿงช Fully tested - Unit tests included for all modules

File structure

mcp-server/
โ”œโ”€โ”€ main.py                          # MCP Server
โ”œโ”€โ”€ README.md                        # This file
โ”œโ”€โ”€ pyproject.toml                   # Dependencies (create if not exists)
โ””โ”€โ”€ frd/
    โ”œโ”€โ”€ FRD-00-master-orchestration.md
    โ”œโ”€โ”€ FRD-01-boilerplate-core-products.md
    โ”œโ”€โ”€ FRD-02-products-database.md
    โ”œโ”€โ”€ FRD-03-auth-security.md
    โ””โ”€โ”€ FRD-04-unit-testing.md

Troubleshooting

Claude doesn't recognize the get_frd tool

  1. Verify that Claude Desktop is restarted

  2. Check logs in:

    • macOS: ~/Library/Logs/Claude/mcp*.log

    • Windows: %APPDATA%\Claude\logs\

  3. Make sure to use absolute paths in claude_desktop_config.json

Error: FRD_DIR does not exist

The frd/ directory must be next to main.py:

ls -la mcp-server/
# Should show: main.py, frd/

Logs don't appear

Change the log level in claude_desktop_config.json:

"env": {
  "FRD_ORCH_LOG_LEVEL": "DEBUG"
}

Python not found

If using uv:

{
  "command": "uv",
  "args": ["run", "/absolute/path/to/mcp-server/main.py"]
}

Environment variables

Variable

Description

Default

FRD_ORCH_LOG_LEVEL

Logging level (DEBUG, INFO, WARNING, ERROR)

INFO

Portability

This directory is 100% portable. To use in another project:

  1. Copy the entire mcp-server/ folder

  2. Update the path in claude_desktop_config.json

  3. Restart Claude Desktop

  4. Ready โœ…

Update FRDs

To modify an FRD:

  1. Edit the file in frd/*.md

  2. It's not necessary to restart the server

  3. The next time Jarvis calls get_frd, it will get the updated version


Author: @jorgegomez
Version: 1.0.0
Date: December 2025

Available Tools

1 tool
get_frdB

Returns the content of an FRD by id. 00 -> FRD-00-master-orchestration.md 01 -> FRD-01-boilerplate-core-products.md ...

ParametersJSON Schema
NameRequiredDescriptionDefault
frd_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns content, implying a read-only operation, but lacks details on permissions, error handling, rate limits, or output format. The mention of specific FRD IDs adds some context but doesn't cover key behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is front-loaded with the core purpose, but the list of FRD ID mappings is verbose and could be condensed. While it provides useful examples, the structure is not optimally efficient, as the mappings might be better placed elsewhere or summarized.

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

Completeness3/5

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

Given the tool's simplicity (1 parameter, output schema exists), the description is somewhat complete but has gaps. It explains the purpose and parameter semantics but lacks behavioral details. The output schema handles return values, so the description doesn't need to cover that, but it should address usage and transparency more thoroughly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 1 parameter with 0% description coverage, but the description compensates by listing examples of FRD IDs (e.g., '00 -> FRD-00-master-orchestration.md'), which clarifies the semantics beyond the enum values. Since there is only one parameter, the baseline is 4, and the examples add meaningful context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Returns the content of an FRD by id.' This is a specific verb ('Returns') and resource ('content of an FRD'), making the function unambiguous. However, it doesn't distinguish from siblings since there are none, so it cannot achieve a perfect 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It mentions specific FRD IDs (e.g., '00 -> FRD-00-master-orchestration.md'), but this is more of an example than usage guidance. There are no explicit instructions on prerequisites, context, or exclusions.

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

TDQS

B3.1/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'get_frd' has a clear and distinct purpose of retrieving FRD content by ID.

Naming Consistency5/5

The naming is trivially consistent as there is only one tool. The tool name 'get_frd' follows a clear verb_noun pattern (get + FRD), which would be appropriate if more tools were added.

Tool Count2/5

A single tool is too few for a server named 'FRD Orchestrator', which implies orchestration capabilities beyond simple retrieval. The scope suggests operations like create, update, delete, or manage FRDs, but only a read operation is provided.

Completeness2/5

The tool surface is severely incomplete for an orchestrator. It only supports retrieving FRDs by ID, lacking essential operations such as creating, updating, deleting, listing, or searching FRDs. This will cause significant agent failures in orchestration tasks.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server built with NestJS that provides OAuth 2.1 authentication with GitHub and exposes MCP tools through Server-Sent Events transport. Enables secure, real-time communication with JWT-based protection and dependency injection.
  • A
    license
    Not graded
    quality
    D
    maintenance
    An AI-native specification framework that enables deep requirements analysis and structured project planning through intelligent Q\&A workflows. The MCP server provides tools for project initialization, requirement analysis, and the generation of living documentation like development plans and architecture specs.
    16
    Apache 2.0
  • F
    license
    Not graded
    quality
    D
    maintenance
    Multi-stack scaffolding engine for generating production-ready module structures (NestJS, Java Spring, Python FastAPI) directly from an MCP-compatible AI client, reducing token usage for boilerplate code.

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jorge6242/boilerplate-nestjs-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server