It is difficult to think like an API consumer when you are an API producer. When I talk to anyone about what I am building at Naftiko, which is extremely API consumer centric, almost everyone I know stumbles while discussing API design, governance, and other considerations—only seeing things from an API producer mindset. The money is in producing APIs, and the real value is generated consuming APIs. APIs don’t exist until they are consumed, but vendors all sell towards producing APIs, so this in turn drives the conversation out on open waters. As I work to define what is different when using Naftiko capabilities to design, document, govern, integrate, or any other things you are going to want to download with an API, I am obsessively focused on what is needed to consume APIs. I am kind of over the API lifecycle, API governance, and other leading API producer ideology produced by the markets and the most passionate API champions within enterprises. Don’t get me wrong. Don’t stop doing it. I am happy to talk about the finer pedantic details of producing APIs, but I’m more interested in us just using the APIs we already have in motion effectively. It feels like we don’t need to be creating more until we have a handle on the ones we already produce, but also consume. A significant portion of the problems we experience with APIs on a daily basis is due to the market heavily focused on an API producer mindset. Learning to think like an API consumer, as well as specially learning to think like your API consumers, is a high value commodity. Doing it reliably over time isn’t easy. Seeing how the APIs you produce fit in with other APIs you don’t own or control is a rare thing to find. Many API producers have integration pages. Few API producers have meaningful workflow and capability pages based upon the most common ways in which their APIs are used with other APIs. This is the important work on the table right now with agents, but if you aren’t able to get out of your defensive API producer mindset and think more about what is needed across service providers and APIs, you are gonna miss a lot. You can use Notion’s MCP server. You can use Figma’s MCP server. You can deploy your own MCP servers. Until you have a specific business capability, or set of capabilities in mind, I am guessing each of those MCP servers do not reflect what you need, and only reflect what each producer wants. For me, the questions really haven’t changed around why we need programmatic interfaces. The power is shifting from an API producer mindset to an API consumer mindset, which breaks us free from the boundaries of a single API producer and is something that reflects what we need across an API. This why Notion’s and Figma’s MCP or API will only get you so far, until you define exactly what resources, functions, tools,…