feat(mcp): add Nessie to the catalog

[annayzhang1337]

What does this PR do?

Adds Nessie to the official Hermes MCP catalog as a data-only manifest.

Nessie is a hosted Streamable HTTP MCP server for searching and reading a user's or team's AI conversation history, notes, profiles, and shared context. The manifest uses the HTTP API-key bearer-header convention already supported on current main through #77356, so this refresh no longer carries installer code.

The default tool set is deliberately curated to 11 modern, read-only operations. Profile/context writes, modality corrections, deletion, and deprecated aliases remain available only when a user explicitly opts into them with hermes mcp configure nessie.

Related Issue

Related to #77356, which supplied the generic HTTP API-key catalog support this manifest uses. There is no separate issue for this catalog submission.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• Added optional-mcps/nessie/manifest.yaml with the hosted https://mcp.nessielabs.com/mcp endpoint.
• Declared MCP_NESSIE_API_KEY as the required secret and used Hermes' generated Authorization: Bearer ${MCP_NESSIE_API_KEY} configuration.
• Enabled 11 read-only tools by default and documented Cloud Sync, API-key creation, connection testing, and explicit opt-in for write/delete tools.

How to Test

1. Run scripts/run_tests.sh tests/hermes_cli/test_mcp_catalog.py -q.
2. Run hermes mcp install nessie, enter a scratch Nessie API key, and inspect ~/.hermes/mcp_config.json for the HTTPS URL and bearer-header reference.
3. Run hermes mcp test nessie, then start a new Hermes session and ask Nessie to identify the current user or search conversation history.

Validation performed for this refresh:

• Hermes catalog suite: 21 passed.
• Manifest parse/config contract: passed; generated config matches the endpoint and bearer-header reference, with 11 read-only defaults.
• Nessie MCP server registration suite: 12 passed.
• Hosted endpoint without a bearer token: HTTP 401, confirming the authentication boundary.
• The full prescribed Hermes runner completed. It reported 66 failures across 21 unrelated optional/platform test files (for example service permissions, optional provider SDKs, media backends, and OS command behavior); the catalog suite and all Nessie-related validation remained green.

An authenticated live test was not repeated during this refresh because no scratch Nessie key was present in the validation environment.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS 15.6.1 (24G90)

The existing catalog invariant suite covers every manifest, including this one; no new test code is needed for a data-only entry. The full-suite exceptions are documented above.

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — N/A; the manifest links the focused Nessie MCP setup documentation
• I've updated cli-config.yaml.example if I added/changed config keys — N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — the entry is data-only and uses the existing cross-platform HTTP MCP installer
• I've updated tool descriptions/schemas if I changed tool behavior — N/A

Screenshots / Logs

N/A — this is a data-only catalog manifest.

[alt-glitch]

This was generated by AI during triage.

Related: #59586, #67682, and #70775 implement the same HTTP api_key header wiring. This PR additionally supplies the Nessie entry, so it is a competing catalog-policy/implementation decision rather than a duplicate.

[teknium1]

Thanks for identifying the missing HTTP API-key catalog path. The current main implementation still writes only url for HTTP api_key entries (hermes_cli/mcp_catalog.py:505-509), so the underlying bug is real.

Problems

• hermes_cli/mcp_catalog.py:518 derives MCP_<NAME>_API_KEY from the catalog name, but auth.env permits arbitrary names; the existing parser test uses DEMO_KEY (tests/hermes_cli/test_mcp_catalog.py:125-144). An HTTP entry with that valid declaration would prompt/store DEMO_KEY while its generated header references MCP_DEMO_API_KEY.
• This PR adds no regression coverage for the HTTP api_key install path. The existing API-key install test only verifies prompting and config presence (tests/hermes_cli/test_mcp_catalog.py:175-195).

Suggested changes

• Bind the generated bearer template to an explicit, validated manifest credential field (such as auth.env_var), and set it for Nessie.
• Add an end-to-end installer test asserting the exact ${VAR} reference in persisted headers and that the secret remains only in .env.

This is an automated hermes-sweeper review.

[annayzhang1337]

@teknium1 I refreshed this PR onto current main and reduced it to the preferred maintainer-friendly shape: one commit adding only optional-mcps/nessie/manifest.yaml.

The generic HTTP API-key bearer-header support from the earlier version has since landed in #77356, so there is no installer code left here. The manifest now:

• declares MCP_NESSIE_API_KEY and relies on the existing generated bearer header;
• enables only 11 current read-only tools by default;
• leaves writes, corrections, deletion, and deprecated aliases as explicit opt-ins;
• points users to the focused setup docs and calls out the Cloud Sync requirement.

Validation is documented in the updated PR body. The relevant Hermes catalog suite is green (21/21), the Nessie server registration suite is green (12/12), the generated-config contract passes, and the hosted endpoint correctly rejects unauthenticated requests with HTTP 401. The full Hermes runner also completed; its unrelated optional/platform failures are disclosed in the body.

Could a maintainer please do the catalog curation pass and, if the entry is acceptable, remove needs-decision and apply the required ci-reviewed approval? Maintainer-owned edits or a salvage PR are completely welcome if you prefer to land the manifest that way.