| name | suggest-reviewers |
| description | Recommend reviewers for an RFC based on file paths in the PR, prior commenters on related RFCs, and the team mapping already visible from listed RFCs. Shows a ranked list with reasons, then requests reviewers on the user's approval. |
| allowed-tools | ["mcp__rfc123__rfc123_get_rfc","mcp__rfc123__rfc123_list_rfcs","mcp__rfc123__rfc123_search_reviewers","mcp__rfc123__rfc123_request_reviewers"] |
suggest-reviewers
Help the user pick the right reviewers for an RFC.
When to use
The user just drafted an RFC and isn't sure who should review, or wants to
add reviewers to an existing RFC.
Process
-
Read the RFC. Call rfc123_get_rfc for the target RFC and note: the file
paths the PR touches, the author, and any reviewers already requested.
-
Look for adjacent context. Call rfc123_list_rfcs on the same repo. Scan for
prior RFCs that:
- Touch overlapping file paths (similar paths in
files).
- Have the same author or were authored by reviewers already on this RFC.
- Carry team slugs in
requestedTeamSlugs that match the topic area.
-
Build a candidate list. For each candidate, write down the reason
they're a good fit ("authored related RFC #X about Y"; "is on
${org}/${team} which has reviewed every storage RFC"). Bare names with
no reason are not useful – the user can't sanity-check them.
-
Rank. Cap the list at 5 individuals + up to 2 teams. Rank by
directness of relevance, not seniority.
-
Show the user. Surface the ranked list with reasons. Do not call
rfc123_request_reviewers yet.
-
Verify handles. Once the user picks who to request, run
rfc123_search_reviewers on any name you're uncertain about. The tool is
org-scoped (across orgs that host RFC repos visible to you) and returns
mixed users + teams with a kind discriminator and a ready-to-use
handle. For teams, handle comes back as org/slug.
-
Request. Call rfc123_request_reviewers with the chosen users and
teams. The response echoes back added, alreadyRequested, removed,
and the final pending set – share the relevant slice with the user. If
the user wants to swap a stalled reviewer, use removeUsers /
removeTeams in the same call.
What not to do
- Don't recommend reviewers without giving the user a reason. "Add Alice"
with no rationale is worse than no suggestion.
- Don't recommend the author. (It happens – check.)
- Don't propose more than 5 individuals; reviewer overload kills response time.
- Don't invent team slugs. If you can't see the team in
requestedTeamSlugs
of any existing RFC, ask the user to confirm the team exists.
