Valyuの知識検索およびフィードバックAPIへのアクセスを提供するモデルコンテキストプロトコルサーバー。このサーバーにより、LLMは独自の情報源やWebソースから情報を検索し、取引に関するフィードバックを送信できます。
knowledge - 独自の情報源やウェブソースを検索して情報を探す
必要な引数:
query （文字列）: 検索する質問またはトピック
search_type (文字列): 検索するソースの種類 ("独自"、"Web"、または "すべて")
max_price (数値): 1000クエリあたりの最大許容価格 (CPM)
オプションの引数:
data_sources (string[]): 検索するインデックス名のリスト
max_num_results (整数): 再ランク付け後に返される結果の数
similarity_threshold (数値): 含まれる結果の最小類似度スコア
query_rewrite (boolean): パフォーマンス向上のためにクエリを書き換えるかどうか
feedback - 取引に関するユーザーフィードバックを送信する
必要な引数:
tx_id (文字列): フィードバックを提供するトランザクションID
feedback (文字列): ユーザーフィードバックテキスト
sentiment （文字列）：感情評価（「とても良い」、「良い」、「悪い」、「非常に悪い」）
docker pull ghcr.io/tiovikram/valyu-mcp-server
docker run -i --rm -e VALYU_API_KEY=your-api-key ghcr.io/tiovikram/valyu-mcp-serverRelated 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
