You.com MCP Server
You.com MCP 서버
이 MCP(모델 컨텍스트 프로토콜) 서버는 AI 비서가 You.com API를 사용하여 웹 검색, 뉴스 수신, 조사 등을 수행할 수 있도록 지원합니다. 피드백을 환영합니다.
특징
웹 검색 : You.com의 웹 검색 기능에 접속
스마트 검색 : 인용 지원이 포함된 AI 기반 답변
연구 : 학문적 질문에 대한 포괄적이고 인용이 뒷받침되는 답변
뉴스 검색 : 모든 주제에 대한 최신 뉴스 기사
Related MCP server: Kagi MCP Server
필수 조건
Node.js(v16 이상)
npm 또는 yarn
You.com API 키( api.you.com 에서 하나 받으세요)
설치
이 저장소를 복제하세요:
지엑스피1
종속성 설치:
npm install다음 예를 기반으로
.env파일을 만듭니다.cp .env.example .envYou.com API 키를
.env파일에 추가하세요.YOU_API_KEY=your_actual_api_key_here프로젝트를 빌드하세요:
npm run build
로컬에서 실행(선택 사항)
테스트를 위해 서버를 로컬로 실행할 수 있습니다.
npm start클로드와 함께 설정
이 MCP 서버를 Claude(Anthropic Assistant)와 함께 사용하려면 Claude가 이 서버를 사용하도록 구성해야 합니다.
VS Code에서 Claude 확장 프로그램 설정을 엽니다.
VS Code 사이드바에서 Claude 아이콘을 클릭하세요.
설정 아이콘(⚙️)을 클릭하고 "MCP 설정"을 선택하세요.
mcpServers섹션에 다음 구성을 추가합니다.
"youcom-mcp": {
"autoApprove": [],
"disabled": false,
"command": "node",
"args": [
"/absolute/path/to/your/youcom-mcp/dist/index.js"
],
"env": {
"YOU_API_KEY": "your_actual_api_key_here"
},
"transportType": "stdio"
}중요 참고 사항:
/absolute/path/to/your/youcom-mcp/dist/index.js시스템의 실제 경로로 바꾸세요.your_actual_api_key_hereYou.com API 키로 바꾸세요.
사용 예
구성이 완료되면 Claude와의 대화에서 MCP 도구를 직접 사용할 수 있습니다.
웹 검색
<use_mcp_tool>
<server_name>youcom-mcp</server_name>
<tool_name>web_search</tool_name>
<arguments>
{
"query": "latest research on renewable energy"
}
</arguments>
</use_mcp_tool>스마트 검색
<use_mcp_tool>
<server_name>youcom-mcp</server_name>
<tool_name>smart_search</tool_name>
<arguments>
{
"query": "how do quantum computers work",
"instructions": "explain in simple terms"
}
</arguments>
</use_mcp_tool>연구
<use_mcp_tool>
<server_name>youcom-mcp</server_name>
<tool_name>research</tool_name>
<arguments>
{
"query": "effects of climate change on ocean ecosystems",
"instructions": "focus on coral reefs"
}
</arguments>
</use_mcp_tool>뉴스 검색
<use_mcp_tool>
<server_name>youcom-mcp</server_name>
<tool_name>news_search</tool_name>
<arguments>
{
"query": "latest developments in AI"
}
</arguments>
</use_mcp_tool>기여하다
기여를 환영합니다! 풀 리퀘스트를 제출해 주세요.
특허
MIT
감사의 말
이 프로젝트에서는 검색 기능을 위해 You.com API를 사용합니다.
Available Tools
4 toolsnews_searchD
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The news query to send to You.com's News API |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
researchD
| Name | Required | Description | Default |
|---|---|---|---|
| instructions | No | Custom instructions for tailoring the response (optional) | |
| query | Yes | The research query to send to You.com's Research API |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
smart_searchD
| Name | Required | Description | Default |
|---|---|---|---|
| conversationId | No | A hex UUID to maintain conversation continuity (optional) | |
| instructions | No | Custom instructions for tailoring the response (optional) | |
| query | Yes | The query to send to You.com's Smart API |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
web_searchD
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query to send to You.com |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
v1.0.0- First observed
news_search - First observed
research - First observed
smart_search - First observed
web_search
TDQS
Scored across 4 tools
The tools are highly ambiguous with overlapping purposes, as all four tools appear to perform search-related functions without clear distinctions. Without descriptions, it's impossible to differentiate between 'news_search', 'research', 'smart_search', and 'web_search', making them effectively indistinguishable for an agent.
The naming shows mixed conventions: 'news_search' and 'web_search' follow a consistent noun_verb pattern, but 'research' and 'smart_search' deviate with different structures. While readable, the inconsistency in verb usage and pattern reduces predictability across the set.
With 4 tools, the count is borderline for a search-focused server, as it feels thin but not unreasonable. However, the lack of descriptions makes it hard to assess if this number adequately covers the domain, suggesting potential under-scoping or redundancy.
Inferred as a search server, there are significant gaps in coverage, such as missing filtering, sorting, or result management tools. The surface is severely incomplete for a robust search domain, likely causing agent failures due to limited operational capabilities.
Maintenance
Related MCP Connectors
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
MCP server giving Claude AI access to 22+ NYC public-record databases for real estate due diligence
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Related MCP Servers
- AlicenseBqualityDmaintenanceAn MCP server that provides access to Jina AI's powerful web services (page reading, web search, fact checking) through Claude.378 npm28MIT

Kagi MCP Serverofficial
AlicenseAqualityDmaintenanceAn MCP server that integrates Kagi search capabilities with Claude AI, enabling Claude to perform real-time web searches when answering questions that require up-to-date information.2533MIT- AlicenseAqualityDmaintenanceAn MCP server that enables Claude to perform web searches using Perplexity's API with intelligent model selection based on query intent and support for domain and recency filtering.64MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that integrates with Sonar API to provide Claude with real-time web search capabilities for comprehensive research.7 npmMIT