I recently spoke with Sam Stobbelaar, Senior Full Stack Software Engineer at name.com, about the MCP server he built to give AI agents direct access to name.com’s domain management API. The server lets you search for domains, check availability and pricing, register names, and update DNS records from inside Claude, Cursor, or any MCP-compatible tool.
When name.com set out to build their MCP server in 2025, they were navigating largely uncharted territory. Their initial approach generated lessons about token efficiency and conversational flow that have since become core principles for any team shipping production-ready MCP tools.
The first-generation mapping strategy
name.com’s API has 65 endpoints. When Sam started building, MCP was still a relatively new concept in the industry. The first version of the server followed the logical path of mapping one-to-one with those endpoints, aiming for complete API coverage from day one.
“The first iteration had an individual tool for every single endpoint,” Sam told me. “So there were 60 tools. And that will eat up your context window before you even send a request.”
The reason is how MCP actually works. When a user connects an MCP server to Claude or Cursor, every tool’s name, description, and parameter schema loads into the model’s context window before any message is processed. That metadata occupies real token budget. With 60 tools, the overhead is substantial before a developer has typed a single character.
Sam had a paid Claude account while building the server. Internal testing with a colleague on a free-tier account is what surfaced the token efficiency ceiling early. “Their free tier had such limited token use that as soon as they opened up Claude, it was like, you’re done. You’ve already used everything.”
name.com was among the first teams to hit this constraint at the tool-count level and engineer a solution for it.
The MCP protocol’s own guidance recommends keeping active tools across all connected servers below 40. name.com’s first version was 60 tools from a single server, before accounting for anything else a developer might have connected.
The Composite Tool Pattern
The architectural shift was to move from API-surface thinking to intent-based design, asking what a developer wants to accomplish rather than which endpoints exist to call.
name.com rebuilt around composite tool groups. The “Manage Domains” tool covers DNS record changes, domain renewals, and the other operations involved in managing a domain you already own. A developer asking to update a DNS record doesn’t need a dedicated update-DNS tool. They tell the agent what they want, the agent reads the Manage Domains tool’s context, and it routes the operation appropriately.
The work is in writing tool descriptions that do real routing. A description that just names what the tool is tells the model nothing useful about when to reach for it. A description that explains the range of operations the tool supports, in enough detail that the model can match a user’s stated intent to the right operation, is what makes grouping functional. Getting those descriptions right took multiple rounds of testing against real prompts before the routing became consistently reliable.
The re-engineering was driven by a specific commitment to free-tier users, not just paying customers. Sam framed this as a deliberate design priority: “Probably the biggest takeaway was to focus on those free users as well as those paid users. If a free user wants to check if a few domains are available, they still have a handful of requests to use before they hit that limit.”
Building flow awareness into the tools
Reducing tool count solved the context window problem. A second round of iteration addressed something subtler: the number of conversational round trips required to complete a common task.
The clearest example is the search-to-purchase flow. A developer searches for available domains, picks one, and registers it. If the agent treats each step as an independent operation with no shared context, the user ends up re-specifying information already established in the conversation. Sam described building against that explicitly: “If I’m searching for a domain, my next step will probably be to buy it. You’re making sure the agent understands those general steps in that flow so that it’s not constantly asking, what’s the next thing?”
Two specific details in the implementation are worth noting. Before completing any purchase, the server runs a fresh availability check regardless of what the earlier search returned, because availability can change between a search and a registration decision. And contact information provided during one step is reused for the rest of the session without prompting again.
Security-first by design
The sandbox default reflects a security-first philosophy that Sam describes as deliberate from the start, not a retrospective fix. name.com’s MCP server connects to the sandbox environment unless you explicitly set the production URL in your configuration.
“That intentional step felt very important to us,” Sam said. “Just to make sure things don’t run away from you immediately.”
Agents execute quickly. A developer exploring the server for the first time could complete a real domain purchase before fully understanding the flow. Sandbox as the default makes it impossible to register a domain by accident.
There’s also a secondary catch. Credentials have to match the environment. If you point the server at the production URL but haven’t updated your API token to match, you get an authentication error before any transaction executes. You have to make two deliberate choices to reach live purchases: set the production URL and supply matching production credentials. Neither step is complicated, but together they mean no one ends up buying a domain unintentionally.
Who it actually fits
Sam was direct about where the tool works well and where it doesn’t. “Our biggest use case is the solo developer or maybe a small team that has a handful of domains they manage. As you’re using something like Cursor to build out your new website, this knocks out that one quick step of buying a domain in the same process, without pulling up a website.”
Large domain resellers managing thousands of names in a single account are a different story. “When you have 10,000 plus domains in an account, you might hit a ceiling of how useful this can be, just because you’re querying between so many domains. Usually, you need to drill down heavier within our UI.” Direct API integration backed by a custom dashboard and a dedicated registrar partner fits that use case better than a conversational interface.
What’s next
The server currently runs locally via npx, which means users need npm on their machine and a configuration file edit to get started. Sam described web hosting as the primary item on the roadmap. “That removes the local dependency, and it paves the way to implement OAuth so that you reduce those clicks to get set up. You just throw the URL in your config and you’re good to go.”
Tools like Cursor already support one-click “add to Cursor” buttons for web-hosted MCP servers. That path becomes available once the server is hosted, and it changes the onboarding experience from five minutes of configuration to a single click.
Getting started
Sam’s recommendation for anyone new to MCP is to start with the docs server before touching the domain server. Connect the API Docs MCP, which requires no credentials, and ask it how to set up the name.com MCP server. It’s a faster path to working configuration than reading through documentation manually, and it’s a good low-stakes introduction to how MCP servers actually behave in practice.
When you’re ready to connect the full server, the npm package has configuration snippets for both Cursor and Claude Desktop alongside credential setup instructions. name.com’s main MCP documentation covers the same material with more detail.
Comments
Loading comments…