Last week I wrote about Agent Skills in this newsletter, and the previous week’s newsletter I wrote about MCP. Next I’d like to zoom out the deep dives into each of these areas to better understand how these two standards fit into my diverse API toolbox. If you search for a “diverse API toolbox” on Google, my storytelling drives the  SEO and LLMEO. Mwahahaha! My world domination strategy continuing to play out.  Albeit slower than I originally imagined, but I am finding my footing within on the next version of working on “Maggies farm”.  I’ve regularly hustled at the top of search engine results, and now I’m learning to hustle and tell stories within the agentic universe y’all are crafting for everyone to live in.

All the skirmishes lately between Model Context Protocol (MCP) and Agent Skills and Model Context Protocol (MCP) and Command Line Interfaces (CLI) are signs that the current landscape is beginning to contract into a more realistic, pragmatic, and diverse API toolbox that powers our companies, institutions, organizations, government agencies, and increasingly personal lives. I’ve seen it before with other waves. Not quite to the scope of contraction that wil be required for artificial intelligence. But, it’s happening. People are shifting back to a more level-headed approach to aligning business objectives with what pattern, protocol, and tools we use to integrate our businesses into the vast array of systems and software required to transact at a global scale.

Patterns
I struggle with cleanly separating the layers of the API universe. But, it doesn’t stop me from trying. I start with simple patterns that are universal like REST and RESTful. Patterns are loose, and difficult to validate in a pipeline. Patterns are more philosophy than religion, but some people will always take things to the religious level. Patterns are the top of the funnel for me when it comes to how we do integration—no matter what the application is.

Patterns are like mosaics for me. Some will involve foundational protocols or standards, but will often do so in looser and more ephemeral ways. Things move fast. The cognitive load of protocols and standards is high. Patterns are cheap. Patterns flex and move with us. While there is a standard for Agent Skills and MCP, I see a lot of patterns emerging on top of and around these standards, implemented by different tools, clients, and copilots along the way.

Standards
This is the next level for me after patterns. Standards are a little more formal. More process. More narrative. MCP and Agent Skills are standards. They aren’t quite as mature and governed as OpenAPI, AsyncAPI, and other standards. A2A just reached an important milestone when it comes to standardization recently—version 1.0. This sends an important signal to the ecosystem, which will begin the shift from pattern to standard, refining things along the way.

I support there being many standards. I applaud people who do standards work. It is essential. I am good at championing, cheerleading, and amplifying standards work. I am less good at doing the standards work. I am a big supporter of new and established stewards of standards, and regularly encourage people to support. I think there is a sort of “natural selection” that will occur across all of the standards that stick around in our diverse API toolboxes.

Protocols
Now we are at the foundation of the conversation happening. We are talking about HTTP, HTTP/2, and HTTP/3. I know MCP has protocol in the name, but it is a standard. FTP, IMAP, and other building blocks of our digital world are protocols. There is a significant amount of governance and ecosystem involved with things maturing to the protocol level. Not just in name. We need to get better at elevating protocols as part of our storytelling, making it clear to everyone.

HTTP is a fundamental building block of why the current artificial intelligence works. HTTP is a fundamental building block of the web and of APIs. MCP, Agent Skills, CLI, SDKs, clients, and copilots all build on this foundation, while using a mix of standards and patterns as the glue and fuel. This framing will help me separate the bucket I have right now of standards, into less mature patterns, as well as elevate protocols as part of my spec-driven approach to this moment.

Services
Moving from tracking hundreds of services to over 2500+ as part of my API Evangelist work, I have a new appreciation for a spec-driven approach to integration at this scale. What services do I need to make something happen? What does their HTTP API surface area look like? GraphQL? Otherwise? I usually just need to know one specific slice of what a service provider offers, but I also need ways to discovery and be informed,or even nudged when any service doe something that I may not know about.

I define services as APIs.json. Well, APIs.yaml to be more precise. I index everything a service provider offers. The APIs, MCPs, Skills, SDKs, clients, documentation—anything you can define with an APIs.json property. Documenting thousands of APIs isn’t easy, but there are deterministic and non-deterministic approaches to properly defining the surface area of services across many different industries and business sectors, which I am looking to translate into what is needed to move forward at scale.

