Context
The github-mcp-server skill catalog exposes search_pull_requests and search_issues as raw tools, and bundles them inside higher-level skills like trace-history and prepare-release. There is no dedicated find-prs or find-issues skill — i.e. a small, focused skill whose contract is just "find PRs/issues matching these criteria, return a list".
Why this matters
Observed during an external evaluation harness (progressive-disclosure-evals) running model arms against the github-mcp-server skill catalog: when a task is "find recent PRs by author X" or "find issues mentioning Y", the model that browses the skill catalog reliably picks search_issues with type:pr qualifiers rather than search_pull_requests. Both go to the same /search/issues REST endpoint and are functionally equivalent, but the catalog lacks a discoverable "find-prs" entry point, so the model lands on the more generic search_issues path.
This is fine for correctness (it works) but it has two downstream effects:
- Evaluation rubrics that mention
search_pull_requests as the expected tool now have to encode that-or-search_issues equivalence themselves (we just shipped this as a schema change on our side).
- Users / agents browsing the skill catalog see no obvious skill for the common "find PRs by author" workflow and have to either reach for
trace-history (which does more) or improvise with search_issues.
Ask
Consider adding two small skills:
find-prs — find pull requests matching author / repo / label / state / date / keyword criteria. Wraps search_pull_requests (or search_issues type:pr, doesn't matter which the implementation picks).find-issues — same shape for issues. Wraps search_issues type:issue.
These would be the obvious search-and-list entry points and would resolve the catalog-gap symptom described above.
Out of scope
I'm not asking you to change search_issues / search_pull_requests themselves, or to deprecate anything. This is purely about a discoverability gap in the higher-level skill layer.
Context
The github-mcp-server skill catalog exposes
search_pull_requestsandsearch_issuesas raw tools, and bundles them inside higher-level skills liketrace-historyandprepare-release. There is no dedicatedfind-prsorfind-issuesskill — i.e. a small, focused skill whose contract is just "find PRs/issues matching these criteria, return a list".Why this matters
Observed during an external evaluation harness (progressive-disclosure-evals) running model arms against the github-mcp-server skill catalog: when a task is "find recent PRs by author X" or "find issues mentioning Y", the model that browses the skill catalog reliably picks
search_issueswithtype:prqualifiers rather thansearch_pull_requests. Both go to the same/search/issuesREST endpoint and are functionally equivalent, but the catalog lacks a discoverable "find-prs" entry point, so the model lands on the more genericsearch_issuespath.This is fine for correctness (it works) but it has two downstream effects:
search_pull_requestsas the expected tool now have to encode that-or-search_issuesequivalence themselves (we just shipped this as a schema change on our side).trace-history(which does more) or improvise withsearch_issues.Ask
Consider adding two small skills:
find-prs— find pull requests matching author / repo / label / state / date / keyword criteria. Wrapssearch_pull_requests(orsearch_issues type:pr, doesn't matter which the implementation picks).find-issues— same shape for issues. Wrapssearch_issues type:issue.These would be the obvious search-and-list entry points and would resolve the catalog-gap symptom described above.
Out of scope
I'm not asking you to change
search_issues/search_pull_requeststhemselves, or to deprecate anything. This is purely about a discoverability gap in the higher-level skill layer.