> Jarek, dismissing MCP as “just a REST wrapper” misses the point: the *only* way an agent can safely touch Airflow today is via the same RBAC-governed REST we already ship. Calling that a weakness is backwards—it’s the guarantee.
Yes. I understand that part and agree that having REST protocol and RBAC/Authentication is good from a security point of view for MCP design - because MCP protocol provides exactly *0* security - it's been designed for "easiness" of use, with complete disregard for security. I personally think MCP security is the **biggest** issue with MCP approach - there have already been multiple security incidents with MCPs and we are barely scratching the surface on what's possible there. We **just** recently had the first case with [1] when hackers actually used local configured agents of the victims and literally employed the agent (with the victims tokens being used for it1 to find and steal even more information after initial breach. So yes making the MCP use strong authentication and REST protocol is strength (because the API permissions might limit the damage) - that part is clear. I have not named a "general" REST as a weakness - I was mostly saying that REST designed for deterministic API consumption (traditional open-api) is not the best solution for MCPs (mostly because of performance and number of token burned). If only for security reasons - maintaining our own MCP server is a serious decision in this context. And I could also very well see for example a combination of the two - It feels pretty reasonable that we could have an MCP server that will actually directly expose the "Skills" defined as local folders (and those skills might actually contain instructions to call REST API in some cases). Today that looks like a good idea. But will that be a good idea tomorrow ? I have completely no idea. One thing I know - we are experts in scheduling deterministic workflows - not in building Agents, and we should rather hear and be open to what's coming - not necessarily figuring our own ways of doing things if others are already doing it. [1] https://www.trendmicro.com/en_us/research/25/i/npm-supply-chain-attack.html On Sat, Oct 18, 2025 at 11:18 AM Jarek Potiuk <[email protected]> wrote: > I think space is so "dynamic" that we do not know yet what things will be > used next year - not to mention the next 5 years. And if we do not see a > clear reason why releasing and maintaining something by us is better than > having others do it - we can always opt for "not" doing things here (and > still stay relevant - also because of community solutions that others > developed and might have good incentive to maintain). > > I keep on repeating it - code is not always an asset, quite often it's a > liability and we need - in the community - to make conscious decisions if > we want to take on the liability of maintaining the code or not. > > > Just to be clear, I'm not saying we have to do anything, at this point. > > Creating MCP servers using REST is already possible, and POC exists. Like > > mine and Gyeongmo Yang's. > > > We can wait until we see the ask from users. > > Yep. I do not see a clear "ask" from the users, to be honest, but It would > be great to hear from you, Avi and Gyengmo more about how users are > using your MCP, whether it's popular, whether there is a churn of users > etc. etc. THAT would be really valuable input to the discussion here, > because without hard data we might only speculate. > > And when we have the data - we could decide - to do or not to do it even > if users ask. We could easily let the "community" MCP servers do what they > already do. IMHO - If we do not release our "own" MCP server - but there > are available MCP servers out there that people can use, it's also a viable > option. There are many similar cases and MCP is no different. > > We already do it (deliberately) for example for things like DagFactory and > Cosmos - that is now provided (alongside other tools > https://airflow.apache.org/community/ ) - by Astronomer. They have very > good incentive to maintain both, they add value to the community, and we do > not have to bear the costs (I know for a fact - rather high in terms of > time, energy, focus and maintenance overhead) of both. We have been toying > with the idea of doing similar things in the community, but so far we have > other things that we want to focus on. > > Also In the past for years we did not have our own chart - there was > https://github.com/airflow-helm/charts - by Matthew that was heavily used > and we released our own. In the hindsight, I personally think that was a > mistake to be honest (we should not have it at all) - we have troubles with > maintaining our chart, PRs gets unreviewed for a long time, we release the > chart very rarely and I think we have no good idea in the community how to > change that - it became a burden for us, and it could be burden for others > (but also opportunity - Matthew build a good business on supporting his > chart and running consultancy). > > We also have to remember that any thing we decide - as a community - to > focus on means that we will not do something else (i.e. the cost of lost > opportunity). Adding something new to Airflow we release always takes away > from other things that could have been done. > > Eventually - as everything here - it's up to a vote if we can't reach a > consensus - and for now it seems that there are different opinions :) > > There are always trade-offs. > > J. > > > > On Sat, Oct 18, 2025 at 8:34 AM Avi via dev <[email protected]> > wrote: > >> Just to be clear, I'm not saying we have to do anything, at this point. >> Creating MCP servers using REST is already possible, and POC exists. Like >> mine and Gyeongmo Yang's. >> We can wait until we see the ask from users. >> >> - Avi >> >> On Sat, Oct 18, 2025 at 11:51 AM Avi <[email protected]> wrote: >> >> > Hi All, >> > >> > Respectfully, I beg to differ. >> > >> > Jarek, dismissing MCP as “just a REST wrapper” misses the point: the >> > *only* way an agent can safely touch Airflow today is via the same >> > RBAC-governed REST we already ship. Calling that a weakness is >> > backwards—it’s the guarantee. >> > >> > Josef, “just use the CLI” is fantasy outside a laptop. Production >> Airflow >> > lives behind Helm, Ingress, service-mesh and audit logs. Handing an LLM >> a >> > kube-exec shell annihilates every one of those controls and leaves zero >> > audit trail. >> > >> > And waving “Claude Skills” as the future ignores every OSS, on-prem and >> > multi-model deployment that will never see Anthropic. If Airflow wants >> to >> > stay relevant to *all* users, a small, opt-in MCP shim over the existing >> > API is the minimal, secure, vendor-neutral step. >> > >> > Before we crown any single approach, let’s ask the community and >> customers >> > how they actually want AI to help them—then build the thinnest, safest >> > bridge that satisfies those needs, whether that’s MCP, CLI wrappers, or >> > something else entirely. Until then, wrapper over REST with streamable >> HTTP >> > method is the safest bet. >> > >> > - Avi >> > >> > On Fri, Oct 17, 2025 at 10:30 PM Ferruzzi, Dennis <[email protected]> >> > wrote: >> > >> >> To add wood to this fire... I'll take this to a different thread if you >> >> want, but it's mostly-related. Has anyone tried a local NotebookLM >> >> instance with access to the Airflow repo? I know the main theme of >> this >> >> thread if a user-facing LLM that can answer questions about their >> >> environment but I've been thinking of a dev-facing tool with access to >> the >> >> codebase for questions like "show me where we decide which executor to >> send >> >> a task to" or whatever. NotebookLM seems to be a tool specifically >> >> designed for aggregating data across many files with optimized search >> and >> >> correlation algorithms and may be super handy. >> >> >> >> >> >> - ferruzzi >> >> >> >> >> >> ________________________________ >> >> From: Jarek Potiuk <[email protected]> >> >> Sent: Thursday, October 16, 2025 9:13 PM >> >> To: [email protected] >> >> Subject: RE: [EXT] [DISCUSS] Apache Airflow official MCP Server >> >> >> >> CAUTION: This email originated from outside of the organization. Do not >> >> click links or open attachments unless you can confirm the sender and >> know >> >> the content is safe. >> >> >> >> >> >> >> >> AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur >> externe. >> >> Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne >> pouvez >> >> pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain >> que >> >> le contenu ne présente aucun risque. >> >> >> >> >> >> >> >> czw., 16 paź 2025, 13:07 użytkownik Josef Šimánek < >> >> [email protected]> >> >> napisał: >> >> >> >> > čt 16. 10. 2025 v 13:02 odesílatel Jarek Potiuk <[email protected]> >> >> napsal: >> >> > > >> >> > > 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. >> >> > >> >> > I got success pointing LLM agents to use airflow CLI to communicate >> >> > with local Airflow instance during development (of both Airflow and >> >> > DAGs), just by pointing it to various useful commands like run dag to >> >> > validate the code change using "uv run airflow dags test abc" and >> vice >> >> > versa. >> >> > >> >> >> >> >> >> Indeed - this is something I also keep in hearing that maybe you can do >> >> better without MCP and relying on better instructions described locally >> >> rather than via server (or derived by the LLM from CLI) - because >> >> basically >> >> this is what MCP does (but by burning a lot more tokens usually). >> >> >> >> Interestingly enough - Claude just today "Claude Skills: Customize AI >> for >> >> your workflows \ Anthropic" https://share.google/Snyqd7mN6peUUmxEn >> >> proposed something way simpler and likely more powerful - Claude >> Skills - >> >> see also this - pretty informative - article "Claude Skills are >> awesome, >> >> maybe a bigger deal than MCP" https://share.google/X3P1OLqDwnrdVb3vD . >> >> That >> >> seems way 'closer' to the Personas and Actions I thought we need to >> think >> >> about anyway for agents. It might be that we could simply describe >> Skills >> >> that airflow LLM might use and have a simple folder in our repo that >> will >> >> describe how agent might use CLI and API to do regular tasks and we are >> >> done (people might simply point to it in GitHub or local folder for the >> >> Agent to use). And it's pretty nuch just structured documenting on how >> >> agent (or human) can do certain things. >> >> >> >> That sounds pretty promising and way more straightforward than the >> whole >> >> MCP frenzy. I also read some studies that because of semantics >> differences >> >> and lack of coherence between MCP servers and the way how the protocol >> is >> >> underspecified, agents are struggling when they have tasks with several >> >> MCP >> >> servers involved and their performance and quality drastically drops. >> >> >> >> It"a a Wild West currently :) we should definitely avoid rushing here >> IMHO >> >> - but carefully listen what's going on - we might be chasing a rabbit >> all >> >> the time. >> >> >> >> J >> >> >> >> >> >> > > >> >> > > 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 >> >> > > > > >> >> > > > >> >> > >> >> > --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: [email protected] >> >> > For additional commands, e-mail: [email protected] >> >> > >> >> > >> >> >> > >> >
