Enables searching and retrieving scanned pages from the Media History Digital Library, hosted on the Internet Archive, with full-text search and keyword-in-context excerpts.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@lantern-mcp search for 'Casablanca' in Variety from 1942"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A CLI and MCP server for Lantern, the full-text search platform of the Media History Digital Library — the digitised entertainment trade press. Variety, Billboard, the New York Clipper, Motion Picture Herald, Boxoffice, the studio year books and the fan magazines: roughly two million scanned pages of the industry writing about itself, from the 1900s to the 1960s.
No API key, no account, no registration.
Search resolves to an individual scanned leaf and returns that leaf's keyword-in-context excerpt inline, so judging a hit costs no second request. Every result links back to the page on the Internet Archive, with the search term pre-highlighted.
lantern search '"Gone with the Wind"' --from-year 1939 --to-year 1941 --per-page 3# "Gone with the Wind" [1939–1941] — 4475 results, page 1 of 1492
[1] December 1939 motionpictureher137unse
leaf 213 · Periodicals
... the première of {Gone} {with} {the} {Wind} in Atlanta ...
motionpictureher137unse_0213
http://archive.org/stream/motionpictureher137unse#page/n212/mode/2up/search/...Related MCP server: historical-investigator-mcp
uv tool install --force --reinstall .That puts lantern on your PATH. To register the MCP server with Claude Code, Codex or Gemini:
uv run lantern-mcp-install # basic search tool only
uv run lantern-mcp-install --enable-advanced-search # plus filters and facetsThe CLI always exposes every filter; the MCP server hides the advanced ones behind that flag, because a tool schema sits in the model's context permanently whether it is used or not.
searchlantern search '"Technicolor"' # 86,314 results
lantern search '"Technicolor" AND Warner' # 33,868 results
lantern search '"Gone with the Wind"' --title Variety --sort date_asc
lantern search '"Gone with the Wind"' --collection 'Hollywood Studio System'Flag | Meaning |
| which result pages to fetch (default: 1) |
| results per request, up to 100 |
| year of publication, inclusive |
| exact collection value, e.g. |
| exact publication title, e.g. |
| exact format, e.g. |
| exact language, e.g. |
|
|
| emit JSON instead of text |
Every filter is optional and absent by default. The active ones are echoed back in the result header, so a small total is always traceable to what produced it.
A query is required. Lantern has no browse-everything mode: an empty query returns 0 results, and so does *, which is matched literally rather than as a wildcard. There is no filters-only search, so the CLI refuses one rather than returning a confident zero.
facetsThe filters match whole strings, so Vaudeville for Theatre and Vaudeville returns zero with no error — indistinguishable from an empty archive. facets is how you get the value verbatim:
lantern facets title '"Gone with the Wind"'# title values for "Gone with the Wind" — 21 listed
1331 Motion Picture Herald
1242 Boxoffice
1231 Variety
1014 Motion Picture Daily
686 The Exhibitor
523 Showmen's trade reviewThe counts describe that query's result set — which trade papers carry a term, and in what numbers. They are never corpus-wide: facet counts are computed over the hits, so a query is required here too. Without one every value comes back as 0, which reads as an empty archive rather than as the missing argument it is.
Fields: collection, title, format, language. There is no year, because year is a range filter rather than a list facet.
getlantern get motionpictureher137unse_0213Prints the path to the cached OCR text of that one leaf.
This is expensive per volume, not per page. Lantern indexes text it does not host: the scans live on the Internet Archive, which publishes OCR per volume and never per page. So reading one leaf means fetching that volume's OCR entire — 8 to 25 MB — and slicing the leaf out locally. The volume is then cached, so every later leaf of the same volume is free. Sweeping one publication is dramatically cheaper than sweeping across many.
Most of the time you do not need it: search already returns the excerpt.
The default operator is OR, not AND. This is the single most important thing to know about this source, and it fails silently:
lantern search 'Technicolor Warner' # 332,891 — pages holding EITHER word
lantern search '"Technicolor" AND Warner' # 33,868 — pages holding bothNothing in the first result set announces that it is mostly pages containing the word Warner. The CLI prints a warning when it sees two or more unquoted words for exactly this reason.
"quoted phrases" match exactly.
AND, OR and NOT all work. They partition cleanly: for one sample query, A AND B returned 788 and A NOT B returned 995, summing to the 1,783 of A alone.
Wildcards and proximity do not work and fail silently. A trailing * returns near-zero rather than expanding, and "a b"~2 breaks the phrase and degrades to OR, returning more results than the corpus has relevant pages.
Reported totals are true match counts, not a relevance-ranked tail: paging reaches exactly the reported total, and the last page holds the expected remainder. A total may therefore be quoted as a count, and --sort date_asc is safe on any query.
Facet counts are the exception: they sum to more than the total, because a volume can belong to several collections at once.
Lantern's robots.txt states crawl-delay: 5 for every user agent, and that is where this client's default pacing comes from — it is the site's published wish rather than a guess. Requests are spaced by a cross-process limiter, so several concurrent CLI invocations still share one budget.
Override with LANTERN_MIN_REQUEST_INTERVAL (seconds). Lowering it is asking for trouble on a free service that no one is being paid to run.
OCR downloads only — never search results. Under $XDG_CACHE_HOME/lantern-mcp, overridable with --cache-dir or LANTERN_CACHE_DIR. Volumes are cached whole and gzipped; individual leaves are written out beside them as plain text.
Apache 2.0.
Download one leaf's OCR text, returning the path to the cached file.
Use only when the search excerpt is not enough and the whole page has to be read or grepped. This is expensive per volume: the Internet Archive serves OCR per volume rather than per page, so the first leaf of a volume costs an 8-25 MB download and every later leaf of that volume is then free.
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes | Leaf reference, as returned by `search_lantern` |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses per-volume cost and caching behavior: first leaf triggers 8-25 MB download, subsequent leaves free. This goes beyond the basic 'download' description and informs decisions, especially since no annotations are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, first states action, second provides guidance. No fluff, efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with output schema, the description covers purpose, usage criteria, cost behavior, and return value. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'reference' is fully described in schema (100% coverage) including provenance from search_lantern. Description adds no extra semantic beyond schema, but that's unnecessary due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Download', specific resource 'one leaf's OCR text', and explicit outcome 'path to cached file'. Distinguishes from sibling search_lantern by focusing on whole-page download vs excerpts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use only when...' with condition 'search excerpt is not enough and whole page has to be read or grepped'. Also mentions cost trade-off, guiding when to prefer this over search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the entertainment trade press full text.
Lantern indexes the Media History Digital Library: Variety, Billboard, the New York Clipper, Motion Picture Herald, the studio year books and the fan magazines, roughly 1900-1960. This is the industry's own press - where stage acts were reviewed, booked and gossiped about by the trade that employed them - rather than general news coverage.
THE DEFAULT OPERATOR IS OR, NOT AND. Bare words are combined with OR, so
thought reader matches every page holding either word (272,059) while
"thought reader" matches the phrase (27). Always quote a phrase, or join
words with AND. Boolean AND, OR and NOT work; wildcards and proximity do not.
Each result resolves to one scanned leaf and carries its keyword-in-context excerpt inline, with matches in {braces}, so no further call is needed to judge a hit.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Result page number, 1-indexed | |
| query | Yes | Search terms |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It does so thoroughly, revealing the OR-default operator, boolean support, lack of wildcards, and the output format (each result resolves to one scanned leaf with keyword-in-context excerpts in {braces}). The example counts (272,059 vs 27) vividly illustrate the impact of quoting phrases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized given the tool's complexities, with the purpose front-loaded in the first sentence. It is well-structured into distinct paragraphs covering corpus, syntax, and output format, with all-caps emphasis for the critical OR-default warning. Every sentence adds value; the examples and counts are illustrative rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a search tool with two simple parameters and an output schema. It covers the corpus scope, notable search quirks, and the inline result format, ensuring the agent understands what will be returned. The implicit nod to the sibling tool for full-text retrieval is sufficient given the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters ('Search terms' and 'Result page number, 1-indexed'), so the baseline is 3. The description adds significant meaning to the query parameter by explaining how terms are combined (OR by default) and the importance of quoting phrases, which is not captured in the schema. It does not add anything for the page parameter, but that is adequately described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search the entertainment trade press full text.' It elaborates on the exact corpus indexed (Variety, Billboard, New York Clipper, etc.) and timeframe, distinguishing it from general news searches. The sibling tool get_lantern_text is implicitly differentiated by noting that search results include excerpts 'so no further call is needed to judge a hit.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong contextual guidance by specifying the corpus is 'the industry's own press' and offering detailed search syntax instructions: 'THE DEFAULT OPERATOR IS OR, NOT AND.' It advises when to quote phrases and explicitly states what is not supported ('wildcards and proximity do not'). However, it does not explicitly name alternatives or state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_lantern_textsearch_lanternScored across 2 tools
The two tools have clearly distinct purposes: one searches and returns excerpts, the other fetches full OCR text for a specific leaf. There is no ambiguity in their roles, and descriptions reinforce their complementary nature.
Both tool names follow a consistent verb_noun snake_case pattern: search_lantern and get_lantern_text. Even though one adds a modifier, the verb-first structure and shared domain noun keep the naming uniform and predictable.
With only two tools, the set feels minimal — at the low end of what's useful. For such a narrow domain (searching and reading a specific archive), two might suffice, but it still borders on overly thin.
The workflow is complete for the core use case: search to locate relevant pages, then fetch full text when needed. Minor gaps exist, such as no way to browse volumes or get metadata, but these are not essential for typical search-and-read tasks.
Search and analyze global news coverage and US TV transcripts via the GDELT Project APIs.
Search books and authors across Open Library, the Internet Archive open catalog.
Search 150M+ academic works, journals, and funders via Crossref API.
Search 36M+ PubMed biomedical articles and ClinicalTrials.gov studies.