design-pattern-mcp

Overview Schema Source Related Servers Discussions Admin

Analyze Design

analyze_design

Analyze a system description and return design pattern selections per decision part, with ranked alternatives and veto notes, without generating code. Use it to route choices before implementing.

Instructions

Analyze a system description and select design patterns per decision part — the analysis-only path for coding agents that write the code themselves. Returns the repaired design brief, the decision parts with their scope/category hypothesis, and one selection per part (primary pattern, supporting patterns with roles, ranked alternatives, veto ledger, quality-attribute weights that drove the scoring) without generating applications or evaluating them. The selection is a routing decision, not an implementation spec: it carries no participants, implementation steps, code sketches or language bindings — before implementing, call generate_design with this payload to materialize the bound applications without re-running the analysis, or get_design_pattern for each selected pattern when only the catalog record and language bindings are needed. A true is_fallback (payload level, or per part with fallback_reason) marks a selection with no eligible primary — treat it as fallback guidance, not a real match. Use select_design_patterns when the caller wants the generated design.

Input Schema

Name	Required	Description
`focus`	No	Optional free text narrowing the decision or naming a realization, e.g. 'use the coroutine-based acceptor variant'.
`language`	No	Optional target language: generic, c, cplusplus, csharp, go, java, javascript, kotlin, python, ruby, rust, scala, swift, typescript. The selections are bound to that language; absent, empty or unrecognized values run in generic mode.
`paradigm`	No	Optional paradigm narrowing the realization variant: oo, functional, concurrent, data-oriented, declarative, procedural. Unknown values are ignored.
`description`	Yes	Free-text description of the system to design: component names with their responsibilities, cross-component flows, and the constraints the design must satisfy (40-100000 characters). Architecture-level choices alone are not enough — name the components to implement.
`architecture_style`	No	Optional architecture style from the architecture server's style enum (e.g. 'event-driven', 'hexagonal', 'microservices'). Unknown values are ignored; a known value takes precedence over any style extracted from the description and adds a soft category prior.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.1Oct 27, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Description discloses the return payload (repaired brief, decision parts, selection, veto ledger, weights) and what it does NOT produce (no apps, no evaluation, no participants/steps/bindings), plus is_fallback semantics — meaningful context beyond annotations. One gap: readOnlyHint=false is not explained despite the description framing this as pure analysis, leaving the non-readonly flag unexplained.

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

Conciseness4/5

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

Front-loaded with purpose and the routing distinction, then alternatives. Dense but nearly every sentence carries decision-relevant content; the pattern-enumeration in the returns sentence is slightly long but justified.

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

Completeness5/5

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

With an output schema present, the description explains the returned structure and non-returned artifacts, plus fallback handling. Combined with annotations and rich schema, an agent has everything needed to invoke correctly and route downstream.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all five params including enums-by-name and defaults. The description adds no param-level detail beyond noting the payload is reusable for generate_design; baseline 3 applies.

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

Purpose5/5

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

States a specific verb (analyze) and resource (system description → design pattern selection) and explicitly positions itself as the 'analysis-only path for coding agents that write the code themselves.' This immediately distinguishes it from generate_design, select_design_patterns, and get_design_pattern.

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

Usage Guidelines5/5

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

Explicit when-to-use alternatives are named with conditions: 'call generate_design with this payload to materialize the bound applications without re-running the analysis, or get_design_pattern for each selected pattern when only the catalog record and language bindings are needed' and 'Use select_design_patterns when the caller wants the generated design.' Nothing is left to inference.

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

Deploy Server