ラテンアメリカのフィンテック向けのプライバシー安全な合成金融データ — Python、CLI、REST、Apify Actor、およびAIエージェント向けのModel Context Protocol (MCP)を通じて利用可能。
金融貯蓄行動の合成データ生成器で、ラテンアメリカの貯蓄アプリの506,311件の実記録（2015〜2024年）の統計分布に基づいて較正されています：メキシコ、コロンビア、アルゼンチン、ペルー、チリなどの305,808件の取引、108,570件の貯蓄目標、91,933人のユーザー。
出力は100%合成です：どの記録も実際のユーザーに由来するものではなく、集計された分布のみに基づいています。PIIはなく、再識別のリスクもありません。
LatAm Synthは、AIエージェントに対してMCPツールとして、2つの独立した経路で利用可能です：
リモート（ホスト型）： Apify MCP Serverがactive_yardstick/latam-synth ActorをStreamable HTTP経由で呼び出し可能なMCPツールとして公開します。インストールは不要です。
ローカル（stdio）： このリポジトリに同梱されているlatam-synth-mcpは、Apifyを呼び出さずにジェネレーターをプロセス内で実行します。ローカルMCPクライアントやコンテナ化されたカタログチェック用です。
両方の経路は、同じSyntheticGeneratorに対する薄いアダプターであるため、同じ参照整合性を持つ同じテーブルを返します。
MCP機能： ツール
トランスポート： 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ツールを通じて機能を公開しています。現在、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"
}
}
}公開されているツール：
Tool | What it does |
| ユーザー + 目標 + 取引を生成します。引数： |
| スキーマ、目標カテゴリ、利用可能な国、プライバシーポリシーを返します。引数はありません。 |
両方ともread_onlyおよびidempotentとして注釈されています：何も書き込まれず、同じシードは同じデータセットを返します。呼び出しごとの200ユーザー上限により、エージェントコンテキストに十分な小ささの応答が保たれます — より大容量の場合はCLIまたはActorを使用してください。
デプロイメントの詳細、Dockerイメージ、Glama設定：docs/mcp_local.md。
Related MCP server: Faker MCP Server
フィンテックのテストとQA：支払いパイプライン、予算アプリ、目標エンジン向けの現実的なフィクスチャ。
デモとPOC：公に表示できるラテンアメリカの信頼できるデータを使ったダッシュボード。
MLトレーニング：季節性、離脱率、目標カテゴリなどの実際のパターンを用いたチャーン、レコメンデーション、セグメンテーションモデル用の初期データ。
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%の期限切れ目標
共有目標のアップリフト
相関するユーザースコア
ガウスコピュラ（ρ=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パラメータにより生成が再現可能になります。同じシードと設定は同じ合成出力を生成します。
すべての実行は出力を2か所に書き込みます。
Apifyコンソールで実行を開き、Storageタブをクリックします。
Key-value storeをクリックします。
生成されたファイルをダウンロードします：
users.csv — 合成ユーザーごとに1行
goals.csv — ユーザーにリンクされた貯蓄目標
transactions.csv — 目標にリンクされた入金/出金取引
OUTPUT — 常に存在します。パラメータ、行数、ダウンロード可能なキーを含む実行のJSONサマリー。
format: jsonが選択された場合、OUTPUT_DATAには3つのCSVファイルの代わりに、3つのテーブルすべてが1つの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 80003つのテーブルを含む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.