Valyu의 지식 검색 및 피드백 API에 대한 액세스를 제공하는 모델 컨텍스트 프로토콜 서버입니다. 이 서버를 통해 LLM은 독점 및 웹 소스에서 정보를 검색하고 거래에 대한 피드백을 제출할 수 있습니다.
knowledge - 독점적이거나 웹 소스에서 정보를 검색합니다.
필수 인수:
query (문자열): 검색할 질문 또는 주제
search_type (문자열): 검색할 소스 유형("독점", "웹" 또는 "모두")
max_price (숫자): 1,000개 쿼리당 허용되는 최대 가격(CPM)
선택 인수:
data_sources (string[]): 검색할 인덱스 이름 목록
max_num_results (정수): 재순위 지정 후 반환되는 결과 수
similarity_threshold (숫자): 포함된 결과에 대한 최소 유사도 점수
query_rewrite (부울): 더 나은 성능을 위해 쿼리를 다시 작성할지 여부
feedback - 거래에 대한 사용자 피드백 제출
필수 인수:
tx_id (문자열): 피드백을 제공할 거래 ID
feedback (문자열): 사용자 피드백 텍스트
sentiment (문자열): 감정 평가("매우 좋음", "좋음", "나쁨", "매우 나쁨")
지엑스피1
Related MCP server: Rememberizer MCP Server
VALYU_API_KEY (필수): Valyu API 키
Claude 설정에 추가:
"mcpServers": {
"valyu": {
"command": "docker",
"args": ["run", "--pull", "--rm", "-i", "-e", "VALYU_API_KEY", "ghcr.io/tiovikram/valyu-mcp-server"],
"env": {
"VALYU_API_KEY": "<your-valyu-api-key>"
}
}
}지식 검색:
{
"name": "knowledge",
"arguments": {
"query": "What is quantum computing?",
"search_type": "all",
"max_price": 0.5,
"data_sources": ["valyu/valyu-arxiv", "valyu/valyu-wikipedia"],
"max_num_results": 5
}
}피드백 제출:
{
"name": "feedback",
"arguments": {
"tx_id": "12345abcdef",
"feedback": "The information was very helpful and accurate.",
"sentiment": "very good"
}
}MCP 검사기를 사용하여 서버를 디버깅할 수 있습니다.
npx @modelcontextprotocol/inspector node dist/index.js"의학 분야에서 인공지능에 대한 정보를 검색할 수 있나요?"
"지속 가능한 에너지 솔루션에 대해 알아보고 싶습니다. 검색해 주실 수 있나요?"
"ID TX123456으로 거래한 것에 대한 피드백을 제출하는 데 도움을 주세요."
"기후 변화 적응 전략에 대한 최신 연구 결과를 찾아보세요."
Submit user feedback and sentiment for a transaction.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_id | Yes | ||
| feedback | Yes | ||
| sentiment | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing side effects, return values, or required permissions. For a write operation, it lacks important behavioral 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 a single sentence with no unnecessary words. It is front-loaded with the action and resource, making it easy to parse.
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?
The tool is simple, but the description lacks information about outcomes, return values, or error conditions. With no annotations or output schema, this leaves critical gaps for an agent invoking the 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?
The schema has zero descriptions for parameters, so the description is the only semantic source. It names 'feedback' and 'sentiment' and implies 'tx_id' via 'transaction,' but provides no details on formats or constraints beyond the enum.
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 uses a specific verb 'submit' and clearly identifies the resource: 'user feedback and sentiment for a transaction.' This is unambiguous and distinct from the sibling tool 'knowledge,' which appears unrelated.
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?
There is no guidance on when to use this tool or when to prefer alternatives. It does not mention prerequisites, exclusions, or relationship to the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search proprietary and/or web sources for information based on the supplied query.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_price | Yes | ||
| search_type | Yes | ||
| data_sources | No | ||
| query_rewrite | No | ||
| max_num_results | No | ||
| similarity_threshold | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It discloses none: no mention of side effects, authorization needs, rate limits, result ranking, or how parameters like max_price or query_rewrite affect behavior. The only behavioral implication is that it performs a search, which is already in the purpose. This is a complete lack of 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 sentence with no filler or redundant phrasing, making it concise. It front-loads the core action ('Search') and then specifies the sources. No structural issues. However, it is so brief that it borders on under-specification, which prevents a perfect score.
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?
This tool has 7 parameters (3 required), no annotations, and no output schema. The description is too minimal to provide the necessary context. It doesn't cover the meaning of max_price, search_type, data_sources, query_rewrite, max_num_results, or similarity_threshold, nor does it hint at the return value or behavior. For such a complex tool, the description is critically incomplete.
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 0%, and the description does not mention or explain any of the seven parameters. It only references 'the supplied query' generically. None of the required parameters (query, search_type, max_price) or optional ones are given meaning beyond their raw schema definitions. Since there are many parameters, the description fails its obligation to compensate for the schema's lack of descriptions.
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 uses the specific verb 'search' and identifies the resources being searched ('proprietary and/or web sources'). It clearly distinguishes itself from the only sibling tool ('feedback'), which is unrelated. However, the object of the search is vague ('information'), so it's not fully specific about what the tool returns or for what use cases it's intended.
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?
There is no guidance on when to use this tool versus alternatives. The only sibling is 'feedback', which suggests no competing search tool exists, but the description still doesn't state prerequisites, typical use cases, or conditions where web vs proprietary search should be preferred. Without this context, an agent must infer usage entirely from the generic description.
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.
v1.0.0feedbackknowledgeThe two tools have completely distinct purposes: one searches for information, the other submits feedback. There is no ambiguity or overlap between them.
Both tools use a single noun as their name, which is consistent. However, they do not follow a verb-noun pattern, which might make the naming convention less predictable, but given the small set, it is clear and consistent.
With only 2 tools, the server feels borderline thin. It is minimal but not unreasonable for a focused utility, though it does not reach the well-scoped typical range of 3-15 tools.
The knowledge tool only provides search, lacking retrieval or listing capabilities, and the feedback tool only submits without any query or management functions. These are notable missing operations for a server that aims to cover knowledge and feedback domains.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/valyuAI/valyu-mcp-js'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
