Refactor tool schemas to a single source of truth

[rcsaquino]

Summary

Fix standalone mnemosyne mcp server returning empty tools list by centralizing all 33 tool schemas into mnemosyne.tool_schemas.

Description

The standalone MCP server (mnemosyne mcp) always returned {"tools": []} because mcp_tools.py imported schemas from the Hermes provider (mnemosyne_hermes / hermes_memory_provider) with a fallback to [] — neither is available outside the Hermes plugin context.
Fix: create mnemosyne/tool_schemas.py as a self-contained schema module within the core package, and update all consumers (mcp_tools.py, hermes_memory_provider, Hermes integration) to import from this single source of truth. Net -480 lines

Related Issue

Closes #360

Type of Change

• Bug fix
• New feature
• Documentation update
• Refactor / performance
• Test improvement
• CI / build tooling

How Has This Been Tested?

• Existing tests still pass (pytest tests/ -v) — 1460 passed, 0 failures
• New tests added for any new functionality
• Manual verification (describe what you tested)

Checklist

• Version bumped in mnemosyne/init.py → 3.10.1
• CHANGELOG.md updated with a brief entry
• README updated if user-facing behavior changed — No user-facing change beyond the fix itself
• Code follows the project's principles:
  • No new external dependencies without good reason
  • No cloud / API key requirement for core functionality
  • SQLite is the only database dependency

[AxDSan]

Sorry for the delay, was IRL busy the last few days.

@rcsaquino the schema consolidation is the right call. Standalone mnemosyne mcp failing on tools/list because the import path went through mnemosyne_hermes (Hermes plugin context, not available in a fresh venv install) was a real packaging bug, and a single source of truth fixes it without leaving consumers to drift.

What I verified:

• git diff main...pr/369 --stat -> 4 files, single new mnemosyne/tool_schemas.py (+708), consolidation in hermes_memory_provider/__init__.py (-582) and mnemosyne_hermes/tools.py (-624), small mcp_tools.py touch (-12). Net -480 LOC.
• py_compile clean on the new tool_schemas.py and both updated provider inits.
• mnemosyne/mcp_tools.py now imports from mnemosyne.tool_schemas instead of trying mnemosyne_hermes.tools with a [] fallback. That fallback was the silent-failure path #360 hit.
• Both provider inits still surface the same schema count (33) to Hermes registration. No behavior change at the tool-surface boundary.
• CI green: docs-check and test on 3.10/3.11/3.12/3.13 all SUCCESS.

One concern worth verifying: the new mnemosyne/tool_schemas.py is imported from three places (mnemosyne/mcp_tools.py, hermes_memory_provider/__init__.py, integrations/hermes/src/mnemosyne_hermes/tools.py). On standalone use (no Hermes plugin), only the first import matters; on Hermes provider mode, only the second or third. Worth confirming there is no circular import when both providers are present in the same process (some Hermes deployments load both surfaces).

LGTM with asks:

1. Version bump. PR bumps to 3.10.1 in mnemosyne/__init__.py, which I see already shipped via #373. If this lands after, confirm the next bump target (likely 3.10.2 since this is a refactor + bugfix combo, no new user-facing surface). If it lands before #373, just ride the 3.10.1 release.
2. CHANGELOG entry. Has one. Good.

Closes #360 cleanly. The schema source-of-truth pattern is exactly what should have been there from day one; thanks for the cleanup.