sfaist

superglue (yc w25) | Founding Engineer | Onsite in Munich, Germany, 70-100k + 0.5-2% Equity

superglue is an integration layer for developers, agents, and enterprises. Our open source product enables users to integrate and orchestrate APIs via natural language at a higher reliability (91%) than any general purpose model. We are making agents actionable.

We can move from first contact to decision in less than two weeks.

Reach out to stefan@superglue.ai

We would've assumed that the llms are much better at writing working code since it's not random APIs but rather established API patterns which they should be able to one-shot (e.g. Stripe). Bad error messages are a problem indeed. We will release another one with retries very soon.

Quite interesting actually. not sure why, I assume it just overthinks. What suprised me even more is how bad o4-mini performed, after taking up hours of evaluation time and more credits than all other llms combined. More thinking != better (integration) coding performance

The reason we think this would be interesting to share here is that these llm benchmarks seem increasingly disconnected from reality. idc if the llm can solve a PhD math question or make scientific discoveries, I care if it can solve our problems, which in our case is automating API integrations. Turns out it mostly can't, which tracks well with our experience using cursor.

Hi folks, I'm Stefan, founder of superglue. To be upfront, we are building an integration agent and had this mildly weird idea of exposing the capabilities through MCP and see what happens if an agent can build its own tools. Beyond using this in Cursor to build data pipelines and integrations faster, we have limited ideas on what to do with this, but it is interesting enough to post. So let us know if you can think of something useful or fun.

Hey HN, I'm Stefan, co-founder of superglue. Adina and I started working on automating data pipelines and transformations about a year ago. Folks love our agent for building and maintaining data pipelines, and we thought it would be fun to let another agent do all the work that's left. Our goal here is to make this process as easy and painless as possible, and we'd love to hear how you deal with building and maintaining data transformations right now, and if this is a value add.

Sure, email me: stefan@superglue.cloud

Thanks!

my personal understanding (anyone feel free to correct me here) of MCP is that it is basically a standardized interface for tool use. So, if you as an API provider (e.g. stripe) want agents to connect to your API, you can offer an MCP server that serves as a middleman between you and the agent. What we fundamentally do is serve also as a middleman, but not (primarily, yet) for agents, but for normal (non-AI) applications that would otherwise need to use the REST/SOAP/whatever API with a bunch of integration code. Also, MCP does not do any data transformation, that would be on the agent to do.

Not quite. The server runs standalone, so you can use it just as you would use linux as part of your project without affecting your own code. The client libraries that become part of your code are MIT licensed. The reason we made this decision is to prevent AWS & co from copying all of our code without contributing to the project.

If you're self-hosting, you can bring your own model and there are no limitiations. For the hosted version, we currently do custom pricing agreements with our customers using this in prod, and keep it free for hobbyists within fair use limits. We still need to figure out what the boundaries will be, tbh.

On your open source question, we accept contributions from non-team-members and have done so in the past, particularly on bugs or new features on the backend.

Thanks for sharing! We're taking a bit of a different angle here. The APIs we are looking at are not the ones that websites are using, but rather then ones you would typically integrate with when thinking about data integrations. Also, while you could use superglue as an MCP server, the usecases we see right now are less in the AI / agent world but rather in the workflow / ETL / onboarding world.

That being said, the mitmproxy2swagger approach is really really cool as an alternative to mindless scraping.

self healing is already a feature :)

Thanks! The primary reason is because we want folks to be able to run this locally and contribute to the project / fix issues as they come up. This is much harder when you have a black box tool and rely on our small team for support.

Thanks for flagging this. Odd. Did this happen on the website or in the actual app? Might be a server overload looking at our logs.

depends on your usecase: - this abstracts away a lot of the complexity, including pagination and format conversion. Also integrated logging and schema validation. - this is self-healing, so when data comes through that you have never seen before or if the api changes it is a lot less likely to break. - if you need to integrate a lot of APIs, or if you have multiple apps needing access to these apis, it is much easier to set up here than writing 1000s of lines of integration code. If none of this is important / applies to you and the generated code works well, then you could also just do that.

Yes, it does update and cache changed schema for the target API. At runtime. The way it works that every time you make a call to superglue, we get the data from the source and apply the jsonata (that's very fast). We then validate the result against the json schema that you gave us. If it doesn't match, e.g. because the source changed or a required field is missing, we rerun the jsonata generation and try to fix it.

I guess you could regularly run the api just to make sure the mapping is still up to date and there are no delays when you actually need the data, depending on how often the api changes.

you can give it any context you have, worst case in text form, and the llm will try to figure it out, call different endpoints etc. Recently someone mentioned to me the intern test by Hamel Husain: if avg college student can suceed with the given input (with a lot of trying and time), then llms should be able to do it too. So that's the bar we're aiming for.

No api at all is out of scope for now, there are other tools that are better suited for that.

working on it... ping me if you have a usecase in mind and I can set it up for you.

Sure! We use structured output for the endpoint, but not for the jsonata since it's hard to actually describe as a format. 3 big levers for accuracy / reducing hallucinations: 1. direct validation: we apply the jsonata that is generated and check if it really produces what we want (we have the schema after all). This way we can catch errors as they come up. 2. using a reasoning model: by switching to o3-mini, we were able to drastically improve the correctness of the jsonata. takes a bit longer, but better waiting a bit than incorrect mappings. 3. using a confidence score: still in development, but sometimes there are multiple options to map something (e.g. 3 types of prices in the source, but you only want one. Which one?). So we're working on showing the user how "certain" we are that a mapping is correct.