Skip to main content
Glama
enesjakozh
sammcj

mcp-data-extractor

by sammcj
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

mcp-data-extractor MCP 服务器

模型上下文协议服务器将嵌入数据（例如 i18n 翻译或键/值配置）从 TypeScript/JavaScript 源代码提取到结构化的 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 客户端配置：

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

基本用法

服务器提供了两个工具：

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 提取的“迁移至”

这有助于追踪哪些文件已被处理，并防止重复提取。此外，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 组件被提取到单独的 .svg 文件中，并删除了 React 特有的代码。例如：

输入（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 遍历：服务器使用 Babel 的遍历函数来遍历 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 许可证获得许可 - 有关详细信息，请参阅LICENSE文件。

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