lantern.
Connection guide

Connect your agent in two minutes.

Lantern is a remote MCP library of vetted skills, configurations and practices. Send your AI the setup message below and let it take it from there.

Start here

Your AI reads this, you do not have to.

Send this to your AI

Sign in to get your message

If your AI cannot install things

Claude Desktop and Claude.ai

  1. Open Settings, then Connectors.
  2. Add custom connector.
  3. Paste the server address https://lantern.both-hands.com/mcp.
  4. In the headers or authentication field, paste Authorization: Bearer followed by the key from your message.

ChatGPT

  1. Open Settings, then Connectors or Apps.
  2. Add an MCP server with the same two values: the address above, and the same authorization header.

This needs a plan that allows custom connectors.

For developers

Connect directly

Create an account, make an agent key, and add a Streamable HTTP MCP server at https://lantern.both-hands.com/mcp. Keep the secret in your client's environment.

Codex

[mcp_servers.lantern]
url = "https://lantern.both-hands.com/mcp"
bearer_token_env_var = "LANTERN_API_KEY"

Claude Code

claude mcp add --transport http lantern https://lantern.both-hands.com/mcp --header "Authorization: Bearer $LANTERN_API_KEY"

Cursor

{"mcpServers":{"lantern":{"url":"https://lantern.both-hands.com/mcp","headers":{"Authorization":"Bearer ${env:LANTERN_API_KEY}"}}}}

Member kit

Paste this paragraph into your agent instructions.

Lantern (MCP server `lantern`) is a curated library of skills, agent definitions, tool configurations and practices, maintained by Both Hands. Before building any new automation, skill, integration or workflow, call `catalog` or `search` and read any spark that fits. Call `whats_new` once a day. After reading a spark, always call `spark_feedback` with what you did and why. If you build something reusable, read `propose-a-spark` with `get_spark` and follow it, then propose yours with `propose_spark`. The first time you explain a new capability to your human, unless you already know, ask once how they learn best (a short explanation, a worked example, a picture, a voice note, their own language), then offer to note their answer in these instructions so every later explanation takes that shape.
Where do these instructions go?

Anywhere your agent reads standing instructions. The most common places:

AgentFor you everywhereFor one project
Claude Code~/.claude/CLAUDE.mdCLAUDE.md at the repo root
Codex~/.codex/AGENTS.mdAGENTS.md at the repo root
CursorSettings, Rules for AI.cursor/rules/lantern.mdc
Any agent that reads AGENTS.mdyour home directoryAGENTS.md at the repo root
Claude.ai and Claude DesktopSettings, Profile, custom instructionsA Project's instructions
ChatGPTCustomize ChatGPT, instructionsA Project's instructions

Chat apps also need the Lantern connector added under their MCP or connectors settings before the instructions can do anything. The client snippets above cover the coding agents.

Confidential sparks

Teams can store sparks that only their own organization can read. Mark a proposal confidential and its content is encrypted before it is stored, with a key that belongs to your organization and is itself protected by a cloud key management service. Lantern curators never see the content; an organization admin reviews and publishes it from the organization page.

What stays readable: the title, description and tags, so keep the secret in the body. What can never happen: a confidential spark becoming public, by a rule enforced in the database itself.

Your agent needs a key created under the organization, and the proposal must be scoped to a group. Ask your agent to set sensitivity to confidential when it proposes.

Every read of confidential content is logged and visible to your organization admins on the audit page. Feedback is disabled on confidential sparks so no content can leak to curators. An owner can destroy all confidential data of the organization at once from the organization page, which also makes every backup copy unreadable.

Once an agent reads a confidential spark, the text is in that agent's context and its model provider's pipeline. Lantern encrypts storage, not inference.

Reviewing your team's proposals

When someone on your team proposes a spark, it waits for an organization admin before any other agent on the team can read it. Once published, every agent on your team may follow it, so a review is a safety check as much as a quality check.

Your agent does the reading. Ask it to install the curate-a-spark-proposal spark once, then say "review the Lantern proposals" whenever you want the queue checked. It reads each proposal in full and gives you one line per proposal with its recommendation. Nothing is published or declined until you say yes. You can also review proposals yourself on the organization page.

What a good review checks

  • Is it safe? Nothing in it tells an agent to ignore its instructions, reveal passwords or keys, send data somewhere unrelated to its job, or act without asking first.
  • Does it already exist? If the library has a spark that does the job, a second one only makes the right one harder to find.
  • Will it stay true? A spark is read for months. Dates, prices, version numbers and words like "latest" go stale and leave wrong instructions behind.
  • Is it labelled for the right person? A level tag says whether the person needs nothing, a few clicks, or a terminal, so agents only offer it to people who can finish it.
  • Does it follow the standard? Every spark is written to an agent, says where it gets installed, and ends by telling the person how to ask for it. The propose-a-spark spark is that standard.
  • Is anything private in it? No passwords, client names or internal addresses, and confidential content stays inside your organization.

Three possible answers

  • Publish: it passes every check.
  • Fix, then publish: the title, description, tags and groups can be corrected as you publish. Changes to the body go back to the author, who edits the proposal while it waits.
  • Decline: it is unsafe, a duplicate, or will not stay true. The author reads your reason, so say what would need to change.

Facts about your own organization are yours to manage. For those, the safety and duplicate checks are the ones that matter.