ハイブリッド検索（セマンティック + キーワード + グラフ拡張）を使用してデザインパターンのレコメンデーションを提供するインテリジェントな MCP（Model Context Protocol）サーバーです。高度なブレンド RAG アーキテクチャを備えた自然言語インターフェースを通じて、90 以上のカテゴリにわたる 710 のデザインパターンにアクセスできます。
# Clone and setup
git clone https://github.com/apolosan/design_patterns_mcp.git
cd design_patterns_mcp
# Install dependencies and build (using bun)
bun install
bun run db:setup
# Or using npm (if bun is not installed)
npm install --ignore-scripts
npx tsc
node dist/cli/migrate.js
node dist/cli/seed.js
node dist/cli/generate-embeddings.js
node dist/cli/setup-relationships.jsMCP クライアント（Claude Desktop、Cursor など）で設定し、自然言語クエリでパターンの発見を始めましょう。
Related MCP server: Acemcp
このリポジトリの標準パッケージマネージャーとして Bun を使用します（bun install のみ）。ロックファイルは bun.lock です。
.git ディレクトリを dist/data にコピーしないでください（dist/ 内に同梱しないでください）。そのパスは、ギガバイト単位のイメージやメタデータの漏えいを防ぐため、プレーンなデータディレクトリのままにしておく必要があります。
機能 | 説明 |
ハイブリッド検索エンジン | セマンティック、キーワード（BM25）、グラフ拡張検索を組み合わせたブレンド RAG |
710 のパターン | 段階的デリバリーと実験のための フィーチャーフラグ / フィーチャートグルを含む 90 以上のカテゴリにわたる包括的なカタログ |
MCP 統合 | Claude、Cursor、その他の MCP クライアントとのシームレスな統合 |
マルチレベルキャッシュ | 95% 以上のヒット率を誇る L1 インメモリ + L3 SQLite キャッシュ |
イベントバスシステム | pub/sub による疎結合なサービス間通信 |
テレメトリとヘルス | リアルタイムのパフォーマンスメトリクスとシステム監視 |
SOLID アーキテクチャ | ベストプラクティスに従ったクリーンで保守性の高いコードベース |
本番稼働対応 | 77 のテストファイルにわたる 654 のテストケース、100% の合格率（失敗 0、スキップ 0） |
カテゴリ | 数 | 例 |
GoF クラシックパターン | 34 | Factory、Builder、Observer、Strategy、Command |
アーキテクチャパターン | 56 | MVC、クリーンアーキテクチャ、ヘキサゴナル、DDD、フィーチャーフラグ |
マイクロサービスとクラウド | 39 | Circuit Breaker、Saga、Service Mesh |
データエンジニアリング | 54 | Repository、CQRS、Event Sourcing |
AI/ML と MLOps | 46 | RAG、Fine-Tuning、Model Compression |
React パターン | 27 | Hooks、Server Components、Performance |
ブロックチェーンと Web3 | 115 | DeFi、NFT、スマートコントラクト、MEV |
並行処理とリアクティブ | 45 | Producer-Consumer、Actor Model |
セキュリティ | 21 | OAuth、RBAC、Zero Trust |
関数型プログラミング | 26 | Monads、Functors、Higher-Order Functions |
src/
├── adapters/ # External service adapters (LLM, embeddings)
├── cli/ # CLI commands (migrate, seed, embeddings, setup-relationships)
├── core/ # DI Container, configuration builder
├── db/ # Database migrations
├── events/ # Event bus system
├── handlers/ # MCP request handlers (hybrid search, recommendations)
├── health/ # Health check services
├── repositories/ # Data access layer
├── search/ # Hybrid search engine
├── services/ # Business services (cache, telemetry, pattern service)
├── strategies/ # Strategy pattern implementations
├── types/ # TypeScript type definitions
└── mcp-server.ts # MCP server entry point
data/
├── patterns/ # 710 JSON pattern definitions (see `feature-flag.json`)
└── design-patterns.db # SQLite database with 710 patterns and embeddingsMCP クライアントを通じて自然言語の質問をします:
"I need to create complex objects with many optional configurations"
→ Builder, Abstract Factory, Factory Method
"How to handle service failures gracefully in distributed systems?"
→ Circuit Breaker, Bulkhead, Retry, Fallback
"What pattern helps with state-dependent behavior in React?"
→ State Machine, Observer, useReducer
"How to implement secure authentication and authorization?"
→ OAuth 2.0, RBAC, JWT, Zero Trustツール | 説明 |
| 問題の説明を使用したパターンのハイブリッド検索 |
| フィルタリング付きのキーワードまたはセマンティック検索 |
| コード例を含む包括的なパターン情報 |
| 利用可能なパターンに関する統計 |
| システムのヘルスとサービスのステータス |
Node.js >= 18.0.0
Bun >= 1.0.0（推奨）または npm >= 8.0.0
bun install
bun run build
bun run db:setuppackage.json の prepare スクリプトには bun が必要です。bun がインストールされていない場合は、--ignore-scripts を使用してスキップし、手動でビルドしてください:
npm install --ignore-scripts
npx tsc
# Setup database
node dist/cli/migrate.js
node dist/cli/seed.js
node dist/cli/generate-embeddings.js
node dist/cli/setup-relationships.jsMCP クライアント設定（Claude Desktop、Cursor など）に追加します:
{
"mcpServers": {
"design-patterns": {
"command": "node",
"args": ["/absolute/path/to/design-patterns-mcp/dist/mcp-server.js"],
"env": {
"LOG_LEVEL": "info",
"DATABASE_PATH": "/absolute/path/to/design-patterns-mcp/data/design-patterns.db",
"ENABLE_HYBRID_SEARCH": "true",
"ENABLE_GRAPH_AUGMENTATION": "true",
"EMBEDDING_COMPRESSION": "true",
"ENABLE_FUZZY_LOGIC": "true",
"ENABLE_TELEMETRY": "true",
"ENABLE_MULTI_LEVEL_CACHE": "true"
}
}
}
}重要:
argsとDATABASE_PATHの両方に絶対パスを使用してください。Cursor などの MCP クライアントはcwdフィールドを確実にサポートしていないため、相対パスはプロジェクトディレクトリではなくユーザーのホームディレクトリに対して解決されます。クライアント固有の設定例については、プロジェクトのクイックスタートを参照してください。
変数 | デフォルト | 説明 |
|
| ログレベル（debug、info、warn、error） |
|
| SQLite データベースのパス |
|
| ブレンド RAG 検索を有効にする |
|
| パターン関係のトラバーサルを有効にする |
|
| 次元削減 |
|
| ファジーロジックによる結果のリファインメント |
|
| パフォーマンスメトリクス |
|
| L1 + L3 キャッシュ |
|
| リクエストの同時実行制限 |
|
| キャッシュサイズの制限 |
|
| キャッシュの TTL（ミリ秒） |
|
| トランスポートモード（stdio/http） |
|
| HTTP ポート（http モード） |
|
| MCP エンドポイントのパス |
|
| ヘルスチェックのパス |
|
| データベースのセットアップをスキップする |
# Build
docker build -t design-patterns-mcp .
# Run HTTP mode
docker run -p 3000:3000 -e TRANSPORT_MODE=http design-patterns-mcp
# Run stdio mode (default)
docker run design-patterns-mcpdocker compose up --build -d変数 | デフォルト | 説明 |
|
| トランスポートモード（stdio/http） |
|
| HTTP ポート（http モード） |
|
| MCP エンドポイントのパス |
|
| ヘルスチェックのパス |
|
| SQLite データベースのパス |
|
| ログレベル |
|
| データベースのセットアップをスキップする |
GET /health - ヘルスチェック
POST /mcp - MCP JSON-RPC エンドポイント
# Development
bun run build # Compile TypeScript
bun run dev # Development with hot reload
bun run start # Build and start production server
# Database
bun run db:setup # Complete database setup
bun run migrate # Run migrations
bun run seed # Seed pattern data
bun run generate-embeddings # Generate semantic embeddings
bun run setup-relationships # Setup pattern relationships
# Quality
bun run test # Run all tests
bun run lint # Check code quality
bun run lint:fix # Auto-fix linting issues
bun run typecheck # TypeScript type checkingこのプロジェクトには 77 のテストファイルにわたる 654 のテストケース が含まれており、100% の合格率（失敗 0、スキップ 0）です:
コントラクトテスト: MCP プロトコル準拠の検証
統合テスト: 実 SQLite DB と埋め込みに対するコンポーネント連携テスト
パフォーマンステスト: 検索とベクトル化のベンチマーク
ユニットテスト: 個々のコンポーネントのテスト
# Run all tests
bun run test
# Run specific test suites
bun run test:unit -- --grep "PatternService"
bun run test:integration -- --grep "database"
bun run test:performance -- --timeout 30000このプロジェクトは、文書化されているパターンを実装しています:
パターン | 実装 |
Repository |
|
Service Layer |
|
Object Pool |
|
Dependency Injection |
|
Strategy |
|
Event Bus |
|
Multi-Level Cache |
|
Builder |
|
サーバーは、保存された埋め込みに対するインメモリのコサイン類似度を備えた sql.js（SQLite WASM）を使用します。ネイティブの sqlite-vec（vec0 仮想テーブル）は、このランタイムでは利用できません。セマンティック検索は現在のカタログサイズ（約 710 パターン）では機能しますが、インデックス化されたネイティブなベクターテーブルは使用しません。
実際のプロバイダー統合がある場合にのみ LLM エンリッチメントを有効にしてください。組み込みの LLM ブリッジプロバイダーは、拡張しない限りプレースホルダーを返します。
コントリビューションを歓迎します。コントリビューティングガイドを参照してください。
リポジトリをフォークする
フィーチャーブランチを作成する
SOLID 原則に従って変更を加える
テストとリンティングを実行する
プルリクエストを送信する
アクティブなソースファイルとドキュメントファイル全体で、正規バージョンを 0.7.1 → 0.7.2 に更新しました。
更新されたファイル: package.json、src/mcp-server.ts（Server 登録 + ランタイム情報）、AGENTS.md、CLAUDE.md（正規 ID ヘッダー）、README.md（バッジ、リリースノートセクション、バージョンフッター）、CHANGELOG.md（新しいエントリ）。docs/IMPROVEMENTS_03.md と QUICKSTART.md の監査証跡参照は、状態 #45 に従って変更せずに保持されます。
古いバージョン参照を修正: AGENTS.md と CLAUDE.md のヘッダー (version 0.6.0) → (version 0.7.2)（実際の package.json より 7 マイナーバージョン遅れていました）。
ランタイムの自己報告が、Server コンストラクターと /info エンドポイントを介して MCP クライアントに 0.7.2 を通知するようになりました。
コードレベルの動作変更はありません。純粋なリリース/バージョン正規化パッチです。
テスト: 完全なスイートを維持（テストファイルの変更なし）、型チェックはクリーン。
テストスイートは完全に検証済み: 654/654 GREEN、0 スキップ、0 TODO (以前は 651/654 で、既存のフレークが 3 件ありました)。
db:setup パイプラインによって導入された data/.git リークを解消しました (データ衛生テスト)。
2 つの古いテストを BUG-007 契約 に合わせました: validateSearchPatternsArgs は snake_case の search_type を黙って無視し、標準のデフォルトである hybrid 戦略が適用されます。
tests/unit/input-validation.test.ts
tests/unit/mcp-server-search.test.ts
README.md のバージョン乖離を修正: 末尾のブロックが正規の 0.7.0 → 0.7.1 ベースラインを反映し、バッジ + Production Ready + Testing セクションが現在の 654 テストスイートに合わせられました。
Lint ベースラインを復元: 0 問題、exit 0 (以前は 2 エラー + 6 警告)。
src/mcp/http-transport.ts 内の未使用の HealthStatus インポートを削除しました。
src/health/embedding-coverage-health-check.ts 内の同期 check() に対する require-await の対象を絞った eslint-disable を追加しました (インターフェース準拠を維持)。
src/handlers/keyword-search-handler.ts の ensureBM25() を BM25Scorer を返すようにリファクタリングし、呼び出し箇所の 4 つの非 null アサーションを排除しました。
tests/unit/bm25-scorer.test.ts 内の results.find() に対する 2 つの非 null アサーションを、明示的な toBeDefined ガードに置き換えました。
bun run typecheck はクリーンです。
docs/01_Agentic_Design_Patterns.md と docs/02_Data_Engineering_Design_Patterns.md から 24 件の新しいデザインパターン を追加しました:
Agentic AI 3 件: Multi-Agent Collaboration、Goal Setting and Monitoring、Exception Handling and Recovery。
Data Engineering 21 件: Aligned Fan-In、Unaligned Fan-In、Bin Pack Orderer、Exclusive Choice、FIFO Orderer、Fine-Grained Accessor for Resources、Fine-Grained Accessor for Tables、Fine-Grained Tracker、In-Place Overwriter、Isolated Sequencer、Metadata Decorator、Metadata Enhancer、Offline Observer、Schema Compatibility Enforcer、Schema Migrator、Secretless Connector、Secrets Pointer、Single Runner、Skew Detector、SLA Misses Detector、Vertical Partitioner。
カタログは 686 → 710 パターン に拡大しました (Agentic AI: 3→6、Data Engineering: 4→25)。
整合性チェック PASS: 710 パターン、151 件の有効なリレーションシップ。
654/654 テストがパス (100% green、0 スキップ、0 TODO)。
MIT ライセンス - 詳細は LICENSE を参照してください。
ベクトル検索のメモ (sql.js vs sqlite-vec) — コントリビューティングガイドを参照
MCP ツールサーフェスリファレンス
ドキュメントインデックス
バージョン: 0.7.2 最終更新: 2026 年 8 月 パターン: 710 件の JSON 定義 (ハイライト: Feature Flag / Feature Toggle) テスト: 654 テストケース | 100% 合格率 (0 失敗、0 スキップ)
関連情報: 最新の敵対的品質保証レポート (16 件の指摘: クリティカル 1 件、高優先度 9 件、軽微 6 件)。指摘は検索パイプラインの正確性、設定の乖離、トランスポートセキュリティ、ドキュメントの同期を対象としています。
Get the total number of design patterns in the database
| Name | Required | Description | Default |
|---|---|---|---|
| includeDetails | No | Include breakdown by category |
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 'Get[s] the total number', implying a read-only operation, but doesn't mention any behavioral traits such as performance considerations, error handling, or whether it's a simple count versus an aggregated query. For a tool with zero annotation coverage, this is a significant gap in transparency.
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 a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly. Every part of the sentence earns its place by conveying essential information.
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?
Given the tool's low complexity (one optional parameter) and high schema coverage, the description is adequate but has clear gaps. It lacks output schema information, usage guidelines, and behavioral context, which could help an agent use it correctly. However, for a simple counting tool, it meets the minimum viable threshold without being fully comprehensive.
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 has 100% description coverage, with the parameter 'includeDetails' clearly documented in the schema. The description adds no additional meaning beyond what the schema provides, as it doesn't mention parameters at all. According to the rules, when schema_description_coverage is high (>80%), the baseline score is 3, which is appropriate here.
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 tool's purpose with a specific verb ('Get') and resource ('total number of design patterns in the database'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'find_patterns' or 'search_patterns', which might also retrieve pattern information, so it doesn't reach the highest 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?
The description provides no guidance on when to use this tool versus alternatives like 'find_patterns', 'get_pattern_details', or 'search_patterns'. It lacks any context about use cases, prerequisites, or exclusions, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find design patterns matching a problem description using semantic search
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language description of the problem or requirements | |
| categories | No | Optional: Pattern categories to search in | |
| maxResults | No | Maximum number of recommendations to return | |
| programmingLanguage | No | Target programming language for implementation examples |
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 mentions 'semantic search' but doesn't explain what this entails—e.g., how results are ranked, whether it's a read-only operation, or any limitations like rate limits or authentication needs. For a tool with no annotation coverage, this leaves critical behavioral traits unspecified.
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 a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core purpose ('Find design patterns...'), making it easy to understand at a glance. Every part of the sentence earns its place by conveying essential information.
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?
Given the tool's complexity (semantic search with 4 parameters) and the absence of both annotations and an output schema, the description is insufficient. It doesn't cover behavioral aspects like result format, error handling, or how semantic search works, nor does it explain the relationship between parameters and outcomes. This leaves significant gaps for an AI agent to use the tool effectively.
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 100%, meaning all parameters are documented in the schema itself. The description adds no additional meaning beyond the schema, such as explaining the 'semantic search' process in relation to the 'query' parameter or how 'categories' affect results. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but no extra value is provided.
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 tool's purpose: 'Find design patterns matching a problem description using semantic search.' It specifies the verb ('Find'), resource ('design patterns'), and method ('semantic search'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search_patterns' or 'count_patterns,' which prevents a perfect 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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'search_patterns' and 'count_patterns' available, it fails to indicate scenarios where this tool is preferred, such as for semantic versus keyword-based searches, or how it differs from 'get_pattern_details.' This lack of comparative context leaves the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific pattern
| Name | Required | Description | Default |
|---|---|---|---|
| patternId | Yes | Pattern ID to get details for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it 'gets' information, implying a read-only operation, but doesn't disclose any behavioral traits such as error handling, permissions needed, rate limits, or what 'detailed information' includes. This is a significant gap for a tool with no annotation coverage.
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 a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to understand quickly.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' entails, potential return values, or any behavioral context. For a tool with no structured data beyond the input schema, this leaves significant gaps in understanding its full functionality.
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 has 100% description coverage, with the parameter 'patternId' clearly documented. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.
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 verb 'Get' and the resource 'detailed information about a specific pattern', which is specific and understandable. However, it doesn't differentiate from sibling tools like 'find_patterns' or 'search_patterns' that might also retrieve pattern information, so it doesn't reach the highest 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?
The description provides no guidance on when to use this tool versus alternatives like 'find_patterns' or 'search_patterns'. It lacks context about whether this is for retrieving details of a known pattern ID versus searching for patterns, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search patterns by keyword or semantic similarity
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| searchType | No | hybrid | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions search functionality but fails to describe critical behaviors such as pagination, rate limits, authentication needs, or what happens on no matches. For a search tool with zero annotation coverage, this is a significant gap in transparency.
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 extremely concise at one sentence with zero waste, front-loading the core functionality. Every word earns its place, making it easy for an agent to parse quickly without unnecessary elaboration.
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?
Given the tool's complexity as a search function with 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks information on return values, error handling, and behavioral traits, leaving the agent with insufficient context to use the tool effectively beyond basic invocation.
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 low at 33%, with only the 'query' parameter documented. The description adds value by explaining that searches can be by keyword or semantic similarity, which helps interpret the 'searchType' enum, but it doesn't clarify the 'limit' parameter or provide details beyond what the schema implies. This partial compensation justifies a baseline score.
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 tool's purpose as searching patterns using keyword or semantic similarity, which is specific and actionable. However, it doesn't explicitly distinguish this from sibling tools like 'find_patterns' or 'count_patterns', leaving some ambiguity about when to choose one over another.
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 provides no guidance on when to use this tool versus alternatives like 'find_patterns' or 'count_patterns'. It mentions search methods but doesn't specify scenarios, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
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.
count_patternsfind_patternsget_pattern_detailssearch_patternsScored across 4 tools
Multiple tools have overlapping purposes that could cause confusion. 'find_patterns' and 'search_patterns' both appear to search for patterns, with descriptions that are nearly identical ('semantic search' vs 'keyword or semantic similarity'), making them difficult to distinguish. 'count_patterns' and 'get_pattern_details' are clearer, but the overlap between the two search tools significantly reduces disambiguation.
All tool names follow a consistent verb_noun pattern with snake_case, such as 'count_patterns', 'find_patterns', 'get_pattern_details', and 'search_patterns'. This uniformity makes the tool set predictable and easy to understand, with no deviations in naming conventions.
With only 4 tools, the set feels thin for a server focused on design patterns, which typically involve operations like creating, updating, or categorizing patterns. While basic retrieval functions are covered, the low count may limit functionality for more complex agent tasks, placing it in the borderline range for appropriateness.
The tool set is severely incomplete for a design patterns domain, as it only supports read operations (counting, searching, and getting details) with no ability to create, update, delete, or manage patterns. This lack of CRUD coverage creates significant gaps that will likely cause agent failures when trying to perform full lifecycle tasks.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
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).
295k+ bug-fix patterns with MCP Hub proxy, PII filtering, and code search
