#3 - Name-based group resolution — replace raw group_id with group_name on all tools - forgejo_admin/groupme-mcp

### Type Feature ### Lineage Standalone incident-fix. Triggered by 2026-03-25 data exposure incident (see `claude-custom#160` for full context). ### Repo `forgejo_admin/groupme-mcp` ### User Story As platform operator, I want all GroupMe MCP tools to accept group names instead of raw group IDs, So that stale or wrong IDs can never cause messages to reach the wrong group. ### Context **Incident (2026-03-25):** `send_message(group_id="113983384")` sent a contract status update to the 6-person Coaches & Staff group instead of the 2-person Stakeholders group (`113996175`). The caller grabbed the wrong ID from a stale docs table. Name-based resolution eliminates this class of error — the MCP resolves names against the live GroupMe API. ### File Targets Files to modify or create: - `src/groupme_mcp/server.py` — ADD shared `_resolve_group(group_name)` helper. Calls `list_groups(per_page=100)` or paginates, fuzzy-matches name, returns group dict. Ambiguous → error with options. No match → error with available names. - `src/groupme_mcp/tools/messages.py` — MODIFY `send_message`: `group_name` replaces `group_id`. Include resolved group name + member names + count in response. - `src/groupme_mcp/tools/members.py` — MODIFY `add_member`, `remove_member`, `list_members`: `group_name` replaces `group_id` - `src/groupme_mcp/tools/groups.py` — MODIFY `get_group`: `group_name` replaces `group_id` Files NOT to touch: - `groupme-sdk` — SDK keeps raw `group_id` interface, MCP resolves above it ### Acceptance Criteria - [ ] All 5 group-scoped tools (`send_message`, `add_member`, `remove_member`, `list_members`, `get_group`) accept `group_name`, not raw `group_id` - [ ] Shared `_resolve_group()` helper in `server.py` used by all 5 tools - [ ] `_resolve_group()` calls `list_groups(per_page=100)` or paginates — must not silently miss groups (currently 10 groups, default page size is 10) - [ ] Ambiguous or missing group name returns helpful error listing available groups - [ ] `send_message` response includes resolved group name + member names + member count - [ ] Existing tests updated for new interface ### Test Expectations - [ ] Unit test: `send_message` with exact group name resolves correctly - [ ] Unit test: `add_member` with exact group name resolves correctly - [ ] Unit test: ambiguous name returns multiple options without sending - [ ] Unit test: no match returns error with available group names - [ ] Unit test: `_resolve_group` handles pagination (>10 groups scenario) - Run command: `cd ~/groupme-mcp && pytest tests/` ### Constraints - Follow existing tool patterns in groupme-mcp - MCP must call GroupMe API live — no local caching of group names - SDK layer unchanged — only MCP tool interface changes - groupme-mcp uses `uv` not pip, Forgejo PyPI for groupme-sdk dependency - `_resolve_group()` must call `list_groups(per_page=100)` or paginate — default page size of 10 will silently miss groups at current count ### Checklist - [ ] PR opened - [ ] Tests pass - [ ] No unrelated changes ### Related - `claude-custom#160` — companion ticket: PreToolUse hook (depends on this deploying first) - `project-groupme-westside` — GroupMe project page

forgejo_admin commented

2026-03-26 03:38:19 +00:00

Owner

Type

Feature

Lineage

Standalone incident-fix. Triggered by 2026-03-25 data exposure incident (see claude-custom#160 for full context).

Repo

forgejo_admin/groupme-mcp

User Story

As platform operator,
I want all GroupMe MCP tools to accept group names instead of raw group IDs,
So that stale or wrong IDs can never cause messages to reach the wrong group.

Context

Incident (2026-03-25): send_message(group_id="113983384") sent a contract status update to the 6-person Coaches & Staff group instead of the 2-person Stakeholders group (113996175). The caller grabbed the wrong ID from a stale docs table. Name-based resolution eliminates this class of error — the MCP resolves names against the live GroupMe API.

File Targets

Files to modify or create:

src/groupme_mcp/server.py — ADD shared _resolve_group(group_name) helper. Calls list_groups(per_page=100) or paginates, fuzzy-matches name, returns group dict. Ambiguous → error with options. No match → error with available names.
src/groupme_mcp/tools/messages.py — MODIFY send_message: group_name replaces group_id. Include resolved group name + member names + count in response.
src/groupme_mcp/tools/members.py — MODIFY add_member, remove_member, list_members: group_name replaces group_id
src/groupme_mcp/tools/groups.py — MODIFY get_group: group_name replaces group_id

Files NOT to touch:

groupme-sdk — SDK keeps raw group_id interface, MCP resolves above it

Acceptance Criteria

All 5 group-scoped tools (send_message, add_member, remove_member, list_members, get_group) accept group_name, not raw group_id
Shared _resolve_group() helper in server.py used by all 5 tools
_resolve_group() calls list_groups(per_page=100) or paginates — must not silently miss groups (currently 10 groups, default page size is 10)
Ambiguous or missing group name returns helpful error listing available groups
send_message response includes resolved group name + member names + member count
Existing tests updated for new interface

Test Expectations

Unit test: send_message with exact group name resolves correctly
Unit test: add_member with exact group name resolves correctly
Unit test: ambiguous name returns multiple options without sending
Unit test: no match returns error with available group names
Unit test: _resolve_group handles pagination (>10 groups scenario)
Run command: cd ~/groupme-mcp && pytest tests/

Constraints

Follow existing tool patterns in groupme-mcp
MCP must call GroupMe API live — no local caching of group names
SDK layer unchanged — only MCP tool interface changes
groupme-mcp uses uv not pip, Forgejo PyPI for groupme-sdk dependency
_resolve_group() must call list_groups(per_page=100) or paginate — default page size of 10 will silently miss groups at current count