Skip to main content
Glama
enesjakozh
tatn

MCP Server Fetch TypeScript

by tatn
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

mcp-server-fetch-typescript MCP 서버

웹 콘텐츠 가져오기 및 변환 기능을 제공하는 모델 컨텍스트 프로토콜 서버입니다. 이 서버는 다양한 형식과 렌더링 방식을 지원하는 포괄적인 웹 콘텐츠 검색 시스템을 구현하여 간단한 데이터 추출부터 정교한 웹 스크래핑까지 다양한 작업에 이상적입니다.

특징

도구

  • get_raw_text - URL에서 직접 원시 텍스트 콘텐츠를 검색합니다.

    • 텍스트 기반 리소스를 가리키는 필수 매개변수로 url 사용합니다.

    • 브라우저 렌더링 없이 처리되지 않은 텍스트 콘텐츠를 반환합니다.

    • JSON, XML, CSV, TSV 또는 일반 텍스트 파일에 이상적입니다.

    • 소스 콘텐츠에 빠르고 직접 액세스해야 할 때 가장 잘 사용됩니다.

  • get_rendered_html - 완전히 렌더링된 HTML 콘텐츠 가져오기

    • url 필수 매개변수로 사용합니다.

    • JavaScript 실행 후 전체 HTML 콘텐츠를 반환합니다.

    • 헤드리스 브라우저 렌더링을 위해 Playwright를 사용합니다.

    • 최신 웹 애플리케이션 및 SPA에 필수

  • get_markdown - 웹 콘텐츠를 Markdown 형식으로 변환

    • url 필수 매개변수로 사용합니다.

    • 구조적 요소를 보존하는 잘 포맷된 Markdown을 반환합니다.

    • 표와 정의 목록을 지원합니다

    • 콘텐츠 보관 및 문서화에 권장됨

  • get_markdown_summary - 주요 콘텐츠 추출 및 변환

    • url 필수 매개변수로 사용합니다.

    • 주요 내용에 초점을 맞춘 깔끔한 마크다운을 반환합니다.

    • 탐색, 헤더, 푸터를 자동으로 제거합니다.

    • 기사 및 블로그 게시물 추출에 적합합니다.

Related MCP server: MCP Server for Google Search

설치

글로벌 패키지로서

지엑스피1

프로젝트 종속성으로서

npm install mcp-server-fetch-typescript

용법

Claude Desktop과 함께 사용

Claude Desktop과 함께 사용하려면 서버 구성을 추가하세요.

MacOS의 경우: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows의 경우: %APPDATA%/Claude/claude_desktop_config.json

"mcpServers": {
  "mcp-server-fetch-typescript": {
    "command": "npx",
    "args": [
      "-y",
      "mcp-server-fetch-typescript"
    ]
  }
}

또는 다음 구성을 추가합니다.

git clone https://github.com/tatn/mcp-server-fetch-typescript.git
cd mcp-server-fetch-typescript
npm install
npm run build
"mcpServers": {
  "mcp-server-fetch-typescript": {
    "command": "node",
    "args": [
      "/path/to/mcp-server-fetch-typescript/build/index.js"
    ]
  }
}

디버깅

MCP 서버를 디버깅하려면:

npx @modelcontextprotocol/inspector npx -y mcp-server-fetch-typescript
npx @modelcontextprotocol/inspector node /path/to/mcp-server-fetch-typescript/build/index.js

Available Tools

4 tools
get_markdownA

Converts web page content to well-formatted Markdown, preserving structural elements like tables and definition lists. Recommended as the default tool for web content extraction when a clean, readable text format is needed while maintaining document structure.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesURL of the web page to convert to Markdown format, supporting various HTML elements and structures.

TDQS

A4.2/5.0
Behavior3/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 discloses key behavioral traits: conversion to Markdown, preservation of structural elements, and suitability as a default extraction tool. However, it lacks details on error handling, performance characteristics, or limitations (e.g., URL accessibility, content size). The description adds value but is incomplete for full 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 appropriately sized and front-loaded, with two sentences that efficiently convey purpose and usage guidelines. Every sentence earns its place by defining the tool's function and providing contextual recommendations without unnecessary details.

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

Completeness4/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 (single parameter, no output schema, no annotations), the description is mostly complete. It covers purpose, usage context, and key behavioral aspects. However, it lacks explicit mention of output format details or potential limitations, leaving some gaps in full context for an agent.

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?

Schema description coverage is 100%, with the single parameter 'url' well-documented in the schema. The description adds no specific parameter semantics beyond what the schema provides, but it implies the URL should point to a web page with content convertible to Markdown. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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

Purpose5/5

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

The description clearly states the specific action ('Converts web page content to well-formatted Markdown') and resource ('web page'), distinguishing it from siblings by emphasizing preservation of structural elements like tables and definition lists. It explicitly contrasts with other tools by positioning itself as the default for clean, readable text format extraction.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool ('Recommended as the default tool for web content extraction when a clean, readable text format is needed while maintaining document structure'), implying alternatives through sibling tool names (get_markdown_summary, get_raw_text, get_rendered_html) and specifying the context of needing structured, readable output.

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

get_markdown_summaryA

Extracts and converts the main content area of a web page to Markdown format, automatically removing navigation menus, headers, footers, and other peripheral content. Perfect for capturing the core content of articles, blog posts, or documentation pages.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesURL of the web page whose main content should be extracted and converted to Markdown.

TDQS

