What about an experimental mcp server that we could ditch on a whim as a middle ground?
> On Oct 18, 2025, at 05:39, Jarek Potiuk <[email protected]> wrote: > > >> >> 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] >>>>>> >>>>>> >>>>> >>>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