Tools
I am fascinated by the MCP vs Agent Skills and MCP vs. CLI debate right now. I love it. Duke it out. This is all part of how we end up defining what are diverse API toolbox contains, and what it does not contain. Honestly I find the scripts, references, and assets of Agent Skills slightly more compelling than the tools, resources, and prompts of MCP. They each provide two different models for looking at the world. I need to overlay A2A with my research to make sure I have a mental map in this realm.

Tools are a pretty wide concept. That is why I like using “API toolbox”. This is my integration toolbox. The is my producing and consuming API toolbox. This is where you put all the other building blocks of integrating with APIs and other data sources. My diverse API toolbox has patterns, standards, and protocols in it, but it also has my scripts, SDKs, clients, copilots, IDE, and other solution, providing something that is looking like something I can effectively manage using Naftiko capabilities.

Signals
One of the tools I have in my diverse API toolbox is called Naftiko Signals. It is a set of Agent Skills I use to make sense of the enterprise landscape every quarter. Naftiko Signals is a GitHub repository where I gather 40 groups of signals, across 250 enterprise organizations spanning 115 industries and 49 sectors. I’ve gathered signals of the different technological areas being invested in across these enterprises, including the services, tooling, and standards that they are using.

Signals are gathered across common public signals like blog posts, press releases, news articles, job postings, and Github repositories. I already have the services and tooling well fleshed out as part of my Naftiko Signals research, but this newsletter is helping me better organize the patterns, standards, and services. I’ll be working through all of the signals I’ve gathered as part of API Evangelist work and Naftiko Signals work and see what relevant context I can provide for Naftiko pilot customers.

Context
The patterns, standards, and protocols separate for providing the context required. I think everyone is taking for granted the ubiquity of HTTP and REST when it comes to what copilots and agents are able to do. This ubiquity needs to be expanded, if we are going to keep moving forward in the AI integration conversation. I see what is attempting to be accomplished with MCP and Agent Skills. We are going to need a lot more domain, tree, and other level context if we are going to do what we desire.

The patterns, standards, and protocols in use across the existing API realm, but also being employed in MCP, Agent Skills, and A2A will be an important layer of semantics we need to make sense of the signal in the noise. I see the potential of MCP in some situations. I see the potential of Agent Skills is other situations. I don’t have my head wrapped around A2A fully yet—will do that next. With both MCP and Agent Skills I see the potential to loose the context that matters if we don’t have some sort of fabric “tying the room together”.

Agents
As I’ve said numerous times before, I’m less excited by the agents as I am for the context mapping and engineering associated with a spec-driven approach. I like the system maps across what is happening. I can see the dots being connected when I look at MCP and Agent Skills, and I’m sure I will see similar when it comes to A2A. Someone has to keep track of all the context, skills, data, poker chips, transactions, or whatever you consider the meaningful bits powering the agentic vision right now using Git and bundles of specs.

I get why people like MCP. It is the same reason I like APIs. It is because MCP is an API. Same as event-driven, GraphQL, gRPC, and others. It’s diverse API toolbox stuff. I really like the standards that emerged as part of the Agent Skills standard, but also the patterns emerging around it. I think there is a lot of potential there. There is also a lot of potential pain and chaos if we don’t manage these little love notes for artificial intelligence we are defining as Agent Skills and plugging into the MCP servers popping up everywhere.

Stories
Agents are stories. They are stories that can reference scripts, assets, and other human and machine-readable bits. I’ve long seen OpenAPI and AsyncAPI as stories about the resources depend on for our businesses. Skills fit right in with that. MCP will have its place right alongside other standards in our diverse API toolbox. But like APIs, MCP, and CLI, Agent Skills will require context. Context to do what we want them to do. Context to ensure they are secure. Context to ensure they do not cause harm. Context in order to be genuinely useful and not waste our time.

I like the storytelling at this level. There is a lot of opportunity to tell stories at this level. There is also a lot of opportunity to get lost. But I see the opportunity in Agent Skills, but also the other PRD, MRD, RULES.md, CLAUDE.md, and other artifacts we are bundling with Agent Skills as part of a spec-driven approach. This is where I think we will achieve the business alignment I’ve been seeking since Postman, and continued to search for at Bloomberg. I am looking for the human and machine readable balance, but also the deterministic and non-deterministic balance to not deliver good enough, but several cuts above.

"For the things we have to learn before we can do them, we learn by doing them." — Aristotle