You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Scope. Land an empty MCP component under components/mcp/, wire it into the operations and HTTP server entry points behind config gates (presence-based: the profile is enabled iff its mcp.<profile> sub-block is present, matching Harper's replication convention — no enabled flag), and add the mcp: block to the config schema.
Design reference. Sections "Config (harperdb-config.yaml)" and "Implementation Location" in #465.
Acceptance criteria
components/mcp/index.ts (or equivalent entry point) exists, exports a registration hook usable by both servers.
mcp.operations and mcp.application blocks parse from harperdb-config.yaml, with every key documented in Expose Operations (API) through an MCP Wrapper #465 (mountPath, allow, deny, maxTools, searchMaxResults, rateLimit, session.idleTimeoutSeconds, session.allowClientDelete).
Config keys are added to utility/hdbTerms.ts; static/defaultConfig.yaml intentionally omits the mcp: block (opt-in via block presence, matching replication's convention), so existing deployments see no behavior change on upgrade.
server/operationsServer.ts and server/http.ts invoke the MCP registration hook only when the corresponding mcp.<profile> sub-block is present in the merged config.
Unit tests cover config parsing + the off-by-default behavior.
CI green (unit + integration + 3 Node versions).
Out of scope. No JSON-RPC, no transport, no tools, no resources. This PR adds plumbing only.
Merge with a merge commit (per CONTRIBUTING.md:92).
Smoke test
# With `mcp: { operations: {} }` added to the user's harperdb-config.yaml:
curl -sS -X POST http://localhost:9925/mcp -d '{}' -i | head -5
# Expected: HTTP 503 with body {"error":"mcp_not_implemented","profile":"operations"}# (placeholder until #614 lands the Streamable HTTP transport).# What MUST hold: with no `mcp:` block in config (the default), the existing# operations API endpoints still respond identically — no regression.
Scope. Land an empty MCP component under
components/mcp/, wire it into the operations and HTTP server entry points behind config gates (presence-based: the profile is enabled iff itsmcp.<profile>sub-block is present, matching Harper'sreplicationconvention — noenabledflag), and add themcp:block to the config schema.Design reference. Sections "Config (
harperdb-config.yaml)" and "Implementation Location" in #465.Acceptance criteria
components/mcp/index.ts(or equivalent entry point) exists, exports a registration hook usable by both servers.mcp.operationsandmcp.applicationblocks parse fromharperdb-config.yaml, with every key documented in Expose Operations (API) through an MCP Wrapper #465 (mountPath, allow, deny, maxTools, searchMaxResults, rateLimit, session.idleTimeoutSeconds, session.allowClientDelete).utility/hdbTerms.ts;static/defaultConfig.yamlintentionally omits themcp:block (opt-in via block presence, matchingreplication's convention), so existing deployments see no behavior change on upgrade.server/operationsServer.tsandserver/http.tsinvoke the MCP registration hook only when the correspondingmcp.<profile>sub-block is present in the merged config.Out of scope. No JSON-RPC, no transport, no tools, no resources. This PR adds plumbing only.
Stacks on. Nothing — this is the foundation.
Branch & PR conventions
feat/mcp-foundationmainCloses #<self>; references Expose Operations (API) through an MCP Wrapper #465 viaTracking: #465.CONTRIBUTING.md:92).Smoke test
Tracking. Part of #465. Sub-issue #1 of 11.