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
