MCP servers by theluckystrike

Practical Model Context Protocol servers for people who work inside Claude, Cursor and other MCP clients.

Every server runs locally over stdio, keeps all data on your machine, and has a genuinely useful free tier.

Pro unlocks the limits for a one-time payment: $19 per server or $39 for the bundle, lifetime. Eight of the

nine products are also reachable as a hosted remote endpoint with no install at all (see below).

\* npm publish is still pending for all nine packages (see npm status below). Until then, the fastest path is the

`.mcpb` one-click bundle from the

latest release -- double-click it in Claude

Desktop and it installs, no terminal needed. Or clone and build:

`git clone https://github.com/theluckystrike/mcp-servers.git && cd mcp-servers`, `npm install`,

`npm run build -w packages/mcp-license -w servers/`. Each server's README has the full 60-second install

with all three client configs.

Buy Pro: https://mcp.zovo.one (keys verify offline with Ed25519; no phone-home).

Hosted endpoints (no install)

All eight servers are also live behind streamable HTTP, for clients that connect to a URL instead of

spawning a local process:

• Base URL: `https://mcp.zovo.one/mcp` -- `GET` returns an index of the endpoints; each server is

`https://mcp.zovo.one/mcp/` (time-tracker, price-tracker, spreadsheet, invoice, expense-tracker,

currency, docx, timezone).

• Auth: `Authorization: Bearer `. `GET https://mcp.zovo.one/mcp/token` mints a free anonymous token

(`anon_`, 30-day KV TTL, refreshed on every request); a Pro license key (`MCPL1....`) works the same

way and lifts the free-tier limits.

• `spreadsheet` runs in inline-data mode remotely, since a hosted worker has no disk to read a path from:

`sheet_load {name, csv}` or `sheet_load {name, xlsx_base64}` loads the data into the request's virtual

filesystem first, then `sheet_query`, `sheet_stats`, `sheet_add_column` and `sheet_convert` work on it as

usual. The stdio install is still the answer for files that live on your own disk.

• `currency` shares one ECB rate cache across every tenant instead of paying for it per token: the daily and

historical rate files are hydrated read-only from `shared:ecb:daily` / `shared:ecb:history` and never

written into any tenant's document, so the endpoint keeps no per-token state at all.

• `docx` accepts an upload the same way spreadsheet accepts inline data (`doc_upload` replaces a file path),

and every generated `.docx` comes back as the real binary Word file behind a download link, not HTML.

• Anything else a tool would normally write to a file (an invoice PDF, a CSV export, a converted spreadsheet,

an .ics invite) comes back as a download link, `https://mcp.zovo.one/mcp/download/`, valid for one

hour; invoices render as an HTML document rather than a PDF on this path.

• office-suite is not hosted: it is a stdio proxy that spawns the other eight as local child processes, which

has no meaning on a remote worker. Install it locally to get all eight in one config line instead.

Registry names

The MCP registry listing for all nine of these servers uses word-rich names instead of the plain directory

name, for example `time-tracker-timesheet-billable-hours` instead of `time-tracker`, or

`office-suite-time-invoice-expense-excel-price` instead of `office-suite`: every extra token is a word the

server's own tool descriptions already use, and registry search matches on whole words, so a name built only

from `time-tracker` was invisible to a search for "timesheet" or "billable hours". The full list, read from

each server's `server.mcpb.json`:

The old short names are deprecated on the registry; npm package names, directory names and checkout URLs are

unchanged.

Why these nine

The median MCP server on the public registry gets installed and never called again. Looking at what actually gets

used, two things separate the servers people keep: a config snippet that works on the first try, and a visible

demo of the tool actually answering a real prompt before anyone installs it. Both of those are cheap to provide and

most servers skip them -- READMEs bury the config three scroll-lengths down, or show no output at all. These servers

were picked because they replace a task people already do in a spreadsheet, a SaaS dashboard or a browser

tab (tracking time, watching a price, editing a sheet, cutting an invoice, logging a receipt, converting a

currency, drafting a Word document, finding a meeting slot across time zones) with one that runs

entirely on-device: no account, no telemetry, no server-side data at rest (the hosted endpoints are the one

exception, and they say plainly what they keep and for how long). office-suite exists because the most-used

server in this category, measured across the registry, is an aggregator: one install beats eight.

Guides

• Track time in Claude Code
• Invoice PDF from chat
• Read Excel in Cursor
• Price drop alerts with Claude
• Expense tracking in Claude
• MCP server free vs pro
• Currency conversion, ECB rates, in Claude
• Word documents and proposals from chat
• Meeting slots across time zones

Also live: 54 client-by-server setup pages (six clients: Claude Desktop, Claude

Code, Cursor, VS Code, Windsurf, Cline, times nine servers) and 8 head-to-head compare pages

against named competitor MCP servers, sourced from each competitor's own README, GitHub metadata or npm/registry

record.

Validation

Before anything ships: 321 unit tests across the nine servers and the shared license package (protocol smoke

tests over real stdio, plus adversarial cases: bad input, oversized strings, path traversal, concurrent

writers, zero-byte files), a 184-check live validation database run against the built servers and the hosted

worker (`data/validation.json`, run 50), seven rounds of user-value testing through a real MCP client (one

prompt per conversation, not a unit test; round 7 is cross-server, chaining calls across the whole

office-suite bundle), and four rounds of independent Codex model review of the core build plus two more of the

remote hosted worker. Details: docs/AUDIT.md, docs/CURRENCY_AUDIT.md,

docs/DOCX_AUDIT.md, docs/EXPENSE_AUDIT.md,

docs/TIMEZONE_AUDIT.md, docs/USER_VALUE.md through

docs/USER_VALUE_R7.md, docs/CODEX_REVIEW.md through

docs/CODEX_REVIEW_V4.md, docs/CODEX_REVIEW_REMOTE.md,

docs/CODEX_REVIEW_REMOTE_V2.md, docs/REMOTE_RESULT.md.

npm status

None of the nine packages are on npm yet (the account's publish token is dead; see

docs/NPM_AUTH_RESULT.md). The working install paths today are the `.mcpb` one-click

bundle from the latest release, a clone and

build from source, or the hosted endpoints above -- no local install at all. The `npx` lines in this README and

in each server's own README start working the moment npm publish succeeds; nothing else about them changes.

Human-gated surfaces

A few distribution surfaces cannot be finished by an agent and are waiting on one human step:

• npm -- publish token is dead; needs `npm login --auth-type=web` once, in a browser, from this account.
• Smithery -- CLI and REST are otherwise fully scriptable with a bearer key, but getting that key needs one

browser login: `npx -y @smithery/cli auth login`, then open the printed `smithery.ai/auth/cli?s=`

URL. `smithery.yaml` is already validated against the CLI schema.

Everything else in this repository -- registry, GitHub, `.mcpb` release, billing, hosted endpoints, guides,

setup pages, compare pages, Docker MCP catalog PR, Cline marketplace issues, mcpservers.org and mcpmarket.com

submissions -- was completed without a human at the keyboard.

Repository layout: `servers/*` one package per server, `packages/mcp-license` shared licensing, `billing/` Cloudflare Worker

that sells keys and serves the marketing site (guides, setup pages, compare pages) through Stripe Checkout,

`remote/` Cloudflare Worker serving the hosted endpoints, `dashboard/` status page, `docs/` runbooks.

Built by theluckystrike. https://github.com/theluckystrike Support: support@zovo.one