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, maintenance_export and the list views are reads and safe to auto-approve. Keep maintenance_log behind a click, because each call is the record of work done, and asset_remove behind one, because an asset carrying a log needs confirm: true and the AST number is never reissued. Nothing here writes into another server's store.
| 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 mcp.json, and the key inside it is mcpServers.
| Scope | Path |
|---|---|
| Cline CLI | ~/.cline/mcp.json |
| The editor extension | opened from the Cline panel, not by path; the documentation deliberately calls it the MCP settings JSON used by the extension |
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.
Cline reads its own config, so here it is:
The config block:
{
"mcpServers": {
"maintenance-log": {
"command": "node",
"args": ["/absolute/path/to/mcp-servers/servers/maintenance-log/dist/index.js"],
"disabled": false,
"autoApprove": []
}
}
}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"]
}
}
}No full-app restart. The MCP settings actions include restarting an unresponsive server if its tools do not appear.
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.
Write the transport in. Omitting type falls back to the legacy sse transport, which will not talk to this endpoint:
{
"mcpServers": {
"maintenance-log": {
"type": "streamableHttp",
"url": "https://mcp.zovo.one/mcp/maintenance-log",
"headers": { "Authorization": "Bearer <token>" }
}
}
}Cline is the one client here with an unsafe transport default. `type` selects it, and omitting `type` falls back to the legacy sse transport, so a streamable HTTP endpoint needs it written in or you will debug a server that is fine. Local entries carry "disabled" and an "autoApprove" array.
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.
The CLI reads ~/.cline/mcp.json. For the extension, do not hunt for a path: MCP Servers icon, Configure tab, Configure MCP Servers. cline mcp opens a wizard, and cline config mcp --json is the non-interactive form.
Set the transport explicitly. Omitting type falls back to the legacy sse transport, so streamable HTTP needs "type": "streamableHttp" written in. It is the one default here that sends you debugging a server that works.
Approve the read-only ones and leave the writing ones behind a click: each entry carries an autoApprove array and a disabled flag.
MCP Maintenance Log in detail · The same server in Windsurf and Claude.ai and Claude Desktop connectors · Every server in Cline · Guides · Cline docs · Buy Pro