Claude を使用して Hacker News の議論を要約するためのモデル コンテキスト プロトコル (MCP)。
このMCPは、Hacker Newsの議論を取得・処理し、クロードが高品質な要約を生成できる形式に整えます。コメントの階層構造とメタデータ（スコア、ダウン投票など）の両方を処理し、クロードが各コメントの相対的な重要性と関連性を理解するのに役立ちます。
Related MCP server: Hacker News MCP Server
Hacker NewsのURLまたは投稿IDを処理する
HNからコメント構造をダウンロードして分析する
コミュニティの関与に基づいてコメントにスコアを付ける
クロードの要約に最適化されたデータのフォーマット
Smithery経由で Claude Desktop 用の Hacker News Companion を自動的にインストールするには:
npx -y @smithery/cli install @georgeck/hn-companion-mcp --client claudeリポジトリをクローンします。
git clone https://github.com/yourusername/hn-companion-mcp.git
cd hn-companion-mcp依存関係をインストールします:
npm installnode index.js <post-id-or-url>例：
node index.js 43448075
# or
node index.js https://news.ycombinator.com/item?id=43448075サーバーを起動します。
npm startリクエストする:
curl -X POST http://localhost:3000/api/summarize \
-H "Content-Type: application/json" \
-d '{"input": "https://news.ycombinator.com/item?id=43448075"}'POST /api/summarizeリクエスト本文:
{
"input": "https://news.ycombinator.com/item?id=43448075"
}応答：
{
"status": "success",
"data": {
"systemPrompt": "...",
"userPrompt": "...",
"commentPathIdMapping": { ... },
"postTitle": "...",
"postId": "...",
"commentCount": 123
}
}このMCPは、クロードが要約するためのデータを準備するために設計されています。ユーザーがクロードにHacker Newsの議論を要約するように依頼すると、クロードはこのMCPを呼び出してフォーマットされたデータを取得し、システムとユーザーの指示に基づいて要約を生成します。
"hn-companion": {
"command": "node",
"args": ["<full path to src>/hn-companion-mcp/server.js"]
}
}マサチューセッツ工科大学
Retrieves and formats comments from a Hacker News discussion post for summarization by an LLM. Use the hacker_news_summarization_user_prompt prompts to generate a summary.
| Name | Required | Description | Default |
|---|---|---|---|
| post_url | Yes | The URL or ID for the Hacker News post to analyze. Can be a full URL (https://news.ycombinator.com/item?id=43456723) or just the numeric post ID e.g. 43456723. |
| Name | Required | Description |
|---|---|---|
| content | No | Contains the formatted comments ('formattedComments') and user prompt ('userPrompt') - Follow the instructions in the `userPrompt` on interpreting the formatted comments. |
| metadata | No | Contains post ID (postId), comment count (commentCount), and original post URL (postUrl). |
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 mentions formatting comments 'for summarization by an LLM,' which hints at preprocessing behavior, but fails to detail critical aspects like rate limits, authentication needs, error handling, or what 'formats' entails (e.g., structuring, truncation). This leaves significant gaps for a tool that interacts with external 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 concise and front-loaded, with the core purpose stated in the first sentence. The second sentence adds practical guidance without redundancy. However, it could be slightly more structured by separating usage notes, and the reference to external prompts might be considered extraneous if those are not tool-specific.
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 (single parameter, external data source), the description covers the basic purpose and usage context. The presence of an output schema means return values need not be explained, and the high schema coverage handles parameters. However, the lack of behavioral details (e.g., formatting specifics, error cases) prevents a perfect score, as annotations are absent.
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, thoroughly documenting the 'post_url' parameter. The description adds no additional parameter information beyond what the schema provides, such as examples or constraints. According to the rules, with high schema coverage, the baseline is 3, as the schema does the heavy lifting without description enhancement.
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: 'Retrieves and formats comments from a Hacker News discussion post for summarization by an LLM.' It specifies the verb ('retrieves and formats'), resource ('comments from a Hacker News discussion post'), and intended use ('for summarization by an LLM'). However, with no sibling tools mentioned, it cannot demonstrate differentiation from alternatives, preventing 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 implied usage guidance by stating the tool is 'for summarization by an LLM' and referencing 'hacker_news_summarization_user_prompt' prompts. However, it lacks explicit instructions on when to use this tool versus other methods (e.g., raw comment retrieval) or any exclusions (e.g., non-Hacker-News URLs). The guidance is helpful but not comprehensive.
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.
get_hn_post_formatted_commentsScored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is clearly distinct as it is the sole tool available.
Since there is only one tool, naming consistency is inherently perfect. The tool name follows a clear verb_noun pattern (get_hn_post_formatted_comments), which would be consistent if more tools existed.
A single tool is too few for a server named 'Hacker News Companion MCP', which suggests broader functionality. The tool only handles comment retrieval and formatting, leaving obvious gaps like fetching posts, searching, or user interactions, making the scope feel incomplete.
The tool set is severely incomplete for a Hacker News companion. It only covers retrieving and formatting comments for summarization, missing core operations such as getting posts, listing top stories, or user management, which are essential for the domain.
Scrape Hacker News stories, comments and user profiles as clean JSON with points, author…
Deterministic Hacker News developer sentiment, themes & feature requests via MCP. No API key.
Browse Hacker News feeds, threads, and user profiles with full-text search.
Hacker News MCP — search and retrieve stories from Hacker News