面向拉丁美洲金融科技的安全隐私合成金融数据——可通过Python、CLI、REST、Apify Actor和模型上下文协议（MCP）供AI代理使用。
金融储蓄行为合成数据生成器，根据来自拉丁美洲储蓄应用（2015–2024年）的506,311条真实记录的统计分布进行校准：来自墨西哥、哥伦比亚、阿根廷、秘鲁、智利等国家的305,808笔交易、108,570个储蓄目标和91,933名用户。
输出100%为合成数据：没有任何记录来自真实用户，仅来自聚合分布。无PII，无重新识别风险。
LatAm Synth 可通过两条独立路径作为MCP工具提供给AI代理：
远程（托管）： Apify MCP Server 通过Streamable HTTP将active_yardstick/latam-synth Actor暴露为可调用的MCP工具。无需安装任何东西。
本地（stdio）： 本仓库附带的latam-synth-mcp在进程内运行生成器，无需调用Apify。适用于本地MCP客户端和容器化目录检查。
两条路径返回相同的表，具有相同的引用完整性，因为两者都是同一SyntheticGenerator之上的薄适配器。
MCP能力： 工具
传输： Streamable HTTP（远程）/ stdio（本地）
托管MCP服务器： Apify MCP Server
本地MCP服务器： latam-synth-mcp（额外[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代理
按需生成测试夹具
为演示和概念验证创建合成数据集
测试推荐或储蓄助手
引导ML和数据管道实验
LatAm Synth目前通过MCP工具暴露其功能。目前不暴露MCP资源或提示。
远程路径不需要本仓库内的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
金融科技测试和质量保证：为支付管道、预算应用和目标引擎提供逼真的夹具。
演示和概念验证：可公开展示的拉丁美洲可信数据仪表板。
机器学习训练：用于流失、推荐和细分模型的启动数据，具有季节性、放弃率和目标类别等真实模式。
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生成器包含：
按交易类型划分的对数正态金额分布
真实的月度季节性
一月目标后高峰和十二月低谷
8个目标类别，各有自己的金额和期限
观察到的达成率和放弃率
73.8%的过期目标
共享目标的提升
相关的用户评分
ρ=0.89的高斯copula用于纪律-成就
每个目标一致的时间轨迹
用户、目标和交易之间的引用完整性
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中打开运行，点击存储选项卡。
点击键值存储。
下载生成的文件：
users.csv——每个合成用户一行
goals.csv——链接到用户的储蓄目标
transactions.csv——链接到目标的存款/取款交易
OUTPUT——始终存在；运行的JSON摘要，包括参数、行数和可下载的键
如果选择了format: json，OUTPUT_DATA包含单个JSON文件中的三个表，而不是三个CSV文件
点击每个键旁边的下载图标以保存文件。
默认情况下（push_to_dataset: true），所有交易也会推送到运行的数据集。
这允许您：
直接从数据集选项卡导出为JSON、CSV或Excel
将原生Apify集成连接到数据集输出
以编程方式消费交易
对于只需要键值存储文件的大型运行，要禁用此功能，请设置：
{
"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。
当前服务器身份：
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.