Skip to main content
Glama
enesjakozh
sammcj

mcp-data-extractor

by sammcj
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Extractor de datos mcp Servidor MCP

Un servidor de protocolo de contexto de modelo que extrae datos integrados (como traducciones i18n o configuraciones de clave/valor) del código fuente TypeScript/JavaScript en archivos de configuración JSON estructurados.

insignia de herrería

Características

  • Extracción de datos:

    • Extrae literales de cadena, literales de plantilla y objetos anidados complejos

    • Conserva las variables de plantilla (por ejemplo, Hello, {{name}}! )

    • Admite estructuras de objetos anidados y matrices

    • Mantiene la estructura jerárquica de claves mediante notación de puntos

    • Maneja archivos TypeScript y JavaScript con soporte JSX

    • Reemplaza el contenido del archivo de origen con "MIGRADO A" después de una extracción exitosa (configurable)

  • Extracción de SVG:

    • Extrae componentes SVG de archivos React/TypeScript/JavaScript

    • Conserva la estructura y los atributos del SVG

    • Elimina el código y los accesorios específicos de React

    • Crea archivos .svg individuales que llevan el nombre de su componente

    • Reemplaza el contenido del archivo de origen con "MIGRADO A" después de una extracción exitosa (configurable)

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

Uso

Agregue a su configuración de cliente MCP:

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

Uso básico

El servidor proporciona dos herramientas:

1. Extracción de datos

Utilice extract_data para extraer datos (como traducciones i18n) de los archivos de origen:

<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. Extracción de SVG

Utilice extract_svg para extraer componentes SVG en archivos individuales:

<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>

Reemplazo de archivo fuente

De forma predeterminada, después de una extracción exitosa, el servidor reemplazará el contenido del archivo de origen con:

  • "MIGRADO A" para extracción de datos

  • "MIGRADO A" para la extracción de SVG

Esto ayuda a rastrear los archivos ya procesados y evita la extracción duplicada. Además, facilita que los LLM y los desarrolladores vean dónde se encuentran los datos extraídos cuando accedan al archivo fuente posteriormente.

Para deshabilitar este comportamiento, configure la variable de entorno DISABLE_SOURCE_REPLACEMENT como true en su configuración de MCP:

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

Patrones compatibles

Patrones de extracción de datos

El extractor de datos admite varios patrones comúnmente utilizados en aplicaciones TypeScript/JavaScript:

  1. Exportaciones de objetos simples:

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

  1. Objetos anidados:

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

  1. Estructuras complejas con matrices:

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. Literales de plantilla con variables:

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

Formatos de salida

Salida de extracción de datos

Los datos extraídos se guardan como un archivo JSON con notación de puntos para estructuras anidadas:

{
  "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?"
}

Salida de extracción SVG

Los componentes SVG se extraen en archivos .svg individuales, eliminando el código específico de React. Por ejemplo:

Entrada (componente 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>
);

Salida (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>

Ampliación de patrones compatibles

El extractor utiliza Babel para analizar y recorrer el AST (Árbol Sintético Abstracto) de sus archivos fuente. Puede ampliar los patrones compatibles modificando el código fuente:

  1. Añadir nuevos tipos de nodos : El método extractStringValue en src/index.ts gestiona diferentes tipos de valores de cadena. Ampliarlo para que admita nuevos tipos de nodos:

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. Procesamiento de valores personalizados : El método processValue gestiona diferentes tipos de valores (cadenas, matrices, objetos). Amplíelo para que admita nuevos tipos de valores o procesamiento personalizado.

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. Recorrido personalizado del AST : El servidor utiliza el recorrido de Babel para recorrer el AST. Puedes añadir nuevos visitantes para gestionar diferentes tipos de nodos:

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

Desarrollo

Instalar dependencias:

npm install

Construir el servidor:

npm run build

Para desarrollo con reconstrucción automática:

npm run watch

Depuración

Dado que los servidores MCP se comunican a través de stdio, la depuración puede ser complicada. Recomendamos usar el Inspector MCP , disponible como script de paquete:

npm run inspector

El Inspector proporcionará una URL para acceder a las herramientas de depuración en su navegador.

Licencia

Este proyecto está licenciado bajo la licencia MIT: consulte el archivo de LICENCIA para obtener más detalles.

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
    5 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