---
name: lore-setup
description: Connect a coding agent to hosted Lore through MCP, authorize with GitHub, and verify access to repository memory. Use when a user asks to install, connect, or troubleshoot their Lore agent connection.
---

# Set up Lore

Connect the user's current coding agent to Lore's hosted repository memory.
Lore ingests connected GitHub repositories and keeps their memory current
automatically. There is no required review queue, local Lore server, or AI provider
key to configure.

- Dashboard: https://app.buildwithlore.ai
- MCP endpoint: https://mcp.buildwithlore.ai/mcp
- Transport: Streamable HTTP
- Authentication: browser-based OAuth using the user's GitHub account
- Human instructions: https://docs.buildwithlore.ai/connect-your-agent

## Identify the client and existing connection

Use the current session's client identity and available configuration to identify
the agent. An installed CLI alone does not identify the current client. If unclear,
ask which client the user wants to connect. The client must support remote HTTP MCP
with OAuth; do not claim every MCP client supports this.

Inspect only the relevant MCP configuration, without displaying existing secrets.
Reuse a working Lore connection. Default to the client's user-level configuration
so Lore is available across projects. Honor an explicit request for project-only
setup. Preserve unrelated servers and settings. If `lore` already points somewhere else,
clarify before replacing it. Do not install another coding agent or a local MCP
proxy as an unrequested workaround.

## Configure the matching client

### Claude Code

Add Lore to the user's configuration if absent:

```sh
claude mcp add --transport http --scope user lore https://mcp.buildwithlore.ai/mcp
```

This makes the connection available across projects. Have the user open `/mcp` in Claude Code,
select Lore, and complete authentication in the browser.

Client reference: https://code.claude.com/docs/en/mcp

### Codex

When the Codex CLI is available, add Lore if absent and authenticate:

```sh
codex mcp add lore --url https://mcp.buildwithlore.ai/mcp
codex mcp login lore
```

Complete the browser flow. If configuring through the client's MCP settings,
choose Streamable HTTP and use the endpoint above, then authenticate there.
The equivalent server entry in Codex's TOML configuration is:

```toml
[mcp_servers.lore]
url = "https://mcp.buildwithlore.ai/mcp"
```

The normal user-level file is `~/.codex/config.toml` (or the configuration under
the user's custom `CODEX_HOME`, when set). Use user-level configuration by default.
Merge this table into that configuration only if needed; do not append
a duplicate table or replace the rest of the file. Reload the client or start a
new session if the tools are not available in the current session.

Client reference: https://developers.openai.com/codex/mcp

### Cursor

For setup across projects, merge the `lore` entry into `~/.cursor/mcp.json`:

```json
{
  "mcpServers": {
    "lore": {
      "url": "https://mcp.buildwithlore.ai/mcp"
    }
  }
}
```

Keep existing server entries. Use project-level `.cursor/mcp.json` only when the
user explicitly requests project-only setup. Enable Lore in MCP settings and complete
browser authentication. Reload the client if necessary.

Client reference: https://cursor.com/docs/mcp

### Other clients

Consult that client's official documentation for remote Streamable HTTP MCP and
OAuth. Add a server named `lore` with the endpoint above using its supported
user-level configuration or settings UI. Do not assume Cursor's JSON or home-directory
path applies to other clients.
If the agent cannot edit its own configuration, give the user the exact settings
or commands to apply, then continue verification after they reconnect.

## Connect GitHub repositories

If the user has not connected a repository, direct them to
https://app.buildwithlore.ai to sign in and install the Lore GitHub App on their
chosen repositories. An organization owner may need to approve installation.
Respect the user's repository selection; do not broaden access to all repositories
to resolve a missing one. GitHub installation and MCP OAuth authorization are
separate steps, and both may be needed.

The user completes browser sign-in and approvals. Never request their password,
OAuth token, authorization code, GitHub App private key, or Lore operator keys in
chat or configuration. Let the client's authentication flow store credentials.

Start the client's OAuth login after adding the server; do not stop at saving
configuration. For clients requiring an interactive settings action, guide the
user to that action. GitHub sign-in creates a Lore account for a new user. Users
without a workspace are sent to the dashboard to install the GitHub App and choose
repositories. After installation, Lore returns them to the pending agent consent
screen automatically. Have them approve the connection and return to the agent.
If the request expired or the client stopped waiting, restart the client's Lore
OAuth login; their account and repository setup remain saved. Complete browser
consent before verifying MCP calls. Do not describe
repository onboarding alone as successful agent authorization.

Once connected, ingestion starts automatically. The user can inspect progress in
Repositories; they do not need to review extracted facts or merge a cleanup PR.

## Verify real tool access

1. Call Lore's `list_repos` with `{}` through the connected MCP client.
2. Read the current project's GitHub remote from local workspace metadata. Match
   it to the returned repositories. Do not make the user type `owner/repo`. For
   forks or multiple workspace roots, select the current origin or ask only if ambiguous.
3. Call `get_context` with `remotes` containing the current remote and `budget: 1500`.
   Include a short `task`, relevant relative `paths`, and optional `issue` when known.
   Do not send the whole chat. This call consumes one shared read or purchased credit.
4. Report what actually worked: configuration saved, authorization completed,
   repository visible, and context retrieved. Distinguish pending steps from success.

An empty repository list can mean the GitHub installation or user access is
missing. An empty context result can mean ingestion is pending or the repository
has no eligible facts; it does not by itself mean authentication failed. Check
scan status before declaring ingestion complete. Do not repeatedly poll reads,
write a test fact, or call `forget` to verify setup.

If tools are not exposed in this session, explain how to reload and provide the
verification request to run afterward. Do not substitute a dashboard screenshot
or an unauthenticated HTTP request for a successful MCP tool call.

At the beginning of later sessions, call `session_briefing` with the same workspace
remote. Use `get_context` for the current task, `related_repositories` for dependency
impact, and `retrospective` for incident lessons. Cite evidence and label inferences.
Facts with conflicting guidance should be explained together, without asking the
user to clear a review queue. `diagnose_connection` reports connected/authenticated,
repository access, ingestion, and retrieval as separate steps. If the client cannot
reach Lore at all, fix its configuration or OAuth login before trying that tool.

For failures, consult https://docs.buildwithlore.ai/troubleshooting and report the
specific failing step without credentials. Do not disable TLS verification or
weaken client authentication settings.

## Finish

Summarize changed configuration and any remaining browser or repository steps.
Once verified, the user can keep working normally and ask the agent to load Lore
context before editing relevant files. Do not modify project instructions, commit
configuration, or install this skill persistently unless requested.

Tool reference: https://docs.buildwithlore.ai/reference/mcp-tools