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] > >
