Skip to content

feat: embedded MCP server exposing the admin API as tools#44

Open
dfradehubs wants to merge 1 commit into
achetronic:masterfrom
dfradehubs:feature/admin-mcp-server
Open

feat: embedded MCP server exposing the admin API as tools#44
dfradehubs wants to merge 1 commit into
achetronic:masterfrom
dfradehubs:feature/admin-mcp-server

Conversation

@dfradehubs
Copy link
Copy Markdown

Closes #43.

Summary

  • New opt-in MCP server embedded in magec-server (server.mcp.enabled, default port 8082).
  • ~61 MCP tools covering full CRUD across backends, memory providers, MCP servers, agents (with link/unlink MCP), clients (with token regeneration), commands, flows, secrets (value redacted on reads), settings, conversations, plus type catalogues.
  • Streamable HTTP transport. Auth reuses server.adminPassword as bearer via a new middleware.BearerAuth that mirrors AdminAuth (constant-time compare + per-IP rate limit, 5 failures/min).
  • Tools call *store.Store directly. No HTTP roundtrip back to admin port.

Design notes

  • Skills upload/download and backup/restore stay on admin REST. Binary archives do not map cleanly to MCP tool inputs and outputs.
  • Validators are shared, not duplicated: admin.ValidateFlowStep, admin.ValidateClientConfig, admin.SecretToResponse are exported and reused.
  • Flow tools use an explicit *jsonschema.Schema{Type:"object"} because store.FlowStep is self-referential and the SDK's reflection-based schema generator does not support cycles. Runtime behaviour is unchanged.
  • omitempty added to id tags and client.token in store/types.go so the MCP SDK does not mark server-assigned fields as required on create_* inputs. Wire shape on responses is unchanged because those fields are always populated at write time.
  • Empty server.adminPassword keeps both admin REST and MCP open with a clear startup WARN per surface (admin and MCP independently).

Docs

  • New page: website/content/docs/admin-mcp-server.md with enablement, auth, Claude Code / mcp-cli connection examples, full tool catalogue and troubleshooting.
  • Sidebar entry weight 6 under Core Concepts (website/hugo.toml).
  • .agents/AGENTS.md, .agents/MULTI_AGENT_ADMIN_API.md updated with pointers.
  • .agents/DECISIONS.md adds decision Chore/complete code audit #30 covering motivation, trade-offs and the explicit do not list.
  • .agents/TODO.md "Recently Completed" entry.

Test plan

  • go test -race ./api/mcp/... ./api/admin/... ./middleware/... ./store/... — green.
  • Per-resource table-driven tests under server/api/mcp/tools_*_test.go.
  • In-memory transport smoke (server_test.go): server connects, lists ≥50 tools, all representative tool names present.
  • HTTP-level bearer smoke (server_http_test.go): 401 without/with wrong bearer, anything-but-401 with correct bearer, open mode bypasses auth when password is empty.
  • Local end-to-end run with server.mcp.enabled: true. Verified initializenotifications/initializedtools/list (61 tools) → tools/call for create/update/delete across every resource group. Cross-surface verification: writes via MCP appear in admin REST immediately and vice versa.
  • Secret redaction verified: grepping the plaintext value across MCP responses returns zero matches in create/list/get paths.

Out of scope

  • MCP resources/prompts. Tools-only keeps every CLI client compatible. Open question on the linked issue.
  • Skill upload/download and backup/restore through MCP. Admin REST remains authoritative.
  • Refactoring AdminAuth to call BearerAuth internally. The two middlewares share the rate limiter and bearer extractor but differ in their /api/ carve-out; consolidating is a follow-up.

Add an opt-in MCP server (server.mcp.enabled, default port 8082) that
exposes the entire admin API as ~61 MCP tools over Streamable HTTP.
Authentication reuses server.adminPassword as a bearer token via a new
middleware.BearerAuth that mirrors AdminAuth's constant-time compare
and per-IP rate limiter.

Tools call *store.Store directly. There is no HTTP roundtrip back to
the admin port, following the spirit of decision achetronic#6 ("Admin UI never
accesses the User API"). Skills upload/download and backup/restore
remain on admin REST because binary archives do not map cleanly to
MCP tool inputs.

Implementation lives in server/api/mcp/, one tools_<resource>.go per
admin resource group. Existing admin validators (ValidateFlowStep,
ValidateClientConfig, SecretToResponse) are exported and reused so
both surfaces enforce the same rules.

Secret values are never returned by GET tools (magec_get_secret,
magec_list_secrets), matching the admin REST redaction policy.

Adds 'omitempty' to id and client.token tags in store.types so the
SDK's JSON schema reflection does not mark server-assigned fields as
required on the inputs of create_* tools.

Docs: website/content/docs/admin-mcp-server.md plus sidebar entry.
Decision record: .agents/DECISIONS.md achetronic#30.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Proposal: embedded MCP server exposing the admin API as tools

1 participant