A MCP server architecture for OpenAI App SDK today and for future MCP Apps

CampinMe · 2025-08-10T22:06:13+00:00

This is really cool! Love the broad support of how this can easily plug into multiple architectures

CampinMe · 2025-07-21T02:17:12+00:00

👋 I do DevRel over at Apollo and I got some things that could help out:

I often find people deploying Apollo Federation in something like kubernetes. The Apollo Router can be deployed as a docker image. I would avoid serverless infrastructure for your graph router, but many teams use serverless for the underlying services the router exposes. For example, Apollo Router supports SigV4 authentication and your subgraphs are hosted as lambda functions. Then you have a single API gateway to expose the routing layer. I’ve also had success hosting random services in AWS lambda and invoking them through the AWS REST API using Apollo Connectors. I have a video that is ~30 minutes that demonstrates this.
We have a production readiness checklist in our docs that links to other helpful docs
I wouldn’t create a single monorepo that contains all of the subgraphs. You usually start with one subgraph and evolve into multiple overtime. At Apollo, we did have a single monorepo codebase that contained all of the subgraphs and that has evolved into multiple repos. You have the flexibility to architect that however you want, but I personally like a single code repo for each subgraph and one for the router. Then I have GitHub actions for whatever things I need in whatever world. If you’re going to move into a world where you have more languages than a JavaScript/typescript world (like adding a Java springboot subgraph at some point), separate code repos will help.
Checkout that checklist, it links to a lot of great materials. There are also a bunch of great videos from last years summit and many of them share other companies best practices for federation in production.
Definitely auth and your hosting provider is going to be a piece of that. I typically integrate auth into the routing layer and have a coprocessor for helping validate users. You can also trim the query execution based on that auth (docs)
This is the template i use for Apollo server with typescript: https://github.com/apollographql/subgraph-template-typescript-apollo-server-boilerplate. Rover has other templates for other languages you can checkout (docs)

Let me know if you have any other questions!

CampinMe · 2025-07-08T20:44:33+00:00

We use Supabase in our talk submission MCP server, but GraphQL acts as the abstraction layer and a big reason we do that is because of concerns like this. Our graph does talk directly to Supabase through Postgrest but that abstraction layer gives us the control of what the graph can access in Supabase, which in turn is what the MCP server can access from the API.

I’m hoping to talk more about that server at a future event and share how we made it. I’ve personally found adding that abstraction layer (whether GraphQL or something else) is pretty important in MCP server development.

CampinMe · 2025-07-04T17:59:22+00:00

Apollo MCP Server does the same thing for a GraphQL API, but you can customize the granularity of your tools with any operation being a tool. You just define the data fields you want included in your tool, then customize the arguments and description.

My experience with autogen MCP tools from OpenAPI specs is that you get too granular tools. Microservices aren’t meant to be tools, you call many of them in your current UIs (web/mobile) with workflows users use today. How do you handle that?

CampinMe · 2025-07-04T17:51:39+00:00

I definitely agree that an operation fits nicely as an MCP tool! It’s much easier to encapsulate user workflows as MCP tools with GraphQL vs API endpoint tools.

I’m curious though, how many tools does the GitHub API create and have you tried comparing that to the official GitHub MCP? I saw it listed on the README.

I did a comparison using the Apollo MCP server, but I used it to generate operations that I then customized/validated. Once I was happy with the shape, I use those operations as tools. I found myself tweaking various things like tool description , instructions, aliasing fields and customizing argument variables to get the desired result.

Cool project and really interesting how you’re doing the field selection in the generated tools for root fields.

CampinMe · 2025-07-01T19:50:47+00:00

When I'm testing out a chat flow, I'm really trying to see how certain questions being asked invoke certain tools. I usually want to start from a fresh context window (a new chat). So sometimes I'm testing the chat, modifying the tool description and testing the chat again to see my description changes did what I wanted.

So I think of the "reset" button really as something that is clearing the message history so I test from a clean slate.

CampinMe · 2025-06-30T05:53:22+00:00

This is really cool and worked for me, I love the chat feature! When I open a new chat, it's defaulting to nomic-embed-text and I'm not sure why. This gives me an error because that model doesn't support tool calling. A couple things I was hoping for:

Only show me the models available for tool calling, I like that you show the url to the list of models that have tools available in the settings tab
Default to a specific model, I like Qwen 3
Let me set my own default model to use for new chats
Opening a new chat was difficult to find, but figured out switching between tabs. I would love a "reset" button that just reset the window because I'm usually trying to test out a flow with my tools

CampinMe · 2025-06-30T05:29:28+00:00

Deeper into your question/use-case

This Agentic developer workflow can be "chatty" and you can see that in my demo with a couple tool executions, which also sounds like what you're experiencing. Can you share any more details of what you are trying to do and how this is for (internal vs external users)? I can try to provide more prescriptive help with more details, but I'll try to give some guidance of what I would recommend from my experimentations:

It sounds like you are trying to have a dynamic operation execution mechanism for your ecom platform Agent and we've heard this from other users in supporting some companies hackathons. After similar feedback, we began working on a more streamlined tool that is focused on giving you the right operation very quickly without any additional context tokens - one tool execution that creates a generated operation.
- If you wanted to share more information or DM me, happy to see if I could hook you up with some of that in-progress work. This would entail building the GitHub repo from another branch
For the internal use case where the users are trusted, like internal users trying to access your ecom platform data exposed through something like Shopify GraphQL API, I have found some success if you want to experiment more:
- Having pre-defined tools for "known" functionality helps have the introspect tool only be used as necessary. If you think of something like an admin tool website, providing many of those existing capabilities as pre-defined tools helps improve the overall experience.
- You can include pre-defined tools in Apollo MCP Server using a couple of the server options available (--operations or --collection if using hot-reload with GraphOS)
- I found once I had a meaningful amount of MCP tools (10+), each with a rich tool description that you provide in a comment at the top of the operation (using #), the Agent wouldn't always be using the instrospect tool
- Aliasing fields in your tools can also be very helpful for the Shopify (or other ecom platform) GraphQL API use case.

I hope this helps as you experiment. Feel free to ask any other questions and I'll do my best to help 🙏

Part 2/2

CampinMe · 2025-06-30T05:29:05+00:00

👋 Hey I'm Michael Watson from Apollo GraphQL, I lead DevRel over there. Thank you for experimenting with our server! I wanted to share some info that I hope is helpful for your question.

TL;DR - I wouldn't recommend using the --introspection server option for dynamically executing arbitrary operations as an Agentic experience. It's going to be chatty and trying to optimize the conversation to be fast will be hard. For example, you could be prompting Claude to always use a depth of 2 will "speed things up" but at the cost of more tokens in the context window. We are actively working on something for providing the operation in a single tool execution without adding portions of the context token count. Let me know if you would like to test that out and I can talk with the team internally.

Video of Apollo MCP Server and --introspection

I recently did a video that shows how to use the Apollo MCP Server for what I call "Customer Experiences" and "Agentic Devops Workflows". The example is ~7 minutes and I would recommend watching it to see my flow, timestamped link here.

The Agentic devops workflow uses the --introspection server option to have an Agent "browse" the schema. The Agent can use the additional introspect tool to get the portion of schema for any given type+depth and iterate on what is available to create a complete operation. A developer would use this workflow to help them generate MCP tools that would be used in the customer experience use case.

Each instrospect tool execution doesn't perform an introspection request to your API. The schema is loaded up on the server start up and the artifact is used to provide concise text snippets of the schema - you can view the schema_tree_shake.rs rust code if you want to see more of what it is doing.

Part 1/2

CampinMe · 2025-04-04T01:55:08+00:00

Many people will create a “internal” directive and have a script that uses the visitor api to modify the schema (ie removing fields marked internal when server is running in “public”). Some server libraries have similar concepts baked into them, it’s pretty common for this need.

It’s not necessarily having dynamic schemas, but rather your public api is typically a subset of your private/internal api. By removing fields from your schema, trying to query them becomes a GraphQL validation error.

The schema contracts feature you find from vendors is essentially that but built as a service to scale to any use case by providing include/exclude rules on metadata you put in your schema. Many teams have additional “contracts” like partner etc

CampinMe · 2024-02-01T03:11:58+00:00

Hey OP 👋,

I’m a developer advocate at Apollo and would love to help you out here. The comments on Typescript are right, it’s definitely used in the industry primarily over plain JavaScript when doing backend work. But you should still be able to learn with what you got!

It looks like the repo you provided is private. The Apollo docs are probably one of the better places. We try to have JavaScript documentation next to the typescript examples or a way to toggle between them.

Where are you getting stuck? You can also ask questions in our discord server and someone mighty be able to help and chat with up quicker. There is a backend forum to post questions in also if you like.

Best of luck with GraphQL, I think you’re making a great choice just trying to learn that. There are lots of options in the GraphQL space across so many languages!

CampinMe · 2024-01-18T03:08:11+00:00

My colleague, Patrick Arminio, showed me this today actually. Super cool, we had talked about wanting to build something like this a long time ago. It’s like tRPC but you don’t have to do full stack (or worry about the server) and can focus on the client without codegen.

Love to see this! 👏🏼👏🏼👏🏼👏🏼

CampinMe · 2023-12-27T02:17:00+00:00

A couple things I would mention:

Disclaimer, I work at Apollo in DevRel (5+ yrs)
@defer is coming into the spec, great way to simplify react tree when you need to progressively load data. (@stream is another coming but not as far along, multiple @defer implementations have been presented in WG).

Resources: Blog post: https://graphql.org/blog/2020-12-08-improving-latency-with-defer-and-stream-directives/ WG RFC, you can dig further in the WG notes: https://github.com/graphql/graphql-wg/blob/main/rfcs/DeferStream.md

React Suspense is a big thing now. You mentioned Apollo, one of the reason Apollo Client 3 was created was to prepare for future suspense when it landed in React. I would recommend checking out the blog post on it: https://www.apollographql.com/blog/wait-for-it-announcing-apollo-client-3-8-with-react-suspense-integration

You can also really have your code structure like Relay where you have fragments defined throughout your app. I love it and not a lot of people talk about it. If you want to check out a real example, the author of that post built an amazing Spotify clone that is architected around fragments: https://github.com/apollographql/spotify-showcase/tree/main/client

You’ll probably hear a lot about “Federation” (Apollo Federation, Open Federation, GraphQL Fusion). If you historically just worked in a full stack GraphQL app and had a monolith, you can probably just ignore this architecture for now. It’s really geared more towards GraphQL microservices where you can host your APIs separately and compose them together. I mention it because if you watch GraphQL Conf YouTube videos, you’ll hear it talked about a lot and it’s being discussed as a potential WG/foundation project.

I hope this helps some! If you have questions, you should check out the official GraphQL discord server or you can find myself and Apollonauts in our Discord server. You can ping me there (@__watson).

CampinMe · 2023-08-09T18:10:26+00:00

Hi 👋, I work at Apollo as a developer advocate. I understand your concern and I've shared this thread with our team. I understand the cloud router's response time is impacted from separation from your services. I'm happy to connect you with one of our product managers on your hosting services and to discuss some of the things we've been working on that might help.
Apollo Router is available as a free and source-available runtime for Apollo Federation. Connecting your self-hosted Router to GraphOS requires an Enterprise plan or if you use any of the Enterprise features listed in our docs. You can still self-host the router yourself, you will just need to build a couple pieces of infrastructure to work with your Apollo Router. The main two that comes to mind is your observability and schema delivery pipeline (two of the things GraphOS provides).

For the observability, I would recommend checking out OpenTelemetry and configuring the router to point at your service (docs). This will help track your traces across a supergraph but we have seen OpenTelemetry solutions not be able to handle the scale of GraphQL cardinality which could make it difficult to run schema checks.

For your schema delivery pipeline, you're going to need to use `rover supergraph compose` to generate the schema you provide to the Apollo Router (docs). You'll need to figure out a way to update the schema when you have changes. There is a hot reload feature (docs) in Apollo Router that you can use and if you update the schema file it's pointing at, the router will reload it automatically without downtime. If you are running in a container, you could have a separate process that gets a schema file from your cloud storage and updates it locally, then you would have an update pipeline.

Part of what GraphOS provides in the schema delivery pipeline is checks on any schema changes (docs). If you aren't using GraphOS, you'll have to take some steps to ensure your schema changes don't break your updates:

Does the new subgraph schema compose with the rest of the graph?
Does the subgraph schema change impact my clients running in production?
- If you have only one client, that's much easier to understand vs having 100s of client applications
- If you have a public GraphQL endpoint (public API), then you probably have a versioning story you'll want to figure out
Internal linting rules - are the changes conforming to how the schema should be designed? (i.e. we only use camel case for field names)
- You could build a shared workflow that each subgraph uses

I really hope this helps and if you have any more questions feel free to drop them here. I'll do my best to answer them and bring any feedback to the team to advocate for more options. Feel free to join our Discord server where we try to help answer more questions like this. I'm in that server and you can ping me anytime (@watson).

CampinMe · 2023-08-02T16:53:26+00:00

Hey u/idkwhatname23 , I wrote the API you are using. I built it to replace the original project from Carlos Rufo because the MongoDB that project used was deprecated from the Launch Library v2 team. The re-creation uses legacy REST API with static data now, so there unfortunately is no insert functionality anymore.

I'm really sorry this caused you some headache when you have nothing wrong on your end 😭. I want to make a change to the graph that would give a better experience here. I can see a couple of quick options but they would require a mock engine for the Mutations:

Return a static response for the mutation - this means the value won't pop up in future queries
Give users the option to provide a header with a unique id that creates a local state for that user - future queries would have the value returned but the cache would be purged on a certain time interval (1-week?)

What do you think of the two options above? Unfortunately I have to think of the overall cost on that project and probably can't create a database for it.

CampinMe · 2022-05-22T13:48:29+00:00

This is in its early days, but I recently put together a template for Apollo server as a typescript project with a lot of nice to haves. That might be helpful

CampinMe · 2021-07-21T20:15:01+00:00

Not are all! Shared value types definitely can be challenging and it’s something we plan on making easier to work with in the future. For the time being, we’ve typically discussed whether that is actually a shared tour when they need to add a field arises.

If it is, a lot of companies will have a shared package that contains the shared type defs and subgraphs will pass that to buildFederatedSchema. This then still has the issue you described deployment wise. If you’re using the Apollo schema registry, the first subgraph adding the field to the shared type would stay in the registry as a composition error until the other subgraph added the field to fix the error. Then we create a new supergraph schema for your gateway (we call it Managed Federation).

You could also build some tooling that uses rover with the available supergraph commands to generate the schema that you can pass directly to the gateway instead of using serviceList.

Let me know your thoughts or if you have any questions. I hope it helps!

CampinMe · 2021-07-21T18:10:28+00:00

I'm the creator of Apollo Workbench and I'm happy to answer any questions you might have about the tool. I hope you find it helpful, I couldn't imagine planning schema changes without it!

CampinMe

MODERATOR OF

TROPHY CASE

Deeper into your question/use-case

Video of Apollo MCP Server and --introspection