The classic B2B lead magnet is a PDF behind a form. It still works in places, but more of the research my buyers do now happens inside an AI assistant, and an assistant cannot fill in a gated form on someone's behalf. So I asked a different question: what would a lead magnet look like if the first "visitor" were an AI client, not a person? My answer was a public Model Context Protocol (MCP) server that exposes the free calculators on this site as tools an assistant can call, plus search over my articles and a way to book or request a call. This piece explains what the server does, the choices I made while building it, and how I measure it. I am deliberately not quoting usage numbers here. The point is the design and the measurement plan, which you can copy whatever your numbers turn out to be.
What the server actually exposes
The server runs at rahuldsarker.co/api/mcp and is listed in the official MCP Registry under the name co.rahuldsarker/growth-tools. It is public and needs no account. The bulk of it is 116 calculators covering marketing, RevOps and SaaS unit economics: ROAS, LTV to CAC, CAC payback, CRM ROI, Rule of 40, lead scoring, creative fatigue and so on. Each one takes numbers in plain language from the assistant, returns a result, and where a sensible benchmark exists, attaches a verdict with the band it falls in and the source of that band. Next to the calculators sit a small set of non-calculator tools. search_content and read_content let an assistant find and quote my articles and case studies with links. check_availability reads my live calendar and returns open slots, each with a link that opens the booking form with that time preselected, so the person still confirms on the site. request_callback sends a contact request, but only with the person's agreement. There are also a few guided prompts, such as a unit economics health check and an ad account audit, that chain several tools together. None of this is new content. It is the same calculators and articles the site already had, made callable.
Why calculators make a better magnet than a PDF
A lead magnet has to do two jobs: be useful enough that someone uses it, and create a natural next step toward a conversation. Calculators are unusually good at both inside an assistant. The assistant is already being asked questions like "is my CAC payback too long?" and would otherwise answer from general knowledge. A tool gives it a deterministic formula and a benchmark band instead, which is a better answer for the user and a reason for the assistant to prefer the tool. The output also creates the next step on its own terms. A number like a 22-month payback period raises an obvious follow-up question, which is what to do about it, and that is the conversation I want to have. A PDF cannot do this. It is static, it cannot use the person's numbers, and an assistant cannot read it from behind a form anyway. I also liked that calculators are low risk to expose. They are arithmetic with no external calls and no personal data, so publishing them openly costs me nothing I would otherwise protect.
Design decisions that mattered
A few choices shaped the build. First, tool descriptions are written for the model, not for a human browsing a menu: what the tool computes, which inputs it needs, and when to use it. Second, the server offers two endpoints. The default lists every calculator as its own tool. A compact variant, at ?toolset=compact, lists only the core tools and reaches calculators through find_calculator and run_calculator, because some clients cap or struggle with long tool lists. Third, results return structured content plus a small interactive widget for hosts that support MCP Apps, and plain text for those that do not. Fourth, missing inputs are requested through a form where the client supports elicitation, rather than having the model guess. Fifth, the tools that do real work are rate limited per IP: content search, calendar reads and callback requests. Callback requests are also capped per email and per day in the database. That last one matters because a public endpoint that can create leads is also a public endpoint that can create spam.
Consent and the callback tool
The one tool that sends personal data, request_callback, is built around consent. Its description tells the model to use it only when the person asks to be contacted. Where the client supports forms, the server asks the person to review and submit their own details, and nothing is sent until they press submit. Where it does not, the tool requires a confirmed flag that the model should set only after showing the person the exact details and getting a yes. I chose this deliberately over a faster flow. An assistant that quietly submits someone's details to a consultant is a bad experience and, depending on where the person is, a compliance problem. The booking route is even more conservative: check_availability only returns links, and the person books on the site. Both paths record which AI client the request came through, so I can see whether a lead arrived via Claude, ChatGPT, an IDE agent or something else, without storing what the person typed into the calculators.
What I measure, and how
Measurement has three layers. The first is server-side logging of protocol events. After each response is sent, the server records the method (initialize, tools/list, tools/call, prompts/get, resources/read), the client name it reports, the tool or prompt called, the session id and the country header. Tool arguments are never stored. That tells me which clients connect, which tools are actually used, and whether sessions go beyond a single call. The second layer is links. Every link the server returns, to a calculator, an article, the booking page or the consultation page, is tagged with utm_source=mcp, utm_medium=ai-agent and a utm_content value naming the tool or page that produced it. So when someone clicks through, analytics attributes the visit to the server and to the specific tool. The third layer is the CRM. Callback requests arrive as leads with source set to the MCP callback and the AI client recorded, and bookings made from an MCP link carry the UTM values. That lets me follow a lead from tool call to conversation without guessing.
What to copy if you build your own
If you are weighing an MCP server as a lead magnet, start from what you already have that is useful and computable: a pricing estimator, an ROI model, a benchmark table, a product configurator. Do not build new content for the server. Write tool descriptions as if briefing a capable assistant. Keep anything that touches personal data behind explicit consent and rate limits. Tag every outbound link so the traffic is attributable, and decide before launch which numbers you will judge it on: connected clients, tool calls per session, click-through to the site, and leads with an MCP source. Then list it in the official MCP Registry, which publishes server metadata through a namespace you verify by GitHub or by your own domain. Be realistic about scale. Discovery of MCP servers is still young, so treat this as a long-term asset that compounds with your content, not a channel that fills a pipeline next month. If you want to try mine, the setup instructions are on the MCP page.
Sources
Model Context Protocol, Introducing the MCP Registry (8 September 2025): https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/ . Model Context Protocol documentation: https://modelcontextprotocol.io . Server details described here come from the rahuldsarker.co MCP server itself: https://rahuldsarker.co/mcp
FAQ
It can create the conditions for one: a useful answer inside the assistant, a tracked link back to your site, and a consent-based way to request contact. Whether it produces meaningful lead volume depends on how often assistants are asked questions your tools answer. Measure it with UTM-tagged links and a dedicated lead source before judging it.
Tag every link the server returns with UTM parameters, for example utm_source=mcp and a utm_content value naming the tool. Log protocol events server-side, such as which tools are called and by which client, without storing tool arguments. Record leads from the server with their own source value in the CRM.
It is reasonable for tools that are pure calculation or public content. Anything that reads live systems or sends data should be rate limited, and anything that submits personal details should require the person's explicit confirmation. Mine rate limits content search, calendar reads and callback requests, and caps callback requests per email and per day.