Summary

Add an optional, declarative MCP capability policy to config.json so operators can pin which MCP tools are exposed — globally and per account — without assembling long --allow-tool / --enable-commands-exact argument strings in every client config.

The default (no config) is unchanged: read-only, exactly like today. This is a governance/ergonomics layer for operators who run gog mcp across several accounts, not a way to widen the tool surface.

Motivation

gog mcp already has excellent runtime controls (--allow-tool, --allow-write, --enable-commands-exact, --disable-commands, --gmail-no-send, --readonly) plus baked safety profiles. In practice, two gaps remain for operators wiring MCP into clients like Claude Desktop:

1. Per-account policy is awkward. A common need is "work account read-only, personal account may write" — today that means duplicating and hand-tuning flag strings across multiple mcpServers entries. The CLI has no per-account MCP policy, even though the config layer already models per-account safety for sending (gmail_no_send + no_send_accounts in internal/config/config.go).
2. Selection isn't declarative or discoverable. Choosing a curated subset means a long --allow-tool read,tool_a,tool_b,... argv that's easy to get wrong and invisible to review.

This proposal reuses the existing gmail_no_send / no_send_accounts idiom — a global default plus a per-account override map — and extends it to MCP tool exposure.

Prior art / concerns this tries to respect

• Security: GOG_ENABLE_COMMANDS lacks sub-command granularity for agent/MCP mode #290 (--enable-commands lacks sub-command granularity for agent/MCP): the risk of an agent reaching gmail send / filters create --forward when granted a top-level command. This proposal only ever narrows exposure and defaults to read-only, so it can't widen that surface.
• Support auth.md-based capability discovery for agent and MCP clients #677 (capability discovery for agent/MCP clients): a declarative, inspectable policy is a step toward operators (and agents) knowing the active surface.
• PR feat(mcp): add typed allowlisted server #637 / the typed-server philosophy: no generic command runner, typed tools only, read-only by default, explicit opt-in. This proposal changes none of that — it's config sugar over the existing tool registry and the existing --allow-* gates. Explicit non-goal: no gog_exec / generic command bridge.

Proposed shape

A new optional mcp block in config.json (JSON5, so comments are fine):

{
  "mcp": {
    // Global default. Ships as "readonly" == current upstream behavior.
    "profile": "readonly",            // readonly | standard | power, or a user-defined name

    // Optional user-defined bundles (expand to tier + allow/deny).
    "profiles": {
      "standard": { "tiers": ["write"], "deny": ["<destructive tool names>"] }
    },

    // Optional per-tool overrides on top of the active profile.
    "tools": {
      "gmail_send": false
    },

    // Per-account overrides — mirrors no_send_accounts.
    "accounts": {
      "[email protected]":  { "profile": "power" },
      "[email protected]":      { "profile": "readonly" }
    }
  }
}

Resolution precedence (most specific wins), so nothing surprising:

CLI flags (--allow-write / --allow-send / --allow-tool)   [highest]
  > config: accounts.<active>.*
  > config: tools.*  (per-tool booleans)
  > config: profile  (named preset)
  > built-in default: readonly (== upstream)              [lowest]

Baked safety profiles remain the tamper-proof ceiling and are unaffected (still checked before any handler).

Non-goals

• No generic exec / command bridge.
• No new tools and no change to which tools are write-gated. The maintainer stays the sole curator of the tool set; this only lets operators select from / restrict it and set per-account defaults.
• No change to default behavior (absent mcp block == today).

Alternatives considered

• Flags only (status quo). Works, but can't express per-account defaults and forces long, error-prone argv duplicated across client entries.
• A separate policy file. More moving parts; config.json already owns account-scoped policy (no_send_accounts), so extending it is the smaller, more idiomatic change.

Willing to implement

Happy to send a PR (config struct + resolver + gog mcp wiring + docs + tests) if the shape looks acceptable. Wanted to align on the design and confirm it's welcome before writing it, given this touches the MCP capability surface. Open to a narrower cut (e.g. per-account profile only, dropping the tools/profiles maps) if you'd prefer to start minimal.