With the recent release of OpenAI App SDK, our team at Apollo built a stack that lets you use familiar tools (React, Apollo Client, GraphQL) to build conversational apps without thinking about the MCP plumbing.
The architecture here is simple, a React app and Apollo MCP Server(MIT). Today we're talking about OpenAI App SDK, but MCP Apps will soon be in the official spec and we'll see multiple Agent/LLM providers create similar experiences. Our goal is to abstract away all of the provider details from you with a great developer experience, allowing you to focus on building your app instead.
We'll talk through what we've learned so far and where this might be headed tomorrow (Dec 17, 10am PT/1pm ET): https://luma.com/mnl0q7rx
Feel free to try out the repo and let us know what you think! (you will need a paid OpenAI plan to connect it to ChatGPT)
Each of these APIs provide a "playground" like experience where you can sign in and start building/testing/executing operations within the docs page. The playground is a better DX than what you see in a Swagger UI "Try it" button because you can execute a GraphQL request that includes multiple entities. This type of request would typically require orchestrating multiple REST API calls in some code for developers.
A big benefit we've seen in the industry is being able to control the API orchestration for developers. With REST, the developers using your public API are using SDKs (provided or generated) and some code (most likely initially written/scaffolded by an Agent). For whatever use case they are building, they might need to interact with multiple of your endpoints. The code they write to do that is something you have little control over and many API teams will conduct developer interviews to come up with new endpoints that solve situations where a developer needed to call multiple endpoints. A GraphQL operation can be more representative of the intention of your user and allow them to cross endpoint boundaries. They no longer are writing code to orchestrate, just building the operation with the fields of information they need. GraphQL helps bridge those entity connections for developers without having to write code.
There are downsides for using GraphQL for a public API. Your documentation experience is typically different and in the examples I referenced, you can see they all have some "explanation" content that helps a developer understand how to make an API call. This is because GraphQL is less used than REST (33% vs 92% in Postman survey) and a new-to-GraphQL developer has to initially learn how to construct an operation in the playground. Internal developers that are familiar with REST will have to learn how to bring those capabilities to GraphQL (i.e. moving function code from routes to resolvers). It's not much different code-wise, but it's definitely a mind shift.
I also know many companies that use GraphQL for their internal usage of APIs, but provide only an external public REST API (and some of those REST APIs are just a facade over the GraphQL API). I don't think there is a wrong answer here. I personally like GraphQL because it enables an API to encapsulate a lot of business logic that is typically needed to connect entities in our domains. You of course can design REST APIs that give a similar feeling depending on your use case.
I work on DevRel at Apollo. We built this because we kept running into the same problem: getting LLMs to reliably call GraphQL APIs without either (a) dumping the entire schema into context and burning tokens, or (b) hoping the LLM correctly orchestrates multiple API calls. MCP standardizes how agents connect to tools, but you still need to bridge your actual APIs. Apollo MCP Server does this for GraphQL specifically.
We announced the GA release of Apollo MCP Server v1.0 today with Auth and OpenTelemtry support.
Apollo GraphQL announced the official GraphOS MCP Server with a set of tools that enables an Agentic workflow to build a graph. The URL links to the timestamp of my demo, but it shows bringing together Flightradar24 and the Aviation Weather REST API from the FAA using only the OpenAPI spec that the GraphOS tools.
The tools include an ApolloConnectorsSpec tool that provides a concise doc set to the LLM for integrating any REST API. The tool response contains the right context plus additional Apollo documentation links. There are also two additional tools for searching and reading Apollo docs that enables an LLM to gather further context.
These tools are all built on top of a strong foundation with the ability to have an LLM fix any errors it has until it has a complete working graph with your integration. This workflow was designed to help teams quickly bring their REST APIs to the graph with little effort.
Would love any feedback on the direction we're taking this!
The architecture here is simple, a React app and Apollo MCP Server(MIT). Today we're talking about OpenAI App SDK, but MCP Apps will soon be in the official spec and we'll see multiple Agent/LLM providers create similar experiences. Our goal is to abstract away all of the provider details from you with a great developer experience, allowing you to focus on building your app instead.
We'll talk through what we've learned so far and where this might be headed tomorrow (Dec 17, 10am PT/1pm ET): https://luma.com/mnl0q7rx
Feel free to try out the repo and let us know what you think! (you will need a paid OpenAI plan to connect it to ChatGPT)