Live data from Hacker News

Show HN: EnrichMCP – A Python ORM for Agents

github.com

21–30 of 35 posts

Re: Show HN: EnrichMCP – A Python ORM for Agents

#21
post #7

This looks very interesting but I’m not sure how to use it well. Would you mind sharing some prompts that use it and solve a real problem that you encountered ?

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, pul…

Why wouldn't we just give the agent read permission on a replica db? Wouldn't that be enough for the agent to know about:

- what tables are there

- table schemas and relationships

Based on that, the agent could easily query the tables to extract info. Not sure why we need a "framework" for this.

Re: Show HN: EnrichMCP – A Python ORM for Agents

#22
post #21
post #7

Earlier quoted context omitted.

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, pul…

Why wouldn't we just give the agent read permission on a replica db? Wouldn't that be enough for the agent to know about: - what tables are there - table schemas and relationships Based on that, the agent could easily query the tables to extract info. Not sure why we need a "framework" for this.

Disclaimer: I don't know the details of how this works.

Time-to-solution and quality would be my guess. In my experience, adding high level important details about the way information is organized to the beginning of the context and then explaining the tools to further explore schema or access data produces much more consistent results rather than each inference having to query the system and build its own world view before trying to figure out how to answer your query and then doing it.

It's a bit like giving you a book or giving you that book without the table of contents and no index, but you you can do basic text search over the whole thing.

Re: Show HN: EnrichMCP – A Python ORM for Agents

#23
post #21
post #7

Earlier quoted context omitted.

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, pul…

Why wouldn't we just give the agent read permission on a replica db? Wouldn't that be enough for the agent to know about: - what tables are there - table schemas and relationships Based on that, the agent could easily query the tables to extract info. Not sure why we need a "framework" for this.

Because you also need proper access controls. In many cases database access is too low level, you need to bring it up a layer or two to know who can access what. Even more so when you want to do more than read data.

Re: Show HN: EnrichMCP – A Python ORM for Agents

#24
post #12

Earlier quoted context omitted.

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 r…

So explicit model description (kind of repeating the schema into explicit model definition) provides better results when used with LLM because it’s closer to the business domain(or maybe the extra step from DDL to business model is what confuses the LLM?). I think I’m failing to grasp why does this approach work better than straight schema fed to Llm.

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.

Re: Show HN: EnrichMCP – A Python ORM for Agents

#25
post #19
post #7

Earlier quoted context omitted.

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, pul…

Cool. Can you give the agent a db user with restricted read permissions? Also, generic db question, but can you protect against resource overconsumption? Like if the junior/agent makes a query with 100 joins, can a marshall kill the process and time it out?

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.

Re: Show HN: EnrichMCP – A Python ORM for Agents

#26
post #4

Super interesting idea. How feasible would it be to integrate this with Django?

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

That's fantastic to hear. Did they configure django to use sqlalchemy as the ORM or were they able to make it work with django's?

Re: Show HN: EnrichMCP – A Python ORM for Agents

#27
post #4

Earlier quoted context omitted.

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

That's fantastic to hear. Did they configure django to use sqlalchemy as the ORM or were they able to make it work with django's?

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

Re: Show HN: EnrichMCP – A Python ORM for Agents

#28
post #16

> agents query production systems How do you handle PII or other sensitive data that the LLM shouldn’t know or care about?

You could implement field-level access controls with attribute decorators that mask PII during serialization, similar to how SQLAlchemy's hybrid_property can transform data before it reaches the agent context.

Re: Show HN: EnrichMCP – A Python ORM for Agents

#30
post #16

> agents query production systems How do you handle PII or other sensitive data that the LLM shouldn’t know or care about?

That's an odd question. If you have a regular ORM how do you handle sensitive data that your user shouldn't know about? You add some logic or filters so that the user can only query their own data, or other data they have permission to access. It's also addressed directly in the README. https://github.com/featureform/enrichmcp?tab=readme-ov-file#... I know LLMs can be scary, but this is the same problem that any ORM…

> You add some logic or filters so that the user can only query their own data, or other data they have permission to access.

What you are talking about is essentially only row level security (which is important for tenant seperation), while in the case of integrating external service providers, you column level security is a more important factor.

> I know LLMs can be scary, but this is the same problem that any ORM or program that handles user data would deal with.

In most other progams you don't directly plug your database full of PII to an external service provider.

In most other programs you don't have that same problem because the data takes a straight path from DB -> server -> user.

The README repeats an example that makes the user's email available for an agent to query (enabling PII leakage), setting a bad precedent in a space that's already chock-full of vibe coders without any concern about data privacy.

Post reply on HN