The Design Patterns MCP Server provides intelligent design pattern recommendations through semantic search and natural language queries, accessing a comprehensive catalog of 555+ patterns across 20+ categories.
Core Capabilities:
Natural language pattern discovery: Find relevant patterns using problem descriptions with confidence-scored recommendations
Advanced search options: Perform keyword, semantic, or hybrid searches with filtering by categories (GoF, Architectural, Microservices, React, AI/ML, Security, etc.) and programming languages
Detailed pattern information: Access comprehensive details including multi-language code examples, relationships, and use cases for any specific pattern
Catalog statistics: Query total pattern counts with optional category breakdowns
High-performance operations: Fast vector search using sqlite-vec with LRU caching and object pooling, delivering 30-40% faster repeated queries
AI assistant integration: Compatible with MCP clients like Claude Code and Cursor for seamless workflow integration
Uses SQLite with vector extensions for efficient semantic search and storage of design pattern embeddings and metadata
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., "@Design Patterns MCP Server I need a pattern for handling user authentication with multiple providers"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An intelligent MCP (Model Context Protocol) server that provides design pattern recommendations using hybrid search (semantic + keyword + graph augmentation). Access 710 design patterns across 90+ categories through a natural language interface with advanced blended RAG architecture.
# 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.jsConfigure in your MCP client (Claude Desktop, Cursor, etc.) and start discovering patterns through natural language queries.
Related MCP server: Acemcp
Use Bun as the canonical package manager for this repository (bun install only). The lockfile is bun.lock.
Never copy a .git directory into dist/data (or ship it inside dist/). That path must remain a plain data directory to avoid multi‑gigabyte images and metadata leakage.
Feature | Description |
Hybrid Search Engine | Blended RAG combining semantic, keyword (BM25), and graph-augmented retrieval |
710 Patterns | Comprehensive catalog across 90+ categories including Feature Flag / Feature Toggle for progressive delivery and experimentation |
MCP Integration | Seamless integration with Claude, Cursor, and other MCP clients |
Multi-Level Caching | L1 in-memory + L3 SQLite cache with 95%+ hit rate |
Event Bus System | Decoupled service communication via pub/sub |
Telemetry & Health | Real-time performance metrics and system monitoring |
SOLID Architecture | Clean, maintainable codebase following best practices |
Production Ready | 654 test cases across 77 test files with 100% pass rate (0 failures, 0 skips) |
Category | Count | Examples |
Classic GoF Patterns | 34 | Factory, Builder, Observer, Strategy, Command |
Architectural Patterns | 56 | MVC, Clean Architecture, Hexagonal, DDD, Feature Flag |
Microservices & Cloud | 39 | Circuit Breaker, Saga, Service Mesh |
Data Engineering | 54 | Repository, CQRS, Event Sourcing |
AI/ML & MLOps | 46 | RAG, Fine-Tuning, Model Compression |
React Patterns | 27 | Hooks, Server Components, Performance |
Blockchain & Web3 | 115 | DeFi, NFTs, Smart Contracts, MEV |
Concurrency & Reactive | 45 | Producer-Consumer, Actor Model |
Security | 21 | OAuth, RBAC, Zero Trust |
Functional Programming | 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 embeddingsAsk natural language questions through your MCP client:
"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 TrustTool | Description |
| Hybrid search for patterns using problem descriptions |
| Keyword or semantic search with filtering |
| Comprehensive pattern information with code examples |
| Statistics about available patterns |
| System health and service status |
Node.js >= 18.0.0
Bun >= 1.0.0 (recommended) or npm >= 8.0.0
bun install
bun run build
bun run db:setupThe prepare script in package.json requires bun. If you don't have bun installed, use --ignore-scripts to skip it and build manually:
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.jsAdd to your MCP client configuration (Claude Desktop, Cursor, etc.):
{
"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"
}
}
}
}Important: Use absolute paths for both
argsandDATABASE_PATH. MCP clients like Cursor do not reliably support thecwdfield, so relative paths resolve against the user's home directory rather than the project directory. See the project quickstart for client-specific configuration examples.
Variable | Default | Description |
|
| Logging level (debug, info, warn, error) |
|
| SQLite database path |
|
| Enable blended RAG search |
|
| Enable pattern relationship traversal |
|
| Dimensionality reduction |
|
| Fuzzy logic result refinement |
|
| Performance metrics |
|
| L1 + L3 caching |
|
| Request concurrency limit |
|
| Cache size limit |
|
| Cache TTL in milliseconds |
|
| Transport mode (stdio/http) |
|
| HTTP port (http mode) |
|
| MCP endpoint path |
|
| Health check path |
|
| Skip database setup |
# 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 -dVariable | Default | Description |
|
| Transport mode (stdio/http) |
|
| HTTP port (http mode) |
|
| MCP endpoint path |
|
| Health check path |
|
| SQLite database path |
|
| Logging level |
|
| Skip database setup |
GET /health - Health check
POST /mcp - MCP JSON-RPC endpoint
# 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 checkingThe project includes 654 test cases across 77 test files with 100% pass rate (0 failures, 0 skips):
Contract Tests: MCP protocol compliance validation
Integration Tests: Component interaction tests against live SQLite DB and embeddings
Performance Tests: Search and vectorization benchmarks
Unit Tests: Individual component tests
# 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 30000This project implements the patterns it documents:
Pattern | Implementation |
Repository |
|
Service Layer |
|
Object Pool |
|
Dependency Injection |
|
Strategy |
|
Event Bus |
|
Multi-Level Cache |
|
Builder |
|
The server uses sql.js (SQLite WASM) with in-memory cosine similarity over stored embeddings. Native sqlite-vec (vec0 virtual tables) is not available in this runtime. Semantic search works for the current catalog size (~710 patterns) but does not use indexed native vector tables.
Enable LLM enrichment only when you have a real provider integration — built-in LLM bridge providers return placeholders unless extended.
Contributions are welcome! See the contributing guide.
Fork the repository
Create a feature branch
Make changes following SOLID principles
Run tests and linting
Submit a pull request
Canonical version bumped from 0.7.1 → 0.7.2 across active source and documentation files.
Files updated: package.json, src/mcp-server.ts (Server registration + runtime info), AGENTS.md, CLAUDE.md (canonical-identity header), README.md (badge, release-notes section, version footer), CHANGELOG.md (new entry). docs/IMPROVEMENTS_03.md and QUICKSTART.md audit-evidence references preserved untouched per state #45.
Stale version references corrected: AGENTS.md and CLAUDE.md header (version 0.6.0) → (version 0.7.2) (was 7 minor versions behind the actual package.json).
Runtime self-report now advertises 0.7.2 to MCP clients via Server constructor and /info endpoint.
No code-level behavioural change: pure release/version-canonicalisation patch.
Tests: full suite preserved (no test files modified), typecheck clean.
Test suite fully validated: 654/654 GREEN, 0 skips, 0 todos (was 651/654 with 3 pre-existing flakes).
Resolved data/.git leak introduced by db:setup pipeline (data-hygiene test).
Aligned two outdated tests with the BUG-007 contract: snake_case search_type is silently ignored by validateSearchPatternsArgs and the canonical default hybrid strategy is applied.
tests/unit/input-validation.test.ts
tests/unit/mcp-server-search.test.ts
README.md version drift corrected: trailing block now reflects canonical 0.7.0 → 0.7.1 baseline, badge + Production Ready + Testing section aligned with current 654-test suite.
Lint baseline restored: 0 problems, exit 0 (was 2 errors + 6 warnings).
Removed unused HealthStatus import in src/mcp/http-transport.ts.
Added targeted eslint-disable for require-await on the synchronous check() in src/health/embedding-coverage-health-check.ts (interface conformance preserved).
Refactored ensureBM25() in src/handlers/keyword-search-handler.ts to return BM25Scorer, eliminating 4 non-null assertions at the call sites.
Replaced 2 non-null assertions on results.find() in tests/unit/bm25-scorer.test.ts with explicit toBeDefined guards.
bun run typecheck clean.
24 new design patterns added from docs/01_Agentic_Design_Patterns.md and docs/02_Data_Engineering_Design_Patterns.md:
3 Agentic AI: Multi-Agent Collaboration, Goal Setting and Monitoring, Exception Handling and Recovery.
21 Data Engineering: 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.
Catalog grew from 686 → 710 patterns (Agentic AI: 3→6, Data Engineering: 4→25).
Integrity check PASS: 710 patterns, 151 valid relationships.
654/654 tests pass (100% green, 0 skips, 0 todos).
MIT License - see LICENSE for details.
Vector search notes (sql.js vs sqlite-vec) — see contributing guide
MCP tools surface reference
Documentation index
Version: 0.7.2 Last Updated: August 2026 Patterns: 710 JSON definitions (highlight: Feature Flag / Feature Toggle) Tests: 654 test cases | 100% pass rate (0 failures, 0 skips)
See also: the latest adversarial quality assurance report (16 findings: 1 critical, 9 high-priority, 6 minor). Findings cover search pipeline correctness, configuration drift, transport security, and documentation sync.
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. Dates show when Glama detected each change.
count_patternsfind_patternsget_pattern_detailssearch_patternsMultiple 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/apolosan/design_patterns_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
