feat: MCP server integration#124
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #124 +/- ##
=======================================
Coverage 95.55% 95.55%
=======================================
Files 8 8
Lines 1823 1823
=======================================
Hits 1742 1742
Misses 81 81 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
…read/write security check
pesap
left a comment
There was a problem hiding this comment.
I would like the MCP server to feel like something I can type from memory. Right now the proposed package name makes the common path clunky because users have to remember both the package name and the executable name: uvx --from mcp-server-plexosdb plexosdb-mcp.
Can we publish this as a separate adapter package named plexosdb-mcp, with the executable also named plexosdb-mcp? Then the happy path becomes uvx plexosdb-mcp, the safe path is uvx plexosdb-mcp --read-only, and users can run simple smoke checks such as uvx plexosdb-mcp health, uvx plexosdb-mcp --version, and uvx plexosdb-mcp --help without needing to know package/install plumbing.
I would still keep plexosdb and the MCP server as separate packages. plexosdb should remain the core library. plexosdb-mcp should be the thin adapter that depends on plexosdb and fastmcp. That keeps core installs clean while making the MCP install path obvious.
For local development, the docs can be explicit about the nested package path, for example uv run --project src/plexosdb-mcp plexosdb-mcp health and uv run --project src/plexosdb-mcp plexosdb-mcp --read-only. The current local uvx --from . plexosdb-mcp shape should not be the recommended path from the repo root because it installs the root package, not the nested MCP package.
Please update the package/docs around this user-facing shape before merge, and add a smoke check that verifies the documented command works.
|
One more request from the agent-ergonomics angle: please make the CLI contract explicit. Data-bearing commands should support |
This is a first approach for the implementation, it'll be updated accordingly.