하이브리드 검색(의미 기반 + 키워드 + 그래프 증강)을 사용하여 디자인 패턴 추천을 제공하는 지능형 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개 패턴 | 점진적 전달 및 실험을 위한 Feature Flag / Feature Toggle을 포함한 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, Clean Architecture, Hexagonal, DDD, Feature Flag |
마이크로서비스 및 클라우드 | 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, NFTs, Smart Contracts, 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(서버 등록 + 런타임 정보), 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 (종전 651/654, 기존 플레이크 3건).
db:setup 파이프라인으로 도입된 data/.git 유출 문제 해결(데이터 위생 테스트).
두 개의 오래된 테스트를 BUG-007 계약에 맞게 정렬: snake_case search_type은 validateSearchPatternsArgs에서 경고 없이 무시되며, 표준 기본값인 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개 테스트 스위트에 맞게 정렬되었습니다.
린트 기준선 복원: 문제 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를 반환하도록 리팩터링하여 호출 지점의 non-null 단언 4건 제거.
tests/unit/bm25-scorer.test.ts에서 results.find()에 대한 non-null 단언 2건을 명시적 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).
무결성 검사 통과: 패턴 710개, 유효한 관계 151개.
테스트 654/654 통과(100% green, 스킵 0, 투두 0).
MIT License - 자세한 내용은 LICENSE를 참조하세요.
벡터 검색 노트(sql.js vs sqlite-vec) — 기여 가이드 참조
MCP 도구 표면 참조
문서 색인
버전: 0.7.2 마지막 업데이트: 2026년 8월 패턴: JSON 정의 710개(하이라이트: 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
