“MCP” is quickly becoming the acronym of the year in dev-focused circles. You’ve probably heard enough about the Model Context Protocol to wonder whether it’s more than hype. Before you add it to your developer engagement strategy, take a step back. The real question isn’t whether MCP is trending—it’s whether it actually helps your users solve specific problems.
While this little acronym has emerged in almost every client conversation recently, the hype doesn’t automatically translate to marketing success. In this post, we’ll look at a real example and provide some guidance as you consider whether MCP makes sense as a marketing project.
What is MCP and Why Should Marketers Care?
Marketers of technical products face a constant stream of new acronyms. Over the last two decades, one of those acronyms was “APIs,” which transformed how systems exchange data. Now, large language models (LLMs) like ChatGPT are changing how developers interact with those APIs. The Model Context Protocol (MCP) bridges that gap.
MCP provides LLMs with the context they need to use your API effectively. It’s an additional layer of instructions that help AI models understand not just what your API does, but how and when to use it correctly.
Here’s how it works: developers install an MCP server that connects their LLM tools (like Cursor or Claude Desktop) directly to your API. The server runs locally on their machine and provides the LLM with structured information about your API’s capabilities, authentication, and proper usage patterns.
Developers are already discovering APIs through LLMs—often with mixed results. Without proper context, an AI model might suggest outdated endpoints, incorrect parameters, or unsupported use cases. Alternatively, it might hallucinate instead of accessing accurate data from a structured source, such as your API. MCP facilitates this connection to help a model perform better using your API as input.
Depending on your API and the developers that use it, an MCP server may:
- Expand the use cases your product supports
- Provide developers with new ways to call your API
- Give your company a concrete AI story
There is an expanding number of AI tools of all types. MCP is trending because it bridges AI tools with APIs for both developers and their end users. But these opportunities alone don’t determine whether MCP makes sense for your API.
When MCP Marketing Makes Sense for Your Product
Whether MCP makes sense for your API depends on how customers actually use your product. The key question isn’t whether MCP offers interesting capabilities—it’s whether those capabilities align with your customer behavior and business model. The APIs that benefit most from MCP marketing operate very differently from typical enterprise APIs.
The latest Postman State of the API survey confirms that:
- Most APIs are internal
- Most public APIs support a SaaS
What these stats tell us is that external developers are rarely the audience for modern APIs. It’s engineers inside your organization who use your private APIs to build software for end users. An MCP server may be useful internally, but in this case, it doesn’t need marketing in the traditional sense.
Similarly, a public API that supports a SaaS tends to be used by integrations, likely driven by customer requests. Unless the customers themselves are developers, don’t expect an MCP server to become a significant marketing channel. Think about Slack’s API or Salesforce’s API. Developers use them because their company already uses Slack or Salesforce, and they need to integrate with existing workflows.
This follows our developer marketing continuum: the closer developers are to being your customer, the larger marketing’s role should be.
When we consulted for OpenCage on this very question, our recommendation was to pursue building an MCP server. Here is how I recently used its geocoding MCP server from within my Cursor developer environment:
With the MCP server running on my machine, I instructed Cursor to retrieve latitude and longitude coordinates for every US state capital. The model was able to decipher, thanks to OpenCage’s MCP server, that its geocoding API had the capability to return the data my app needed.
Being technically possible is not the same as being a viable marketing vehicle. Here’s why it made sense for OpenCage to market its API with an MCP server:
- The API is the product, not supporting another product
- 99% or more of their customers use the API
- Authentication is simple, only an API key
As with any development project, there are trade-offs to consider, even if your product is a fit for an MCP server. In OpenCage’s case, the team had available development cycles. There were no competing features, so the MCP project could be prioritized. It’s also a one-time investment: since most MCP servers run locally, there are no ongoing server or maintenance costs.
Though the MCP server was a go, we still had some caveats for OpenCage to consider: namely, not to expect the MCP hype to carry their product to huge gains. We told OpenCage what to watch for and how to quantify progress.
Set Realistic Expectations and Measure Success
You may be impatient for an MCP story, but you need the ending to make sense. To do this, get specific about the problem you’re solving and how you’ll know you’re on the right track. If you know how your MCP server will be used, then you’ll also have a better idea of what it can and cannot deliver for you.
One of the most powerful ways to think about APIs is through use cases. Since we’ve focused on MCP servers to access APIs, it follows that use cases will help here, too. For OpenCage, we recommended that they consider the steps a developer would take that might result in calling its MCP server. Some of the use cases we identified:
- Gather realistic latitude/longitude points to use as testing data
- Batch geocode multiple locations to store as app data
- Build geocoding (reverse or forward) into an application
- Enrich a data source with geographic context
Each of these translates to specific prompting scenarios—a developer asking their AI assistant to “find coordinates for these city names” or “add location data to this CSV file.”
Most of these are ongoing needs, which fit with the expectation that these developers are likely to discover OpenCage through means other than the MCP server. However, it may expand their usage or provide new ways to embed OpenCage further into their stack. Like an SDK, the MCP server doesn’t create demand—it provides a new interface for existing demand. If you treat MCP like an SDK, you should also measure it like one.
OpenCage already has nearly 50 code libraries and SDKs:
The MCP server becomes another way for developers to use OpenCage’s API. Like the Python library serves Python developers and the JavaScript SDK serves web developers, the MCP server supports a growing number of developers who build with AI assistants.
Similarly, MCP likely fits into your existing methods to engage developers. Look first to those areas for measurement. If you include documentation in your attribution, by all means, track whether MCP and AI-related pages drive signups. But also consider how many ways current developers use your API and how their usage is expanded with new interfaces.
It’s still very early for this MCP trend. Expect to learn and adapt as new tools and use cases are developed. For example, in the short time since first consulting with OpenCage about MCP, updates to the MCP specification have already been made, including changes to how it handles authentication. The future of MCP, like APIs, may be more about enabling less technical audiences to make use of these connections.
Your early experiments with MCP could also plant the seeds for future opportunities. Perhaps a customer asks to implement use cases you hadn’t considered. This feedback could both contribute to the product roadmap, as well as your technical content calendar. Both are good for your marketing in the long run, even if today’s MCP server won’t single-handedly drive developer acquisition.
Integrate MCP into Your Developer Engagement Strategy
If you’re a marketer considering MCP, or tasked with announcing it to a developer community, start with the use cases where MCP makes sense for your API. You’ll be most successful with developers when the API is your primary product interface or supports your developer tool.
Don’t look for MCP to be a marketing breakthrough as much as another engagement method in your ecosystem. Instead of replacing your current developer engagement strategy, It should complement. So measure against realistic outcomes like expanded usage and new integration patterns rather than dramatic acquisition gains.
These strategic decisions about developer marketing channels require understanding your specific API, audience, and business model. We help companies navigate these choices, from evaluating MCP to integrating it into your broader developer engagement strategy. If you’re weighing MCP alongside other developer marketing investments, let’s talk about your specific situation.