How to refer PR as a resource? Meaning of path parameter

[atapin]

I was trying to add a PR as resource. I couldn't understand how the proper path value would look like. Tests also do not cover fetching of raw content for a PR. So, what should be there in order to use a PR resource as a context?

[SamMorrowDrums]

That is definitely an interesting idea, but you would need to wire in an API call, and then format the response. I think it could be a great idea to support more types or resources though! I have also thought about it.

[itzabhinavarya]

Would be really useful if PRs could be exposed as first-class resources directly instead of manually wiring API calls + formatting responses.

Having native PR context support for agents would make review and code analysis workflows much cleaner.

[jluocsa]

PRs are exposed as resources by this server today — just only the file contents at the PR head ref, not the PR's metadata/conversation. The URI template is defined in pkg/github/repository_resource.go:

repo://{owner}/{repo}/refs/pull/{prNumber}/head/contents{/path*}

So path is the file path inside the repo at the PR's head commit, exactly like browsing the PR's "Files changed" tab and selecting a file. A few concrete examples for this very server:

• Root of the repo at PR Do I use `web_search` tool providing github-mcp-server? #2186's head:
  repo://github/github-mcp-server/refs/pull/2186/head/contents/
• A specific file from that PR:
  repo://github/github-mcp-server/refs/pull/2186/head/contents/README.md
• A nested file:
  repo://github/github-mcp-server/refs/pull/2186/head/contents/pkg/github/repository_resource.go

The handler walks path against the GitHub repos/{owner}/{repo}/contents/{path}?ref=refs/pull/{prNumber}/head endpoint, so directory listings return a list of text/uri-list children and files return their raw bytes (with sensible MIME detection). This is the same handler used for repo://.../refs/heads/{branch}/contents{/path*} and repo://.../sha/{sha}/contents{/path*}, just bound to the PR head ref instead of a branch/SHA — which is why tests for those branch/commit variants also cover the PR shape implicitly.

What this resource does not give you:

• The PR title / body / labels / reviewers
• Diff or patch view of the PR
• PR review comments or general comments

For those, use the pull_requests toolset tools (pull_request_read, pull_request_review_*, etc.) — they're tools, not resources, because they need parameters beyond a URI.

So the short answer:

• path is a file path inside the repo, evaluated at the PR head ref.
• Use an empty / trailing / to list the repo root or directory contents.
• If you need PR metadata or diff, that's a tool call, not a resource fetch.