Skip to main content
Glama
manimohans

The Verge News MCP Server

by manimohans

The Verge 뉴스 MCP 서버

대장간 배지

The Verge의 RSS 피드에서 뉴스를 가져오고 검색할 수 있는 도구를 제공하는 MCP 서버입니다.

특징

  • The Verge에서 오늘의 뉴스를 받아보세요

  • 지난주 The Verge의 뉴스를 무작위로 선택하여 가져옵니다.

  • 키워드로 뉴스기사 검색

Related MCP server: News Aggregator MCP Server

설치

지엑스피1

용법

서버 실행

npm start

Claude와 함께 데스크톱 사용

  1. 데스크톱용 Claude 설치

  2. 다음 위치에서 Claude for Desktop App 구성을 엽니다.

    • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

    • Windows: %APPDATA%\Claude\claude_desktop_config.json

  3. 다음 구성을 추가합니다.

{
  "mcpServers": {
    "verge-news": {
      "command": "node",
      "args": ["/absolute/path/to/verge-news-mcp/build/index.js"]
    }
  }
}
  1. 데스크톱용 Claude를 다시 시작하세요

Smithery와 함께 사용

Smithery 와 함께 이 MCP 서버를 사용하면 MCP 서버를 쉽게 공유하고 사용할 수 있습니다.

  1. Smithery가 설치되어 있는지 확인하세요.

npm install -g @anthropic-ai/smithery
  1. Smithery를 통해 이 서버를 사용하려면 다음을 실행하세요.

smithery use https://github.com/manimohans/verge-news-mcp
  1. 설치가 완료되면 Claude나 다른 MCP 호환 애플리케이션과 함께 사용할 수 있습니다.

대장간 구성

이 저장소에는 Smithery에 필요한 구성 파일이 포함되어 있습니다.

  • Dockerfile : MCP 서버용 Docker 컨테이너를 빌드하는 방법을 정의합니다.

  • smithery.yaml : Smithery의 기능을 포함하여 MCP 서버를 구성합니다.

Smithery 구성에 대한 자세한 내용은 Smithery 설명서를 참조하세요.

사용 가능한 도구

데일리 뉴스 받기

지난 24시간 동안 The Verge에 게재된 최신 뉴스 기사를 가져옵니다.

예시 쿼리: "오늘 The Verge에서 무슨 뉴스가 나왔나요?"

주간 뉴스 받기

지난 7일 동안 The Verge에서 발행된 뉴스 기사를 가져옵니다.

예시 쿼리: "지난주 The Verge의 뉴스를 보여주세요."

참고: 이 도구는 지난주 뉴스 기사 10개를 무작위로 선택하여 사용할 때마다 다양성을 제공합니다.

검색 뉴스

특정 키워드가 포함된 뉴스 기사를 검색합니다.

매개변수:

  • keyword : 검색할 용어

  • days (선택 사항): 되돌아볼 일 수(기본값: 30)

예시 쿼리: "The Verge에서 AI에 대한 뉴스 기사를 찾으세요."

개발

# Run in development mode
npm run dev

특허

아이에스씨

Available Tools

3 tools
get-daily-newsB

Get the latest news from The Verge for today

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
Behavior2/5

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 fetching 'latest news' but doesn't specify aspects like rate limits, authentication needs, data freshness, or what happens if no news is available today. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's function without any wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly, which is ideal for conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It explains what the tool does but lacks details on behavioral traits, output format, or differentiation from siblings. For a basic read operation, it meets the minimum viable standard but doesn't provide full context for optimal agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, but since there are no parameters, a baseline score of 4 is appropriate as there's nothing to compensate for, and the description adequately conveys the tool's purpose without parameter confusion.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and resource ('latest news from The Verge for today'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-weekly-news' (which presumably covers a different time frame) or 'search-news' (which likely offers search capabilities), so it misses the highest score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides minimal guidance by specifying 'for today', implying usage for current news. However, it doesn't explicitly state when to use this tool versus alternatives like 'get-weekly-news' or 'search-news', nor does it mention any exclusions or prerequisites, leaving the agent with incomplete decision-making context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-weekly-newsB

Get the latest news from The Verge for the past week

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states what the tool does but lacks behavioral details like whether it returns a list or single item, pagination, rate limits, authentication requirements, or error conditions. 'Get' suggests a read operation, but no safety or performance characteristics are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with the core action, zero waste. Every word contributes to understanding the tool's function without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations, no output schema, and no parameters, the description is incomplete. It lacks details on return format (e.g., list of articles, metadata), error handling, or any behavioral traits needed for reliable agent use, given the complexity of news retrieval.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0 parameters and 100% schema description coverage, the baseline is 4. The description adds context about the time frame ('past week') and source ('The Verge'), which is meaningful beyond the empty schema, though minimal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and resource ('latest news from The Verge for the past week'), making the purpose understandable. It distinguishes from 'get-daily-news' by specifying weekly scope, but doesn't explicitly differentiate from 'search-news' which might also retrieve news.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like 'get-daily-news' or 'search-news'. The description implies usage for weekly news from The Verge, but doesn't clarify scenarios where other tools would be more appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search-newsB

Search for news articles from The Verge by keyword

ParametersJSON Schema
NameRequiredDescriptionDefault
keywordYesKeyword to search for in news articles
daysNoNumber of days to look back (default: 30)

TDQS

B3.1/5.0
Behavior2/5

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 searching by keyword but lacks details on permissions, rate limits, pagination, or the format of returned articles. For a search tool with zero annotation coverage, this is a significant gap in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage guidelines, and output format, which are important for a search tool. It meets the minimum viable standard but has clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so the input schema already documents both parameters ('keyword' and 'days') clearly. The description adds no additional meaning beyond what the schema provides, such as examples or constraints, but the baseline score of 3 is appropriate since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Search') and resource ('news articles from The Verge by keyword'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'get-daily-news' or 'get-weekly-news', which might also retrieve news articles but with different time-based scopes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get-daily-news' or 'get-weekly-news', nor does it specify scenarios where keyword-based searching is preferred over time-based retrieval, leaving the agent without clear usage context.

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.

  1. 3 tool updatesv1.0.0
    • Addedget-daily-news
    • Addedget-weekly-news
    • Addedsearch-news

TDQS

A3.6/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: get-daily-news retrieves today's news, get-weekly-news covers the past week, and search-news allows keyword-based queries. There is no overlap in functionality, making tool selection straightforward for an agent.

Naming Consistency5/5

All tool names follow a consistent verb-noun pattern with hyphens (e.g., get-daily-news, get-weekly-news, search-news). The naming is predictable and readable throughout the set.

Tool Count5/5

With 3 tools, the server is well-scoped for its purpose of accessing news from The Verge. Each tool earns its place by covering distinct timeframes and search capabilities, avoiding bloat or thinness.

Completeness4/5

The tool set covers core news retrieval operations (daily, weekly, and search), but lacks advanced features like filtering by category or date range. However, agents can work around these minor gaps for basic news access.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers