I think we are in a bit different place than in June. I think there are many more cases where MCP cases have quite a bit "matured" and I was going here and there (including some discussions on MCP during the Airflow Summit) - so let me add what I think now.
1) Yep, I think eventually it would be great to have an MCP server of sorts with basic features and use cases built-in Airflow. I think we can likely come up with some usages that should be quite common and if we allow people to extend their MCP in the way that they deem appropriate, that could be a major win for the community in general 2) The OpenAPI -> MCP direct translation is likely not too good idea. The thing with directly using existing APIs designed for "REST" kind of protocol is quite a bit too chatty for LLMs. You either need a layer on top of the REST API for the LLM to make less number of "calls", or make specific APIs that do more things together than just single API calls. One of the issues is performance, another excessive token usage by agents if the API is too fine-grained. I likely mean separate LLM-specific API. 3) If we follow the "develop our MCP" route - we should likely start with Personas and Actions - typical use cases where we think MCP server could be really useful for humans that want something from running Airflow instance - and the design of the MCP server should spin out of that. Things are evolving fast :) J. On Tue, Oct 14, 2025 at 5:58 PM Shahar Epstein <[email protected]> wrote: > Hey Gyeongmo, > > I've initiated the idea of an official Airflow MCP in dev. list - currently > I put it aside in favor of other ideas that I wanted to implement, everyone > is welcome to take the lead instead. > I'll share some insights, following the recent thread and discussions I had > with people in the latest Airflow summit (including Avi who posted > earlier): > 1. In the recent thread there was a consensus that if we support MCP in the > official project - we should aim it in solving specific tasks (e.g., > debugging Dags) exposing specific endpoints, rather than just being a > complete "mirror" of the current API - reasons are available in the > previous thread. Last time I checked, the latter was anyway technically > impossible due to the current number of endpoints surpassing the max. > allowed number of MCP tools. > 2. Currently we don't have a good way to assess the quality of the MCP > functionality (e.g., prompts) using the Apache's CI, being it Airflow's > repository or another, as we do not have access for AI assessment tools > (like promptfoo), or even LLMs themselves (like GitHub Copilot). For that > reason, supporting official prompts puts us in high-risk in terms of > reliability and security, as results are very not-deterministic due to LLM > nature and the differences between LLM models. Even if someone donates > access to such tools, we'll need to confirm legal aspects with ASF - which > seems unlikely at this point of time. > 3. Following the above, I think that the best thing that we could do at the > moment, as the official repository, is to provide an easier way for > integrating unofficial MCP servers using an official UI plugin (like Avi > created), and the user will just have to provide MCP server connection > details and LLM credentials. If and when we have the ability to support MCP > from end to end (including assessment toolings, and legal approval) - then > we could discuss supporting an MCP server officially. > 4. Regarding the AIP - I created one, but drafted > <https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-91+-+MCP> it for > now. It might be good to have it for agreeing on the standards of the > implementation, but as long as we have it as a separate and isolated > plugin, and it does not affect other components - it might not be necessary > (we could just implement it). > > I'm aware that it is not ideal, and to be honest this is one of the reasons > that I put it aside - > but I think that having an official UI plugin is the best we could do for > now (feel free to challenge my claims in the 2nd bullet). > I'll be happy to put it to a discussion in one of the next dev. calls. > > > Shahar > > > > > On Tue, Oct 14, 2025 at 4:05 PM Gyeongmo Yang <[email protected]> > wrote: > > > > > > > Hi all, > > > > I'm developer of mcp-server-apache-airflow. > > It seems there were already quite a lot of discussion! I couldn't find > any > > other progress on this topic. May I know if there is another thread about > > the same topic? Also, I would love to collaborate on this project too. > > > > If a discussion (and possibly AIP) is already in progress, I'd like to > add > > a few ideas: > > > > • Being a user of my own MCP server, what I thought to be a better option > > is having a MCP server native to Airflow itself. Convenience would be > first > > reason, users wouldn't have to spin up a new server for MCP server. > General > > agreement on MCP looks like we could use it as an interface for agents, > > just like machines(and human) use REST api as an interface. So since we > > have an endpoint for REST api.. I think adding endpoint for MCP is kind > of > > natural. > > • Main usecases of using remote MCP server instead of local one would be > > tilted towards removing redundancy and governance from what my > experience, > > e.g. sharing same configuration in an Airflow cluster and controlling > what > > users can do with the MCP server. So I agree Airflow should let users > build > > MCP server by their own for some extent, but since Airflow holds many > > common parts it could provide common implementation for bootstraping. > Maybe > > it could provide an optional configuration to add mcp server, use a > default > > docker image for mcp server if not specified, and allow users to > customize > > by themselves using a custom image. I think most users won't deviate from > > default implementation. > > > > > > Regards, > > Gyeongmo Yang > > > > On 2025/06/19 15:08:33 Shahar Epstein wrote: > > > > > Apologies for the delay, thanks for your great insights Jarek! > > > I'll consider them when starting to work on the AIP and initial > > > implementation. > > > > > > > > > Shahar > > > > > > On Tue, Jun 17, 2025 at 7:43 PM Jarek Potiuk <[email protected]> wrote: > > > > > > > > > > > I wanted to pass my learnings from the AI Plumbers conference > > > > > https://lu.ma/vqx423ct that I was at just before Berlin Buzzwords. > > This is > > > > > where AI open source "creators" meet and discuss on the "low level > AI > > > > > engineering" - and MCP was one of the subject of the unconference > > part we > > > > > had - and of course I jumped in and took part in it and listened > > (mostly) > > > > > and spoke (a bit) on our case (and listened to feedback) > > > > > > > > > > My take on it - and this summarises > 2 hour discussion we had.... > > > > > > > > > > * MCP is about "intents" of people (or AI imitating people) - not > > about > > > > > what you can do in the system, but what you want to achieve. MCP is > > really > > > > > a bridge between "engineering" driven API which describes low-level > > > > > capabilities of the system and "Product" driven view of what users > > want to > > > > > achieve (so far, so good - using use cases as starting point for > MCP > > > > > running server is likely good idea) > > > > > * There are different users of your system and different > > expectations of > > > > > what they want to achieve. It's nearly impossible to figure out > what > > > > > exactly every single user of Airflow would want from it - we know > > about > > > > > vastly different cases on how airflow is used, and we will likely > > never be > > > > > able to create an MCP server that would not be limited to a very > > small set > > > > > of use cases - which means that if we release an MCP server, it > will > > be > > > > > usable by some but non-usable by others. This is a striking > contrast > > with > > > > > the API approach where we deliberately create an API to be composed > > of a > > > > > small set of actions you can use and basically anyone can tailor it > > to > > > > > their expectations on how they are using it. > > > > > * There is also one important aspect of MCP server that is > currently > > very > > > > > hotly debated - i.e. security. we should make sure that whatever we > > make > > > > > possible to do by the "agent" is not breaking the security > > assumptions and > > > > > model of those who run Airflow. > > > > > * Connected to that - whenever the MCP server has to get more > > permissions > > > > > to get more data that only more "privileged" user can access, there > > should > > > > > be human-in-the-loop involvement where the user can clearly give > > > > > permissions to agent to read specific data - or better, read the > > data and > > > > > hand it over to the agent. This is a crucial aspect in case we have > > some > > > > > parts of the system that require more permission than "default". > > > > > > > > > > In essence - no-one yet knows really how to do "good MCP" - we are > > very > > > > > early stage and things will get better over time in understanding > > what and > > > > > how to implement parts of it - and we should focus now on things > > that are > > > > > "known" leaving the "unknown" for our users to fill (and adapt and > > modify > > > > > in the future) > > > > > > > > > > Generally speaking I think summary of the conclusions I had was: > > > > > > > > > > * The term that I really liked is that we should likely not have > our > > own > > > > > MCP server that people will be treating as a black-box, but that we > > should > > > > > be "MCP READY" -> i.e. we should give our users an option to have > MCP > > > > > server that they will have to configure and adjust in the way that > > will be > > > > > good for them and that they will have to essentially build > > themselves, > > > > > building in prompts, capabilities they expect as "users" from the > > system, > > > > > using the building blocks, scaffolding and tooling that we will > > provide > > > > > them. > > > > > > > > > > * Open API and generating MCP server "base" from it is a good idea > - > > it > > > > > provides a very good base in terms of security and we can turn our > > expert > > > > > knowledge of airflow internals into better describing the API. Ee > > should > > > > > focus indeed (and having a scaffolding) on improving description > and > > > > > documentation of the Open API, use the generator to generate > > "scaffolding > > > > > MCP" from Airflow's openapi and tell the user "Here are next steps > > that > > > > > you have to do in order to have your MCP server" is likely most > > effective > > > > > way and safest. We should not pretend that we can implement the > best > > > > > prompts for our users, most likely users should be able to write > > their > > > > > prompts that will better describe what they want from the system - > > we can > > > > > come with some examples, and guide the user on what they should do > > with > > > > > them and they will have to write, adapt and adjust their prompts - > > > > > especially that each of our users has different dag structure, > > functions, > > > > > criticality, etc. etc. Generally - Airflow is so generic that only > > the user > > > > > who knows their DAGs can properly descibe in a human language what > > they > > > > > might want from the system. Our OpenAPI should have a good-enough > > > > > description that it should be "easy" to describe the MCP prompts > and > > such > > > > > that are good for them. > > > > > > > > > > * the security we have from making sure the MCP server can **only** > > do > > > > > whatever our OpenAPI allows - is already a very good start for > > security. > > > > > But we should also implement a layer of "Human In The Loop" that > > will allow > > > > > the MCP server to have access to more sensitive data - this is > > something > > > > > that we currently do not have, generally allowing the user to > specify > > > > > access to only part of what they have access to - and exposing it > to > > the > > > > > MCP layer in secure way. Without it, MCP server will be very > limited > > in > > > > > many cases as it will not have access to necessary data to make it > > powerful > > > > > enough, but we also (by human in the loop) need to be able to > expose > > more > > > > > data when needed (and control it by the human) > > > > > > > > > > * in essence - rather than having a single "MCP server to rule them > > all" - > > > > > we should have a mechanism that users should be able to build their > > own > > > > > server easily and use some of the building blocks we provide them > to > > do so > > > > > (especially around security). But they should be ultimately in > > control of > > > > > what "intents" they might have when interacting with Airflow. > > > > > > > > > > Those are the thoughts and learnings I had. Maybe that will be > > helpful in > > > > > our > > > > > > > > > > J. > > > > > > > > > > > > > > > On Wed, Jun 4, 2025 at 1:09 PM Jason Sebastian Kusuma < > > > > > [email protected]> > > > > > wrote: > > > > > > > > > > > > > > > > I want to present a use case I have in mind. I think it would > be > > useful > > > > > > > > > > for > > > > > > > > > > > task delay analysis for tasks in complex workflows spanning > > multiple DAGs > > > > > > > or assets. > > > > > > > > > > > > > > We can ask questions like "why does task X finished later than > > > > > > > > > > yestersay", > > > > > > > > > > > where it could fetch upstream tasks and upstream DAGs execution > > durations > > > > > > > from this day and yesterday, use them as context and conclude > > which > > > > > > > upstream tasks causes the delay. > > > > > > > > > > > > > > On Wed, Jun 4, 2025, 5:53 PM Jason Sebastian Kusuma < > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > Glad that my initial slack thread has been brought into an > > interesting > > > > > > > > > discussion. Would love to contribute to this effort. > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > > > Jason Sebastian Kusuma > > > > > > > > > > > > > > > > > > On Wed, Jun 4, 2025, 5:07 PM Sumit Maheshwari < > > [email protected]> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > >> At Uber, we've been using GenAI to debug task failures > > and suggest > > > > > > > > > > > > > > further > > > > > > > > > > > > > > >> mitigation steps to our users. We would love to > > collaborate on this > > > > > > > > > >> project > > > > > > > > > >> and share our learnings & contribute. > > > > > > > > > >> > > > > > > > > > >> On Mon, Jun 2, 2025 at 11:09 AM Amogh Desai < > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> wrote: > > > > > > > > > >> > > > > > > > > > > > > > > > > > >> > I agree that a use case driven approach is the way > to > > go too. > > > > > > > > > > >> > > > > > > > > > > > >> > When we go full-blown, it is easy to lose track of > > the intention we > > > > > > > > > > > > > > > > > >> started > > > > > > > > > > > > > > > > > >> > with. > > > > > > > > > > >> > > > > > > > > > > > >> > Some of the use cases related to debuggability > > improvements is > > > > > > > > > > > > > > > > > >> something we > > > > > > > > > > > > > > > > > >> > already > > > > > > > > > > >> > had a north star for in: > > > > > > > > > > > > > > > https://github.com/apache/airflow/issues/40975, > > > > > > > > > > > > > > > >> > with a good amount of > > > > > > > > > > >> > analysis already done. Maybe you can get some data > > here that will be > > > > > > > > > > >> > useful. > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > Thanks & Regards, > > > > > > > > > > >> > Amogh Desai > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > On Fri, May 30, 2025 at 9:27 PM Avi > > <[email protected]> > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > >> > > Hi All, > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > Had a chat with @Kaxil. And we discussed on > > use-case first > > > > > > > > > > > > > > approach > > > > > > > > > > > > > > >> > rather > > > > > > > > > > > > > > > > > > > >> > > than opening up to all possibilities, on > building > > and maintaining > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > >> MCP > > > > > > > > > > > > > > > > > > >> > > server. > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > A few use-cases which I had in mind were: > > > > > > > > > > > >> > > - Debugging task failures > > > > > > > > > > > >> > > - Schedule sparse across all dags for better > > resource utilization. > > > > > > > > > > > >> > > - Recommend provider usage in place of native > > python codes. > > > > > > > > > > > >> > > - Cross-DAG Dependency Analysis > > > > > > > > > > > >> > > - Migration/Refactor Planning > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > We would need an ongoing effort on this, as > every > > other day > > > > > > > > > > > > > > > > something > > > > > > > > > > > > > > >> new > > > > > > > > > > > > > > > > > > >> > > comes up. Could be more optimization, or newer > > use-cases. We also > > > > > > > > > > > > > > > > > > >> need to > > > > > > > > > > > > > > > > > > >> > > maintain the security aspect of if. Like, where > > do we recommend > > > > > > > > > > > > > > > > > > >> running, > > > > > > > > > > > > > > > > > > >> > > auth and transport methods, etc. > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > I made a new release today with FastMCP and > > discovery of tools > > > > > > > > > > > > > > based > > > > > > > > > > > > > >> on > > > > > > > > > > > > > > > > > > >> > > category. After seeing today that FastMCP mount > > and sending > > > > > > > > > > > > > > refresh > > > > > > > > > > > > > >> the > > > > > > > > > > > > > > > > > > >> > > tools list notification is working (*which it > > wasn't 3 months > > > > > > > > > > > > > > > > back*). > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > Things I have on my roadmap: > > > > > > > > > > > >> > > - HTTP based transport specifically for OAuth > > currently it is > > > > > > > > > > > > > > stdio > > > > > > > > > > > > > >> only > > > > > > > > > > > > > > > > > > >> > > for it to be installed in a plugin > > (*airflow-wingman*) as a > > > > > > > > > > > > > > > > > > >> dependency. > > > > > > > > > > > > > > > > > > >> > > - Waiting for search tools to be implemented. > > > > > > > > > > > >> > > - Decide to bake prompts with the server, > perhaps. > > > > > > > > > > > >> > > - Very minimal Docs as a resource which tells > > about recent changes > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > >> > > Airflow behavior (Example: *every LLM till date > > still tries to > > > > > > > > > > > > > > write > > > > > > > > > > > > > > > >> > > schedule_interval instead of schedule*) > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > @Shahar feel free to take a lead and see if > there > > are things you > > > > > > > > > > > > > > > > would > > > > > > > > > > > > > > > >> > like > > > > > > > > > > > > > > > > > > > >> > > to cherry-pick from it. > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > Thanks, > > > > > > > > > > > >> > > Avi > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > On Fri, May 30, 2025 at 9:57 AM Avi < > > [email protected]> wrote: > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > >> > > > 💯 agreed > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > On Fri, May 30, 2025 at 9:52 AM Kaxil Naik < > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > wrote: > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> Agreed > > > > > > > > > > > > > >> > > >> > > > > > > > > > > > > > >> > > >> On Fri, 30 May 2025 at 15:18, Jarek > Potiuk > > <[email protected]> > > > > > > > > > > > > > > > > > > > > >> wrote: > > > > > > > > > > > > > > > > > > > > >> > > >> > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > Yeah, I think none of us want to just > > publish the code and be > > > > > > > > > > > > > > > > > > > > > >> "done" > > > > > > > > > > > > > > > > > > > > >> > > >> with > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > it ... There is a real work to be > done > > to make MCP much more > > > > > > > > > > > > > > > > > > > > > >> useful > > > > > > > > > > > > > > > > > > >> > > and > > > > > > > > > > > > > > > > > > > > > > >> > > >> "AI > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > friendly" and the examples you gave > > Brian are cool, because I > > > > > > > > > > > > > > > > > > > > > >> think > > > > > > > > > > > > > > > > > >> > we > > > > > > > > > > > > > > > > > > > > > >> > > >> need > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > to (and this is mostly the ask from > > maintainers for the users > > > > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > >> > come > > > > > > > > > > > > > > > > > > > > > >> > > >> and > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > participate in the design phase of > > what the MCP can do). > > > > > > > > > > > > > > >> > > >> > It looks like that "backbone" of the > > MCP and the glue between > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > >> > REST > > > > > > > > > > > > > > > > > > > > > >> > > >> API > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > and MCP can be done in a simple (and > > easy to maintain) way. > > > > > > > > > > > > > > > > > But > > > > > > > > > > > > > >> the > > > > > > > > > > > > > > > > > > > > >> > > >> added > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > value is indeed in figuring out what > > would be useful missing > > > > > > > > > > > > > > > > > > > > > >> things > > > > > > > > > > > > > > > > > >> > - > > > > > > > > > > > > > > > > > > > > > > >> > > >> > starting from what broad use cases we > > want to address - and > > > > > > > > > > > > > > > > > > > > > >> whether > > > > > > > > > > > > > > > > > > > > >> > > >> some > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > help for the agent can be described > as > > prompts, better > > > > > > > > > > > > > > > > > > > > > >> description > > > > > > > > > > > > > > > > > >> > of > > > > > > > > > > > > > > > > > > > > > >> > > >> the > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > API and examples or maybe we need > more > > aggregated, new APIs > > > > > > > > > > > > > > > > > > > > > >> (maybe > > > > > > > > > > > > > > > > > > > > >> > > >> simply > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > new REST API calls we need) that will > > allow the agents to > > > > > > > > > > > > > > > > > > > reason > > > > > > > > > > > > > > > > >> > > better > > > > > > > > > > > > > > > > > > > > > > >> > > >> and > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > faster. All of that is possible. > > > > > > > > > > > > > > >> > > >> > > > > > > > > > > > > > > > >> > > >> > J > > > > > > > > > > > > > > >> > > >> > > > > > > > > > > > > > > > >> > > >> > On Fri, May 30, 2025 at 11:29 AM > Kaxil > > Naik < > > > > > > > > > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > >> > > >> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > You can easily add as many tools > > you want: > > > > > > > > > > > > > > > >> > > >> > > > > https://gofastmcp.com/servers/tools > > > > > > > > > > > > > > > >> > > >> > > > > > > > > > > > > > > > > > >> > > >> > > I would be surprised if there is > a > > thing you can't do with > > > > > > > > > > > > > > > > > > > > > > >> FastMCP > > > > > > > > > > > > > > > > > > > > >> > > >> 2.0+ > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > that you can do with the MCP > > Python SDK. > > > > > > > > > > > > > > > >> > > >> > > > > > > > > > > > > > > > > > >> > > >> > > Like I said earlier: This is a > > simplistic example :) but > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > >> gist > > > > > > > > > > > > > > > > > >> > is > > > > > > > > > > > > > > > > > > > > > >> > > >> we > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > should be using the newer > > abstractions which I am happy to > > > > > > > > > > > > > > > > > > > > > > >> comment > > > > > > > > > > > > > > > > > > > > >> > > >> during > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > the development phase too. Like > > everything else we need to > > > > > > > > > > > > > > > > > > > > > > >> ensure > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > maintainability is worth the > value > > we create. > > > > > > > > > > > > > > > >> > > >> > > > > > > > > > > > > > > > > > >> > > >> > > > > > > > > > > > > > > > > > >> > > >> > > > > > > > > > > > > > > > > > >> > > >> > > On Fri, 30 May 2025 at 14:48, > > Kaxil Naik < > > > > > > > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > >> > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > > Btw we don’t need to use > > FastMCP just for create MCP from > > > > > > > > > > > > > > > > > > > > > > > > >> > OpenApi > > > > > > > > > > > > > > > > > > > > > >> > > >> spec. > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > > Many of you mighht already be > > aware - FastMCP 1.0 was > > > > > > > > > > > > > > > > > > > > > > > >> adopted in > > > > > > > > > > > > > > > > > > >> > > the > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > > official mcp python sdk since > > 1.2 and is recommended > > > > > > > > > > > > > > > > > > > > > > > >> high-level > > > > > > > > > > > > > > > > > > > > >> > > >> server > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > > framework. > > > > > > > > > > > > > > > > >> > > >> > > > > > > > > > > > > > > > > > > > >> > > >> > > > Check: > > > > > > > > > > > > > > > > >> > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.2.0 > > > > > > > > > > > > > > > > > > > > > >> > > >> > > > > > > > > > > > > > > > > > > > >> > > >> > > > @Bryan Coder: I will be > > surprised if you can’t do the > > > > > > > > > > > > > > > > > > > > > > > >> use-case > > > > > > > > > > > > > > > > > >> > you > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > > mentioned with FastMCP - > > either the one donated to MCP > > > > > > > > > > > > > > > > > > > > > Python > > > > > > > > > > > > > > > >> > SDK > > > > > > > > > > > > > > > > > > > >> > > or > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > > FastMCP 2.0 - have you tried > > that? It isn’t just a > > > > > > > > > > > > > > > > > > > wrapper! > > > > > > > > > > > > > > > > > > > > >> > > >> > > > > > > > > > > > > > > > > > > > >> > > >> > > > On Fri, 30 May 2025 at 13:16, > > Avi > > > > > > > > > > > > > > > > > > > > > <[email protected] > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > >> > > >> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > >> Yeah FastMCP is nice, I > > didn't select fast mcp for this > > > > > > > > > > > > > > > > > > > > > > > > > >> > specific > > > > > > > > > > > > > > > > > > > > > > >> > > >> > reason: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > >> - The sheer number of > tools > > that are created using > > > > > > > > > > > > > > > > > > > > OpenAPI > > > > > > > > > > > > > >> spec > > > > > > > > > > > > > > > > > > > > > >> > > >> > doesn't > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > >> need to be passed to AI > > every single message. > > > > > > > > > > > > > > > > > >> > > >> > > >> - Instead, we can do a > > hierarchical tool discovery based > > > > > > > > > > > > > > > > > > > > > > on > > > > > > > > > > > > > > > > > > > >> > > >> > categories. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > >> And > > > > > > > > > > > > > > > > > >> > > >> > > >> let AI select a particular > > category and then get tools > > > > > > > > > > > > > > > > > > > > > > only > > > > > > > > > > > > > > >> for > > > > > > > > > > > > > > > > > > > > >> > > >> that > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > >> category. > > > > > > > > > > > > > > > > > >> > > >> > > >> > > > > > > > > > > > > > > > > > >> > > >> > > >> python3 -c " > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > >> > import json > > > > > > > > > > > > > > > > > > >> > > >> > > >> > with > > open('path/to/openapi.json') as f: > > > > > > > > > > > > > > > > > > >> > > >> > > >> > spec = json.load(f) > > > > > > > > > > > > > > > > > > >> > > >> > > >> > > > > > > > > > > > > > > > > > > > >> > > >> > > >> > tags = {} > > > > > > > > > > > > > > > > > > >> > > >> > > >> > for path, methods in > > spec['paths'].items(): > > > > > > > > > > > > > > > > > > >> > > >> > > >> > for method, details in > > methods.items(): > > > > > > > > > > > > > > > > > > >> > > >> > > >> > if 'tags' in details: > > > > > > > > > > > > > > > > > > >> > > >> > > >> > for tag in > > details['tags']: > > > > > > > > > > > > > > > > > > >> > > >> > > >> > tags[tag] = > > tags.get(tag, 0) + 1 > > > > > > > > > > > > > > > > > > >> > > >> > > >> > > > > > > > > > > > > > > > > > > > >> > > >> > > >> > print('Tags and their > > counts:') > > > > > > > > > > > > > > > > > > >> > > >> > > >> > for tag, count in > > sorted(tags.items(), key=lambda x: > > > > > > > > > > > > > > > > > > > > > > > x[1], > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > >> reverse=True): > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > >> > print(f'{tag}: > {count}') > > > > > > > > > > > > > > > > > > >> > > >> > > >> > " > > > > > > > > > > > > > > > > > > > > [message truncated...] > > > > Sent with Spark > > >
