so 18. 10. 2025 v 8:22 odesílatel Avi via dev <[email protected]> napsal: > > Hi All, > > Respectfully, I beg to differ.
All I see is just disrespect in your response to others sharing experiences. > 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. I have never written "just use the CLI", I have shared that for my use case of local development (of Airflow and dags) I had success using CLI. I just shared my experience. > 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]
