I'm curious, what issue does that solve? I'm only working on agents that make tool calls via HTTP in a home baked way but I can't imagine how resolving the tools from 2 MCP servers is harder than 1.
The issue is when you have many MCP tools the context becomes too large for the LLM. So Nexus indexes all the tools and lets you search for the right tool and then execute it.
Thanks, I think I get it now. In our case I've dealt with this problem by refactoring the monolithic agent into smaller agents, smaller, more specific prompts, fewer, more relevant tools.
We've found that monolithic agents just don't perform that well.
Here are a few key differentiators vs LiteLLM today:
- Nexus does MCP server aggregation and LLM routing - LiteLLM only does LLM routing
- The Nexus router is a standalone binary that can run with minimal TOML configuration and optionally Redis - LiteLLM is a whole package with dashboard, database etc.
- Nexus is written in Rust - LiteLLM is written in Python
That said, LiteLLM is an impressive project, but we're just getting started with Nexus so stay tuned for a steady barrage of feature launches the coming months:)
The main difference is that while you can get Nexus to list all tools, by default the LLM accesses tools by semantic search — Nexus returns only the relevant tools for the what the LLM is trying to accomplish. Also, Nexus speaks MCP to the LLM, it doesn't translate like litellm_proxy seems to do (I wasn't familiar with it previously).
GraphQL Federation has historically been constrained by the complexities of managing subgraphs, custom integrations, and infrastructure overhead. While existing solutions provide ways to unify GraphQL APIs, they still require significant operational effort. Until now.
We’re excited to introduce Grafbase Extensions, a powerful new way to customize and enhance your GraphQL APIs without the hassle of building and maintaining additional infrastructure. With WebAssembly-powered extensions, you can federate any API, database, or service into your GraphQL schema, whether it’s REST, gRPC, or Kafka. With Extensions, you can bring in any authentication (e.g. OpenID connect) or custom authorization logic directly into the gateway.
Grafbase Federated Graphs are spec compliant with Apollo Federation. We've invested a lot in the developer experience of building an deploying GraphQL APIs. Local development, the Grafbase SDK and the Grafbase dashboard were built from the ground up to be easy and efficient to use.
GraphQL APIs deployed to Grafbase are also deployed to the edge by default, but can now also be deployed in your own infrastructure.
Thanks - what is your sweet spot use-case do you think? I've built a few GraphQL projects in the past, so I'm curious where you fit into the ecosystem?
Luis from Fauna here - confirming that we are working with partners like Grafbase, who can provide a fully featured GraphQL experience for use with Fauna. We are working with the Grafbase team to help them integrate with our new version of FQL and take advantage of the declarative schema support we have added to Fauna. Get in touch with us if you want to discuss more. -L
GraphQL really shines when it comes to providing a unified data layer for frontend teams. Having a consistent, typed API is a big time saver for developers building data rich applications.
The ability for frontend teams to shape the data they need without talking to a backend developer and reduce the number of requests made to the API makes for a perfect match when building high performance applications.
