라틴아메리카 핀테크를 위한 프라이버시 보호 합성 금융 데이터 — Python, CLI, REST, Apify Actor 및 AI 에이전트용 Model Context Protocol(MCP)로 제공됩니다.
라틴아메리카 저축 앱(2015–2024)의 506,311건의 실제 기록에 대한 통계적 분포로 보정된 금융 저축 행동 합성 데이터 생성기입니다: 멕시코, 콜롬비아, 아르헨티나, 페루, 칠레 등의 305,808건의 거래, 108,570건의 저축 목표, 91,933명의 사용자.
출력은 100% 합성 데이터입니다: 어떤 기록도 실제 사용자에게서 파생되지 않으며, 오직 집계된 분포로부터만 생성됩니다. PII가 없고 재식별 위험이 없습니다.
LatAm Synth는 두 가지 독립적인 경로를 통해 AI 에이전트에 MCP 도구로 제공됩니다:
원격(호스팅): Apify MCP Server는 active_yardstick/latam-synth Actor를 Streamable HTTP를 통해 호출 가능한 MCP 도구로 노출합니다. 설치할 것이 없습니다.
로컬(stdio): 이 저장소에 포함된 latam-synth-mcp는 Apify를 호출하지 않고 생성기를 프로세스 내에서 실행합니다. 로컬 MCP 클라이언트 및 컨테이너화된 카탈로그 검사를 위한 것입니다.
두 경로 모두 동일한 SyntheticGenerator 위의 얇은 어댑터이므로 동일한 참조 무결성을 유지하면서 동일한 테이블을 반환합니다.
MCP 기능: Tools
전송: Streamable HTTP(원격) / stdio(로컬)
호스팅 MCP 서버: Apify MCP Server
로컬 MCP 서버: latam-synth-mcp(extra [mcp], SDK mcp>=2,<3)
도구로 노출된 Actor: active_yardstick/latam-synth
인증: Apify OAuth 또는 Bearer 토큰
공식 MCP 레지스트리 이름: io.github.jmendozapuche/latam-fintech-synthetic-data
레지스트리 메타데이터: server.json
Apify Actor: https://apify.com/active_yardstick/latam-synth
https://mcp.apify.com?tools=active_yardstick/latam-synthtools 매개변수는 Apify MCP Server를 LatAm Synth Actor로 제한하여 호환되는 AI 에이전트가 직접 검색하고 호출할 수 있게 합니다.
{
"mcpServers": {
"latam-synth": {
"url": "https://mcp.apify.com?tools=active_yardstick/latam-synth"
}
}
}최초 연결 시 호환되는 MCP 클라이언트는 Apify OAuth 흐름을 열어 사용자가 구성에 API 토큰을 직접 넣지 않고 액세스를 승인할 수 있습니다.
{
"mcpServers": {
"latam-synth": {
"url": "https://mcp.apify.com?tools=active_yardstick/latam-synth",
"headers": {
"Authorization": "Bearer <APIFY_TOKEN>"
}
}
}
}<APIFY_TOKEN>을 Apify API 토큰으로 바꾸세요.
MCP 호환 에이전트는 LatAm Synth를 호출하여 다음을 생성할 수 있습니다:
합성 금융 사용자
연결된 저축 목표
입금 및 출금 거래
국가별 필터링된 라틴아메리카 데이터셋
무작위 시드를 사용한 재현 가능한 데이터셋
개인 식별 정보를 노출하지 않는 현실적인 핀테크 테스트 데이터
일반적인 에이전트 사용 사례는 다음과 같습니다:
금융 AI 에이전트 평가
주문형 테스트 픽스처 생성
데모 및 POC용 합성 데이터셋 생성
추천 또는 저축 어시스턴트 테스트
ML 및 데이터 파이프라인 실험 부트스트래핑
LatAm Synth는 현재 MCP Tools를 통해 기능을 노출합니다. 현재 MCP Resources 또는 Prompts는 노출하지 않습니다.
원격 경로는 이 저장소 내부에 MCP 전송 서버를 필요로 하지 않습니다: Apify가 호스팅합니다. 로컬 경로에는 생성기를 직접 실행하려는 클라이언트를 위해 하나(src/latam_synth/mcp_server.py)가 포함되어 있습니다 — 토큰 없음, 네트워크 없음, 실행당 비용 없음.
아키텍처는 다음과 같습니다:
MCP-compatible AI client
|
| Streamable HTTP
v
Apify MCP Server
|
| exposes Actor as MCP Tool
v
active_yardstick/latam-synth
|
v
Synthetic users + goals + transactionsApify는 호스팅된 MCP 서버와 인증 계층을 제공합니다. LatAm Synth Actor는 실행 가능한 도구 기능과 구조화된 입출력을 제공합니다.
pip install -e ".[mcp]"
latam-synth-mcp # entry point
python -m latam_synth.mcp_server # equivalent로컬 MCP 클라이언트(Claude Desktop / Claude Code)용 구성:
{
"mcpServers": {
"latam-synth": {
"command": "latam-synth-mcp"
}
}
}노출된 도구:
도구 | 기능 |
| 사용자 + 목표 + 거래를 생성합니다. 인수: |
| 스키마, 목표 카테고리, 사용 가능한 국가 및 개인정보 보호 정책을 반환합니다. 인수가 없습니다. |
둘 다 read_only 및 idempotent로 주석 처리되어 있습니다: 아무것도 기록하지 않으며 동일한 시드는 동일한 데이터셋을 반환합니다. 호출당 200명 사용자 상한은 에이전트 컨텍스트에 응답이 충분히 작게 유지되도록 합니다 — 더 큰 볼륨은 CLI 또는 Actor를 사용하세요.
배포 세부 정보, Docker 이미지 및 Glama 구성: docs/mcp_local.md.
Related MCP server: Faker MCP Server
핀테크 테스팅 및 QA: 결제 파이프라인, 예산 앱, 목표 엔진을 위한 현실적인 픽스처.
데모 및 POC: 공개적으로 표시할 수 있는 그럴듯한 LatAm 데이터가 포함된 대시보드.
ML 학습: 계절성, 이탈률, 목표 카테고리 같은 실제 패턴을 가진 이탈(churn), 추천, 세분화 모델용 부트스트랩 데이터.
AI 에이전트: MCP를 통한 합성 금융 데이터셋 주문형 생성.
교육: 실제 비즈니스 내러티브가 포함된 데이터 사이언스 강좌용 무제한 데이터셋.
pip install -e .
latam-synth generate --users 5000 --seed 42 --format csv --out ./output멕시코와 콜롬비아만, parquet 형식:
latam-synth generate --users 10000 --countries Mexico Colombia --format parquetfrom latam_synth import SyntheticGenerator, GeneratorConfig
data = SyntheticGenerator(
GeneratorConfig(n_users=1000, seed=42)
).generate()
data["transactions"].head()보정은 실제 데이터와 대조하여 검증되었습니다. 참조:
docs/validation_report.txt이 생성기에는 다음이 포함됩니다:
거래 유형별 로그정규 금액 분포
실제 월간 계절성
새해 결심 이후 1월 피크와 12월 바닥
고유한 금액과 기간을 가진 8가지 목표 카테고리
관찰된 달성률 및 포기율
73.8%의 만료된 목표
공유 목표의 uplift
상관된 사용자 점수
규율-달성을 위한 ρ=0.89의 가우시안 코풀라
목표별 일관된 시간 경로
사용자, 목표, 거래 간 참조 무결성
LatAm Synth는 호스팅된 Apify Actor로도 제공됩니다:
active_yardstick/latam-synthActor 페이지:
https://apify.com/active_yardstick/latam-synthActor는 Apify에서 직접, Apify API를 통해 호출하거나 Apify MCP Server를 통해 AI 클라이언트에 노출할 수 있습니다.
입력 예시:
{
"users": 1000,
"seed": 42,
"countries": ["Mexico", "Colombia"],
"format": "csv",
"push_to_dataset": true,
"start_date": "2023-01-01",
"end_date": "2024-12-31"
}seed 매개변수는 생성을 재현 가능하게 만듭니다. 동일한 시드와 구성은 동일한 합성 출력을 생성합니다.
모든 실행은 두 곳에 출력을 기록합니다.
Apify Console에서 실행을 열고 Storage 탭을 클릭합니다.
키-값 저장소를 클릭합니다.
생성된 파일을 다운로드합니다:
users.csv — 합성 사용자당 한 행
goals.csv — 사용자에게 연결된 저축 목표
transactions.csv — 목표에 연결된 입금/출금 거래
OUTPUT — 항상 존재; 매개변수, 행 수, 다운로드 가능한 키를 포함한 실행의 JSON 요약
format: json을 선택한 경우, OUTPUT_DATA에는 세 개의 CSV 파일 대신 단일 JSON 파일에 세 테이블이 모두 포함됩니다.
각 키 옆의 다운로드 아이콘을 클릭하여 파일을 저장합니다.
기본적으로(push_to_dataset: true) 모든 거래는 실행의 Dataset에도 푸시됩니다.
이를 통해 다음을 할 수 있습니다:
Dataset 탭에서 직접 JSON, CSV 또는 Excel로 내보내기
네이티브 Apify 통합을 Dataset 출력에 연결
프로그래밍 방식으로 거래 사용
키-값 저장소 파일만 필요한 매우 큰 실행에서 이를 비활성화하려면 다음을 설정하세요:
{
"push_to_dataset": false
}실행 로그는 실행 종료 시 정확한 파일 이름과 행 수를 출력합니다.
API 종속성을 설치합니다:
pip install -e ".[api]"
uvicorn latam_synth.api:app --port 8000세 테이블이 포함된 JSON 생성:
curl -s -X POST http://localhost:8000/generate \
-H "Content-Type: application/json" \
-d '{"users": 100, "seed": 42, "countries": ["Mexico", "Colombia"]}' | jq .meta메타데이터 응답 예시:
{
"users": 100,
"goals": 121,
"transactions": 453
}거래 CSV 직접 다운로드:
curl -s -X POST http://localhost:8000/generate \
-H "Content-Type: application/json" \
-H "Accept: text/csv" \
-d '{"users": 500, "seed": 7}' \
-o transactions.csv헬스 체크:
curl http://localhost:8000/health{
"status": "ok",
"version": "0.2.0"
}로컬 REST API 제한:
속도 제한: IP당 분당 10회 요청
최대: 요청당 사용자 50,000명
생성된 데이터셋은 프로덕션 PII를 요구하지 않고 개발, 테스트, 데모, 실험 및 교육용으로 설계되었습니다.
주요 특성:
100% 합성 레코드
실제 사용자에게서 복사된 행 없음
보정 데이터셋에서 이름, 이메일, ID 또는 기타 직접 PII가 재생산되지 않음
생성은 집계된 통계 분포를 기반으로 함
합성 테이블은 사용자, 목표 및 거래 간의 현실적인 관계를 보존함
pip install -e ".[dev]"
pytest이 저장소는 MCP 레지스트리 검색을 위해 server.json을 포함합니다.
현재 서버 ID:
io.github.jmendozapuche/latam-fintech-synthetic-data등록된 원격 MCP 엔드포인트는 다음과 같습니다:
https://mcp.apify.com?tools=active_yardstick/latam-synth로그정규 혼합(KS=0.032)
반올림 값으로 스냅(그리드의 69.5%)
목표별 일관된 시간 경로
거래의 100%가 [created_at, deadline] 창 안에 있음
FastAPI API
Apify Actor
호스팅된 Apify MCP Server를 통한 MCP 노출
Describe the schema and calibration of the LatAm Synth dataset.
Use this tool to inspect which tables, columns, goal categories and
countries are available before generating data. It performs no generation
and takes no arguments.
Returns:
Table columns, relationships, goal categories, available countries
and the privacy policy of the generated data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds behavioral context by stating 'performs no generation' and specifying the return items including the privacy policy, which goes beyond what annotations alone convey.
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 appropriately sized, with the purpose front-loaded in the first sentence, usage guidance in the second, and a structured 'Returns' block for the output. Every sentence adds value and there is no wasted text.
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 tool has no parameters and an output schema exists, the description is complete. It clearly states what the tool does, when to use it, and what it returns, including a notable privacy policy detail. Nothing essential is missing for an agent to call it 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?
The tool has zero parameters, so the baseline is 4. The description redundantly states 'takes no arguments', but this reinforces the fact that no input is needed, which is helpful for an agent. No parameter documentation is required.
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?
States a specific verb 'Describe' and a specific resource 'schema and calibration of the LatAm Synth dataset'. It explicitly distinguishes itself from the sibling generate_latam_financial_data by saying 'It performs no generation', making the purpose immediately clear.
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 tells when to use the tool: 'before generating data' to inspect available tables, columns, goal categories, and countries. It also states exclusions: 'It performs no generation' and 'takes no arguments'. This provides clear context and indirectly points to the generation sibling as the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate privacy-safe synthetic financial data for Latin America.
Use this tool when you need synthetic financial users, savings goals and
transactions for Latin American fintech testing, QA, demos,
machine-learning experiments, data pipelines or agent evaluation. The output
is fully synthetic: it is sampled from aggregate distributions and contains
no personally identifiable information and no real records.
Args:
users: Number of synthetic users to generate. Use 1 to 200.
seed: Random seed for reproducible datasets. The same seed and
parameters always return the same dataset.
countries: Optional list of Latin American countries to include,
for example ["Colombia", "Mexico"].
start_date: Optional ISO start date of the generated period,
for example "2023-01-01".
end_date: Optional ISO end date of the generated period,
for example "2024-12-31".
Returns:
Synthetic users, linked savings goals, linked transactions,
and dataset row counts.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| users | No | ||
| end_date | No | ||
| countries | No | ||
| start_date | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the annotations: it states the output is 'fully synthetic', 'sampled from aggregate distributions', contains 'no personally identifiable information and no real records', and that 'the same seed and parameters always return the same dataset.' This goes far beyond the readOnlyHint and idempotentHint annotations by explaining what the data actually is and how reproducibility works.
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 well-structured with a summary sentence, a usage paragraph, a structured Args list, and a Returns note. It is slightly verbose in the usage paragraph (listing many use cases) but every sentence contributes value, and the most important information (what it does, key constraints) is front-loaded.
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 tool's moderate complexity (five optional parameters, one sibling tool, output schema available), the description is complete. It explains the purpose, when to use it, all parameters with examples, the synthetic nature, and the return shape. There are no obvious gaps that would prevent an agent from invoking the tool 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?
With 0% schema description coverage, the description fully carries the burden of explaining all five parameters. It provides detailed meaning and usage for each: users range '1 to 200', seed guarantees reproducibility, countries gives an example list, and both date parameters specify ISO format with examples. This is exemplary compensation for the absence of schema descriptions.
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 opens with a clear statement of what the tool does: 'Generate privacy-safe synthetic financial data for Latin America.' It then specifies the exact resources produced (financial users, savings goals, transactions), which distinguishes it from the sibling describe_latam_synth_dataset that describes rather than generates.
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 explicitly states when to use the tool: 'Use this tool when you need synthetic financial users, savings goals and transactions for Latin American fintech testing, QA, demos...' This provides clear context, but it does not mention any alternative tool or describe situations where it should NOT be used, so it falls just short of full marks.
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.
v1.0.0describe_latam_synth_datasetgenerate_latam_financial_dataScored across 2 tools
The two tools have completely distinct purposes: one generates synthetic data, the other describes the dataset schema. No overlap or ambiguity exists.
Both tools follow a consistent verb_noun pattern (generate_..., describe_...). The slight difference in noun phrasing ('financial_data' vs 'synth_dataset') is minor and does not break the pattern.
Only 2 tools is on the thin side. For a data generation server, a generate and describe tool is minimal but arguably sufficient for the core workflow. Still, it barely meets the borderline threshold.
The tool surface covers the main lifecycle: generating data and understanding the schema/config. No obvious missing operations for the stated purpose, though there is no tool for exporting or managing datasets, which might be a minor gap.
Hosted MCP endpoint with realistic fake data for prototyping agents. 12 tools, no setup.
Brazilian Open Finance MCP — 30+ banks (Itaú, Nubank, etc.) to Claude/Cursor. Read-only.
Verified LATAM data for AI agents: sanctions, entity, rates, KYB. Pay via x402.
Open Finance API and MCP discovery for developers and AI agents building in Brazil.