MCP Gets Another Major Boost: Local LLMs Can Directly Invoke Google’s Time-Series Foundation Model for Zero-Shot Forecasting

A Graduate Student Stuffed Two of Google’s Foundation Models into One MCP

Last week, Google pushed updates for two foundation models to the community in one go: TabFM and TimesFM. The former targets zero-shot classification and regression for tabular data, while the latter focuses on time-series forecasting. Neither model is particularly large—TimesFM 2.5 is only 200M parameters—but it was pretrained on 100 billion real-world time points. In theory, a single forward pass can replace much of the repetitive hyperparameter tuning and retraining work common in traditional ML.

The problem is that these models are hosted on HuggingFace, which means you still have to write your own inference code, build your own data pipelines, and handle format conversion yourself. For developers trying to use LLMs as agents, there’s still a manual integration layer in the middle.

On July 11, a project called Zer0Fit appeared on Reddit’s r/MachineLearning. The author, an AI graduate student, packaged TabFM and TimesFM together into an MCP Server. Run a service through a single Docker container, connect it to Claude Code, Codex, or Open WebUI, and a local LLM can directly invoke the two models to perform zero-shot ML tasks. The entire workflow is 100% local, with no cloud API involved.

The significance here isn’t technical complexity—the MCP wrapper is essentially just a protocol adapter layer—but that it fully bridges two things that previously had a gap between them: “foundation model capabilities” and “agent workflows.” Previously, if you asked Claude to analyze a CSV, it would either calculate things itself using pandas or generate some sklearn training code for you to run manually. Now it can directly call a pretrained tabular foundation model and return results in seconds.

How Good Is Zero-Shot ML Really?

Here’s the short version: it’s not better than a fine-tuned model, but it’s good enough for “just give me an answer quickly” scenarios.

The author tested it on several classic datasets:

• Iris classification: 94.7% zero-shot accuracy
• California Housing regression: R² reached 0.91

Compared to the traditional workflow—data cleaning, feature engineering, model selection, cross-validation, hyperparameter search—those numbers aren’t particularly stunning. You can casually hit 96%+ on Iris using SVM or random forests, and a properly tuned XGBoost model can exceed 0.85 on California Housing, with 0.9 achievable through feature engineering.

But the key phrase is “zero-shot.” Users don’t need to write any training code, split training and validation sets, choose algorithms, or even understand what R² means. Drop in a CSV, and the model directly outputs predictions. That experience is revolutionary for two groups:

1. People who aren’t ML specialists but still need ML: product managers validating business hypotheses, operations teams forecasting next quarter’s metrics, backend engineers building rough anomaly detection systems. Previously they needed help from data scientists; now they can get results themselves.
2. ML engineers building prototypes and baselines: previously even running a baseline took at least half a day of coding. Now results come in minutes, and they can quickly determine whether a problem is worth deeper investment.

The TimesFM side is even more interesting. It’s a 200M-parameter decoder-only transformer trained on real-world “temporal corpora” including Wikipedia page views and Google Search trends. Google Cloud has already integrated it into BigQuery through the AI.FORECAST function, and according to official claims, its forecasting accuracy is competitive with ARIMA.

The most important upgrades in version 2.5 are the 16k context window and native probabilistic quantile forecasting. The former means you can feed in much longer historical sequences without window splitting. The latter means it doesn’t just output a point estimate—it also provides confidence intervals. That’s extremely important in business forecasting, because executives rarely ask “What will sales be next month?” They ask “What’s the worst-case scenario?”

Engineering Details: Why the Source Code Is Worth a Look

Zer0Fit includes several implementation details worth discussing.

Dynamic model loading + TTL. The two models don’t permanently occupy VRAM after startup. Instead, they load on demand and automatically unload after 5 minutes of inactivity. The logic behind this is straightforward:

• If someone only occasionally uses the MCP, there’s no reason to permanently consume 16GB of VRAM
• But for continuous usage, repeated cold starts would also be undesirable
• A 5-minute TTL balances VRAM usage against response latency

For users running local LLMs via Ollama or vLLM, this design significantly reduces VRAM contention. Local large models already consume substantial memory; if TabFM and TimesFM stayed resident all the time, running them on an 8GB consumer GPU would be nearly impossible.

Two models in a single container. The author chose to package both models into one Docker image rather than separating them. The reasoning is simple: from the user’s perspective, “tabular data” and “time-series data” are often two views of the same business problem. In a single scenario, you might want both future trend forecasting (TimesFM) and classification of current data (TabFM). Registering separate MCP endpoints is enough.

The roadmap for format support. Currently only CSV is supported, but the author says XLS, XLSX, JSON, and JSONL are coming. This prioritization is actually pragmatic—90% of real business data is CSV. Solve the largest common denominator first, and handle Excel edge cases later.

