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 >
