MCP: tool profiles in MCPConfiguration

[robfrank]

Part of #4859.

Motivation

The server will grow from 10 to potentially 16+ tools; flat tool lists degrade model tool-selection accuracy. A configurable profile (e.g. rag: query, vector_search, hybrid_search, full_text_search, sample_records, schema resource vs. admin: the current 10 operator tools) lets a given agent see a focused set. This isn't a new tool, so the four-justification test from #4859 doesn't directly apply — it's the Epic's explicit alternative to unbounded tool-list growth.

Proposed design

• Add profile (or enabledTools allowlist) field to MCPConfiguration, default all (backward-compatible — no behavior change for existing deployments).
• tools/list and tools/call in both transports filter/reject against the active profile — a tools/call for a tool outside the active profile is denied even though it's globally registered (defense in depth, not just a UI filter).
• Expose profile selection via MCPConfigHandler.java's existing admin config surface.
• Update MCPConfigurationTest/MCPPermissionsTest for profile filtering.

Acceptance criteria

• Default profile (all) preserves current behavior exactly (regression-tested).
• rag and admin profiles defined and enforced in both tools/list and tools/call.
• Config persists through mcp-config.json like existing fields.
• Tests + docs, including a worked example of restricting an agent to rag.

Files to touch

MCPConfiguration.java, MCPHttpHandler.java, MCPStdioServer.java, MCPConfigHandler.java, tests, docs.

Dependencies

Soft-depends on #4860, #4861, #4862, #4863, #4864 for the rag profile's tool list to be meaningful; the filtering mechanism itself can be built in parallel with default all/admin profiles only, then extended once new tool names land.

Effort estimate

M — config schema change, filtering logic duplicated across two transports, admin surface update.