Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Design-Pattern-MCP I need the Strategy pattern template for TypeScript."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that provides design pattern structural constraints and anti-patterns to AI coding agents. Agents call this server during code generation to ensure they implement patterns correctly.
This server is not for human use. It is called by AI coding agents (Claude Code, Cursor, Copilot, etc.).
suggest_patternMap a problem description to pattern name(s).
Input: { description: string, category?: "creational"|"structural"|"behavioral"|"modern"|"architectural" }
Output: Up to 3 PatternSuggestion[] — { name, category, rationale, confidence }
Token cost: ~50–100 tokens
get_templateGet structural constraints and anti-patterns for a specific pattern in a specific language.
Input: { pattern: string, language: "go"|"java"|"python"|"rust"|"typescript"|"generic" }
Output: Compact plain text with COMPONENTS, CONSTRAINTS, ANTI-PATTERNS, language-specific notes, example structure
Token cost: ~300–500 tokens
Related MCP server: AI Code Toolkit
git clone git@github.com:sirius-zuo/design-pattern-mcp.git
cd design-pattern-mcp
npm install
npm run buildAdd to ~/.claude/settings.json:
{
"mcpServers": {
"design-pattern-templates": {
"command": "node",
"args": ["/absolute/path/to/design-pattern-mcp/dist/index.js"]
}
}
}Add to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):
{
"mcpServers": {
"design-pattern-templates": {
"command": "node",
"args": ["/absolute/path/to/design-pattern-mcp/dist/index.js"]
}
}
}Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"design-pattern-templates": {
"command": "node",
"args": ["/absolute/path/to/design-pattern-mcp/dist/index.js"]
}
}
}Add to .vscode/mcp.json (project) or user settings:
{
"servers": {
"design-pattern-templates": {
"type": "stdio",
"command": "node",
"args": ["/absolute/path/to/design-pattern-mcp/dist/index.js"]
}
}
}Once registered, you can ask Claude to use the tools directly in conversation. The typical workflow is: suggest a pattern first, then fetch the full template for the one you want to implement.
You ask Claude:
I need to support multiple payment methods like credit card, PayPal, and crypto that can be swapped at runtime. What pattern should I use?
Claude calls suggest_pattern and returns:
[
{
"name": "Strategy",
"category": "behavioral",
"rationale": "multiple interchangeable algorithms",
"confidence": 0.67
},
{
"name": "Decorator",
"category": "structural",
"rationale": "add responsibilities dynamically without subclassing",
"confidence": 0.50
},
{
"name": "Saga",
"category": "modern",
"rationale": "long-running distributed transaction",
"confidence": 0.33
}
]Strategy is the strongest match. You then ask for the full template.
You ask Claude:
Give me the Strategy pattern template for TypeScript.
Claude calls get_template with { pattern: "strategy", language: "typescript" } and returns:
Pattern: Strategy
Language: typescript
COMPONENTS:
- **Context**: Holds a reference to a Strategy. Delegates algorithm execution to it. Contains NO algorithm logic itself.
CONSTRAINTS:
- Context must NOT contain algorithm logic; all logic lives in ConcreteStrategy.
ANTI-PATTERNS:
- Embedding the if/else or switch selection logic inside Context (defeats the purpose).
TYPESCRIPT-SPECIFIC NOTES:
- Define single-method stateless strategies as function types: `type SortStrategy = (data: number[]) => number[]` — no interface or class needed.
- Multi-method or stateful strategies: use an `interface` with structural typing — no `implements` declaration required.
- Inject via constructor (`constructor(private strategy: SortStrategy)`) for immutability; use a setter only when runtime switching is required.
- `Context` holds a field typed to the function type or interface; calling it is `this.strategy(params)` or `this.strategy.execute(params)`.
EXAMPLE STRUCTURE:
```typescript
type Sorter = (data: number[]) => number[];
class SortContext {
constructor(private strategy: Sorter) {}
setStrategy(s: Sorter): void { this.strategy = s; }
run(data: number[]): number[] { return this.strategy(data); }
}
// Usage — any function with the right signature is a valid strategy
const ctx = new SortContext(data => [...data].sort((a, b) => a - b));
ctx.run([3, 1, 2]); // [1, 2, 3]
// Interface-based for stateful strategies
interface PricingStrategy { calculate(basePrice: number): number; }
class DiscountStrategy implements PricingStrategy {
constructor(private pct: number) {}
calculate(base: number): number { return base * (1 - this.pct); }
}Claude then uses this output as grounding constraints when writing your actual payment service code — ensuring the context doesn't embed algorithm logic, strategies are injected via constructor, and the TypeScript-idiomatic function-type approach is used.
38 patterns across 5 categories:
Creational (5): Abstract Factory, Builder, Factory Method, Prototype, Singleton
Structural (7): Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
Behavioral (11): Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor
Modern (8): Circuit Breaker, CQRS, Dependency Injection, Event Sourcing, Pub/Sub, Repository, Retry with Backoff, Saga
Architectural (7): Clean Architecture, Event-Driven Architecture, Hexagonal Architecture, Layered Architecture, Microservices, MVC/MVP/MVVM, Pipe and Filter
npm test # run tests
npm run build # compile TypeScript to dist/
npm start # run the MCP serverGet structural constraints and anti-patterns for a specific design pattern in a specific language. Returns compact plain text (~300-500 tokens) optimized for LLM consumption. Call this when you know which pattern to implement.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | Pattern name (e.g. "Strategy", "Observer", "Circuit Breaker") | |
| language | Yes | Target language: "go", "java", "python", "rust", or "generic" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns compact plain text (~300-500 tokens) optimized for LLM consumption, which goes beyond the basic action. Since no annotations are provided, this adds useful context about output format and size. It does not explicitly state side effects, but the verb 'Get' implies a read-only operation, and no contradicting information exists. A small deduction for not explicitly noting that the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first sentence stating the core purpose and the second providing usage guidance. Every word earns its place; there is no fluff or repetition of schema information. It is efficiently structured and immediately readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema coverage, the description provides sufficient context: it tells the agent what the tool does, when to call it, and what the output format looks like. No output schema exists, but the description's mention of plain text token size gives the agent enough to know what to expect. The sibling tool relationship is also addressed via usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters (`pattern` and `language`) with examples and allowed values. The description does not add meaning beyond what the schema gives, such as parameter constraints or relationships. The baseline of 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: retrieving structural constraints and anti-patterns for a specific design pattern in a specific language. The verb 'Get' and the resource ('structural constraints and anti-patterns') are specific and distinguish this from the sibling `suggest_pattern`, which likely suggests patterns rather than retrieving details for a known one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this when you know which pattern to implement,' which directly tells the agent when to use this tool. It implicitly contrasts with the sibling `suggest_pattern`, implying that if the pattern is unknown, the other tool should be used first. This provides clear usage guidance and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map a problem description to design pattern name(s). Returns up to 3 ranked suggestions with confidence scores. Call this when you know the problem but not which pattern to apply.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional: narrow search to one pattern category | |
| description | Yes | Describe the problem (e.g. "multiple interchangeable algorithms selected at runtime") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses the response format (up to 3 ranked suggestions with confidence scores), which covers the core behavior. It does not address failure modes, but for a simple suggestion tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no redundancy. It front-loads the core purpose and includes usage context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential context: input, output, and when to use. Since there is no output schema, it provides necessary return information (ranked suggestions with confidence). Minor gaps like no-suggestion behavior are not critical for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of both parameters with clear descriptions. The tool description adds no additional parameter-level semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Map') and clearly identifies the input (problem description) and output (design pattern name(s)), including result limit and confidence scores. It does not explicitly differentiate from the sibling tool get_template, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call this tool ('when you know the problem but not which pattern to apply'), giving clear context. However, it does not mention alternatives or when not to use it, so it doesn't fully earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_templatesuggest_patternScored across 2 tools
The two tools have completely distinct purposes: one maps a problem to pattern names, the other retrieves implementation details for a known pattern. No overlap or ambiguity exists.
Both tool names follow the verb_noun convention (suggest_pattern, get_template), creating a predictable pattern.
With only 2 tools, the server feels minimal. However, the narrow scope (pattern suggestion and template retrieval) justifies the small count, though it borders on too few.
The core workflow is covered: identify a pattern, then retrieve its template. Missing a list_patterns or comparison tool, but these are not essential for the primary purpose.
Read-only Pattern-Assist corpus for aspiring software engineers: grounded dev patterns with sources.
Design intelligence for coding agents: audits, design systems, and a taste profile agents consult.
Live React design-system APIs, patterns, and code validation so AI agents build real UI, not slop.
Curated knowledge API for AI agents - skill packs, semantic search, validated patterns.
