Provides tools for querying and searching arXiv papers (and Hacker News discussions) via SQL and full-text search, with live data refresh.
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., "@research-mcp-lab Find recent arXiv papers about machine learning"
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.
Hacker News × arXiv を横断する research intelligence エージェントの MCP サーバ。 自然文の問いを SQL / 全文検索に変換し、根拠（実行した SQL・検索ヒット）つきで答える。
MCP サーバ（Model Context Protocol）— Claude Code 等の AI クライアントから「道具」として呼べる。
DuckDB + FTS — HN/arXiv のメタデータを列指向 DB に格納し、BM25 で全文検索。
根拠を返す — どのツールを・どんな SQL / 検索で答えたかを併記する。
ライブ取得（スクレイピング） — refresh_data で最新の HN×arXiv を取得し、別ストア（data/live/）に保存。凍結スナップショット（data/snapshot/）は再現性のため不変。
Related MCP server: nl2sql-mcp
ツール | 役割 |
| テーブル/列の意味・FTS 対象を返す（AI が SQL/検索の前に読む） |
| 読み取り専用 SQL を実行し表形式で返す（＝根拠 SQL） |
| BM25 全文検索（ |
| HN×arXiv を取得して live ストアを更新（スクレイピング） |
live=True を付けると refresh_data 後の最新データに対して問い合わせる。
既定（live=False）は凍結スナップショット＝再現可能な基準データを見る。
uv sync --dev
# 凍結スナップショット(data/snapshot/*.csv)から DuckDB を構築
PYTHONPATH=src uv run python -c "from research_mcp.data import build_db; build_db()"
uv run pytest
# MCP サーバを stdio 起動
PYTHONPATH=src uv run python -m research_mcpclaude mcp add research-intelligence -s user \
-e PYTHONPATH="$PWD/src" \
-- uv run --directory "$PWD" python -m research_mcpdata/snapshot/*.csv — HN/arXiv の凍結スナップショット（公開データ）。eval / デモの再現性の基準。
data/live/ — refresh_data が再生成（.gitignore 済み）。
Hacker News API（Firebase）— https://hacker-news.firebaseio.com/v0/
arXiv API（Atom）— http://export.arxiv.org/api/query
src/research_mcp/
sources.py # HN/arXiv 取得・arxiv_id 抽出・サニタイズ・build_snapshot
data.py # スナップショット→DuckDB、メタデータ層、FTS、接続
server.py # MCP ツール(get_schema / run_sql / search_text / refresh_data)
__main__.py # `python -m research_mcp` で stdio 起動
tests/ # pytest（取得の純関数・MCP ツール・live ルーティング）テーブル/列の意味・FTS 対象を返す。AI が SQL/検索の前に読む。
live=True で refresh_data 後の最新データ(live ストア)のスキーマを見る。
| Name | Required | Description | Default |
|---|---|---|---|
| live | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains what is returned and the live-store behavior, and the verbs '返す' and '見る' imply a read-only operation. However, it does not explicitly state whether the operation has side effects or what happens when live=True is used before refresh_data.
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 very short and front-loaded: the first sentence states purpose and usage timing, the second clarifies the optional parameter. Every sentence earns its place with no 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?
For a single-optional-parameter tool with an output schema present, the description covers purpose, timing, and the live parameter's relationship to refresh_data. Nothing critical is missing for an agent to call it correctly.
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 only provides a default for live with no description, so the description must add meaning. It explains that live=True shows the latest schema after refresh_data, which is essential parameter context. It does not explicitly define live=False, but the default and contrast are inferable.
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 returns table/column meanings and FTS targets, with a specific intended use: reading before SQL or search. This distinguishes it from sibling tools like run_sql and search_text, which execute queries rather than describe schema.
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 explicitly says to read this before SQL/search operations, giving clear context for when it should be used. It also explains that live=True should be used after refresh_data to see the latest schema, but it does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
HN×ArXiv を今すぐ取得し、別の live ストア(data/live/)に保存する（スクレイピング）。
凍結スナップショット(data/snapshot=eval の基準)は変更しない。取得後は get_schema/run_sql/search_text に live=True を付けると最新データを検索できる。 top_n は HN topstories の取得上限（多いほど網羅的だが遅い）。
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It explicitly mentions scraping (external network access), saving to a live store without modifying the frozen snapshot, and the speed/comprehensiveness tradeoff of top_n. These are key behavioral traits for a refresh tool. It does not mention potential rate limits or error conditions, but the core side effects are well disclosed.
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 three short sentences, each earning its place: the first states the main action and target, the second explains side effects and subsequent usage with siblings, and the third defines the parameter. It is front-loaded with the primary action and avoids redundant phrasing. Slightly longer than strictly necessary but still efficient.
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?
For a refresh tool with one parameter, the description covers the main action, side effects (snapshot untouched), how to use the resulting data with siblings, and the parameter semantics. An output schema exists, so return value details are not needed. It does not mention error handling or network prerequisites, but these are minor for this tool's scope.
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%, so the description must explain the parameter. It does: 'top_n は HN topstories の取得上限（多いほど網羅的だが遅い）' explains that top_n is the upper limit for HN topstories, with more being comprehensive but slower. This adds meaningful meaning beyond the bare integer type and default value in the schema.
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 action (fetch HN×ArXiv and save to a separate live store), the resource (HN×ArXiv data), and the side effect (scraping). It distinguishes itself from the sibling query tools (get_schema, run_sql, search_text) by describing the refresh/scrape operation rather than a read-only query, so an agent can easily tell them apart.
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 concrete usage context: after running this tool, use live=True with get_schema/run_sql/search_text to search the latest data. This implies the tool should be used when fresh data is needed, but it does not explicitly state when not to use it (e.g., if the frozen snapshot is sufficient) or name alternatives directly. The guidance is clear but could be more explicit about exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
読み取り専用 SQL を実行し結果を表形式文字列で返す（＝根拠 SQL）。
live=True で refresh_data 後の最新データ(live ストア)に対して実行する。
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | ||
| live | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior; it does state the tool is read-only and returns a table-formatted string, and it explains the live parameter's effect. Yet it omits details on error handling, permissions, or any constraints beyond read-only, which is a notable gap for a SQL execution tool.
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 two concise sentences with no waste, front-loading the core purpose and then the live condition. Every sentence contributes essential information.
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 (SQL execution), the description covers the main behavior (read-only, return format, live store option) but lacks details on output schema specifics, potential errors, or usage limits. While an output schema exists and may mitigate some gaps, the description alone is not fully comprehensive for an agent to handle all edge cases.
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%, so the description must compensate. It clarifies the live parameter (using the live store after refresh_data) but offers no additional detail for the sql parameter beyond the tool's read-only nature, leaving its syntax, allowed statements, or limitations undocumented.
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 executes read-only SQL and returns a table-formatted string, using a specific verb ('実行する') and resource. It distinguishes itself from siblings by emphasizing the read-only nature, which separates it from get_schema, search_text, and refresh_data.
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 context for the live parameter, explaining that live=True operates on the latest data after refresh_data, which is a useful condition. However, it does not explicitly state when to choose this tool over siblings or provide exclusionary guidance, leaving the selection criteria implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FTS 全文検索。target は 'papers'(abstract) か 'comments'(text)。
BM25 スコア順にヒット行を返す（＝どの文書がヒットしたかの根拠）。 live=True で refresh_data 後の最新データ(live ストア)を検索する。
| Name | Required | Description | Default |
|---|---|---|---|
| live | No | ||
| query | Yes | ||
| target | No | papers |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses BM25 score ordering, explains that returned rows are evidence of which documents matched, and describes the live-store behavior. It does not state read-only/auth/rate details, but the search semantics are sufficiently transparent.
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?
Three compact sentences: the first states the core purpose, and the next two add ordering and live-store behavior. Every sentence earns its place with no 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?
For a three-parameter search tool with an output schema, the description covers target selection, live-store semantics, and result ordering. Minor omissions such as pagination or result limits do not prevent correct invocation.
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 compensates well by defining target values and the meaning of live. query is only implied by '全文検索', but it is the required parameter and its purpose is obvious from the tool name and context.
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 opens with 'FTS 全文検索' (full-text search) and specifies the two target corpora: 'papers' (abstract) and 'comments' (text). This clearly separates search_text from sibling tools like run_sql and get_schema.
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?
It explicitly states when to use live=True (after refresh_data, on the live store) and which target to choose. It does not explicitly say when not to use the tool or compare it to run_sql, but the usage context is otherwise clear.
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.
v0.1.0get_schemarefresh_datarun_sqlsearch_textScored across 4 tools
Each tool targets a clearly distinct operation: schema introspection, read-only SQL execution, full-text search, and data refresh. There is no meaningful overlap between any two tools.
All tool names follow the same verb_noun snake_case pattern: get_schema, run_sql, search_text, refresh_data. The naming is perfectly consistent and predictable.
Four tools is an appropriate scope for a research data exploration server. Each tool covers a necessary part of the workflow without redundancy.
The set covers schema discovery, SQL querying, full-text search, and live data refresh, which forms a complete research workflow. A minor gap is the lack of an explicit refresh status or provenance tool, but this can be worked around via queries.
MCP server for searching Airweave collections with natural language queries.
GibsonAI MCP server: manage your databases with natural language
Analytical memory for AI agents: a real Postgres queried in plain English over MCP. One command.
