The Valyu MCP Server enables:
Knowledge Retrieval: Search proprietary and web sources using customizable queries with filters like max price, data sources, and similarity thresholds
Feedback Submission: Submit user feedback and sentiment ratings for specific transactions
Searches arXiv's research papers repository through the Valyu knowledge API, allowing users to retrieve academic research content.
Provides Docker container deployment for the Valyu MCP server, allowing users to run the server in an isolated environment.
Enables querying Wikipedia content through the Valyu knowledge API, providing access to general knowledge information.
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., "@Valyu MCP Server search for recent developments in quantum computing with a max price of $0.50 per thousand queries"
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.
A Model Context Protocol server that provides access to Valyu's knowledge retrieval and feedback APIs. This server enables LLMs to search proprietary and web sources for information and submit feedback on transactions.
knowledge - Search proprietary and/or web sources for information
Required arguments:
query (string): The question or topic to search for
search_type (string): Type of sources to search ("proprietary", "web", or "all")
max_price (number): Maximum allowed price per thousand queries (CPM)
Optional arguments:
data_sources (string[]): List of index names to search over
max_num_results (integer): Number of results returned after reranking
similarity_threshold (number): Minimum similarity score for included results
query_rewrite (boolean): Whether to rewrite the query for better performance
feedback - Submit user feedback for a transaction
Required arguments:
tx_id (string): Transaction ID to provide feedback for
feedback (string): User feedback text
sentiment (string): Sentiment rating ("very good", "good", "bad", "very bad")
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 (required): Your Valyu API key
Add to your Claude settings:
"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>"
}
}
}Knowledge search:
{
"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
}
}Submit feedback:
{
"name": "feedback",
"arguments": {
"tx_id": "12345abcdef",
"feedback": "The information was very helpful and accurate.",
"sentiment": "very good"
}
}You can use the MCP inspector to debug the server:
npx @modelcontextprotocol/inspector node dist/index.js"Can you search for information about artificial intelligence in medicine?"
"I'd like to learn about sustainable energy solutions. Can you search for that?"
"Please help me submit feedback for my transaction with ID TX123456."
"Find me the latest research on climate change adaptation strategies."
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
