Equipment maintenance log: assets, service entries with costs, and a due report computed from stored dates. You add each piece of equipment once - name, serial or asset tag, where it lives, the currency its costs are in - and it comes back with an AST-YYYY-NNNN id, a second asset with the same tag refused because a serial identifies one machine. maintenance_log records the work: the day, what was done, the cost in whole cents, who did it, and when the next service falls due, as a date or as an interval in days, never both, and a future work date is refused. maintenance_due is the report: what is overdue and by how many days, what falls due within the next N days (30 unless you say otherwise), what is scheduled later and what has no schedule at all, computed from the stored dates at the moment you ask, so the register cannot go stale. asset_history reads one asset's whole log in chronological order with the total spend in integer cents and the spend per technician, and maintenance_export hands a date range over as CSV or a Markdown summary per asset. An asset carrying a log cannot be removed without confirm: true, because removing it loses the record of work done; the AST number is never reissued.
asset_history and maintenance_export of CSV are free, unlimited and write nothing new, so leave them enabled permanently and read an asset's log as often as you like. maintenance_log is the deliberate one: next_due or interval_days, never both, and work dated in the future is refused.
| You say | Tool |
|---|---|
| Add the combi boiler, serial SN-88-4412, at 14 Nowa Street flat 3, EUR. | asset_add |
| Log the annual service on the 9th, 120.00 by Acme Heating, next due in 365 days. | maintenance_log |
| What is overdue or coming due this month? | maintenance_due |
The contract suite drives the eight tools over real stdio: the fourth asset is refused and nothing is written, a duplicate tag is refused, next_due and interval_days together are refused, a logged asset needs confirm to remove, and the only files written are assets.json and counter.json. The due report is asserted as computed at call time: an interval becomes a date once, at log time, and nothing about overdue is stored.
The file is .cursor/mcp.json, and the key inside it is mcpServers.
| Scope | Path |
|---|---|
| This project only | <project>/.cursor/mcp.json |
| Every project | ~/.cursor/mcp.json |
If you also run Claude Desktop, the shortest path there is one click: maintenance-log.mcpb
from the latest release opens as an extension, with no JSON and no terminal.
Cursor reads its own config, so here it is:
The config block:
{
"mcpServers": {
"maintenance-log": {
"type": "stdio",
"command": "node",
"args": ["/absolute/path/to/mcp-servers/servers/maintenance-log/dist/index.js"]
}
}
}The node command above wants a built file. From a clone, once:
git clone https://github.com/theluckystrike/mcp-servers.git
cd mcp-servers && npm install
npm run build -w packages/mcp-license -w servers/maintenance-logThat writes servers/maintenance-log/dist/index.js, and its absolute path is the one argument
the config needs.
The npm packages are not published yet, so the form below returns a 404 today. It is here because it is what the entry becomes the day the publish lands, with nothing else changed:
{
"mcpServers": {
"maintenance-log": {
"command": "npx",
"args": ["-y", "@theluckystrike/mcp-maintenance-log"]
}
}
}The Customize page shows the server and its tools once it has started.
Nothing is published to npm yet, so the working install paths are the ones above: the .mcpb bundle from the latest release, a clone and build, or the hosted URL.
The same server runs at https://mcp.zovo.one/mcp/maintenance-log over MCP streamable HTTP, no install. Mint a free token with curl https://mcp.zovo.one/mcp/token, or use a Pro key. It has no filesystem, so a file comes back as a one-hour download link.
{
"mcpServers": {
"maintenance-log": {
"url": "https://mcp.zovo.one/mcp/maintenance-log",
"headers": { "Authorization": "Bearer <token>" }
}
}
}The current field table marks `type` as required, with `stdio` for a locally launched server, so write it out rather than relying on command and args alone. The other documented restriction is that `envFile` is stdio-only: a remote HTTP or SSE server does not read it, and its headers belong in the config.
Free: Three assets on the register, with logging work, the per-asset history with its total spend and CSV export free and unlimited on every tier. Removing an asset frees its slot, so the record is never metered. Pro is $19 once, verified offline.
<project>/.cursor/mcp.json applies to that project and can be committed, which suits a server tied to one client. ~/.cursor/mcp.json applies everywhere. Both are managed from the Customize page.
The current field table marks type as required, with stdio for a locally launched server, so include it. Pointing at a remote endpoint, envFile is documented as stdio-only and is not read.
Servers in Cursor's marketplace get an Add to Cursor button. The deeplink reference currently documents prompt, command and rule links only, so for MCP Maintenance Log pasting the config block above is the supported route.
MCP Maintenance Log in detail · The same server in Claude Code and VS Code · Every server in Cursor · Guides · Cursor docs · Buy Pro