GitHub Pages Retrieval MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GPR_PLUGIN_DATA | No | Overrides the persistent data directory for manual startup. Normally Claude Code uses CLAUDE_PLUGIN_DATA and GitHub Copilot CLI uses COPILOT_PLUGIN_DATA. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_pages_sourcesA | Checks whether any Pages search targets are configured. Call this before authentication or search so an agent can request a site URL when the list is empty. |
| configure_pages_sourceA | Persists a user-provided HTTPS Pages URL as a local search target, derives its exact origin allowlist, and creates a dedicated browser-profile path. Existing configuration is never replaced. |
| get_source_auth_statusB | Returns the last known authentication state for a configured GitHub Pages source without exposing browser credentials. |
| begin_source_reauthC | Opens a visible, persistent local browser at the configured GitHub Pages URL. The user completes GitHub, SAML, and MFA themselves. |
| validate_source_authB | Validates a completed interactive authentication session against the configured protected Pages URL and persists only the resulting status. |
| fetch_pages_contentB | Fetches one allowlisted GitHub Pages URL through its persistent local browser profile. It never reads the source repository. |
| refresh_pages_indexA | Starts a parallel background crawl of allowlisted rendered Pages links. Returns immediately; poll get_pages_index for compact progress and final statistics. |
| get_pages_indexA | Returns index status, locale counts, and one page of a compact URL/title list. Use search_pages_index for named items; follow nextOffset only when a complete listing is required. |
| search_pages_indexA | Searches one source or all configured sources in the local multilingual trigram index. Use sourceId all for cross-site search; each result includes its actual sourceId for fetch_indexed_section. |
| fetch_indexed_sectionA | Returns one cached page or exact heading/anchor with a strict character cap. Prefer a heading returned by search_pages_index to minimize tokens. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Most tools have clearly distinct purposes, but some overlap exists between fetch_pages_content and fetch_indexed_section (both retrieve content, one live and one cached), and the three auth-related tools (begin_source_reauth, validate_source_auth, get_source_auth_status) represent sequential steps that could be confused. Descriptions are clear enough to resolve most ambiguity.
All tool names follow a consistent verb_noun snake_case pattern (e.g., begin_source_reauth, fetch_pages_content, list_pages_sources). No casing or naming style deviations are present.
The 10 tools are well-scoped for the server's purpose of retrieving and indexing GitHub Pages content. Each tool covers a distinct step in the configuration, authentication, fetching, and search workflow without unnecessary bloat.
The tool surface covers the core lifecycle: configure, list, authenticate, fetch live content, build and query an index, and retrieve indexed sections. Minor gaps exist, such as no tool to delete or update a configured source, but these do not significantly hinder the primary use case.