모든 큐레이션된 Awesome 리스트와 해당 항목에 대한 액세스를 제공하는 MCP(Model Context Protocol) 서버입니다. GitHub의 8,500개 이상의 Awesome 리스트 섹션과 100만 개 이상(계속 증가 중)의 Awesome 항목에서 에이전트를 위한 최적의 리소스를 제공할 수 있습니다.
Awesome 리스트란 무엇인가요? Awesome 리스트는 머신러닝 프레임워크부터 디자인 도구까지, 모든 주제에 대해 커뮤니티가 직접 큐레이션한 최고의 도구, 라이브러리, 리소스 모음입니다. 이 MCP 서버를 추가하면 AI 에이전트가 무작위 웹 검색에 의존하는 대신, 검증된 고품질 리소스에 즉시 액세스할 수 있습니다.
다음과 같은 경우에 완벽합니다:
지식 노동자 에이전트가 업무에 가장 관련성 높은 참조 자료를 얻을 때
최고의 학습 리소스를 찾을 때
심층 연구 시 모든 주제에 대해 고품질 리소스를 빠르게 수집할 때
검색 에이전트
https://github.com/user-attachments/assets/babab991-e4ff-4433-bdb7-eb7032e9cd11
모드 | 설치 | 용도 |
MCP 서버 | 호스팅된 URL을 에이전트에 지정하거나 | Claude Desktop, Cursor, Windsurf, VS Code — MCP를 기본 지원하는 에이전트 |
CLI |
| 스크립트, 셸 워크플로우, MCP를 지원하지 않는 에디터, CI 작업 |
두 모드 모두 동일한 npm 패키지(context-awesome)에서 제공되며 동일한 호스팅 백엔드를 사용합니다.
Related MCP server: agent101-mcp
모든 MCP 도구는 1:1 CLI 하위 명령을 가집니다. 서버와 CLI는 동일한 작업을 수행합니다.
도구 | CLI 대응 명령 | 기능 |
|
| 쿼리와 일치하는 Awesome 리스트의 섹션/카테고리 검색 |
|
| 개별 항목(도구/라이브러리/리소스)에 대한 전체 텍스트 검색 |
|
| 알려진 리스트 + 섹션에서 항목 가져오기 (토큰 제한 적용) |
CLI(context-awesome)는 호스팅된 백엔드와 직접 통신합니다. MCP 서버의 경우 별도의 context-awesome-mcp 바이너리를 사용하세요(아래 설치 — MCP 클라이언트 참조).
context-awesome <command> [options]
Commands:
sections <query...> Find sections matching a query
search <query...> Search items (e.g., context-awesome search "postgres orm")
items <target> Fetch items from a list (by owner/repo or listId)
Globals:
--api-host <url> Backend API host (env: CONTEXT_AWESOME_API_HOST)
--api-key <key> API key (env: CONTEXT_AWESOME_API_KEY)
--json Emit raw JSON (for scripts)npm install -g context-awesome
context-awesome --help
context-awesome search "rate limiter"
context-awesome sections "graph databases"npx context-awesome search "vector database"Context Awesome은 호스팅된 MCP 서버로 제공됩니다. 별도의 설치가 필요하지 않습니다.
이동: Settings → Cursor Settings → MCP → Add new global MCP server
{
"mcpServers": {
"context-awesome": {
"url": "https://www.context-awesome.com/api/mcp"
}
}
}claude mcp add --transport http context-awesome https://www.context-awesome.com/api/mcpSettings → Connectors → Add Custom Connector.
이름: Context Awesome
URL: https://www.context-awesome.com/api/mcp
각 클라이언트의 "add remote MCP" UI에서 동일한 URL(https://www.context-awesome.com/api/mcp)을 사용하세요. 정확한 스니펫은 아래 전용 섹션을 참조하세요.
{
"mcpServers": {
"context-awesome": {
"command": "npx",
"args": ["-y", "context-awesome-mcp", "serve", "--transport", "stdio"],
"env": {
"CONTEXT_AWESOME_API_HOST": "https://api.context-awesome.com"
}
}
}
}npx context-awesome-mcp serve --transport http --port 3001
# then point your client at http://localhost:3001/mcpgit clone https://github.com/bh-rat/context-awesome.git
cd context-awesome
npm install
npm run build
# CLI
./build/cli.js search "graph databases"
# MCP server (stdio)
./build/index.js --transport stdio
# MCP Inspector
npm run inspector이 MCP 서버와 CLI는 Awesome 리스트 처리의 복잡한 작업을 수행하는 백엔드 API 서비스에 연결됩니다.
백엔드 서비스는 곧 오픈 소스로 공개될 예정이며, 커뮤니티가 전체 context-awesome 생태계에 기여하고 혜택을 받을 수 있게 될 것입니다.
{
"mcpServers": {
"context-awesome": {
"url": "https://www.context-awesome.com/api/mcp"
}
}
}{
"context_servers": {
"context-awesome": {
"url": "https://www.context-awesome.com/api/mcp"
}
}
}햄버거 메뉴 클릭
Settings 선택
Tools로 이동
+ Add MCP 클릭
URL 입력: https://www.context-awesome.com/api/mcp
이름: Context Awesome
{
"mcpServers": {
"context-awesome": {
"type": "streamable-http",
"url": "https://www.context-awesome.com/api/mcp"
}
}
}{
"mcpServers": {
"context-awesome": {
"httpUrl": "https://www.context-awesome.com/api/mcp"
}
}
}"mcp": {
"context-awesome": {
"type": "remote",
"url": "https://www.context-awesome.com/api/mcp",
"enabled": true
}
}Settings -> Tools -> AI Assistant -> Model Context Protocol (MCP)로 이동
+ Add 클릭
URL 구성: https://www.context-awesome.com/api/mcp
OK 및 Apply 클릭
Kiro > MCP Servers로 이동
+ Add 클릭
URL 구성: https://www.context-awesome.com/api/mcp
Save 클릭
{
"mcpServers": {
"context-awesome": {
"url": "https://www.context-awesome.com/api/mcp"
}
}
}{
"mcpServers": {
"context-awesome": {
"url": "https://www.context-awesome.com/api/mcp"
}
}
}Settings > AI > Manage MCP servers로 이동
+ Add 클릭
URL 구성: https://www.context-awesome.com/api/mcp
Save 클릭
{
"mcpServers": {
"context-awesome": {
"type": "http",
"url": "https://www.context-awesome.com/api/mcp",
"tools": ["find_awesome_section", "search_awesome_items", "get_awesome_items"]
}
}
}Program > Install > Edit mcp.json으로 이동
추가:
{
"mcpServers": {
"context-awesome": {
"url": "https://www.context-awesome.com/api/mcp"
}
}
}{
"mcpServers": {
"context-awesome": {
"url": "https://www.context-awesome.com/api/mcp"
}
}
}Perplexity > Settings로 이동
Connectors 선택
Add Connector 클릭
Advanced 선택
이름 입력: Context Awesome
URL 입력: https://www.context-awesome.com/api/mcp
{
"inputs": [],
"servers": {
"context-awesome": {
"type": "http",
"url": "https://www.context-awesome.com/api/mcp"
}
}
}{
"$schema": "https://charm.land/crush.json",
"mcp": {
"context-awesome": {
"type": "http",
"url": "https://www.context-awesome.com/api/mcp"
}
}
}acli rovodev mcp그런 다음 추가:
{
"mcpServers": {
"context-awesome": {
"url": "https://www.context-awesome.com/api/mcp"
}
}
}Zencoder 메뉴(...)로 이동
Agent tools 선택
Add custom MCP 클릭
이름: Context Awesome
URL: https://www.context-awesome.com/api/mcp
Qodo Gen 채팅 패널 열기
Connect more tools 클릭
Add new MCP 클릭
추가:
{
"mcpServers": {
"context-awesome": {
"url": "https://www.context-awesome.com/api/mcp"
}
}
}MIT
기여를 환영합니다! 다음 단계를 따라주세요:
저장소 포크
기능 브랜치 생성
새로운 기능에 대한 테스트 추가
모든 테스트 통과 확인
풀 리퀘스트 제출
문제 및 질문:
GitHub Issues: https://github.com/bh-rat/context-awesome/issues
이 프로젝트는 GitHub의 8,500개 이상의 Awesome 리스트 데이터를 사용합니다. 데이터가 포함된 모든 저장소의 전체 목록은 ATTRIBUTION.md를 참조하세요.
다음 기술을 사용하여 제작되었습니다:
context7 MCP 서버 패턴에서 영감을 받음
Discovers sections/categories across awesome lists matching a search query and returns matching sections from awesome lists.
You MUST call this function before 'get_awesome_items' to discover available sections UNLESS the user explicitly provides a githubRepo or listId.
Selection Process:
Analyze the query to understand what type of resources the user is looking for
Return the most relevant matches based on:
Name similarity to the query and the awesome lists section
Category/section relevance of the awesome lists
Number of items in the section
Confidence score
Response Format:
Returns matching sections of the awesome lists with metadata
Includes repository information, item counts, and confidence score
Use the githubRepo or listId with relevant sections from results for get_awesome_items
For ambiguous queries, multiple relevant sections will be returned for the user to choose from.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search terms for finding sections across awesome lists | |
| confidence | No | Minimum confidence score (0-1) | |
| limit | No | Maximum sections to return |
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 effectively describes the tool's behavior: the selection process (4 criteria), response format (metadata included), and handling of ambiguous queries (returns multiple sections). It doesn't mention rate limits, authentication needs, or error conditions, but provides substantial operational context.
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 well-structured with clear sections: purpose statement, usage requirement, selection process, response format, and handling of ambiguous queries. While comprehensive, some sentences could be more concise (e.g., the selection process could be bulleted more efficiently). Overall, it's appropriately sized for the tool's complexity.
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 no annotations and no output schema, the description provides substantial context: purpose, usage rules, selection algorithm, response format, and relationship to sibling tool. It doesn't explicitly describe the exact structure of returned metadata or error cases, but covers most essential aspects for a search/discovery tool.
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%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting for parameter documentation.
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: 'Discovers sections/categories across awesome lists matching a search query and returns matching sections from awesome lists.' It specifies the verb ('discovers'), resource ('sections/categories across awesome lists'), and distinguishes it from its sibling 'get_awesome_items' by explaining this tool is for discovering sections before retrieving items.
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 explicit usage guidance: 'You MUST call this function before 'get_awesome_items' to discover available sections UNLESS the user explicitly provides a githubRepo or listId.' It clearly states when to use this tool versus its sibling and includes conditions for when it's not needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves items from a specific awesome list or section with token limiting. You must call 'find_awesome_section' first to discover available sections, UNLESS the user explicitly provides a githubRepo or listId.
| Name | Required | Description | Default |
|---|---|---|---|
| listId | No | UUID of the list (from find_awesome_section results) | |
| githubRepo | No | GitHub repo path (e.g., 'sindresorhus/awesome') from find_awesome_section results | |
| section | No | Category/section name to filter | |
| subcategory | No | Subcategory to filter | |
| tokens | No | Maximum number of tokens to return (default: 10000). Higher values provide more items but consume more tokens. | |
| offset | No | Pagination offset for retrieving more items |
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 effectively describes key behaviors: the token limiting mechanism ('with token limiting'), the dependency on another tool ('call 'find_awesome_section' first'), and the conditional logic for parameters. However, it doesn't mention error handling, rate limits, or authentication needs, which are common gaps for retrieval tools.
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 perfectly concise with two sentences that each serve distinct purposes: the first states the core functionality with a key constraint, and the second provides essential usage guidance. There is no wasted language, and information is front-loaded effectively.
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 complexity (6 parameters, dependency on another tool) and lack of annotations/output schema, the description does well by covering purpose, usage guidelines, and key behavioral aspects. However, it doesn't describe the return format (e.g., structure of items, pagination details), which would be helpful since there's no output schema, leaving some gaps in completeness.
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%, so the schema already documents all 6 parameters thoroughly. The description adds minimal parameter semantics beyond the schema, only implying that 'githubRepo' and 'listId' come from 'find_awesome_section' results. This meets the baseline of 3 when schema coverage is high, but doesn't provide significant additional value.
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 'retrieves' and the resource 'items from a specific awesome list or section', specifying the action and target. It distinguishes from the sibling tool 'find_awesome_section' by indicating this tool is for retrieving items after sections are identified, establishing a clear functional relationship.
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 this tool: 'You must call 'find_awesome_section' first to discover available sections, UNLESS the user explicitly provides a githubRepo or listId.' This provides clear prerequisites and alternatives, directly addressing the sibling tool relationship and user input scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have clearly distinct purposes: 'find_awesome_section' discovers sections/categories across awesome lists based on a search query, while 'get_awesome_items' retrieves actual items from a specific list or section. There is no overlap in functionality—one is for discovery and the other for retrieval, making them perfectly distinguishable.
Both tools follow a consistent verb_noun pattern with snake_case: 'find_awesome_section' and 'get_awesome_items'. The naming is predictable and readable, with 'find' and 'get' as appropriate verbs for their respective actions, maintaining uniformity throughout the set.
With only 2 tools, the server feels thin for its apparent purpose of interacting with awesome lists. While the tools cover discovery and retrieval, typical operations like creating, updating, or deleting items are missing, suggesting the scope might be limited or incomplete. A count of 2 is borderline for a functional server in this domain.
The tool surface is significantly incomplete for the domain of awesome list management. It only supports discovery and retrieval, lacking any CRUD operations such as adding, updating, or removing items or sections. This will likely cause agent failures when full lifecycle management is needed, as there are obvious gaps in coverage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI Agent Source Registry. 288K+ curated sources for agentic search and discovery.
Agent-first resource directory for AI agents: protocols, security, RAG, memory, evals, and more.
Curated knowledge API for AI agents - skill packs, semantic search, validated patterns.
Live data gateway for AI — 3,300+ tools across 750+ sources, with citations
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bh-rat/context-awesome'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
