Kagi MCP Server
OfficialKagi MCPサーバー
セットアップ手順
検索以外のツールのみを使用する場合を除き、作業を開始する前に検索APIへのアクセス権があることを確認してください。現在クローズドベータ版であり、リクエストベースで提供されています。招待をご希望の方は support@kagi.com までご連絡ください。
まず uv をインストールしてください。
MacOS/Linux:
curl -LsSf https://astral.sh/uv/install.sh | shWindows:
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"Smithery経由でのインストール
または、Smithery を使用してClaude Desktop用のKagiをインストールすることもできます:
npx -y @smithery/cli install kagimcp --client claudeOpenAIでのセットアップ
Codex CLI
codex cli にKagi MCPサーバーを追加するには、以下のコマンドを使用する必要があります:
codex mcp add kagi --env KAGI_API_KEY=<YOUR_API_KEY_HERE> -- uvx kagimcpこれにより設定が ~/.codex/config.toml に書き込まれます。APIキーの更新やローテーションが必要な場合は、再度 codex を実行する前にそこでキーを更新してください。
Codex CLIには独自の組み込み検索(--search フラグ)が付属していますが、デフォルトでは無効になっています。検索とKagiの競合を避けるため、有効にしないでください。
Claudeでのセットアップ
Claude Desktop
// claude_desktop_config.json
// Can find location through:
// Hamburger Menu -> File -> Settings -> Developer -> Edit Config
{
"mcpServers": {
"kagi": {
"command": "uvx",
"args": ["kagimcp"],
"env": {
"KAGI_API_KEY": "YOUR_API_KEY_HERE",
"KAGI_SUMMARIZER_ENGINE": "YOUR_ENGINE_CHOICE_HERE" // Defaults to "cecil" engine if env var not present
}
}
}
}Claude Code
以下のコマンドでKagi MCPサーバーを追加します(要約エンジンの設定はオプションです):
claude mcp add kagi -e KAGI_API_KEY="YOUR_API_KEY_HERE" KAGI_SUMMARIZER_ENGINE="YOUR_ENGINE_CHOICE_HERE" -- uvx kagimcpこれでClaude CodeがKagi MCPサーバーを使用できるようになります。ただし、Claude Codeにはデフォルトで独自のウェブ検索機能が付属しており、Kagiと競合する可能性があります。Claude Codeの設定ファイル (~/.claude/settings.json) に以下を記述することで、Claudeのウェブ検索機能を無効にできます:
{
"permissions": {
"deny": [
"WebSearch"
]
}
}ツールの使用が必要なクエリの実行
e.g. 検索の場合は「Who was time's 2024 person of the year?」、要約の場合は「summarize this video: https://www.youtube.com/watch?v=jNQXAC9IVRw」など。
デバッグ
実行:
npx @modelcontextprotocol/inspector uvx kagimcpRelated MCP server: sysauto Ask MCP Server
ローカル/開発環境のセットアップ手順
リポジトリのクローン
git clone https://github.com/kagisearch/kagimcp.git
依存関係のインストール
まず uv をインストールしてください。
MacOS/Linux:
curl -LsSf https://astral.sh/uv/install.sh | shWindows:
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"次に、MCPサーバーの依存関係をインストールします:
cd kagimcp
# Create virtual environment and activate it
uv venv
source .venv/bin/activate # MacOS/Linux
# OR
.venv/Scripts/activate # Windows
# Install dependencies
uv syncClaude Desktopでのセットアップ
MCP CLI SDKを使用する場合
# `pip install mcp[cli]` if you haven't
mcp install /ABSOLUTE/PATH/TO/PARENT/FOLDER/kagimcp/src/kagimcp/server.py -v "KAGI_API_KEY=API_KEY_HERE"手動で行う場合
# claude_desktop_config.json
# Can find location through:
# Hamburger Menu -> File -> Settings -> Developer -> Edit Config
{
"mcpServers": {
"kagi": {
"command": "uv",
"args": [
"--directory",
"/ABSOLUTE/PATH/TO/PARENT/FOLDER/kagimcp",
"run",
"kagimcp"
],
"env": {
"KAGI_API_KEY": "YOUR_API_KEY_HERE",
"KAGI_SUMMARIZER_ENGINE": "YOUR_ENGINE_CHOICE_HERE" // Defaults to "cecil" engine if env var not present
}
}
}
}ツールの使用が必要なクエリの実行
e.g. 検索の場合は「Who was time's 2024 person of the year?」、要約の場合は「summarize this video: https://www.youtube.com/watch?v=jNQXAC9IVRw」など。
デバッグ
実行:
# If mcp cli installed (`pip install mcp[cli]`)
mcp dev /ABSOLUTE/PATH/TO/PARENT/FOLDER/kagimcp/src/kagimcp/server.py
# If not
npx @modelcontextprotocol/inspector \
uv \
--directory /ABSOLUTE/PATH/TO/PARENT/FOLDER/kagimcp \
run \
kagimcpその後、http://localhost:5173 でMCP Inspectorにアクセスします。Inspectorの環境変数 KAGI_API_KEY にKagi APIキーを追加する必要がある場合があります。
高度な設定
ログレベルは環境変数
FASTMCP_LOG_LEVELで調整可能です(例:FASTMCP_LOG_LEVEL="ERROR")要約エンジンは環境変数
KAGI_SUMMARIZER_ENGINEを使用してカスタマイズできます(例:KAGI_SUMMARIZER_ENGINE="daphne")各要約エンジンの詳細についてはこちらを参照してください
MCPへの接続には、より安全な方法が存在する可能性があります。ユーザーが詳細をこちらにまとめています
--httpCLIオプションを使用して、ストリーム可能なHTTPトランスポートを有効にできます。--portおよび--host引数と一緒に使用可能です。
Available Tools
2 toolskagi_extractA
Extract the content of a web page as markdown using the Kagi Extract API. Use this to read the full content of a page when needed.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The HTTPS URL of the page to extract content from. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. Only states core behavior without additional context like rate limits, authorization, or side effects. Adequate for a simple read 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?
Two sentences, no fluff, front-loaded with purpose. Every sentence earns its place.
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?
Low complexity with one parameter and existing output schema. Description covers what it does and when to use it, but could mention potential errors or prerequisites for full completeness.
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 coverage is 100% and describes the only parameter (url). Description adds no extra meaning beyond the schema, so baseline 3 applies.
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?
Clearly states the action (extract content), resource (web page), output format (markdown), and API. Distinguishes from sibling tool by focusing on content extraction.
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?
Explicitly says 'Use this to read the full content of a page when needed,' providing clear context. Does not explicitly exclude alternatives, but sibling name implies separation of concerns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kagi_search_fetchA
Fetch web results for a query using the Kagi Search API. Use for general search and when the user explicitly tells you to 'fetch' results/information. Results are numbered so that a user may refer to a result by a specific number.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Only include results published/updated on or after this date (ISO format, e.g., '2024-01-15'). | |
| limit | No | Maximum number of results per category. In the mixed 'search' workflow this caps each category independently, so the total can exceed this number; in single-category workflows it caps total results. | |
| query | Yes | A concise, keyword-focused search query. Include essential context for standalone use. | |
| before | No | Only include results published/updated on or before this date (ISO format, e.g., '2024-12-31'). | |
| lens_id | No | Apply a Kagi lens to narrow the search to a curated set of sources. Built-in lens IDs: '2' (Academic — education/.edu domains), '1' (Forums — discussion forums across the web), '15' (Programming — official programming language sites and forums), '29' (News 360 — multi-perspective coverage of global news), '120' (Recipes — high-quality recipe sites, English), '107' (Small Web — noncommercial domains and topics). You may also pass a custom lens ID or full URL from https://kagi.com/settings/lenses (only shareable lenses work). Mutually exclusive with 'include_domains', 'exclude_domains', 'time_relative', and 'file_type'; use those args or 'lens_id', not both. | |
| workflow | No | Type of results to return. Use 'news' for current events and recent reporting, 'videos' for video content (e.g. tutorials, talks), 'podcasts' for audio shows, 'images' for image results, or the default 'search' for general web results. Note that 'search' may return a mix of categories (web, news, videos, images) in one response, like a typical SERP; the other workflows return only their single category. | search |
| file_type | No | Restrict to results with this file type (e.g., 'pdf', 'docx', 'xlsx'). Specify the extension without a leading dot. | |
| extract_count | No | Number of top results to fetch full page content for, inline as markdown. | |
| time_relative | No | Restrict to results published/updated within the last day, week, or month, evaluated server-side. Mutually exclusive with 'after'/'before'. | |
| exclude_domains | No | Exclude results from these domains (e.g., ['pinterest.com', 'quora.com']). Overrides any 'site:' operators in the query. | |
| include_domains | No | Restrict results to these domains (e.g., ['docs.python.org', 'github.com']). Overrides any 'site:' operators in the query. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds one behavioral trait: 'Results are numbered so that a user may refer to a result by a specific number.' With no annotations provided, the description carries the full burden, but it does not disclose other behaviors like rate limits, authentication needs, or error handling.
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 extremely concise with two sentences, front-loading the core purpose and adding essential usage guidance and a behavioral trait without any fluff.
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 complexity (11 parameters, output schema exists, sibling tool present), the description is mostly complete. It explains the tool's purpose and numbering, but could mention that results include standard fields (title, URL) though the output schema likely covers that.
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 baseline is 3. The description does not add any parameter-level information beyond what is already in the schema; it merely states the overall purpose.
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 'Fetch web results for a query using the Kagi Search API', which specifies the verb and resource. It further distinguishes usage for general search and when the user explicitly says 'fetch', helping differentiate from sibling kagi_extract (which likely extracts content from a URL).
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.' It implies when to use it but does not explicitly exclude alternative tools like kagi_extract or list when not to use it.
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.
2 tool updates
v1.0.1- First observed
kagi_extract - First observed
kagi_search_fetch
TDQS
Scored across 2 tools
Each tool has a clearly distinct purpose: one extracts page content, the other fetches search results. There is no overlap or ambiguity between them.
Both tools follow a consistent 'kagi_' prefix combined with a verb_noun pattern ('extract' and 'search_fetch'), making naming predictable and clear.
With only two tools, the set is minimal but still covers the core search and extract functionalities. However, it feels thin compared to typical MCP servers, which might offer more diverse operations.
The server provides the essential operations for its domain: searching and retrieving content. While additional tools like summarization could be useful, the current set is reasonably complete for basic tasks.
Maintenance
Related MCP Connectors
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
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
Related MCP Servers
- 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
- AlicenseDqualityFmaintenanceMCP server that provides Claude AI assistants with the ability to search the web, get news, and perform research using the You.com API.42MIT
- AlicenseCqualityDmaintenanceMCP server integrating the Kagi Search API to perform web searches using the kagi_search tool.1MIT