kagi-session2api-mcp
Kagi Session2API MCPサーバー
無料のKagi検索MCP(Model Context Protocol)サーバーです。公式APIキーを必要とせず、セッショントークンを使用してKagi検索と要約機能にアクセスできます。Claude Desktop、Cursor、Windsurf、Cline、Hermes、およびMCP互換のAIコーディングアシスタントやエージェントで動作します。
⚠️ エンドユーザーへの警告: このプロジェクトは、公式の有料APIを使用せずに検索および要約機能にアクセスするためにKagiセッショントークンを使用します。これはKagiの利用規約に違反する可能性があります。アカウントの停止や永久追放などの結果を招く恐れがあります。自己責任で使用してください。 著者は、Kagiによって取られたいかなるアカウント措置に対しても責任を負いません。
⚠️ セキュリティ警告: Kagiセッショントークンはアカウントへのフルアクセス権を提供します。パスワードのように扱ってください。決して共有したり、バージョン管理システムにコミットしたりしないでください。
機能
セッションベースのアクセス: 公式API($25/1000クエリ)の代わりにKagiセッショントークンを使用するため、完全に無料です。
マルチトークンプール: 複数のトークンを設定してラウンドロビン方式でローテーションさせることで、スループットを向上させます。
トークンごとのレート制限: トークンバケットアルゴリズムにより、トークンあたり5リクエスト/秒に制限されます。
API互換の出力: 公式の
kagimcpと同じ形式で結果を返します。2つのツール:
kagi_search_fetch(ウェブ検索)およびkagi_summarizer(URL要約)Firefox UAスプーフィング: セッションベースのアクセスのために、本物のFirefoxブラウザを模倣します。
期限切れトークンの自動無効化: 期限切れのトークンは自動的に検出され、スキップされます。
検索演算子: Kagiの演算子(
site:,lang:,filetype:など)をサポートしています。
Related MCP server: Kagi MCP Server
対応プラットフォーム
MCP互換のあらゆるクライアントで動作します:
stdioまたはHTTPトランスポートをサポートするすべてのMCPクライアント
クイックインストール(AIエージェント向け)
AIエージェントに以下のプロンプトを貼り付けてください:
Install the Kagi Session2API MCP server from https://pypi.org/project/kagi-session2api-mcp/.
Then add it to my MCP:
`uvx kagi-session2api-mcp`
set env KAGI_SESSION_TOKEN to my token (ask me if you don't have it).
If I have multiple tokens, use KAGI_SESSION_TOKENS (comma-separated) instead,
or create a config file at ~/.config/kagi-session2api-mcp/config.toml with:
[kagi]
session_tokens = ["TOKEN_1", "TOKEN_2"]
summarizer_engine = "cecil"
[client]
timeout = 30
max_retries = 2
and set env KAGI_SESSION_CONFIG to that path.手動インストール
pip install kagi-session2api-mcpまたは uvx を使用する場合:
uvx kagi-session2api-mcp設定
オプション1: 環境変数(単一トークン)
{
"mcpServers": {
"kagi-session": {
"command": "uvx",
"args": ["kagi-session2api-mcp"],
"env": {
"KAGI_SESSION_TOKEN": "YOUR_SESSION_TOKEN_HERE"
}
}
}
}オプション2: 環境変数(複数トークン)
{
"mcpServers": {
"kagi-session": {
"command": "uvx",
"args": ["kagi-session2api-mcp"],
"env": {
"KAGI_SESSION_TOKENS": "TOKEN_1,TOKEN_2,TOKEN_3"
}
}
}
}オプション3: 設定ファイル(マルチトークンに推奨)
~/.config/kagi-session2api-mcp/config.toml を作成します:
[kagi]
session_tokens = [
"YOUR_TOKEN_1_HERE",
"YOUR_TOKEN_2_HERE",
]
summarizer_engine = "cecil"
[client]
timeout = 30
max_retries = 2次に設定します:
{
"mcpServers": {
"kagi-session": {
"command": "uvx",
"args": ["kagi-session2api-mcp"],
"env": {
"KAGI_SESSION_CONFIG": "/path/to/config.toml"
}
}
}
}セッショントークンの取得方法
kagi.com にログインします。
Settings → Account → Session Link に移動します。
セッションURLからトークンをコピーします:
https://kagi.com/search?token={THIS_PART}&q=testこのトークンを設定で使用します。
使用方法
MCPツール
kagi_search_fetch
Kagiを使用してウェブ検索を行います:
Search for "Python async tutorial"Kagiの検索演算子をサポートしています:
site:github.com- ドメインを制限-site:reddit.com- ドメインを除外filetype:pdf- ファイルタイプでフィルタリングintitle:python- タイトルでフィルタリングlang:zh- 言語でフィルタリングbefore:2024-01-01/after:2024-01-01- 日付でフィルタリング"exact phrase"- 完全一致
kagi_summarizer
URLを要約します:
Summarize https://example.com/articleオプション:
summary_type: "summary"(文章)または "takeaway"(箇条書き)engine: "cecil"(デフォルト)、"agnes"、"daphne"、"muriel"target_language: 言語コード(例: "EN")
⚠️ 要約機能は実験的なものであり、変更される可能性のあるKagiの内部エンドポイントを使用しています。
トランスポートモード
Stdio(デフォルト、Claude Desktop用):
kagi-session2api-mcpHTTP(リモートアクセス用):
kagi-session2api-mcp --http --host 0.0.0.0 --port 8000アーキテクチャ
MCP Client → FastMCP Server → TokenPool (round-robin) → httpx.AsyncClient → kagi.com
↓
TokenBucket (5 req/s per token)
↓
Auto-disable expired tokensトークンプールの動作
設定 | レート制限 | 実効レート |
1トークン | 5 req/s | 5 req/s |
2トークン | 各5 req/s | 10 req/s |
Nトークン | 各5 req/s | 5×N req/s |
トークンが期限切れになると(401/403エラーまたはログインページへのリダイレクトで検出)、自動的に無効化されます。残りのトークンは引き続きリクエストを処理します。
公式 kagimcp との違い
項目 | 公式 |
|
認証 | APIキー ($25/1000) | セッショントークン (無料) |
検索エンドポイント |
|
|
要約機能 |
|
|
レート制限 | サーバー側 | クライアント側 (トークンバケット) |
| 残高を返す | 常に |
コスト | 有料 | 無料 (既存のセッションを使用) |
リスク
KagiがHTML構造を変更した場合、パーサーが動作しなくなる可能性があります。
セッションベースのアクセスはKagiの利用規約に違反する可能性があります。
アカウントの停止や永久追放の可能性があります。
要約エンドポイントは内部的なものであり、予告なく変更される可能性があります。
自己責任で使用してください。 著者は、Kagiによって取られたアカウント措置を含む(ただしこれに限定されない)いかなる結果に対しても責任を負いません。
ライセンス
MIT
Available Tools
2 toolskagi_search_fetchA
Fetch web results based on one or more queries using Kagi Search.
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. Supports Kagi operators: site:, -site:, filetype:/ext:, intitle:, inurl:, lang:, loc:, before:, after:, "exact phrase", +term, -term | |
| limit | No | Maximum number of results per query. Default: all available. |
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 the description carries the full burden. It mentions numbering and that results are from all queries, but fails to disclose other behavioral traits such as pagination, caching, or auth requirements.
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 concise, with three sentences that are front-loaded with purpose. Every sentence adds value without redundancy.
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 presence of an output schema, return values need not be explained. The description is adequate for basic usage, though it could mention rate limits or error handling for 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 the description adds meaning by specifying that queries should be concise and keyword-focused, with essential context. The limit parameter's default behavior is explained.
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 it fetches web results using Kagi Search, for general search and when the user explicitly asks to 'fetch'. It distinguishes from the sibling tool kagi_summarizer by focusing on search results rather than summaries.
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 explains when to use (general search, explicit fetch) and notes that results from all queries are numbered continuously. While it doesn't explicitly state when not to use, the sibling context implies summarization is separate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kagi_summarizerA
Summarize content from a URL using the Kagi Summarizer.
The Summarizer can summarize any document type (text webpage, video, audio, etc.)
Note: This tool uses Kagi's internal summarizer endpoint accessed via session token. This is experimental and may break if Kagi changes their internal API.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A URL to a document to summarize. | |
| 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. | |
| engine | No | Summarizer engine to use. 'cecil' is the default. Note: This is an experimental feature — the summarizer endpoint may change without notice. | cecil |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly states the experimental nature, potential breakage, and support for various content types. It does not detail error handling or rate limits, but the explicit warning about instability adds significant 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 concise and structured: a clear purpose statement, a brief capability note, and a critical caution. Each sentence serves a purpose, though the capability note could be integrated into the first sentence.
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 4 parameters and existing output schema (not shown), the description provides enough context to understand the tool's function and risks. However, it lacks guidance on error handling, prerequisites (e.g., need for a valid session token), and typical usage scenarios, which would enhance 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?
The input schema has 100% description coverage, so the baseline is 3. The description adds limited value, only restating the summary_type and engine options in a mildly explanatory way. It does not introduce new meaning beyond the schema's own 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 clearly states the tool summarizes content from a URL using Kagi Summarizer, including support for various document types. It distinguishes from the sibling tool (kagi_search_fetch) by focusing on summarization rather than search, though no explicit comparison is made.
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 warns that the tool is experimental and may break due to internal API changes, which provides important context. However, it does not specify when to use this tool over alternatives or when not to use it, leaving the agent to infer from the sibling tool's purpose.
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
v0.2.1- First observed
kagi_search_fetch - First observed
kagi_summarizer
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: one fetches search results, the other summarizes content from URLs. There is no overlap or ambiguity in their functionality.
Both tools follow a consistent verb_noun pattern with the 'kagi_' prefix ('kagi_search_fetch', 'kagi_summarizer'), making the naming predictable and understandable.
With only 2 tools, the server feels minimal but still reasonable for its narrow focus on Kagi search and summarizer APIs. The experimental nature of the summarizer tool might warrant additional tools in the future.
The tool surface covers the two core operations of the Kagi API: search and summarization. While there are no additional utilities like listing or filtering, the basic workflow is supported without obvious dead ends.
Maintenance
Related MCP Connectors
Free web search for AI agents. No API key required. Hosted MCP in active development.
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.
MCP server for Firecrawl — web search, scraping, and biomedical/arXiv paper search.
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Related MCP Servers
- AlicenseAqualityCmaintenanceUnofficial MCP server for working with Kagi without API access (you'll need to be a customer, tho). Searches and summarizes. Uses Kagi session token for easy authentication.242MIT
- AlicenseNot gradedqualityDmaintenanceEnables integration with Kagi search engine services including web search, content summarization from URLs, and AI assistant conversations. Uses session tokens to access Kagi's search API, summarizer, and AI models directly within MCP-compatible applications.8 npm3MIT
- AlicenseNot gradedqualityDmaintenanceFree web search MCP server using SearXNG, supporting web search, news search, and search summaries.MIT
- AlicenseAqualityBmaintenanceMCP server for Kagi Search that uses your session token for web and news search without a separate API subscription.327 npmMIT