Skip to main content
Glama
enesjakozh
sammcj

mcp-data-extractor

by sammcj
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

mcp-data-extractor MCP 서버

TypeScript/JavaScript 소스 코드에서 내장된 데이터(i18n 번역이나 키/값 구성 등)를 추출하여 구조화된 JSON 구성 파일에 저장하는 모델 컨텍스트 프로토콜 서버입니다.

대장간 배지

특징

  • 데이터 추출:

    • 문자열 리터럴, 템플릿 리터럴 및 복잡한 중첩 객체를 추출합니다.

    • 템플릿 변수(예: Hello, {{name}}! )를 보존합니다.

    • 중첩된 객체 구조 및 배열을 지원합니다.

    • 점 표기법을 사용하여 계층적 키 구조를 유지합니다.

    • JSX 지원을 통해 TypeScript 및 JavaScript 파일을 모두 처리합니다.

    • 성공적인 추출 후 소스 파일 내용을 "MIGRATED TO"로 바꿉니다(구성 가능)

  • SVG 추출:

    • React/TypeScript/JavaScript 파일에서 SVG 구성 요소를 추출합니다.

    • SVG 구조 및 속성을 보존합니다.

    • React 관련 코드와 속성을 제거합니다.

    • 구성 요소의 이름을 따서 개별 .svg 파일을 만듭니다.

    • 성공적인 추출 후 소스 파일 내용을 "MIGRATED TO"로 바꿉니다(구성 가능)

Related MCP server: @lex-tools/codebase-context-dumper

용법

MCP 클라이언트 구성에 추가:

지엑스피1

기본 사용법

서버는 두 가지 도구를 제공합니다.

1. 데이터 추출

extract_data 사용하여 소스 파일에서 데이터(i18n 번역 등)를 추출합니다.

<use_mcp_tool>
<server_name>data-extractor</server_name>
<tool_name>extract_data</tool_name>
<arguments>
{
  "sourcePath": "src/translations.ts",
  "targetPath": "src/translations.json"
}
</arguments>
</use_mcp_tool>

2. SVG 추출

extract_svg 사용하여 SVG 구성 요소를 개별 파일에 추출합니다.

<use_mcp_tool>
<server_name>data-extractor</server_name>
<tool_name>extract_svg</tool_name>
<arguments>
{
  "sourcePath": "src/components/icons/InspectionIcon.tsx",
  "targetDir": "src/assets/icons"
}
</arguments>
</use_mcp_tool>

소스 파일 교체

기본적으로 추출이 성공적으로 완료되면 서버는 소스 파일의 내용을 다음으로 바꿉니다.

  • 데이터 추출을 위해 "MIGRATED TO"로 변경

  • SVG 추출을 위한 "MIGRATED TO"

이를 통해 이미 처리된 파일을 추적하고 중복 추출을 방지할 수 있습니다. 또한 LLM과 개발자가 나중에 소스 파일을 접할 때 추출된 데이터가 현재 어디에 있는지 쉽게 확인할 수 있습니다.

이 동작을 비활성화하려면 MCP 구성에서 DISABLE_SOURCE_REPLACEMENT 환경 변수를 true 로 설정하세요.

{
  "mcpServers": {
    "data-extractor": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-data-extractor"
      ],
      "env": {
        "DISABLE_SOURCE_REPLACEMENT": "true"
      },
      "disabled": false,
      "autoApprove": [
        "extract_data",
        "extract_svg"
      ]
    }
  }
}

지원되는 패턴

데이터 추출 패턴

데이터 추출기는 TypeScript/JavaScript 애플리케이션에서 일반적으로 사용되는 다양한 패턴을 지원합니다.

  1. 간단한 객체 내보내기:

export default {
  welcome: "Welcome to our app",
  greeting: "Hello, {name}!",
  submit: "Submit form"
};

  1. 중첩된 객체:

export default {
  header: {
    title: "Book Your Flight",
    subtitle: "Find the best deals"
  },
  footer: {
    content: [
      "Please refer to {{privacyPolicyUrl}} for details",
      "© {{year}} {{companyName}}"
    ]
  }
};

  1. 배열을 사용한 복잡한 구조:

export default {
  faq: {
    heading: "Common questions",
    content: [
      {
        heading: "What if I need to change my flight?",
        content: "You can change your flight online if:",
        list: [
          "You have a flexible fare type",
          "Your flight is more than 24 hours away"
        ]
      }
    ]
  }
};

  1. 변수가 있는 템플릿 리터럴:

