mcp: product decision — should tools/list reveal ability metadata to non-admin app passwords?

[pluginslab]

From the v0.12.0 MCP endpoint security review (PR #216, finding [Info #7]).

The MCP wire endpoint requires `is_user_logged_in()` only (per-ability `permission_callback` gates actual execution). This means:

• A subscriber-level app password CAN call `tools/list` and see the names + descriptions of every exposed read-only ability.
• They CANNOT call `tools/call` on any ability whose `permission_callback` requires higher caps — that returns `-32001 Permission denied`.

Question: is exposing the ability catalog to subscriber-level users acceptable? Pros: matches MCP convention (clients discover, server enforces). Cons: reconnaissance signal — a low-privilege user learns the shape of the admin surface.

Options:

1. Keep current behavior (recommended; matches MCP conventions, no real exploit path).
2. Filter `tools/list` per-user via each ability's `permission_callback` (more conservative, costs an extra `check_permissions` call per tool per list request).
3. Add a `manage_options` gate at the MCP route level — simplest, but blocks legitimate read-only use cases for editor / author roles.

Product call — not a bug.

[pluginslab]

Closed as decided: keep current behavior (matches MCP convention, no exploit path). Documented the rationale in docs/MCP-ENDPOINT.md under 'Who can see tools/list?' so it's a deliberate product call, not an accident. Commit bf47c59 on PR #216.