Skip to main content
Glama
README.md
# Harthad Status MCP

Functional open-source MCP server, API client and Status plugin for personal services, entries and linked state changes. Apache-2.0.

## Architecture

The ten real tools and their executable request schemas live in `src/tools/index.ts`. They call a private API boundary; there are no stub handlers. The hosted endpoint imports this same public package rather than maintaining a second tool implementation.

```text
ChatGPT / plugin → status.harthad.com/mcp → public MCP tools → private API → database
Local assistant  → public stdio MCP      → private HTTP API → database
Webapp                                  → private API     → database
```

Open source: MCP tool registration and dispatch, request validation, API transport, optional stdio bridge, plugin manifests, skill, icons, examples and tests.

Private: webapp, OAuth/session issuance, API authorization, business logic, database access and hosting. No database SDK or credentials are shipped in this repository. The current API base is `https://status.harthad.com/v1`; `api.status.harthad.com` remains a planned address.

## Run

Node.js 22+ and Python 3 for optional plugin packaging.

```sh
npm ci
npm test
```

For a stdio assistant, supply your own account credential through its environment:

```sh
STATUS_ACCESS_TOKEN='<your account credential>' npm start
```

`STATUS_API_URL` optionally selects another HTTPS API or a loopback development server. Missing credentials fail explicitly on startup rather than exposing nonfunctional tools. Logs belong on stderr; stdout is reserved for MCP.

The remote plugin uses the host OAuth flow and needs no manually supplied token. See [plugin setup](docs/plugin.md), [ChatGPT](examples/chatgpt/README.md) and [auth](docs/auth.md). A saved plugin is distinct from a verified native ChatGPT connection.

## Tools

Read scope `status:read`: `get_profile`, `list_services`, `get_status`, `get_changelog`, `get_context`.

Write scope `status:write`: `create_service`, `update_service`, `create_changelog_entry`, `create_entry`, `create_comment`.

States: `operational`, `degraded`, `major_incident`. Visibility: `public`, `private`. Publishing intent: `explicit` (human request, even through MCP) or `context` (AI inference). The backend derives provenance, ownership, timestamps and linked transitions. An entry may contain zero or more state changes; changes generate the linked changelog atomically. See the [current API contract](docs/api-contract.md).

## Layout

- `src/tools`: ten functional tools and current strict input schemas.
- `src/client`: authenticated HTTPS API transport with credential containment and no retries.
- `src/server.ts`: local stdio server; `src/bridge.ts`: optional upstream relay.
- `src/schemas`: legacy draft domain shapes, explicitly separate from the current request contract.
- `plugin/harthad-status`: editable remote plugin and Spanish workflow.
- `scripts/package-plugin.py`: deterministic private-plugin archive builder.
- `tests`: discovery, execution over HTTP, validation, API failures and transport boundaries.

## Packaging

`npm run package:plugin` creates `dist/harthad-status-plugin.zip` for Plugin Creator.

`npm pack` creates the functional library with compiled source and Apache license. The private hosted repo pins this archive with a lockfile integrity hash. The package is not published to npm; the source is available on GitHub. Rebuild and deliberately update that dependency when changing the public runtime.

The old REST proposal is retained as [historical draft](docs/legacy-api-contract.md), not a deployed compatibility guarantee. Pagination, subscriber tools and UI extensions are future work.

[Apache License 2.0](LICENSE).

TDQS

B3.2/5.0

Scored across 10 tools

Disambiguation3/5

Most tools have clear resource+action targets, but create_entry vs create_changelog_entry vs create_comment blur together, and update_service (status change creates a changelog atomically) overlaps conceptually with create_changelog_entry (records a status transition atomically). The read tools (get_status, get_context, get_profile, get_changelog) are distinguishable but adjacent enough to require careful reading.

Naming Consistency5/5

All ten tools follow a clean verb_noun snake_case pattern (get_, create_, update_, list_). The only mild quirk is that create_entry doesn't name the entity type the way create_changelog_entry and create_service do, but the convention itself is unbroken.

Tool Count5/5

Ten tools is well within the ideal range, and each maps to a plausible operation (read profile/status/context, manage services, manage changelog and entries, comment). No filler or redundant wrappers.

Completeness3/5

The service and changelog surfaces are reasonably covered, but there is no read/list for entries or comments (only creation), no delete or update for entries/changelog, and no delete_service. Agents attempting to inspect or clean up created data will hit dead ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues