From time to time we feature guest posts from folks in the MCP ecosystem doing interesting things. This post comes from Matt Dailey, founder of Ref, who navigated the unique challenge of pricing what may be the first standalone paid MCP server.
The Model Context Protocol ecosystem is exploding with servers from the community and teams at existing SaaS products. Ref is different. It's possibly the first standalone MCP server built as a paid product from the ground up.
This presents an interesting challenge: How do you price something that's never been priced before, in a market where users expect everything to be free?
We had to balance individual developers making 10 searches a day versus agents making thousands, high web crawling costs versus users who only see value when they search, and an ecosystem where everything else is free versus building a sustainable business.
Our solution: A credit-based system with 200 free credits that never expire, followed by $9/month for 1,000 credits ($0.009 per search). Users only pay for searches, not indexing, and the monthly minimum covers our fixed costs while scaling with actual usage.
It's working well: Since launching with this pricing and packaging 3 months ago, Ref has thousands of weekly users and hundreds of subscribers with more signing up and subscribing everyday.
This article covers the strategic decisions that led us to our final pricing. Our hope is that it will be helpful to others facing similar challenges.
Your Product, Your Competition, Your Cost-Drivers
What makes
Comparable Products
We needed to understand what people are already paying for similar capabilities and how Ref differentiates itself.
Paid search APIs: Tavily and Exa both offer agent-focused search and scraping services, charging roughly $0.01 per search with volume discounts. Both have popular MCP servers, making them relevant benchmarks for pricing and positioning.
Free documentation tools: Context7 provides a free MCP server with basic RAG for documentation, primarily from public GitHub repos.
Our positioning: Ref sits between Context7 and Tavily/Exa, offering premium documentation search specifically for coding agents. Ref has two key differentiators: (1) the search precision and (2) the ability to build private indexes of your team's documentation alongside our curated public index.
Our Cost Drivers
Understanding our cost structure was essential for building a sustainable pricing model. Ref incurs costs in three main areas:
- Search infrastructure - Turbopuffer hosts our search indices, charging for both data storage and query volume.
- AI processing - LLM costs in our retrieval pipeline, in addition to the base Turbopuffer query costs.
- Web crawling - Our highest expense: compute resources for running the web crawler that keeps documentation current.
This creates both variable costs (spiky query volumes) and fixed costs (ongoing index maintenance), which our pricing needed to accommodate.
Making Strategic Decisions
Our starting point was understanding our product, competition, and cost-drivers. Next, we needed to tackle the philosophical questions and strategic choices that would shape our pricing approach.
Who We're Building For
Our alpha testing revealed three distinct user segments:
- Individual engineers using AI coding agents to search documentation is the most common use case.
- Small teams that want to share an account. It’s pretty common for small teams to have a single service account they share. In fact, since all you need is an API key to access Ref, we encouraged this use case to help roll out Ref to an entire team by just sharing a single key.
- Agent developers integrating Ref into tools used by many users. This is much less common but could result in one account making significantly more requests than a single developer or even a team would make.
We needed a pricing scheme that supports both individuals doing tens of queries a day and teams or agents doing thousands. There is a wide range of possible usage volumes that our pricing had to accommodate.
What to Charge For
You could think about this in two ways:
- Cost-based: Charge for the work done on behalf of the user (indexing)
- Value-based: Charge for the value provided to the user (search results)
It’s tempting to focus only on pricing to match the underlying cost because then you’re certain that each operation you do on behalf of the user is profitable. For us, that would mean billing for each repo and PDF a user indexes in Ref.
But it's crucial that the value customers receive feels obvious when you ask them to pay. For Ref, everything leads up to getting the perfect search result. Users only get value when they search.
You might argue that maintaining an up-to-date search index is valuable in itself. After all, the core problem Ref solves is that LLMs hallucinate and lack the latest docs. But that value is only realized when users actually search.
With all that in mind, we decided to charge only for searches, not indexing.
This creates a key point of tension our pricing needs to resolve: charge only based on search volume while still covering our ongoing indexing costs.
How to Structure a Free Trial
These days, nearly all software products have a free option, so we considered that a requirement. This is especially true for MCP servers where nearly everything is free or a free add-on to an existing product.
A tempting option would be to give away some features for free and ask users to upgrade for advanced ones. Ref could have provided our public index for free and charged for private indexes, but we chose a different path.
We took the stance that Ref is a premium product and the purpose of the free tier is to let users evaluate whether they want to pay. Users will either come to the product and eventually upgrade or find a different solution. This framing helped us design the free tier to meet both our users' needs and the business's needs.
To truly evaluate a product, users need to test drive every feature. They shouldn't be forced to imagine what it would be like to index their PDFs. They should be able to try it for free, see that it works, and do so enough times that when it comes time to upgrade they can be certain whether Ref solves their problem.
The key decision: usage-based limits, not time-based.
A straightforward two-week free trial wouldn't match our wide range of usage patterns. A single developer might not search much in two weeks and reach the end unsure about upgrading. An agent developer might make thousands of queries in two weeks at significant cost to us.
Our constraints became clear: offer Ref for free with every feature available, but limit the trial based on usage, not time.
Our Solution: Credit-Based Pricing
Our strategic decisions led to some clear constraints:
- Support wide usage ranges from solo developers to deployed agents.
- Charge for searches, not indexing.
- Cover ongoing indexing costs despite only charging for searches.
- Offer a full-feature free trial.
- Limit trials by usage, not time.
A usage credit system with a minimum monthly commitment is the pricing scheme that satisfies all of these.
How it works: Our MCP server has two tools, (ref_search_documentation and ref_read_url), each billed at 1 credit per call. New users get 200 free credits that never expire to try the product. We estimated 200 searches represent approximately 10 weeks of casual usage for a normal developer in Cursor or Claude Code, so this felt generous. If someone can make 200 searches and still isn't sure if the search results are helpful, then Ref probably isn't the product for them.
The pricing structure: To upgrade, users pay $9 per month for 1,000 credits and can buy additional blocks of 1,000 credits for $9 each. This works out to $0.009 per search, aligning with other search services like Exa and Tavily.
Why this works: The monthly commitment covers our ongoing indexing costs while additional credit purchases allow usage to scale from individual developers to high-volume agents. Users only pay for the value they receive (searches), but we still cover our fixed costs.
This usage-based pricing is common with AI products, and we feel it's fair to users while supporting our business model.
In many ways, MCP servers follow the same pricing fundamentals as other software products. You need to solve a real problem, help users understand the value of that solution, and cover your operational costs.
But MCP introduces unique challenges:
The free ecosystem challenge: MCP is new and nearly everything else is free. When competing against free alternatives, communicating your value becomes critical. Users need to immediately grasp why your solution is worth paying for.
The dual identity problem: An MCP server can serve individual humans making occasional requests or autonomous agents making thousands of calls. This means you're simultaneously building an API business and a traditional SaaS product, requiring pricing that works for both scenarios.
The ecosystem timing advantage: As early pioneers in MCP monetization, we're not just pricing our product but helping establish market norms. The decisions we make now could have an influence on the MCP ecosystem.
The MCP protocol is still young, but its potential to standardize AI-data connections could mean that paid services could become more common.
Building in an emerging ecosystem means everything feels both familiar and completely new, and that makes it exciting.