Pattern Intelligence MCP is a deterministic local architectural decision engine that diagnoses forces, scores patterns, generates TypeScript scaffolds, and enforces architectural fitness via CI/CD rules.
Diagnose open-ended design cases (analyze_design_case) with force scoring, rejected patterns, baselines, and compound topologies.
Compare 2–6 named patterns (compare_pattern_options) against a case, reporting non-winners and tipping points.
Detect pattern misuse/cargo-cult (detect_pattern_misuse) with rejection matrices and simpler alternatives.
Stress-test decisions (stress_test_pattern_decision) by patching scenarios to find flip conditions.
Plan reversible adoption (plan_pattern_adoption) with baseline-first steps, exit criteria, and rollback triggers.
Generate Architecture Decision Records (write_pattern_adr) with uncertainty, validation metrics, and reversal triggers.
Create evidence plans (get_pattern_evidence_plan) with hypotheses, measurements, experiments, and deletion criteria.
Traverse the 116-pattern knowledge graph (query_pattern_graph) by layer, cost, and seed, using typed relations.
Prescribe architecture (in README) producing domain ports, adapters, scaffolds, and ESLint/Vitest fitness rules.
Analyze AST code quality (in README) for cyclomatic complexity, LCOM4, coupling, instability, and dual-write hazards.
Generate CI governance (in README) with ESLint boundary constraints and automated test suites.
Click on "Install 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., "@Pattern Intelligence MCP Analyze a design case where retries cause duplicate charges in payments."
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.
Deterministic architectural decision engine, TypeScript refactoring synthesizer, and automated fitness governance for AI coding agents.
Most pattern tools are searchable glossaries or static prompts. Pattern Intelligence MCP is a full-fledged local architectural intelligence platform: it diagnoses system forces, penalizes unjustified complexity, recommends direct baselines when appropriate, synthesizes complete production TypeScript scaffolds, and generates automated CI/CD architectural fitness rules.
It is implemented in strict TypeScript with 100% deterministic local execution (zero model API, vector database, or external network dependencies) and speaks the Model Context Protocol through the official SDK.
Prompt-heavy frameworks inject tens of thousands of tokens into context on every turn, causing severe attention dilution and bloating token costs. Pattern Intelligence MCP keeps 116 design patterns, AST analyzers, and force ontologies outside the context window, delivering exact blueprints and TypeScript scaffolds on demand.
Where standard LLMs or prompt skills offer conversational opinions, Pattern Intelligence MCP generates:
Executable TypeScript Scaffolds: Ready-to-use domain ports, infrastructure adapters, outbox tables, and saga coordinators.
Deterministic AST Smell & Complexity Analysis: Exact Cyclomatic Complexity, Cohesion (LCOM4), Module Instability ($I = \frac{C_e}{C_a + C_e}$), Dual-Write hazard detection, and missing timeout detection.
Anti-Cargo-Cult Rejection Matrices: Quantified tipping points (e.g. > 5,000 writes/sec, > 15 engineers) that mathematically justify when complex patterns are warranted versus when to keep direct baselines.
Automated CI Architecture Fitness Rules: Auto-generated ESLint boundary constraints (@typescript-eslint/no-restricted-imports) and automated TS-Arch/Vitest test suites to enforce architectural boundaries in CI.
Related MCP server: Design-Pattern-MCP
┌─────────────────────────────────────────────────────────────────────────┐
│ Pattern Intelligence MCP Engine │
├─────────────────────────┬──────────────────────────┬────────────────────┤
│ Decision & Strategy │ Scaffolding & Smells │ Governance & Graph │
├─────────────────────────┼──────────────────────────┼────────────────────┤
│ • Force Scoring Engine │ • AST Code Analyzer │ • Fitness Rules │
│ • Rejection Matrices │ • LCOM4 & Complexity │ • ESLint Enforcer │
│ • Quantitative Triggers │ • Dual-Write Detector │ • Typed Edge Graph │
│ • Compound Topologies │ • TypeScript Scaffolds │ • ADR Generator │
└─────────────────────────┴──────────────────────────┴────────────────────┘Solves real-world distributed challenges by intelligently assembling multi-pattern topologies:
Dual-Write Consistency: Transactional Outbox + Idempotent Receiver + Change Data Capture (CDC Relay).
Dependency Resilience: Circuit Breaker + Bulkhead + Bounded Timeout + Retry with Jitter + Fallback Router.
Third-Party Isolation: Ports & Adapters (Hexagonal) + Anti-Corruption Layer (ACL) + Strategy Dispatch.
Distributed Workflows: Saga Orchestrator + Compensating Transaction Handler + Outbox Step Dispatcher.
Safe Monolith Migration: Strangler Fig + Branch by Abstraction + Dark Launching Shadow Taps + Canary Fallback.
Parses source code into local AST structures to compute:
Cyclomatic & Cognitive Complexity: Branch, loop, and conditional operator counting.
Cohesion of Methods (LCOM4): Method-variable connectivity graphs to pinpoint God Classes.
Package Coupling & Instability: Afferent ($C_a$) and Efferent ($C_e$) coupling metrics.
Dual-Write AST Scanner: Spots database updates followed by network/broker calls within uncommitted scopes.
generate_architecture_fitness_rules)Automates architectural governance by exporting:
ESLint boundary configurations preventing core domain modules from importing infrastructure, ORMs, or vendor SDKs.
Automated Vitest fitness test suites that fail CI builds if unauthorized cross-layer dependencies are introduced.
Tool | Purpose | Distinguishing Output |
| Unified one-shot blueprint | Domain ports, infrastructure adapters, rollout seams, and rollback triggers. |
| AST smell refactoring | AST metrics, before/after complexity delta, and refactored TypeScript code. |
| CI/CD architectural governance | ESLint layer boundary configs, Vitest TS-Arch suites, and CI bash commands. |
| Static code metrics | Cyclomatic Complexity, LCOM4 cohesion score, Afferent/Efferent coupling, and Instability. |
| Scaffolding generation | Full multi-file TypeScript implementations with contract verification test suites. |
| Open-ended force diagnosis | Transparent multi-term scores, rejected patterns, direct baselines, and compounds. |
| 2-to-6 option evaluation | Trade-off comparison matrix, non-winner declarations, and force tipping points. |
| Anti-cargo-cult detection | Rejection matrix, premature complexity warnings, and quantitative tipping points. |
| Sensitivity analysis | Decision flip conditions under shifting scale, throughput, or team capacity. |
| Reversible execution plan | Step-by-step Strangler phases, characterization test nets, and rollback triggers. |
| Durable decision records | Standard Architecture Decision Record with explicit uncertainty boundaries. |
| Falsification planning | Testable hypotheses, measurement metrics, experiment designs, and exit criteria. |
| Knowledge exploration | Typed graph neighbor traversal ( |
Resources expose the catalog (pattern://catalog), ontology (pattern://ontology), individual pattern records (pattern://pattern/{patternId}), and layers (pattern://layer/{layer}).
Track / Layer | Count | Examples |
TypeScript-Native | 8 | Discriminated Union, Result Type, Composition Root, Brand Types |
GoF Creational | 5 | Factory Method, Builder, Singleton, Abstract Factory |
GoF Structural | 7 | Adapter, Bridge, Composite, Decorator, Facade, Proxy |
GoF Behavioral | 11 | Command, State, Strategy, Visitor, Observer, Pipeline |
Enterprise & Domain | 17 | Domain Model, Aggregate, CQRS, Event Sourcing, Repository |
Messaging & Integration | 18 | Router, Aggregator, Idempotent Receiver, Transactional Outbox, CDC |
Distributed & Resilience | 18 | Timeout, Circuit Breaker, Bulkhead, Saga, Sharding, Cells |
Concurrency & Async | 8 | Mutex, Actor, Optimistic Concurrency Control (OCC), Reactor |
Testing | 8 | Characterization Test, Contract Test, Property-Based, Mutation |
Architecture | 10 | Ports & Adapters (Hexagonal), Modular Monolith, Event-Driven |
Cloud-Native & AI Agent | 6 | Model Router, Tool Circuit Breaker, Semantic Cache, Singleflight, Cache Stampede Lock, Token Bucket |
Each record contains the problem statement, system context, mechanism, simpler direct alternative, misuse risks, evidence plan, TypeScript-specific concerns, adoption costs, and typed graph relations.
Requirements: Node.js 22 or newer.
npx (Recommended)Add directly to your MCP client configuration (e.g. Claude Desktop, Cursor, Pi, Codex):
{
"mcpServers": {
"pattern-intelligence": {
"command": "npx",
"args": ["-y", "pattern-intelligence-mcp"]
}
}
}npm install -g pattern-intelligence-mcp{
"mcpServers": {
"pattern-intelligence": {
"command": "pattern-intelligence-mcp"
}
}
}git clone https://github.com/mateusdcc/pattern-intelligence-mcp.git
cd pattern-intelligence-mcp
npm install
npm run check
npm run build{
"mcpServers": {
"pattern-intelligence": {
"command": "node",
"args": ["/absolute/path/to/pattern-intelligence-mcp/dist/cli.js"]
}
}
}Evaluated against maintainability scenarios adapted from Uncle Bob Clean Architecture principles and ryanmcdermott/clean-code-javascript (85,000+ GitHub Stars):
80% Token Reduction: Slashing total token usage from ~300k tokens down to ~61k tokens per scenario by keeping the 116-pattern knowledge graph and AST smell detectors outside the system prompt and querying only when needed.
Anti-Cargo-Cult Resistance: Scored 96.5/100 on resisting premature distributed over-engineering (e.g. rejecting Sagas/CQRS when a single local database transaction suffices).
Architectural Decision Soundness: Consistently enforces Single Responsibility (aiming for sub-10 line cohesive functions), Open/Closed polymorphic dispatch, and domain boundary insulation.
100% Deterministic & Local: Sub-millisecond execution with zero reliance on external LLM APIs or vector databases.
{
"case": {
"problem": "Three third-party carrier APIs (FedEx, UPS, DHL) expose incompatible models and leak vendor SDK types across 19 domain files.",
"failureModes": ["vendor downtime", "breaking SDK updates"],
"goals": ["insulate domain model", "support dynamic carrier selection"],
"evidence": ["vendor models imported across 19 core domain files"]
}
}prescribe_architectureVerdict: ADOPT-PATTERN (Ports and Adapters + Anti-Corruption Layer + Strategy).
Rejection Matrix: Disqualifies Microservices and CQRS as premature for in-process boundary insulation.
Generated TypeScript Code:
Domain Port contract (CarrierPort).
Anti-Corruption Layer vendor mapper functions.
Infrastructure adapter (FedExAdapter) with AbortSignal timeout handling.
Dynamic carrier strategy registry (CarrierRegistry).
Automated CI Fitness Rule: ESLint configuration disallowing @typescript-eslint/no-restricted-imports from importing vendor SDKs inside src/domain/.
Reversible Adoption Seams: File-by-file Strangler Fig migration steps and quantified rollback triggers.
npm run typecheck # Strict TypeScript verification
npm run lint # Biome check & linting
npm test # Vitest test suite (100 unit tests)
npm run test:coverage # Full coverage report (>95% coverage)
npm run build # Compile to dist/Deterministic Local Execution: Zero dependencies on external AI APIs or vector databases. All reasoning is local, deterministic, and auditable.
No-Pattern Baseline: Adding abstraction layers must mathematically beat a simpler direct solution.
Single Responsibility & Brevity: Strict Uncle Bob Clean Code standards with concise, cohesive functions and clear bounded contexts.
Falsifiable & Reversible: Every architectural prescription includes testable metrics, exit criteria, and zero-friction rollback triggers.
MIT License. See LICENSE for details.
Diagnose forces before prescribing a pattern. Returns questions, transparent scores, rejected patterns, a non-pattern baseline, evidence plans, and a bounded pattern compound. Use this first for an open-ended design problem.
| Name | Required | Description | Default |
|---|---|---|---|
| case | Yes | ||
| maxRecommendations | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral substance beyond the annotations: it specifies the tool returns rejected patterns, a non-pattern baseline, evidence plans, and a bounded pattern compound, and that it diagnoses before prescribing. Since annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, these output details add meaningful context about what the agent can expect.
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 three sentences, front-loaded with the core purpose, followed by the return-value list, and ends with the usage instruction. No word is wasted; every sentence contributes a distinct piece of the operational picture.
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 tool with a complex nested input schema and no output schema, the description gives the high-level output components and use case, but does not help the agent construct a well-formed 'case' object (e.g., what to put in 'team', 'scales', 'delivery'). The tool is fundamentally clear, but the missing parameter guidance leaves an agent with significant inference burden.
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?
Schema description coverage is 0% for top-level parameters, so the description needed to compensate. Instead, it does not mention 'case', 'maxRecommendations', or any guidance on how to structure the input object beyond implying the user provides a design problem. The nested schema is rich but the agent gets no help from the description on what to populate.
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 states a specific verb ('Diagnose forces') and clearly indicates the tool analyzes a design case to produce a pattern recommendation bundle. It lists concrete outputs ('questions, transparent scores, rejected patterns...'), which makes the tool's function identifiable. However, it does not explicitly distinguish itself from sibling tools beyond 'Use this first', so it stops short of a 5.
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?
'Use this first for an open-ended design problem' explicitly tells the agent when to invoke this tool and gives it an ordering relative to the pipeline. It does not, however, mention when not to use it or name any specific sibling alternative, so it lacks the full when/when-not/alternatives coverage that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two to six named patterns against one concrete case. Returns no winner when evidence is insufficient and states the force that would make each option preferable.
| Name | Required | Description | Default |
|---|---|---|---|
| case | Yes | ||
| patterns | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly=true, idempotent=true, non-destructive), so the description adds genuinely useful behavior beyond them: it discloses that the tool may deliberately return no winner when evidence is insufficient, and that its output states the forces that would make each option preferable. This is substantive behavioral context, not a restatement of annotations. No contradiction with annotations.
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 sentences with zero waste. The core action is front-loaded, and the second sentence adds the critical behavioral nuance about insufficient evidence and force-based output. Every clause 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 tool is moderately complex (large nested case schema, no output schema), and the description covers the essential outcome behavior: when no winner is returned and what the output expresses (preferring forces). However, it does not describe the output structure of a comparison result or how the many case fields are weighted, which leaves an agent guessing about the return format and the comparison criteria.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaning by clarifying 'patterns' are named patterns limited to 2-6 (matching schema minItems/maxItems) and that 'case' is exactly one concrete case. However, the case object is large and heavily nested with 16+ subfields, and the description provides no guidance on which fields matter or how they feed the comparison. The schema's self-descriptive property names and enums carry most of the weight.
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?
States a specific verb and resource: 'Compare two to six named patterns against one concrete case.' The scope is precise and the action is clearly differentiated from sibling tools like detect_pattern_misuse (detection) and stress_test_pattern_decision (stress-testing a single decision). No ambiguity about what this tool does.
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?
Establishes a clear usage context: comparing a bounded set of patterns against a single concrete case. The 'two to six' constraint and 'one concrete case' framing distinguish it from sibling tools implicitly, though it does not explicitly name alternatives or state when NOT to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit patterns already used or proposed for cargo-cult risk, missing forces, hidden costs, and simpler alternatives. Use during design or code review, not as a generic pattern search.
| Name | Required | Description | Default |
|---|---|---|---|
| case | Yes | ||
| patternsInUse | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior; the description adds that the audit covers existing and proposed patterns and surfaces hidden costs and simpler alternatives. No contradiction with annotations.
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 sentences, both earning their place: the first defines the audit scope and criteria, the second gives usage timing and an exclusion. Information is front-loaded with the action verb.
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 tool has a rich nested `case` schema and no output schema, yet the description does not explain what `case` should contain or what kind of report to expect. The rich property names partially compensate, making this a minimum-viable level rather than a complete definition.
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?
With 0% top-level schema coverage, the description carries the burden of explaining parameters. It only maps to patternsInUse via 'patterns already used or proposed' and says nothing about the required `case` object or its role as the design context. This leaves a significant gap.
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 opens with a specific verb 'Audit' and a target ('patterns already used or proposed'), then lists the concrete evaluation dimensions: cargo-cult risk, missing forces, hidden costs, and simpler alternatives. It explicitly distances itself from a generic pattern search, which separates it from siblings like query_pattern_graph.
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?
'Use during design or code review, not as a generic pattern search' gives explicit when-to-use and when-not-to-use guidance. It does not name specific sibling alternatives, so it falls just short of the full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the hypothesis, measurements, experiment, rejection criteria, and deletion triggers for one pattern in one case. Use when a recommendation needs proof before implementation.
| Name | Required | Description | Default |
|---|---|---|---|
| case | Yes | ||
| pattern | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds value by specifying the exact evidence-plan payload returned — hypothesis, measurements, experiment, rejection criteria, and deletion triggers — which is especially useful since there is no output schema. It does not discuss behavior for missing patterns or invalid cases, but the safety profile is well covered by annotations.
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 short sentences with no filler. It front-loads the concrete returned fields and ends with a practical use trigger. Every sentence 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 usefully lists the returned evidence-plan elements, partially compensating for the missing output schema. However, given the highly nested case parameter and zero parameter semantics in the description, an agent may struggle to construct a valid request or understand invalid-input behavior.
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?
Schema description coverage is 0%, so the description must compensate, but it only says 'one pattern in one case.' It gives almost no guidance on how to populate the large nested case object or what values the pattern string should take. The rich schema structure for case is not reflected in the description.
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 opens with a specific verb and resource: 'Return the hypothesis, measurements, experiment, rejection criteria, and deletion triggers for one pattern in one case.' This clearly scopes the tool to a single pattern and case, which distinguishes it from broader sibling tools like query_pattern_graph and plan_pattern_adoption.
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 second sentence gives an explicit use condition: 'Use when a recommendation needs proof before implementation.' However, it does not name alternative tools or state when not to use this tool, so exclusion guidance is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a reversible, evidence-gated adoption plan for one named pattern. The plan starts with a baseline and smallest production slice and includes exit criteria and rollback.
| Name | Required | Description | Default |
|---|---|---|---|
| case | Yes | ||
| pattern | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond annotations: the plan is evidence-gated, starts with a baseline and smallest production slice, and includes exit criteria and rollback. 'Create' refers to generating a plan artifact, not a side-effecting mutation, so there is no contradiction.
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 front-loaded sentences with no filler. The first sentence states the action and constraints, and the second concisely lists the deliverable's required components.
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 tells the caller what the plan will contain and conveys the evidence-gating requirement, which is useful given there is no output schema. However, it does not describe the output format, explain how to populate `case`, or address potential edge cases for a complex nested input. This leaves important gaps for an agent.
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?
Schema description coverage is 0%, so the description must compensate. It only elaborates the `pattern` parameter with 'one named pattern' and leaves the complex `case` object unaddressed. Given that `case` has many nested fields and no descriptions, the description provides minimal help for parameter semantics.
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 names a specific verb ('Create'), a concrete resource ('reversible, evidence-gated adoption plan'), and a scope ('one named pattern'). It also enumerates plan components, which distinguishes it from siblings like compare_pattern_options or write_pattern_adr.
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 clearly implies the tool is for planning adoption of a single, already-selected pattern, with evidence-gating and reversibility as requirements. However, it never explicitly says when to use it versus alternatives, and it does not mention any sibling tools or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Traverse contextual candidates and explicit pattern relationships with layer and cost filters. Use for bounded discovery around a problem or seed—not to dump the entire catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| limit | No | ||
| layers | No | ||
| seedPatterns | No | ||
| maxAdoptionCost | No | high |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the behavioral nuance of traversing contextual candidates and applying filters, plus the bounded nature of results. It does not describe output shape or pagination, but it does not contradict the annotations.
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 with no filler. The first sentence states the core functionality and filters, and the second gives clear usage guidance. Every sentence 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?
Without an output schema, the description should at least sketch what the tool returns, but it only describes the traversal behavior. The optional parameters and their relationships are left ambiguous, so an agent may not know whether to provide text, seedPatterns, or just rely on defaults. Annotations provide safety context but not enough for a complete call.
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?
Schema description coverage is 0%, so the description needs to compensate. It only references 'layer and cost filters', which maps to `layers` and `maxAdoptionCost`, and hints at `seedPatterns` via the phrase 'around a problem or seed'. The `text`, `limit`, and exact role of `seedPatterns` remain unexplained, leaving a significant gap for a tool with five parameters.
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 identifies a specific action ('traverse contextual candidates and explicit pattern relationships') and scopes it with layer and cost filters. It also clarifies the intended use case ('bounded discovery around a problem or seed'), which distinguishes it from a broad catalog dump. It does not explicitly name sibling tools, but its purpose is still clear.
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 gives a clear 'when to use' directive: bounded discovery around a problem or seed. It also provides a 'when not to use' warning: not to dump the entire catalog. However, it does not name any sibling alternatives or explain how this tool differs from them, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply explicit counterfactual scenarios—scale, delivery, consistency, team, evidence, or goals—and report when the leading decision flips. Use before committing to expensive architecture.
| Name | Required | Description | Default |
|---|---|---|---|
| case | Yes | ||
| scenarios | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by listing the scenario dimensions and the outcome ('report when the leading decision flips'), but it does not describe the report format or any implicit constraints. This is adequate but not enriched beyond annotations.
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 sentences, no filler, with the core action front-loaded and the usage tip in a separate concise sentence. Every word adds value.
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 tool is complex with nested objects, an array of patches, and no output schema. The description gives strategic context but omits operational details: what a 'flip' looks like, how to structure a scenario patch, and what the response contains. The schema provides structural guidance, but the absence of output/return behavior is a noticeable gap for a tool of this complexity.
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?
Schema description coverage is 0%, so the description must compensate. It does partially by naming the counterfactual dimensions (scale, delivery, consistency, team, evidence, goals), which maps to fields in the case object. However, it never explicitly explains the 'case' parameter or how to construct valid scenario patches, leaving significant semantic burden on the schema structure.
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 ('Apply') and resource ('pattern decision'), and clearly distinguishes the tool's function: applying counterfactual scenarios to see when the leading decision flips. This is a unique activity not covered by siblings like analyze_design_case or compare_pattern_options.
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 states when to use the tool ('Use before committing to expensive architecture'), providing clear temporal context. It does not mention alternatives or when not to use it, but the timing guidance is actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a proposed architecture decision record from a case. It records considered options, uncertainty, validation metrics, open questions, and reversal triggers rather than pretending the decision is final.
| Name | Required | Description | Default |
|---|---|---|---|
| case | Yes | ||
| title | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful context by clarifying the output is a proposed, non-final ADR and by listing the kind of content it records, which shapes agent expectations beyond the annotations.
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?
A single front-loaded sentence with no filler; every clause contributes either the action, the input source, or the output character.
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 main purpose and output contents are covered, and no output schema exists to document the return shape. However, the description does not clarify the ADR's format/representation or how the large nested `case` object maps into the generated record, leaving some practical gaps for a complex input schema.
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?
Schema description coverage is 0%, and the description only indirectly refers to `case` with 'from a case'; `title` receives no semantic explanation. The description does not compensate for the absence of schema descriptions on the two required parameters.
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 ('Generate') and resource ('architecture decision record'), and states what the output captures: considered options, uncertainty, validation metrics, open questions, and reversal triggers. It is clear, but it does not explicitly name or differentiate against sibling tools like analyze_design_case or plan_pattern_adoption.
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?
Use is implied: call this when a proposed ADR should be produced from a case. There is no explicit when/when-not guidance or mention of alternatives, so an agent must infer how this differs from the sibling planning/analysis tools.
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. Dates show when Glama detected each change.
v0.1.0analyze_design_casecompare_pattern_optionsdetect_pattern_misuseget_pattern_evidence_planplan_pattern_adoptionquery_pattern_graphstress_test_pattern_decisionwrite_pattern_adrEach tool addresses a distinct phase in the pattern workflow: open-ended analysis, option comparison, misuse auditing, stress testing, adoption planning, ADR writing, evidence planning, and graph discovery. The descriptions make the trigger conditions explicit enough that an agent should rarely confuse one operation with another.
All tools follow a clear snake_case verb-noun pattern, with the pattern theme appearing consistently across objects. The verbs are distinct and readable: analyze, compare, detect, stress_test, plan, write, get, and query.
Eight tools is well within the ideal range for a specialized pattern-intelligence server. Each tool covers a necessary step in the decision lifecycle without redundant operations or bloat.
The set covers the full pattern decision lifecycle from open-ended analysis through comparison, evidence, adoption, and ADR output, plus review-time misuse detection. A minor gap is the absence of a dedicated catalog/detail lookup tool, though query_pattern_graph mitigates this with bounded discovery.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Evidence-backed architecture-quality analysis for Python agent applications.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
AI Agent with Architectural Memory. Impact analysis (free), tests and code from the graph (pro).
Research intelligence for AI coding agents. 2M+ CS papers with evidence and tradeoffs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mateusdcc/pattern-intelligence-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
