Skip to content

🔒 avenor mcp: scope-filtered tool registration via --scope - #193

Open
sdougbrown wants to merge 1 commit into
mainfrom
mcp-scoping
Open

🔒 avenor mcp: scope-filtered tool registration via --scope#193
sdougbrown wants to merge 1 commit into
mainfrom
mcp-scoping

Conversation

@sdougbrown

Copy link
Copy Markdown
Owner

Adds a --scope flag to the avenor mcp server so the registered tool surface depends on scope.

Why: the supervisor-facing control server exposes orchestrate/admin tools (spawn, shutdown, answer_permission, workflow control). Any consumer that should only observe — not mutate or drive — needs those tools absent at registration time, not gated by a permission dialog.

What changed:

  • --scope accepts supervisor (default) or agent; --scope wins over the AVENOR_MCP_SCOPE env var, which wins over the default.
  • supervisor scope registers the full control surface (unchanged default behavior).
  • agent scope registers only read-only introspection tools (status, result, events, workflow_status, workflow_inspect, workflow_events). Orchestrate/admin/workflow-control tools are simply not registered.

Scope note (intentional): this build wires the scoping machinery and the flag. Child backends today are provisioned with avenor-channel-tools (messaging) or a backend sidecar — they never receive the avenor mcp supervisor server — so children already cannot reach spawn/shutdown/answer_permission by construction. Injecting a real agent-scoped avenor mcp server into children is a separate, structural child-provisioning change and is deliberately out of scope here.

Tests: TestScopeAgentExcludesControlTools, TestScopeSupervisorRegistersAllTools, plus default-supervisor coverage in internal/mcpserver/scope_test.go. Full go build ./..., go vet, and go test ./... pass.

supervisor scope (default) registers the full control surface; agent scope
registers only read-only introspection tools (status/result/events and
workflow_status/inspect/events). Orchestrate, admin, and workflow-control
tools (spawn/shutdown/answer_permission/follow_up/workflow_wait,
workflow_complete/gate) are simply not registered in agent scope, so an
agent-scoped consumer can observe runs but never mutate or drive them —
enforced at registration time, no permission dialogs.

--scope wins over the AVENOR_MCP_SCOPE env var, which wins over the default.

Trailer: sparky/deepseek-flash

@umpire-bot umpire-bot Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR is marked... FOUL BALL. 👉

No prior bot findings were found for this PR, so this is a fresh review.

@sdougbrown

Copy link
Copy Markdown
Owner Author

@umpire-bot review

Comment thread cmd/avenor/mcp.go
idleTimeout := fs.Duration("idle-timeout", 30*time.Minute, "idle timeout before server exits")
addr := fs.String("addr", "127.0.0.1:3748", "address to listen on for HTTP transport")
authToken := fs.String("auth-token", "", "bearer token required for HTTP transport (defaults to MCP_AUTH_TOKEN)")
scope := fs.String("scope", "", "tool scope: \"supervisor\" (default) or \"agent\"")

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Coverage gap: the new --scope flag and AVENOR_MCP_SCOPE env-var resolution in runMCP (mcp.go:21, 39-51) is not exercised by any test. runMCP's only caller is main.go:37, and no test sets the flag or the env var; the internal/mcpserver/scope_test.go tests cover server-side scope behavior, not the CLI wiring. Add a test that exercises runMCP with --scope and AVENOR_MCP_SCOPE set/unset to lock in flag-wins-over-env, env-wins-over-default, and invalid-value rejection.

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.

1 participant