Fundata MCP

Solution Architecture

A remote MCP server that wraps the Fundata WebData & DbSync APIs for AI clients — with fixed inbound and outbound IPs, per-client credential relay, and per-credential rate limiting, deployed per environment by CloudFormation.

AWS ACCOUNT — PROD 229346405114 · UAT 986434714650 VPC 10.210.0.0/16 · 2 AZ · PRIVATE SUBNETS AI clients Claude Desktop ChatGPT Copilot Global Accelerator 2 fixed IPs ALB HTTPS · ACM AWS Lambda (Mangum) FastMCP MCP server · 91 tools credential relay + rate check Fundata APIs authenticate webdata · dbsync *.fundataapi.com DynamoDB rate-limit counters NAT Gateway fixed egress IP Route 53 → GA IPs HTTPS rate check · VPC endpoint egress whitelisted egress IP
End-to-end path: a client authenticates with its own Fundata credentials to mcp.fundataapi.com; the Lambda relays them to Fundata over the whitelisted egress IP and enforces per-credential rate limits in DynamoDB.
request / data path account · VPC boundary
How it fits together

Inbound & fixed IPs

mcp.fundataapi.com (Route 53) → Global Accelerator's two static IPs → ALB (HTTPS via ACM) → Lambda. The GA IPs are the fixed inbound addresses a client firewall can allowlist.

Credential relay

The server stores no Fundata credentials. Each client sends its own key/secret (HTTP Basic, or X-Fundata-Key/-Secret); the Lambda relays to Fundata /authenticate and caches the token per credential.

Fixed egress

Lambda runs in private subnets → NAT Gateway with a pinned Elastic IP. Fundata allowlists that one egress IP. DbSync download URLs are fetched by the client directly, not proxied through the server.

Rate limiting

Per-credential fixed-window limits in DynamoDB, reached over a VPC gateway endpoint (private, off the NAT); the checks run in parallel. DbSync gets its own stricter budget.

Multi-account & IaC

One CloudFormation template deploys UAT and Prod as separate accounts from per-env config, with stack-level tags and Lambda code pinned by S3 object version. Each env has its own in/out IPs.