Hardware requirements. It’s PyTorch-based and CUDA-only, with the installation script automatically detecting hardware architecture. The author explicitly mentions compatibility with DGX Spark, 3090, H100, and “any Nvidia GPU with 16GB+ VRAM.” That 16GB threshold is critical: the 16GB version of the 4060 Ti can run it, but the 12GB 3080 Ti may struggle. AMD users and Apple Silicon users are currently out of luck.

How to Integrate It into Your Workflow

A typical deployment flow looks roughly like this:

git clone https://github.com/porespellar/Zer0Fit
cd Zer0Fit
./install.sh  # Automatically detects hardware architecture
docker compose up -d

Once running, Zer0Fit exposes MCP endpoints. Taking Claude Code as an example, you simply add the MCP server address in the configuration. Then you can directly tell Claude:

Help me analyze this sales.csv, forecast next quarter’s sales, and provide a 90% confidence interval

Claude will automatically invoke TimesFM, parse the CSV, and return forecasts and quantiles. The entire process requires no pandas or sklearn code from the user.

The same applies to Open WebUI and Codex—any host supporting the MCP protocol can connect to it. That’s also why the MCP ecosystem has exploded over the past six months: the protocol itself is lightweight enough that once a tool is wrapped as MCP, it becomes reusable across all mainstream agents.

A Signal from the MCP Ecosystem

If you’ve been following the MCP ecosystem recently, you’ve probably noticed projects like Zer0Fit emerging rapidly. Half a year ago, MCP was mainly used for “read-operation” tools like databases, file systems, and Git. Over the past three months, there’s been a surge of wrappers for “specialized model capabilities”—OCR, speech recognition, image segmentation, and now tabular/time-series foundation models.

This evolutionary path isn’t accidental. There’s a ceiling to what LLMs can do on their own, especially for tasks requiring numerical precision. Having an LLM perform numerical forecasting through in-context learning is both slow and inaccurate. The correct approach is to let it invoke a specialized pretrained model. Fundamentally, this is the practical implementation of the compound AI system approach—LLMs handle planning and interaction, while specialized models handle precise computation.

By open-sourcing TabFM and TimesFM, combined with HuggingFace hosting and protocol layers like MCP, Google is effectively driving something larger: making foundation model capabilities composable like APIs. Previously, a data analysis task required an ML engineer writing code and configuring libraries. In the future, an agent may simply invoke several foundation models on its own to complete the task.

Some Questions and Limitations

A few caveats are worth mentioning. Projects like Zer0Fit currently face several real issues:

First, the evaluation data is too limited. The author only tested Iris and California Housing. Those are toy datasets—the complexity, noise, missing values, and distribution shifts of real business data are on an entirely different scale. Zero-shot model performance in real-world scenarios still requires much broader validation.

Second, lack of interpretability. Foundation models can output predictions, but you can’t inspect feature importance or decision-tree split paths like in traditional ML. That’s a major weakness in heavily regulated domains such as finance and healthcare.

Third, hardware dependency. The requirement for 16GB VRAM and CUDA excludes many lightweight use cases. Ideally there should be an API fallback—if local hardware isn’t sufficient, users could invoke a cloud-based TimesFM API.

Fourth, the maturity of the MCP protocol itself. MCP specifications are still evolving rapidly, and compatibility issues occasionally appear between different host implementations. Zer0Fit has officially tested Open WebUI, Claude Code, and Codex, but other agent frameworks still require experimentation.

One More Thing

If you don’t have an Nvidia GPU with 16GB of VRAM but still want agents capable of “invoking specialized models,” another option is API aggregation. Platforms like OpenAI Hub support access to all major LLMs (GPT, Claude, Gemini, DeepSeek, etc.) through a single key, with direct access from China and OpenAI-compatible APIs. Replacing Claude Code’s local LLM with a remote API while keeping only the Zer0Fit inference container running locally is a practical combination—the cost of large-model inference is outsourced while specialized model capabilities remain local.

For individual developers, this kind of “hybrid deployment” may become mainstream: lightweight inference tasks run locally to protect data privacy, while heavyweight conversational generation uses APIs to reduce hardware costs.

One-Sentence Summary

Zer0Fit itself isn’t technically complex, but it signals something important: composable use of foundation models is moving from concept to everyday workflow. Previously, you needed an ML engineer to train a model for you. By this time next year, you may only need to tell an agent: “Help me forecast this data.”

The project is available on GitHub (porespellar/Zer0Fit). Anyone interested can try it out on their own 3090. The author says Excel and JSON support are coming next, and once the file-format pain points are solved, it could genuinely become a default tool for many small teams.

---

References

• Zer0Fit Main Repository - GitHub — The author’s original open-source codebase, including installation scripts and Docker configuration
• Google TimesFM Official Repository - GitHub — TimesFM 2.5 model code, weights, and LoRA fine-tuning examples
• Zer0Fit Launch Discussion - Reddit r/MachineLearning — Original author post and community discussion, including additional benchmarks and user feedback