Skip to content

docs(spec): add spec 057 for in-proxy profiles (#55)#531

Open
Ylsssq926 wants to merge 1 commit into
smart-mcp-proxy:mainfrom
Ylsssq926:docs/spec-057-in-proxy-profiles
Open

docs(spec): add spec 057 for in-proxy profiles (#55)#531
Ylsssq926 wants to merge 1 commit into
smart-mcp-proxy:mainfrom
Ylsssq926:docs/spec-057-in-proxy-profiles

Conversation

@Ylsssq926
Copy link
Copy Markdown
Contributor

Captures the design discussion from #55 (@Dumbris's "In-Proxy Profiles + Permanent URLs" plan plus the scope trade-offs from the follow-up comments) into a draft spec, so the implementation can be reviewed in two stages, matching the pattern from #525 / #56.

What this is

Just the spec doc: `specs/057-in-proxy-profiles/spec.md` (single-file draft, no `plan.md` / `tasks.md` yet; those come after direction is locked).

Scope captured in the spec

MVP (this spec, next PR):

  • `config.profiles: [{name, servers}]` with slug-validated names
  • New permanent URL `/mcp/p/{slug}`, stateless, filters the visible upstream set per request
  • Filter wired into the existing scope hooks in `handleRetrieveTools*` / `handleCallToolVariant`, composes with agent-token `AllowedServers` (Spec 028) by intersection
  • Reuses per-server `enabled_tools` / `disabled_tools` for tool-level filtering inside a profile
  • Zero migration: missing `profiles` keeps current behaviour

Out of scope (deferred, with reasons in the spec):

  • Active profile switching (state ownership is an open question; `/mcp` semantics stay as-is)
  • Tray UI / `set_profile` MCP tool (depend on active state)
  • Index-level profile field (cardinality is small, filter at search-result time)
  • Melodeiro's `server:tool` mixed list (existing `enabled_tools` already expresses it)

Open Questions for review

Three calls I deliberately left for you to make in the spec (rather than baking them in):

  1. `profile.servers` referencing an unknown server: hard error or warn-and-skip?
  2. `/mcp` semantics when `profiles` is configured: keep "show everything" (current behaviour) or expose a "default" profile?
  3. Should `all` be reserved as a slug for a future "show everything" profile?

Refs: #55, #333

Captures the design discussion from issue smart-mcp-proxy#55 (Dumbris's
"In-Proxy Profiles + Permanent URLs" plan plus the scope
trade-offs from the follow-up comments) into a spec doc so the
implementation can be reviewed in two stages (spec first, code
after), matching the pattern from spec 056 / PR smart-mcp-proxy#525.

Scope:
- profiles config + /mcp/p/{slug} pinned URL
- filter at retrieve_tools / call_tool_* hooks
- composes with agent-token AllowedServers (Spec 028) and
  per-user visibility (Spec 029) by intersection
- existing per-server enabled_tools / disabled_tools reused
  for tool-level filtering inside a profile

Out of scope (deferred to follow-up specs/PRs):
- active profile switching (state ownership is an open
  question for the maintainer)
- tray UI / set_profile MCP tool
- index-level profile field
- mixed server / server:tool list per profile

Refs: smart-mcp-proxy#55, smart-mcp-proxy#333
@codecov-commenter
Copy link
Copy Markdown

⚠️ Please install the 'codecov app svg image' to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

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.

2 participants