export default {
  greeting: `Hello, {{username}}!`,
  message: `Welcome to {{appName}}`
};

출력 형식

데이터 추출 출력

추출된 데이터는 중첩 구조에 대한 점 표기법을 사용하여 JSON 파일로 저장됩니다.

{
  "welcome": "Welcome to our app",
  "header.title": "Book Your Flight",
  "footer.content.0": "Please refer to {{privacyPolicyUrl}} for details",
  "footer.content.1": "© {{year}} {{companyName}}",
  "faq.content.0.heading": "What if I need to change my flight?"
}

SVG 추출 출력

SVG 구성 요소는 React 관련 코드가 제거된 개별 .svg 파일로 추출됩니다. 예:

입력(React 구성 요소):

const InspectionIcon: React.FC<InspectionIconProps> = ({ title }) => (
  <svg className="c-tab__icon" width="40px" id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 32 32">
    <title>{title}</title>
    <path className="cls-1" d="M18.89,12.74a3.18,3.18,0,0,1-3.24-3.11..." />
  </svg>
);

출력(InspectionIcon.svg):

<svg width="40px" id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 32 32">
    <path class="cls-1" d="M18.89,12.74a3.18,3.18,0,0,1-3.24-3.11..." />
</svg>

지원되는 패턴 확장

추출기는 Babel을 사용하여 소스 파일의 AST(추상 구문 트리)를 파싱하고 탐색합니다. 소스 코드를 수정하여 지원되는 패턴을 확장할 수 있습니다.

  1. 새 노드 유형 추가 : src/index.ts 의 extractStringValue 메서드는 다양한 유형의 문자열 값을 처리합니다. 새 노드 유형을 지원하도록 확장합니다.

private extractStringValue(node: t.Node): string | null {
  if (t.isStringLiteral(node)) {
    return node.value;
  } else if (t.isTemplateLiteral(node)) {
    return node.quasis.map(quasi => quasi.value.raw).join('{{}}');
  }
  // Add support for new node types here
  return null;
}

  1. 사용자 지정 값 처리 : processValue 메서드는 다양한 값 유형(문자열, 배열, 객체)을 처리합니다. 새로운 값 유형이나 사용자 지정 처리를 지원하도록 확장합니다.

private processValue(value: t.Node, currentPath: string[]): void {
  if (t.isStringLiteral(value) || t.isTemplateLiteral(value)) {
    // Process string values
  } else if (t.isArrayExpression(value)) {
    // Process arrays
  } else if (t.isObjectExpression(value)) {
    // Process objects
  }
  // Add support for new value types here
}

  1. 사용자 지정 AST 순회 : 서버는 바벨의 순회를 사용하여 AST를 순회합니다. 다양한 노드 유형을 처리하기 위해 새로운 방문자를 추가할 수 있습니다.

traverse(ast, {
  ExportDefaultDeclaration(path: NodePath<t.ExportDefaultDeclaration>) {
    // Handle default exports
  },
  // Add new visitors here
});

개발

종속성 설치:

npm install

서버를 빌드하세요:

npm run build

자동 재빌드를 사용한 개발의 경우:

npm run watch

디버깅

MCP 서버는 stdio를 통해 통신하므로 디버깅이 어려울 수 있습니다. 패키지 스크립트로 제공되는 MCP Inspector를 사용하는 것이 좋습니다.

npm run inspector

검사기는 브라우저에서 디버깅 도구에 액세스할 수 있는 URL을 제공합니다.

특허

이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.

Available Tools

2 tools
extract_dataA

Extract data content (e.g. i18n translations) from source code to a JSON file. IMPORTANT: When encountering files with data such as i18n content embedded in code, use this tool directly instead of reading the file content first. This tool will programmatically extract all translations into a structured JSON file, preserving nested objects, arrays, template variables, and formatting. This helps keep translations as configuration and prevents filling up the AI context window with translation content. By default, the source file will be replaced with "MIGRATED TO " and a warning message after successful extraction, making it easy to track where the data was moved to. This behaviour can be disabled by setting the DISABLE_SOURCE_REPLACEMENT environment variable to 'true'. The warning message can be customized by setting the WARNING_MESSAGE environment variable.

NameRequiredDescriptionDefault
sourcePathYesPath to the source file containing data inside code
targetPathYesPath where the resulting JSON file should be written

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: it states the source file will be replaced with a 'MIGRATED TO ...' message and that this can be disabled via environment variable. It also mentions customizing the warning message. This gives the agent clear expectations of side effects.

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

Conciseness4/5

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

