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 クライアント構成に追加します:

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

基本的な使い方

サーバーは次の 2 つのツールを提供します。

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>

ソースファイルの置換

デフォルトでは、抽出が成功すると、サーバーはソース ファイルの内容を次のように置き換えます。

  • データ抽出のために「移行先」

  • 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コンポーネントは、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トラバーサル：サーバーは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
    24 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