simba-k

Yes, I think its a good comparison

Currently would have to be done on the SQLAlchemy side, but someone asked to contribute django directly. Let me see if they are still planning to do that and create/link an issue if you want to keep up with it.

You could also build an EnrichMCP server that calls your Django server manually

Yeah to restricted read, still a lot of API work to do here and we're a bit blocked by MCP itself changing its auth spec (was just republished yesterday).

If you use the lower-level enrichMCP API (without SQLAlchemy) you can fully control all retrieval logic and add things like rate limiting, not dissimilar to how you'd solve this problem with a traditional API.

Yeah, think of it as a data analyst. If I give you a Postgres account with all of our tables in it, you wouldn't even know when to start and would spend tons of time just running queries to figure out what you were looking at.

If I explain the semantic graph, entities, relationships, etc. with proper documentations and descriptions you'd be able to reason about it much faster and more accurately.

A postgres schema might have the data type and a name and a table name vs. all the rich metadata that would be required in EnrichMCP.

Yes but the agent reasoning is going to use an LLM, I sometimes run our openai_chat_agent example just to test things out. Try giving it a shot, ask it to do something then ask it to explain its tool use.

Obviously, it can (and sometimes will) hallucinate and make up why its using a tool. The thing is, we don't really have true LLM explainability so this is the best we can really do.

So one big difference is that we aren't doing text2sql here, and the framework requires clear descriptions on all fields, entities, and relationships (it literally won't run otherwise).

We also generate a few tools for the LLM specifically to explain the data model to it. It works quite well, even on complex schemas.

The use case is more transactional than analytical, though we've seen it used for both.

I recommend running the openai_chat_agent in examples/ (also supports ollama for local run) and connect it to the shop_api server and ask it a question like : "Find and explain fraud transactions"

Not sure exactly what you mean here. Prisma is an ORM for developers working with databases in TypeScript. EnrichMCP is more like an ORM for AI agents. It’s not focused on replacing Prisma in your backend stack, but it serves a similar role for agents that need to understand and use your data model.

It's also Python.

Imagine you're building a support agent for DoorDash. A user asks, "Why is my order an hour late?" Most teams today would build a RAG system that surfaces a help center article saying something like, "Here are common reasons orders might be delayed."

That doesn't actually solve the problem. What you really need is access to internal systems. The agent should be able to look up the order, check the courier status, pull the restaurant's delay history, and decide whether to issue a refund. None of that lives in documentation. It lives in your APIs and databases.

LLMs aren't limited by reasoning. They're limited by access.

EnrichMCP gives agents structured access to your real systems. You define your internal data model using Python, similar to how you'd define models in an ORM. EnrichMCP turns those definitions into typed, discoverable tools the LLM can use directly. Everything is schema-aware, validated with Pydantic, and connected by a semantic layer that describes what each piece of data actually means.

You can integrate with SQLAlchemy, REST APIs, or custom logic. Once defined, your agent can use tools like get_order, get_restaurant, or escalate_if_late with no additional prompt engineering.

It feels less like stitching prompts together and more like giving your agent a real interface to your business.

Yep, we can essentially convert from SQLAlchemy into an MCP server.

Auth/Security is interesting in MCP. As of yesterday a new spec was released with MCP servers converted to OAuth resource servers. There's still a lot more work to do on the MCP upstream side, but we're keeping up with it and going to have a deeper integration to have AuthZ support once the upstream enables it.

Very! We had quite a few people do this at a hackathon we hosted this past weekend.

I feel like I see a new company doing this every week. I know there is Skyvern and browser-use in particular. Is there something special about this one?

I don't think so, I write about why I think this one warrants it though in the article. Do you disagree with any specific points?

MCP's "security nightmare" and toll poising was all is due to people downloading and `exec`ing random untrusted executables. I mention and link it in the article. Same would be true if you downloaded a random REST server, ran it on your computer, and started doing random cURLs to it. MCP over HTTP is just REST for LLMs.

I agree that the current ecosystem pushes for insecure use of MCP, but if we move to using trusted HTTPS-hosted services with OAuth (which is all in the spec), the security issues would be on par with any REST service.

https://www.featureform.com/post/what-mcp-gets-wrong

We just wrote a ton about this, after using it.

tl;dr The spec and implementation orients towards stdio. We think this is a mistake and have created our own implementation that's backwards compatible with the spec but oriented towards production grade remote server.

MCP promises to be REST for LLMs. Imagine pointing your Claude, ChatGPT, or Gemini directly at Gmail’s (hypothetical) MCP endpoint and asking it to organize your inbox today—no custom Python wrappers, no complicated API integrations, just simple, direct communication between LLMs and servers. When you expand this to Slack, WhatsApp, banking, Uber, Twilio, GitHub, and beyond, everything becomes interconnected and actionable by language models.

Our also has a local mode, the goal is to solve organisational problems as well such as versioning. It solves the problem of having a Google doc full of SQL snippets that people pass around, or digging for a notebook called untitled_110.ipynb to copy some code from,