The description is slightly longer but every sentence is purposeful: it explains the core action, usage directive, benefits, side effects, and configuration. It is front-loaded and well-structured, though could be slightly trimmed without losing value.

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 no output schema and a tool with side effects, the description covers usage, behavior, and configuration. It explains what happens after extraction (file replacement) and how to control it. It could explicitly mention the return value (the JSON file written) but it is implied.

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 coverage is 100% with clear descriptions. The description adds minimal semantic value beyond the schema; it repeats the purpose but does not provide new details about parameter formats or constraints. Baseline 3 is appropriate.

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?

Clearly states it extracts data content (e.g., i18n translations) from source code to a JSON file. The verb 'extract' and resource 'data content from source code to JSON file' are specific, and it distinguishes from sibling 'extract_svg' by focusing on code data rather than SVG.

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?

Provides explicit usage guidance: 'When encountering files with data such as i18n content embedded in code, use this tool directly instead of reading the file content first.' It explains why (prevents filling context window) but does not explicitly mention when not to use or alternatives.

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

extract_svgA

Extract SVG components from React/TypeScript/JavaScript files into individual .svg files. This tool will preserve the SVG structure and attributes while removing React-specific code. By default, the source file will be replaced with "MIGRATED TO " and a warning message after successful extraction, making it easy to track where the SVGs were moved to. This behaviour can be disabled by setting the DISABLE_SOURCE_REPLACEMENT environment variable to 'true'. The warning message can be customized by setting the WARNING_MESSAGE environment variable.

NameRequiredDescriptionDefault
sourcePathYesPath to the source file containing SVG components
targetDirYesDirectory where the SVG files should be written

TDQS

A3.9/5.0
Behavior3/5

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

Discloses key behavior: source file replacement by default and ability to disable/customize via environment variables. With no annotations, the description carries full burden; it could be more comprehensive (e.g., what happens if target directory doesn't exist, handling of multiple SVGs).

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?

Five sentences are well-structured, front-loaded with purpose, then preservation, then default behavior and customization options. No redundant information.

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 output schema, no annotations, and 2 params, the description is fairly complete but lacks mention of return values or failure modes. Could also note if it handles one or multiple SVGs per file.

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?

Input schema has 100% coverage with clear param descriptions. The description adds minimal extra meaning beyond what schema already provides (e.g., implying sourcePath is a code file). Baseline of 3 is appropriate.

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 verb 'Extract' and the resource 'SVG components from React/TypeScript/JavaScript files' with output to 'individual .svg files'. It distinguishes from the sibling tool 'extract_data' by specifying 'SVG components'.

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?

Provides clear context for when to use (extract SVGs from code files) and details about default source file replacement and environment variables to control behavior. However, it doesn't explicitly mention when not to use or compare with alternatives.

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. 2 tool updates
    • First observedextract_data
    • First observedextract_svg
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A4.1/5.0

Scored across 2 tools

Disambiguation5/5

The two tools target clearly distinct extraction types: structured data (e.g. i18n translations) versus SVG components. An agent can easily choose between them based on the file/content type, with no meaningful overlap.

Naming Consistency5/5

Both tools follow the same verb_noun pattern: extract_data and extract_svg. The naming is simple, predictable, and directly reflects the output type.

Tool Count4/5

At two tools, the server is slightly below the typical well-scoped range, but the count is reasonable for a narrowly focused extractor utility. Each tool covers a distinct extraction workflow and earns its place.

Completeness4/5

The server covers its stated domain reasonably well: data extraction and SVG extraction are both implemented with source-replacement behavior. It is a small surface, but there are no obvious dead ends within the apparent scope of a specialized extractor.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Swagger MCP Server

    tuskermanshu
    A
    license
    B
    quality
    D
    maintenance
    A server based on Model Context Protocol that parses Swagger/OpenAPI documents and generates TypeScript types and API client code for different frameworks (Axios, Fetch, React Query).
    12
    17 npm
    16
    ISC

  • Basic MCP Server

    Merlin21x
    F
    license
    B
    quality
    D
    maintenance
    A basic TypeScript implementation of the Model Context Protocol (MCP) server designed as a starting point for MCP development. Provides a minimal foundation for building custom MCP servers with stdio configuration for local integration with VS Code and GitHub Copilot.
    1
    -

  • CRAG-MCP

    bluemot
    F
    license
    B
    quality
    D
    maintenance
    A Model Context Protocol server that builds and queries a config-aware code graph with support for conditional compilation (#ifdef) filtering, enabling context-aware code analysis across different build configurations.
    9
    -

Appeared in Searches