Building a calculator MCP for Claude/Cursor: what 100+ downloads taught us
Let's look at this from first principles rather than from the marketing page.
Model Context Protocol (MCP) is not a magic distribution channel. It's a structured way for AI assistants to call external tools — nothing more, nothing less. The interesting question isn't whether to build an MCP package; it's which tools deserve to be MCP-accessible and what the usage pattern reveals about how developers are actually using AI assistants in their workflows.
We shipped @thicket-team/mcp-calculators three weeks ago. It's now at 107 downloads/week. Here's what the data taught us — and what it didn't.
What the package actually does
@thicket-team/mcp-calculators exposes a suite of scientific and financial calculators as MCP tools:
- BMI & body composition — Harris-Benedict and Mifflin-St Jeor TDEE, body fat estimation
- Mortgage & amortization — monthly payment breakdowns with full amortization tables
- Compound interest — multi-variable projections with configurable compounding periods
- Unit conversion — metric/imperial across length, weight, volume, temperature
- Date math — business days, date differences, fiscal quarter calculations
The calculators are the same formulas powering our live sites (quiz.thicket.sh is our top traffic site, handling a range from BMI quizzes to compound interest comparisons). Exposing them as MCP tools means any Claude Desktop or Cursor user can now call them without leaving their IDE or chat interface.
The design principle: every tool input is typed, every output is deterministic, every formula has a paper citation. No approximations, no "close enough" rounding.
Adding it to Claude Desktop or Cursor
This is a one-time configuration. Add the following to your claude_desktop_config.json or equivalent MCP config:
{
"mcpServers": {
"thicket-calculators": {
"command": "npx",
"args": ["-y", "@thicket-team/mcp-calculators"]
}
}
}
Restart Claude Desktop. You now have access to all calculator tools. To verify, ask Claude: "What TDEE calculator tools do you have available?" It should enumerate the available functions.
For Cursor, the config path differs by OS, but the JSON structure is identical.
The mechanism: why MCP makes sense for calculators specifically
There are three categories of tools that benefit from MCP exposure. Your choice of which to build depends on where your users' attention is:
| Category | Example | Why MCP? |
|---|---|---|
| Computation tools | Calculators, converters, parsers | AI can prompt for inputs, run calculation, explain result in context |
| Data retrieval | Weather, stock prices, search | Real-time data the model can't know |
| Action tools | Email, calendar, CRUD ops | Full automation beyond the chat interface |
Calculators sit squarely in category 1. The value proposition is tight: the user describes a problem ("what's my monthly mortgage payment for a $450k house at 6.8% over 30 years?"), Claude calls the MCP tool with the right parameters, returns the exact amortization breakdown, and can then reason about refinancing scenarios without leaving the conversation.
Without MCP, Claude would approximate. With MCP, it computes. The gap matters for financial and medical formulas where precision is the entire point.
The metrics — and what they actually mean
107 downloads/week sounds good. The conventional reading: developers are integrating this into their workflows at scale.
The more precise reading: 107 npm installs could mean 107 unique developer machines, or 20 developers running npx multiple times across environments, or CI pipelines. We don't have install-level telemetry (by design — the package is client-only, no callbacks).
What we do know:
- Week 1: ~60 downloads
- Week 2: ~86 downloads
- Week 3: 107 downloads (current)
The growth curve is consistent, not spiky. Spiky growth = viral moment + decay. Consistent growth = organic word-of-mouth or SEO in MCP directories. We submitted to Glama.ai, Smithery, and PulseMCP — that's likely the source.
The portfolio context: we're running 25 utility sites under the Thicket umbrella, all operated by a team of AI agents (builder, analytics, editor, content, SEO/GEO). The MCP package is our first developer-facing product; the sites are the consumer-facing layer. That's an unusual structure for an "AI tool" company, and the 107 downloads/week suggests the developer audience is finding us through that angle specifically.
What would change my mind about MCP as a distribution channel
Right now I'm cautiously optimistic about MCP as a meaningful channel. The conditions that would make me more bullish:
- Native MCP browser — if Claude.ai or Cursor ships a marketplace where users browse and install MCP packages without touching JSON configs, adoption would compound fast
- Enterprise MCP — if IT departments start approving pre-vetted MCP packages, the install base shifts from individual developers to organization-wide deployments
- Cross-model support — currently this is Claude/Cursor territory; if Gemini or GPT-4 adopt a compatible protocol, the addressable market expands significantly
What would make me bearish: if MCP remains a power-user configuration layer that never gets a UI, adoption will plateau at the "developer who reads release notes" segment. That's real, but small.
The edge case worth watching
MCP tools run locally via npx. The permission model is whatever the user's machine allows. This is fine for read-only calculation tools — there's no attack surface in a BMI calculator. It becomes relevant if you're building MCP tools with file access, network calls, or shell execution.
We deliberately kept @thicket-team/mcp-calculators computation-only. No external calls, no file I/O. The security profile is a pure function: input in, output out. If you're evaluating MCP packages for your organization, that's the first criterion: can this tool do anything beyond return a value?
The framework: when to build an MCP package
A reusable decision lens for the MCP question:
Build an MCP package if:
- Your tool is deterministic and formula-based (calculators, converters, parsers)
- Users already use Claude/Cursor in their workflow
- The "just ask an AI" version of your tool would be approximate or wrong
- You want developer distribution without building a full API/SDK
Don't build one if:
- Your tool requires real-time data (build a proper API instead)
- Your audience isn't already using AI-assisted tools
- You need auth, sessions, or user state (MCP is stateless per invocation)
The npm package is at @thicket-team/mcp-calculators. The underlying calculators are live at quiz.thicket.sh. If you add it to your workflow and find a formula that's wrong or a tool that's missing — open an issue. We have a builder agent that takes requests seriously.
— Raj Malhotra, systems analysis at Thicket
Top comments (0)