I let an Apify Actor read my docs and write one GitHub issue. It found a 404 without cloning the repo.

A broken-link checker operates on a deployed website. However, the author's checker needed to begin the process earlier, within the Markdown files residing in GitHub. Some of these files had not yet been deployed, and the author desired to receive exact path and line evidence rather than the URL of a rendered page. The author also aimed for the checker to run on a scheduled basis, leaving the results for maintainers to review, without needing to clone the repository into the Actor or input a GitHub token.

Consequently, the author developed a GitHub Documentation Link Auditor using an Apify Managed Connector (MCP) service.

This Actor reads explicit .md or .mdx file paths, inspects a maximum of 100 public HTTP links, and generates or updates a single GitHub issue. It is incapable of modifying files, creating branches, or initiating pull requests. On August 9, 2026, the author executed the published build twice against a public fixture, fixed at one commit.

The first run identified 404 errors for two links, while the third was a loopback URL that was rejected before the request. The second run updated issue #5, indicating that the 404 error was equally significant.

A daily checker that opens a daily issue would simply create an additional broken workflow. Instead, by utilizing the MCP connector, the Actor can invoke third-party services during its run. The connector facilitates communication by allowing the Actor to call external services at two specific points: replacing a checkout or manual upload and merging a report back into GitHub, as well as verifying whether the previous day's issue already exists.

The Actor's routine handles link extraction, DNS policy, HTTP checks, classification, and report rendering.

Two connector inputs are utilized - one for a dry run without write authority, and another for write access. The Actor's contract does not require issue tools until write permissions are enabled. The permission boundary is defined in the input schema. The author declares the MCP connector with `resourceType: mcpConnector`. The read input exposes the GitHub read connector, allowing access to the required tool `get_file_contents`.

The write input declares the GitHub issue connector, providing access to the `search_issues` and `issue_write` tools.

No content-write, branch, pull-request, or merge tools are available. The connector's GitHub authorization is still enforced beneath this boundary. The Actor receives a connector ID and an Apify proxy URL, rather than the GitHub credentials. It then connects through a standard Streamable HTTP MCP client using the run token obtained from the environment variable `APIFY_TOKEN`. This connection establishes the initial communication channel before the Actor proceeds to examine the specified files at an immutable reference.