Integrates with VS Code via GitHub Copilot's MCP support to provide EPH-specific context, design records, and methodology, helping AI assistants write correct code for EPH data analysis.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@eph-context Write R code for EPH household weights using official design"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Los modelos de IA alucinan variables de la EPH que no existen, aplican mal los ponderadores y se olvidan del panel rotante. eph-context le da al modelo los diseños de registro oficiales del INDEC y las reglas metodológicas antes de que escriba una línea. Resultado: código correcto, sin inventos.
Herramienta | Instalación | Sección |
ChatGPT (web, sin instalar nada) | Ninguna | |
Claude Desktop | Muy simple | |
Cursor | Muy simple | |
VS Code | Muy simple | |
Claude Code (terminal) | Para desarrolladores |
Related MCP server: emovi-mcp
La opción más simple. Funciona directamente en chatgpt.com creando un GPT personalizado con el conocimiento de la EPH incluido.
Una cuenta de ChatGPT Plus (pago) — necesaria para subir archivos de conocimiento a un GPT personalizado
Los archivos de la carpeta assets/ de este repositorio
1. Descargá los archivos de conocimiento
Andá a la página principal del repositorio en GitHub, hacé clic en el botón verde Code → Download ZIP y descomprimí el archivo en tu computadora.
2. Creá un GPT personalizado
En chatgpt.com:
Hacé clic en tu nombre (abajo a la izquierda) → My GPTs → Create a GPT
En la pestaña Configure, completá:
Name: Asistente EPH INDEC
Instructions: copiá y pegá todo el contenido del archivo gpt_instructions.md que está en este repositorio
3. Subí los archivos de conocimiento
En la misma pantalla de configuración, en la sección Knowledge, hacé clic en Upload files y subí todos los archivos .md de la carpeta assets/ (design, methodology, classifiers, tools).
4. Guardá y empezá a usarlo
Hacé clic en Save (arriba a la derecha) y listo. Podés empezar a preguntarle sobre la EPH o pedirle que te escriba código.
Nota: Para subir archivos de conocimiento necesitás ChatGPT Plus (pago). Con la versión gratuita podés pegar el contenido de los archivos directamente en el chat cuando lo necesites.
Claude Desktop es la aplicación de escritorio de Anthropic. Si no la tenés, descargala desde claude.ai/download.
uvuv es una herramienta que maneja las dependencias de Python. Sin ella no va a funcionar.
En Mac o Linux, abrí la Terminal y pegá:
curl -LsSf https://astral.sh/uv/install.sh | shEn Windows, abrí PowerShell y pegá:
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"Cerrá y volvé a abrir la terminal después de instalar.
1. Descargá este repositorio
Si tenés git instalado, en la terminal:
git clone https://github.com/matias-denatale/eph-context.gitSi no tenés git, descargá el ZIP desde GitHub (botón verde Code → Download ZIP) y descomprimilo donde quieras. Guardá la ruta de la carpeta — la vas a necesitar.
2. Abrí el archivo de configuración de Claude Desktop
Andá a Claude Desktop → menú Claude (arriba) → Settings → Developer → Edit Config.
Se va a abrir un archivo claude_desktop_config.json. Si está vacío, pegá esto directamente:
{
"mcpServers": {
"eph": {
"command": "uv",
"args": [
"--directory",
"/ruta/a/eph-context",
"run",
"server.py"
]
}
}
}Si ya tiene contenido, agregá solo la parte de "eph": { ... } dentro de "mcpServers".
3. Reemplazá la ruta
Cambiá /ruta/a/eph-context por la ruta real donde descomprimiste el repositorio.
Mac/Linux: algo como /Users/tu-nombre/eph-context
Windows: algo como C:\\Users\\tu-nombre\\eph-context (con doble barra invertida)
4. Guardá y reiniciá Claude Desktop
Cerrá y volvé a abrir Claude Desktop. Las herramientas EPH van a aparecer disponibles — las podés ver haciendo clic en el ícono de herramientas (🔧) en el chat.
Cursor es un IDE basado en VS Code con IA integrada. Si no lo tenés, descargalo desde cursor.com.
Necesitás tener uv instalado (ver instrucciones en la sección de Claude Desktop).
1. Descargá este repositorio (igual que en Claude Desktop, paso 1)
2. Abrí la configuración de MCP en Cursor
Cursor → Settings → Cursor Settings → MCP → Add new MCP server
O bien editá el archivo ~/.cursor/mcp.json directamente y agregá:
{
"mcpServers": {
"eph": {
"command": "uv",
"args": [
"--directory",
"/ruta/a/eph-context",
"run",
"server.py"
]
}
}
}3. Reemplazá la ruta y reiniciá Cursor
Necesitás la extensión GitHub Copilot o Continue con soporte MCP.
Necesitás tener uv instalado (ver instrucciones en la sección de Claude Desktop).
1. Descargá este repositorio (igual que en Claude Desktop, paso 1)
2. Editá el archivo de configuración MCP
Creá o editá .vscode/mcp.json en tu proyecto:
{
"servers": {
"eph": {
"type": "stdio",
"command": "uv",
"args": [
"--directory",
"/ruta/a/eph-context",
"run",
"server.py"
]
}
}
}3. Reemplazá la ruta y reiniciá VS Code
Para usuarios del CLI de Claude Code en terminal.
1. Cloná el repositorio en tu carpeta de skills:
git clone https://github.com/matias-denatale/eph-context.git ~/.claude/skills/eph2. Agregá esta línea a tu ~/.claude/CLAUDE.md en la tabla de skills:
| EPH microdata, usu_hogar, usu_individual, scripts R/Python con EPH | `~/.claude/skills/eph/SKILL.md` |La skill se activa automáticamente cuando Claude Code detecta consultas sobre EPH, variables como CODUSU, PONDERA, ESTADO, etc.
Una vez instalado, podés pedirle cosas como:
"Calculá la tasa de desocupación para el 2do trimestre de 2024 con R"
"¿Qué es el panel rotante y cómo afecta el análisis longitudinal?"
"Escribime un script en Python para calcular informalidad laboral"
"¿Cómo mergeo las bases de hogar e individual?"
"¿Qué variables cambaron en el 4T2023?"
El modelo siempre consulta los diseños de registro y la metodología oficial antes de responder. No adivina, no improvisa.
Usuario: Calculá la tasa de desocupación para el 4T2024 con R.
El modelo (internamente):
eph_setup() → recibe workflow obligatorio + reglas críticas
get_design_record("31_aglomerados_post") → variables ESTADO, PONDERA y sus categorías exactas
get_methodology("indicadores_mercado_laboral") → fórmula oficial INDEC
Respuesta del modelo:
library(eph)
base <- get_microdata(year = 2024, trimester = 4, type = "individual")
base |>
summarise(
desocupacion = sum(PONDERA[ESTADO == 2]) / sum(PONDERA[ESTADO %in% c(1, 2)]) * 100
)Sin inventar nombres de variables. Sin ponderadores incorrectos. Sin mezclar períodos pre/post 4T2023.
Contenido | Qué es |
Diseños de registro | Variables, categorías y codificaciones para EPH Continua y Total Urbano, antes y después del 4T2023 |
Reglas metodológicas | Ponderadores, panel rotante, quiebre de serie, informalidad, indicadores de mercado de trabajo |
Documentación de packages | Paquete |
Clasificador CNO 2001 | Clasificador Nacional de Ocupaciones completo (5 dígitos) |
Diego Kozlowski — creador del paquete eph para R
Desarrollado por Matías De Natale.
MIT. Usalo, modificálo, compartilo. Si lo mejorás, mandá un PR.
CALL THIS FIRST — before writing any code or referencing any variable.
Returns the mandatory workflow, critical rules, and available topics. This is step 1 of every EPH task. No exceptions.
After calling this, proceed to:
get_design_record() → exact variable names for the dataset
get_package_docs() → correct function signatures for R or Python
get_methodology() → weighting rules, rate formulas, indicator definitions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that the tool returns workflow, rules, and topics, implying a read-only setup operation. While it does not detail exact return format or side effects, the context suggests no destructive actions. The transparency is good but could be enhanced by stating it is non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short sentences plus a bullet list. It uses formatting (bold, dashes) to highlight key points. Every sentence earns its place by conveying essential instructions, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has zero parameters and no output schema, the description fully explains its role as a mandatory first step, what it returns, and how to proceed. It covers the entire context needed for an agent to use this tool correctly within the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is fully covered trivially (100%). The description confirms this implicitly by not referencing any parameters. Since no parameter info is needed, the description adds value by clarifying the no-argument nature implicitly through its focus on the single call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Returns the mandatory workflow, critical rules, and available topics.' It uses strong language like 'CALL THIS FIRST' and 'step 1 of every EPH task,' making the role unmistakable and differentiating it from siblings that are listed as subsequent steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'CALL THIS FIRST — before writing any code or referencing any variable. No exceptions.' It also tells what to do after calling this tool, listing specific sibling tools with their purposes, effectively guiding the agent on the correct workflow order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the complete CNO 2001 (Clasificador Nacional de Ocupaciones).
Call eph_setup() first if you have not already. Use this to correctly interpret or recode occupation variables (PP04D_COD, P47T). Includes all 5-digit codes, descriptions, and qualification categories.
Pass filter to get only matching lines (case-insensitive substring match).
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses read-only nature, filter behavior (case-insensitive substring), and contents. However, it omits details on output format, error handling, or dependency on eph_setup (e.g., what happens if not called).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five concise sentences, each adding unique value: purpose, prerequisite, use case, contents, filter behavior. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers return contents and filter behavior. It includes a prerequisite but lacks details on error conditions or the scope of the filter substring match.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'filter' is well-explained: 'Pass filter to get only matching lines (case-insensitive substring match).' This adds semantic value beyond the schema's empty title, though default value is not mentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Returns the complete CNO 2001 classification' with a specific verb and resource. It distinguishes the tool from siblings like search_variable by focusing on occupation classification retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite ('Call eph_setup() first') and use cases ('correctly interpret or recode occupation variables'). Lacks explicit 'when not to use' but gives clear context compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the OFFICIAL variable dictionary for EPH microdata files.
Call eph_setup() first if you have not already. Call this BEFORE writing any code that references variable names or category codes. Do NOT use variable names from memory — they change between periods.
tipo values: "31_aglomerados_pre" — EPH 31 aglomerados urbanos, quarters BEFORE 4T2023 "31_aglomerados_post" — EPH 31 aglomerados urbanos, FROM 4T2023 onward (redesigned variables) "total_urbano_pre" — EPH Total Urbano, before 4T2023 "total_urbano_post" — EPH Total Urbano, from 4T2023 onward
If the user has not specified the period, ASK before calling this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates this is a retrieval operation (returns a dictionary) and states a prerequisite (eph_setup). However, it could more explicitly state that the tool is read-only and has no side effects, though the action of 'returning' implies no mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is logically structured: purpose first, then usage instructions, then parameter explanation, then conditional guidance. It is slightly lengthy but each sentence adds value, earning a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and sibling tools, the description adequately covers its role and prerequisites. It lacks error handling details (e.g., invalid tipo), but the overall guidance is sufficient for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (parameter tipo has no description), but the description compensates fully by listing and explaining all valid values for tipo, including their temporal contexts. This adds critical meaning beyond the schema's mere string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the official variable dictionary for EPH microdata files, identifying its specific purpose and resource. It distinguishes from siblings by emphasizing its role as a dictionary to be used before referencing variable names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-call instructions: call eph_setup() first if needed, call before writing code referencing variables, and advises not to use variable names from memory. It also explains the two main scenarios for tipo values and instructs to ask the user if the period is unspecified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns official EPH methodological documentation for a specific topic.
Call eph_setup() first if you have not already. Call this BEFORE computing rates, applying weights, or building indicators.
tema values: "que_es_la_eph" — survey overview, periodicity, geographic coverage "panel_rotante" — rotating panel design, cohort tracking across waves "ponderadores" — PONDERA / PONDIH / PONDIIO: which to use and when "indicadores_mercado_laboral" — unemployment and employment rate formulas (INDEC official) "informalidad_laboral" — informal employment classification rules "quiebre_serie_4t2023" — series break details, what changed, how to handle it "eph_continua_vs_total_urbano" — coverage and methodological differences between variants
| Name | Required | Description | Default |
|---|---|---|---|
| tema | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description implies a read-only operation returning documentation. It does not detail error behavior or rate limits, but the context is sufficiently clear for a simple retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise two-sentence purpose/guidance followed by a well-formatted list of options. No wasted words; every line adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, an output schema exists, and the description covers prerequisite, ordered usage, and all topic values. No gaps for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter 'tema' has 0% schema coverage, but the description compensates fully by listing all valid string values with detailed explanations, adding essential meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'returns' and specific resource 'official EPH methodological documentation for a specific topic'. The description then enumerates valid topic values, distinguishing it from sibling tools like get_classifiers or get_package_docs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite 'Call eph_setup() first if you have not already' and ordering 'Call this BEFORE computing rates, applying weights, or building indicators', providing strong guidance on when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the OFFICIAL API reference for the EPH data package.
Call eph_setup() first if you have not already. Call this BEFORE writing any import statement or function call. Do NOT use function names or argument names from memory — they may be wrong.
lang values:
"r" — eph R package: get_microdata(), organize_labels(), calculate_tabulates()
"python" — pyeph library: download(), organize(), LaborMarket, Poverty classes
| Name | Required | Description | Default |
|---|---|---|---|
| lang | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses the tool's behavior: it returns documentation with language-specific details. It also implies a read-only operation without side effects, meeting transparency needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five concise sentences covering purpose, prerequisite, usage order, warnings, and parameter values. No redundancy; each sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and existing output schema, the description fully covers what agents need: return type (documentation), when to use, and parameter mapping.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds complete meaning for the single 'lang' parameter by listing valid values ('r', 'python') and their associated packages and classes/functions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the OFFICIAL API reference for the EPH data package, with a specific verb and resource. It distinguishes from sibling tools like eph_setup and get_classifiers by emphasizing documentation retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call eph_setup() first and to use this tool before writing any code, providing clear context and preventing misuse. Warns against relying on memory for function names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search a variable by partial name or description across all design records.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that search spans all design records and uses partial matching, but lacks details on return format, pagination, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is direct and front-loaded with key action and scope. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description sufficiently covers the operation and parameter usage. No gaps given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema only defines 'name' as string with 0% coverage. Description adds meaning: the parameter can be a partial name or description, clarifying how to use the parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Search', resource 'variable', scope 'across all design records', and method 'by partial name or description'. Distinguishes from sibling tools which are not search-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage context (searching by partial name or description) but does not explicitly state when to use this tool versus alternatives like get_design_record or get_classifiers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0eph_setupget_classifiersget_design_recordget_methodologyget_package_docssearch_variableScored across 6 tools
Each tool has a distinct purpose: setup, classifiers, design record, methodology, package docs, variable search. No overlaps.
Most tools follow get_noun pattern; eph_setup and search_variable deviate but are still clear and recognizable.
6 tools is well-scoped for a context server covering EPH survey setup and reference materials.
Covers all essential context aspects (setup, codes, variables, methods, docs, search). Minor gap: no direct tool for period validation but covered by setup instructions.
Official Mexican data for AI agents: CURP, RFC, CFDI, postal codes, phone, SPEI/CEP, DOF, geocoding.
Datos econ�micos y financieros oficiales de Argentina (BCRA, INDEC, CNV, MECON), AI-ready.
Privacy-safe synthetic financial data for LatAm fintech, AI agents, testing and ML.
Brazilian public data API for AI agents. BCB, IBGE, CVM, B3, compliance. x402 payments on Base.