Up for a call? Would love to get your Api feedback, email me at simba@featureform.com , I’ll buy you lunch :)

Yes, we essentially have three components: the serving layer, the orchestrator, and the metadata layer.

All three of these work across different infrastructure by design. We already have users who use Google Cloud services like BigQuery for experimentation and DynamoDB on AWS for serving in productions.

The data mesh analogy is interesting. In a way, we're an applied form of data mesh, as opposed to a theoretical argument for it. By separating the abstraction/workflow layer from the data infra layer, you can put your data where it makes sense and access it all through featureform's feature store abstraction.

you can read more about the virtual feature store architecture here: https://www.featureform.com/post/feature-stores-explained-th...

Imagine you're Spotify and you have a stream of user-song-timestamp triplets per listen. You'll likely want to transform it into features such as: top genre per user in last 30 days. As a data scientist, you'll write your transformations to do so and run it yourself on something like Spark and store it on Redis for inference and S3 for training. You have to keep track of your versioning, jobs, and transformations. You also can't easily share them across data scientists.

Featureform's library allows you to define your transformations, feature, and training sets. It will interface with Spark, Redis, etc. on your behalf to achieve your desired state. It'll also keep track of all the metadata for you and easily make it share-able and re-usable.

The client libraries are all in Python. Much like Tensorflow, even though most of the heavy-lifting is done in a different language, the client feels like native Python. The internals of Featureform's deployed solution benefit from Go's native and lightweight networking and multithreading libraries.

More here: https://docs.featureform.com/system-architecture

A feature is an input to a machine learning model. You can think of a model as a black-box function that takes features and outputs a prediction: prediction = model(features)

For example, If you're building a recommendation model at Spotify, you'll transform a stream of user listens into features like: user's top genre in last 30 days.

Featureform orchestrates the transformations on your infrastructure, manages the metadata like versioning, and allows you to serve them for training and inference.

Mozilla Public License 2.0 is standard, well-known, and OSI approved: https://opensource.org/licenses

Great question! We wrote about this in our blog post: https://www.featureform.com/post/feature-stores-explained-th...

Feast is a literal feature store. it exclusively stores features, it does not manage the transformations used to compute them. The pros and cons of Feast are more obvious when examining the process to change a feature. It happens in three steps:

1. Write and run your new data transformation in your existing transformation pipeline. Note that this happens outside of Feast.

2. A new feature table must be created in Feast, since the old one cannot be directly overwritten. Once the new feature is created the transformation pipeline should be re-run and write all the features to the new table.

3. All the models that use this new feature should be updated to point at the new feature.

Feast also has other problems, for example, it can’t copy your features from the offline to the online store, you have to download the features and upload them to the online store yourself using their CLI tool. You also have to manage retries and failure yourself.

Featureform treats the transformation lineage as part of the feature and orchestrates your infrastructure to create and change your features.

Hey everyone,

I'm Simba Khadder, Co-Founder & CEO of Featureform. I'm super stoked to be sharing our open-source feature store with you all. At my last company, we were building models that served to <100M MAU. Most of our time was spent feature engineering and using off-the-shelf model architectures. I remember having google docs that got shared around with useful SQL snippet, and digging in my file system to find untitled_128.ipynb which had a super useful transformation. We built Featureform so no one would ever have to deal with that again.

Featureform is a virtual feature store. It enables data scientists to define, manage, and serve their ML model's features. Featureform sits atop your existing infrastructure and orchestrates it to work like a traditional feature store.

By using Featureform, a data science team can solve the organizational problems:

- Enhance Collaboration Featureform ensures that transformations, features, labels, and training sets are defined in a standardized form, so they can easily be shared, re-used, and understood across the team.

- Organize Experimentation The days of untitled_128.ipynb are over. Transformations, features, and training sets can be pushed from notebooks to a centralized feature repository with metadata like name, variant, lineage, and owner.

- Facilitate Deployment - Once a feature is ready to be deployed, Featureform will orchestrate your data infrastructure to make it ready in production. Using the Featureform API, you won't have to worry about the idiosyncrasies of your heterogeneous infrastructure (beyond their transformation language).

- Increase Reliability Featureform enforces that all features, labels, and training sets are immutable. This allows them to safely be re-used among data scientists without worrying about logic changing. Furthermore, Featureform's orchestrator will handle retry logic and attempt to resolve other common distributed system problems automatically. Finally, Featureform will monitor and notify you of infrastructure problems and data drift.

- Preserve Compliance With built-in role-based access control, audit logs, and dynamic serving rules, your compliance logic can be enforced directly by Featureform.

You can check out our repo: https://github.com/featureform/featureform

Our docs: https://docs.featureform.com

Our quickstart guide: https://docs.featureform.com/quickstart-local

Read more about feature stores: https://featureform.com/post/feature-stores-explained-the-th...