A3.9/5.0
Behavior3/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 describes key behaviors like automatic removal of navigation menus and headers, which is useful context, but lacks details on potential limitations, error handling, or performance aspects that could affect tool selection.

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 appropriately sized and front-loaded, with two concise sentences that efficiently convey the tool's purpose and use case without any wasted words, making it easy for an agent to quickly understand the tool's value.

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 (content extraction and conversion), no annotations, and no output schema, the description is somewhat complete but lacks details on output format, error conditions, or performance characteristics that would help an agent use it effectively in varied contexts.

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?

Schema description coverage is 100%, so the input schema already documents the 'url' parameter thoroughly. The description does not add any additional meaning or details beyond what the schema provides, such as URL format constraints or examples, resulting in a baseline score of 3.

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

Purpose5/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 specific verbs ('extracts and converts') and resources ('main content area of a web page to Markdown format'), distinguishing it from siblings like get_raw_text or get_rendered_html by emphasizing content extraction and conversion to Markdown.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool ('Perfect for capturing the core content of articles, blog posts, or documentation pages'), but does not explicitly state when not to use it or name alternatives among the sibling tools, leaving some room for improvement in distinguishing usage scenarios.

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

get_raw_textA

Retrieves raw text content directly from a URL without browser rendering. Ideal for structured data formats like JSON, XML, CSV, TSV, or plain text files. Best used when fast, direct access to the source content is needed without processing dynamic elements.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesURL of the target resource containing raw text content (JSON, XML, CSV, TSV, plain text, etc.).

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits like 'without browser rendering' and 'fast, direct access', but lacks details on error handling, rate limits, or authentication needs. It does not contradict annotations.

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 front-loaded with the core purpose, followed by usage guidelines, all in three concise sentences with zero waste. Every sentence adds value without redundancy.

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 no annotations and no output schema, the description is adequate for a simple retrieval tool but lacks details on return values, error cases, or performance constraints. It covers the basics but could be more complete for a tool with potential complexity in handling various data formats.

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?

Schema description coverage is 100%, so the schema already documents the 'url' parameter. The description adds some context by listing acceptable formats (JSON, XML, CSV, TSV, plain text), but does not provide additional syntax or format details beyond what the schema implies.

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

Purpose5/5

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

The description clearly states the specific action ('retrieves raw text content') and resource ('from a URL'), distinguishing it from siblings like get_markdown or get_rendered_html by emphasizing 'without browser rendering' and 'direct access to source content'.

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

Usage Guidelines4/5

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

It provides clear context on when to use ('ideal for structured data formats', 'best used when fast, direct access to source content is needed without processing dynamic elements'), but does not explicitly mention when not to use or name specific alternatives among siblings.

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

get_rendered_htmlA

Fetches fully rendered HTML content using a headless browser, including JavaScript-generated content. Essential for modern web applications, single-page applications (SPAs), or any content that requires client-side rendering to be complete.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesURL of the target web page that requires JavaScript execution or dynamic content rendering.

TDQS

A3.7/5.0
Behavior3/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 explains the tool's approach ('using a headless browser') and scope ('including JavaScript-generated content'), which adds value beyond the input schema. However, it omits details like performance characteristics, error handling, or output format, leaving gaps for a mutation-like operation (fetching rendered content).

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 appropriately sized with two sentences that are front-loaded and zero waste. The first sentence states the core functionality, and the second provides essential usage context, making it efficient and well-structured.

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 complexity (rendering dynamic content) and lack of annotations and output schema, the description is adequate but incomplete. It covers the purpose and usage context but misses details like what the returned HTML includes (e.g., full DOM, specific elements), potential limitations, or error scenarios, which are crucial for such an operation.

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 input schema has 100% description coverage, with the 'url' parameter well-documented in the schema itself. The description adds marginal context by implying the URL must target pages needing JavaScript execution, but doesn't provide additional syntax, format, or validation details beyond what the schema already states.

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 specific verbs ('fetches fully rendered HTML content') and resources ('using a headless browser'), distinguishing it from sibling tools that fetch markdown or raw text. However, it doesn't explicitly differentiate from potential non-sibling alternatives like basic HTML fetchers, keeping it from 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.

Usage Guidelines4/5

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

The description provides clear context for when to use this tool ('modern web applications, single-page applications (SPAs), or any content that requires client-side rendering'), which implicitly distinguishes it from sibling tools that handle markdown or raw text. It lacks explicit exclusions or named alternatives, preventing a score of 5.

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. 4 tool updates
    • First observedget_markdown
    • First observedget_markdown_summary
    • First observedget_raw_text
    • First observedget_rendered_html
Deploy Server
Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

TDQS

A4.2/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: get_markdown preserves full structure, get_markdown_summary focuses on core content, get_raw_text handles raw data formats, and get_rendered_html captures JavaScript-rendered content. The descriptions explicitly differentiate use cases, leaving no ambiguity for agent selection.

Naming Consistency5/5

All tool names follow a consistent 'get_*' verb_noun pattern with snake_case, making them predictable and easy to parse. The naming convention is uniform across all four tools, enhancing readability and coherence.

Tool Count5/5

With 4 tools, the set is well-scoped for a web content fetching server, covering key extraction methods (Markdown, raw text, rendered HTML) and a specialized summary variant. Each tool earns its place without redundancy or excessive complexity.

Completeness5/5

The tool surface comprehensively covers the domain of web content fetching: it includes raw extraction, rendered content, and two Markdown variants for different needs. There are no obvious gaps, as the tools handle static, dynamic, and structured content effectively.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches