Enables web search capabilities via Kagi Search API and content summarization of documents, videos, and audio using Kagi Summarizer API
Click on "Deploy 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., "@Kagi MCP search for recent developments in quantum computing"
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 Node.js implementation of the Kagi Model Context Protocol (MCP) server. This provides a more stable alternative to the official Python implementation, especially when running multiple instances.
Search web content using Kagi Search API
Summarize documents, videos, and audio using Kagi Summarizer API
No port conflicts when running multiple instances
Full compatibility with Claude Desktop
Related MCP server: MCP Web Research Server
Node.js 18 or higher
Kagi API key (request from support@kagi.com)
Note: The Search API is in closed beta. You may need to request access separately.
No installation needed! Claude Desktop can run the package directly using npx.
npm install -g kagi-mcpOr use it directly with npx:
npx kagi-mcpnpm install -g github:yuki-yano/kagi-mcpgit clone https://github.com/yuki-yano/kagi-mcp.git
cd kagi-mcp
npm install
npm run build
npm linkKAGI_API_KEY (required): Your Kagi API key
KAGI_SUMMARIZER_ENGINE (optional): Summarization engine - cecil (default), agnes, daphne, or muriel
Add the following to your Claude Desktop config file:
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"kagi": {
"command": "npx",
"args": ["kagi-mcp"],
"env": {
"KAGI_API_KEY": "your-kagi-api-key"
}
}
}
}This method automatically downloads and runs the latest version from npm without requiring manual installation.
{
"mcpServers": {
"kagi": {
"command": "kagi-mcp",
"env": {
"KAGI_API_KEY": "your-kagi-api-key"
}
}
}
}To use with Claude Code CLI, run the following command:
claude mcp add kagi -s user -e KAGI_API_KEY="your-kagi-api-key" -- npx kagi-mcpThis will:
Add the Kagi MCP server to your Claude Code configuration
Set it up at the user level (-s user)
Configure your API key as an environment variable
Use npx to automatically download and run the latest version from npm
You can also use the MCP inspector for debugging:
# Method 1: Using npx (requires npm package to be published)
KAGI_API_KEY="your-kagi-api-key" npx @modelcontextprotocol/inspector npx kagi-mcp
# Method 2: Using local installation (more reliable)
npm install -g kagi-mcp
KAGI_API_KEY="your-kagi-api-key" npx @modelcontextprotocol/inspector kagi-mcp
# Method 3: Using source build
KAGI_API_KEY="your-kagi-api-key" npx @modelcontextprotocol/inspector node dist/index.jsThe MCP server provides two tools:
Search the web using Kagi Search API.
{
"queries": ["array of search queries"]
}Summarize content from a URL.
{
"url": "https://example.com/article",
"summary_type": "summary" | "takeaway", // optional
"target_language": "EN" // optional
}# Install dependencies
npm install
# Run in development mode
npm run dev
# Build
npm run build
# Run built version
npm startThis error indicates that your API key is invalid or not properly formatted. Make sure:
You have a valid Kagi API key from support@kagi.com
The key is correctly set in your environment variable
You're not adding extra quotes or spaces around the key
The Search API is in closed beta. You may need to:
Request access to the Search API separately from support@kagi.com
Ensure your API key has the necessary permissions
You can test your API key using the included test script:
KAGI_API_KEY="your-api-key" node test-api.jsMIT
Fetch web results based on one or more queries using the Kagi Search API. Use for general search and when the user explicitly tells you to 'fetch' results/information. Results are from all queries given. They are numbered continuously, so that a user may be able to refer to a result by a specific number.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | One or more concise, keyword-focused search queries. Include essential context within each query for standalone use. |
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 explains that 'Results are from all queries given' and 'They are numbered continuously, so that a user may be able to refer to a result by a specific number,' which adds useful context about result aggregation and numbering. However, it doesn't cover important behavioral aspects like rate limits, authentication needs, pagination, or error handling, leaving significant gaps.
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 appropriately concise with three sentences that each serve a distinct purpose: stating the tool's function, providing usage guidelines, and explaining result formatting. It's front-loaded with the core purpose. A slight improvement could be made by combining the last two sentences for even tighter structure.
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 tool's moderate complexity (search API with result aggregation), no annotations, and no output schema, the description provides adequate but incomplete context. It covers the basic purpose, usage triggers, and result numbering, but lacks details about return format, error cases, rate limits, or how results from multiple queries are integrated. This is minimally viable but has clear gaps.
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 input schema has 100% description coverage, with the 'queries' parameter well-documented in the schema itself. The description doesn't add any meaningful parameter semantics beyond what's already in the schema description ('One or more concise, keyword-focused search queries'). This meets the baseline of 3 when schema coverage is high.
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: 'Fetch web results based on one or more queries using the Kagi Search API.' It specifies the verb ('fetch'), resource ('web results'), and method ('Kagi Search API'). However, it doesn't explicitly differentiate from its sibling tool 'kagi_summarizer' beyond the general search focus, which prevents a perfect score.
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 clear usage context: 'Use for general search and when the user explicitly tells you to 'fetch' results/information.' This gives practical guidance on when to invoke the tool. It doesn't explicitly state when NOT to use it or mention alternatives like the sibling summarizer tool, which keeps it from a score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize content from a URL using the Kagi Summarizer API. The Summarizer can summarize any document type (text webpage, video, audio, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| summary_type | No | Type of summary to produce. Options are 'summary' for paragraph prose and 'takeaway' for a bulleted list of key points. | summary |
| target_language | No | Desired output language using language codes (e.g., 'EN' for English). If not specified, the document's original language influences the output. | |
| url | Yes | A URL to a document to summarize. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the API and document type support, but fails to disclose critical behavioral traits such as rate limits, authentication requirements, error handling, or what the output looks like (e.g., format, length). For a tool with no annotations, this leaves significant gaps in understanding its operation.
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 appropriately sized and front-loaded: two concise sentences that directly state the tool's function and capabilities without unnecessary details. Every sentence earns its place by providing essential information about the tool's purpose and scope.
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 of a summarization tool with no annotations and no output schema, the description is incomplete. It lacks information on output format, error conditions, performance characteristics, and integration details. The description does not compensate for the absence of structured data, leaving the agent with insufficient context for reliable use.
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 three parameters thoroughly. The description adds no additional parameter semantics beyond what the schema provides (e.g., no examples, edge cases, or usage tips). According to the rules, with high schema coverage, the baseline is 3 even with no param info in the 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?
The description clearly states the tool's purpose: 'Summarize content from a URL using the Kagi Summarizer API' with a specific verb ('summarize') and resource ('content from a URL'). It distinguishes from the sibling tool 'kagi_search_fetch' by focusing on summarization rather than search/fetch operations. However, it doesn't explicitly differentiate the API from other summarization tools beyond mentioning Kagi.
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 some implied usage context by stating it can 'summarize any document type (text webpage, video, audio, etc.)', which suggests when to use it (for diverse content types). However, it lacks explicit guidance on when to use this tool versus alternatives, prerequisites, or exclusions. No comparison with the sibling tool 'kagi_search_fetch' is provided.
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.
v1.0.0kagi_search_fetchkagi_summarizerScored across 2 tools
The two tools have clearly distinct purposes: one is for fetching search results from queries, and the other is for summarizing content from URLs. There is no overlap in functionality, making it easy for an agent to choose the right tool based on the task.
Both tools follow a consistent naming pattern with the prefix 'kagi_' followed by a descriptive verb_noun format (search_fetch and summarizer). This consistency aids in predictability and readability.
With only 2 tools, the server feels thin for a search and summarization domain, as it lacks operations like advanced search filtering, result management, or summarization customization. This minimal set may limit agent workflows.
The server covers basic search and summarization but has significant gaps: no tools for updating or deleting search results, handling search history, or managing summarization settings. This incompleteness could lead to agent failures in more complex scenarios.
A Model Context Protocol server for Wix AI tools
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Docs: https://docs.keenable.ai/mcp-server Keenable is a free, remote MCP server that gives agents access to the web index. Search the web with ranked results and date/site filters, then fetch any indexed page as clean markdown. Works out of the box with no account or API key.
Zotero MCP server for Claude and ChatGPT: search, citations, safe writes, PDF passages and pages.