> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lanesync.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Connect LaneSync to an MCP client

> Connect an AI client to onboard repositories, manage releases, inspect quality, and request governed deployment.

Connect LaneSync to your AI client to set up repositories, manage release milestones and issues, inspect quality and gates, and request deployment.

## Before you start

Use a remote MCP client that supports OAuth, or a client that can set a custom authorization header. You need a GitHub account and permission to access the workspace you connect.

<Steps>
  <Step title="Add the LaneSync server">
    Add `https://lanesync.dev/api/mcp` as a remote MCP server in your client. Choose browser sign-in when prompted.
  </Step>

  <Step title="Sign in and choose access">
    Sign in with GitHub, install the LaneSync GitHub App if needed, and select a LaneSync workspace. Grant read access for inspection or release write access for setup and release changes.
  </Step>

  <Step title="Onboard and plan">
    Ask your client: “Inspect and plan onboarding for owner/repo.” Review the proposed configuration and use the confirmation link for protection changes. Then ask it to create a release milestone and add issues.
  </Step>
</Steps>

<Note>
  OAuth access tokens expire after 15 minutes and refresh automatically when supported by the client. Access is tied to your current workspace membership. GitHub App installation and missing GitHub permissions may require a browser step before your conversation can continue.
</Note>

## What you can ask

* **Onboard:** `inspect_repository_onboarding`, `plan_repository_onboarding`, and `apply_repository_onboarding` use LaneSync's setup verification and reviewed configuration.
* **Organization setup:** `plan_organization_onboarding` and `apply_organization_onboarding` review central policy and organization rulesets when the repository is organization managed. `get_repository_workflow_update` and `update_repository_workflows` maintain LaneSync's managed workflows.
* **Plan:** `create_release_milestone`, `get_release_scope`, and `manage_release_issue` create and organize a release on GitHub.
* **Track:** `get_release_progress`, `get_gate_verdict`, `get_next_actions`, and `rerun_failed_required_checks` explain the current stage and resolve failed configured checks.
* **Quality and projects:** `list_quality_results`, `list_quality_features`, `list_quality_anomalies`, `get_quality_evidence`, `compare_release_quality`, and the LaneSync Project tools show evidence and cross-repository progress.
* **Deliver:** `get_evidence_review`, `approve_release_evidence`, `merge_release_evidence`, `preview_release_deployment`, `start_release_deployment`, and `get_release_deployment` guide controlled delivery.

Ask “What is blocking owner/repo v1.2?” or “Compare the latest quality results for owner/repo.” Changes return an operation ID so you can inspect the outcome before retrying. Setup protection, evidence review/merge, and deployment require a one-time LaneSync confirmation link for that exact action.

Try these prompts after connecting:

* “Onboard owner/repo, show me the exact setup preview, then help me finish the browser confirmation.”
* “Create v1.2 in owner/repo, add issues 12 and 18, and show me which issues still need owners.”
* “What is blocking owner/repo v1.2? Show the failing required check and the next action.”
* “Compare quality in owner/repo v1.2 with v1.1, including coverage and security findings.”
* “Review evidence for owner/repo v1.2 and prepare its configured production deployment.”

The deployment tool dispatches only a workflow bound in `sdlc.yaml`. The configured workflow must accept a `candidate_sha` input and run a LaneSync gate check before deployment. A dispatch request is not a deployment result; use `get_release_deployment` to track the run and confirmed deployment record. The starter production workflow fails until you configure real deployment commands.

For a repository using the bundled production workflow, the binding looks like this:

```yaml theme={null}
stages:
  deployment:
    workflow_dispatch:
      workflow: .github/workflows/deploy-prod.yml
      ref: main
      inputs:
        release_version: "{{release_version}}"
        candidate_sha: "{{candidate_sha}}"
```

Use the workflow's actual file and execution ref. GitHub environment approvals remain in force. LaneSync checks the candidate again inside the workflow.

## Finish repository onboarding

After reviewing the plan and completing its confirmation link, apply repository onboarding. When the installed App supports setup, LaneSync uses it automatically. Otherwise, follow the returned setup link to complete [Trusted Bootstrap](/guides/trusted-bootstrap) in the wizard.

A **`PR_CREATED`** receipt means setup still needs a merge. Follow its `reviewLink` to review and merge the setup PR in LaneSync. If App-based automatic merging was blocked, LaneSync completes protection after your manual merge using the same App; no PAT is required. PAT-based setup uses the encrypted token while available and may require a replacement through the wizard.

Wait for **`COMPLETE`** and verified active protection before treating the repository as ready. A completed receipt does not require another merge. If an operation's result is uncertain, inspect its operation ID and repository onboarding status before submitting setup again.

## Clients that use custom headers

Open **Configuration → System Config → MCP connection** and create a personal key. Read access is the default. Select **Allow release changes** when the client needs writes. Copy the key once, then set `Authorization: Bearer <your MCP key>` for `https://lanesync.dev/api/mcp`. Keys expire after 30 days and can be revoked in Configuration.

<Warning>
  Keep personal keys in your client's secret store. Do not paste them into prompts or commit them. CI API keys beginning with `lsk_` cannot access MCP. Unknown setup, stale gates, or missing deployment configuration cannot authorize deployment.
</Warning>

## Connection troubleshooting

<AccordionGroup>
  <Accordion title="LaneSync asks you to reconnect with GitHub">
    Your signed-in GitHub credential could not be accepted. In LaneSync, open your user menu, choose **Sign out**, then sign in again with the GitHub account you want to use. Retry personal-key creation, or restart the browser authorization flow in your MCP client.

    A LaneSync MCP key and your GitHub credential are separate. Creating another MCP key does not repair an expired GitHub credential.
  </Accordion>

  <Accordion title="GitHub denies permission for an action">
    Check that your GitHub account has the required access to the repository or organization and that the LaneSync GitHub App is installed with access to that repository. Ask your GitHub administrator to grant missing access, then retry. A permission error does not by itself mean your credential has expired.
  </Accordion>

  <Accordion title="GitHub is rate limiting or temporarily unavailable">
    Wait before retrying. Follow the retry delay when your client displays one. You do not need to reconnect just because GitHub is throttling requests or unavailable.

    During OAuth token exchange or refresh, these failures leave the existing authorization code or refresh token available for retry while it remains valid. If the code expires before retry succeeds, restart browser authorization. Personal-key creation can be retried from **Configuration → System Config → MCP connection** after GitHub recovers.
  </Accordion>
</AccordionGroup>

## Related

<CardGroup cols={2}>
  <Card title="Install the GitHub App" href="/guides/install-github-app">Connect your repositories to LaneSync.</Card>
  <Card title="First release" href="/guides/first-release">Track a release through the pipeline.</Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.