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., "@Prophets What has President Nelson taught about the gathering of Israel?"
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.
Prophets, apostles and the women who lead The Church of Jesus Christ of Latter-day Saints, in an MCP.
The First Presidency, the Quorum of the Twelve, and the Relief Society, Young Women and Primary general presidencies, each turned into a searchable MCP server built from their General Conference talks and BYU speeches. Add one to Claude, Cursor or Codex. Every answer cites its source.
Use it · Women leaders · Prophets and apostles · How it works · Content
You need uv, the Python package manager.
git clone https://github.com/kcferguson1/prophets-mcp.git
cd prophets-mcp
uv sync
uv run fetch.py # downloads every talk into prophets.db (about 20 minutes; rerun any time, it skips what's saved)Then add a server from inside the folder. Leave out --speaker to get every speaker in one server.
# Claude Code: everyone
claude mcp add --scope user prophets -- uv run --directory "$PWD" server.py
# Claude Code: one speaker
claude mcp add johnson -- uv run --directory "$PWD" server.py --speaker camille-n-johnson# Codex
codex mcp add prophets -- uv run --directory "$PWD" server.pyIn Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json) and Cursor (~/.cursor/mcp.json), add it with the folder's full path:
{
"mcpServers": {
"prophets": {
"command": "uv",
"args": ["run", "--directory", "/full/path/to/prophets-mcp", "server.py"]
}
}
}Then just ask: "What has Sister Camille N. Johnson taught about finding relief in Jesus Christ?", "What has President Nelson taught about the gathering of Israel?" or "How does Sister Emily Belle Freeman describe a covenant relationship with Christ?"
ChatGPT only connects to MCP servers at a public HTTPS address. uv run server.py --http serves the same tools over streamable HTTP at /mcp on $PORT, but there's no public server yet.
New talks arrive on their own. When a server starts and the last full check is more than 30 days old, it runs fetch.py in the background and keeps answering while it works. Only one update runs at a time, even with several servers open. Progress goes to prophets-update.log.
To update right away, run uv run fetch.py. When the roster changes, run git pull to get the new speaker list.
Server | Tool | What it does |
One speaker ( |
| Searches that speaker's talks and returns passages in their own words, each with title, date and source link |
| Lists every talk and speech in that speaker's collection, newest first | |
Everyone (no |
| Searches all speakers, or one if you pass a slug |
| Lists every speaker, their slug and how many talks they have | |
| Lists one speaker's talks, newest first |
## 1. Clark G. Gilbert, "Come Home"
General Conference, 2026-04
Source: https://www.churchofjesuschrist.org/study/general-conference/2026/04/15gilbert?lang=eng&id=p_vO6YV#p_vO6YV
Come home! Come home! Ye who are weary, come home!Conference links jump straight to the quoted paragraph. BYU links open the speech.
Related MCP server: Gospel Library MCP Server
The women who preside over the Relief Society, Young Women and Primary lead the Church's organizations for women, young women and children around the world. They serve as general officers of the Church and sit on its executive councils. (They aren't General Authorities, a title the Church uses for priesthood offices.) Their talks are searchable on equal footing with everyone else's.
Speaker | Slug | Calling | Serving since | Conference talks | BYU speeches | Passages |
Camille N. Johnson |
| Relief Society General President | 2022 | 3 | 1 | 260 |
J. Anette Dennis |
| First Counselor, Relief Society General Presidency | 2022 | 3 | 1 | 206 |
Kristin M. Yee |
| Second Counselor, Relief Society General Presidency | 2022 | 3 | 1 | 307 |
Emily Belle Freeman |
| Young Women General President | 2023 | 3 | — | 168 |
Tamara W. Runia |
| First Counselor, Young Women General Presidency | 2023 | 3 | — | 192 |
Andrea Muñoz Spannaus |
| Second Counselor, Young Women General Presidency | 2023 | 1 | — | 39 |
Rosemary K. Chibota |
| Primary General President | 2026 | 1 | — | 34 |
Nina M. Garfield |
| First Counselor, Primary General Presidency | 2026 | — | — | — |
Theresa A. Collins |
| Second Counselor, Primary General Presidency | 2026 | — | — | — |
Presidencies as listed on the Church's leadership pages in October 2026. The Primary presidency began serving in August 2026. Sister Garfield and Sister Collins haven't spoken in General Conference or at BYU yet, so their talks will appear through the monthly update once they do.
Speaker | Slug | Calling | Apostle since | Conference talks | BYU speeches | Passages |
Dallin H. Oaks |
| President of the Church | 1984 | 99 | 33 | 5,673 |
Henry B. Eyring |
| First Counselor in the First Presidency | 1995 | 106 | 20 | 5,451 |
D. Todd Christofferson |
| Second Counselor in the First Presidency | 2008 | 44 | 12 | 2,175 |
Dieter F. Uchtdorf |
| Acting President of the Quorum of the Twelve | 2004 | 75 | 6 | 4,332 |
David A. Bednar |
| Quorum of the Twelve | 2004 | 45 | 10 | 2,475 |
Quentin L. Cook |
| Quorum of the Twelve | 2007 | 41 | 7 | 2,054 |
Neil L. Andersen |
| Quorum of the Twelve | 2009 | 41 | 10 | 2,600 |
Ronald A. Rasband |
| Quorum of the Twelve | 2015 | 29 | 7 | 1,566 |
Gary E. Stevenson |
| Quorum of the Twelve | 2015 | 26 | 4 | 1,327 |
Dale G. Renlund |
| Quorum of the Twelve | 2015 | 25 | 6 | 1,218 |
Gerrit W. Gong |
| Quorum of the Twelve | 2018 | 20 | 7 | 1,479 |
Ulisses Soares |
| Quorum of the Twelve | 2018 | 23 | 4 | 789 |
Patrick Kearon |
| Quorum of the Twelve | 2023 | 9 | 4 | 665 |
Gérald Caussé |
| Quorum of the Twelve | 2025 | 10 | 2 | 478 |
Clark G. Gilbert |
| Quorum of the Twelve | 2026 | 3 | 4 | 332 |
Russell M. Nelson |
| 17th President of the Church (died 2025) | 1984 | 114 | 22 | 5,468 |
Jeffrey R. Holland |
| President of the Quorum of the Twelve (died 2025) | 1994 | 64 | 36 | 4,163 |
M. Russell Ballard |
| Acting President of the Quorum of the Twelve (died 2023) | 1985 | 88 | 22 | 4,298 |
Roster as of March 2026, plus apostles who died since October 2021. Counts include talks given before each speaker became an apostle. When callings change, edit SPEAKERS in fetch.py and run it again.
Each server is a small, cited search index over one speaker's own words. Nothing is summarized or rewritten, so every passage is a direct quote.
speaker pages ──▶ talk text ──▶ paragraphs ──▶ search index ──▶ MCP server
(conference (content (each with (SQLite FTS5, (search, list_talks,
+ BYU lists) APIs) its own link) BM25 ranking) list_speakers)Step | Command | Output |
1. Fetch |
|
|
2. Check |
| A self-check of the paragraph reader and the search |
3. Serve |
| An MCP server over stdio, ready for Claude, Cursor or Codex |
4. Update | automatic, monthly | The server reruns step 1 in the background when the last full check is over 30 days old |
Sources. General Conference talks come from the Church's content API on churchofjesuschrist.org. BYU devotionals and forums come from the BYU Speeches site's data API.
Search. SQLite's built-in full-text search (FTS5) ranks paragraphs with BM25, a standard way to score how well text matches a question. Porter stemming means "repenting" also finds "repentance". A matching talk title helps a passage rank, footnotes are left out, and at most two passages come from any one talk, so one long talk can't fill every result.
Skipped on purpose. The sustaining of Church officers, auditing reports and statistical reports are left out. They are read aloud as procedure, not given as teaching.
fetch.py downloads the talks and builds the index. Rerunning it skips talks already saved.
server.py is the MCP server, and it starts the monthly update. It's built on the official MCP Python SDK.
test_prophets.py is the self-check.
This project is unofficial. It is not affiliated with or endorsed by The Church of Jesus Christ of Latter-day Saints or Brigham Young University.
Talks are © Intellectual Reserve, Inc. and Brigham Young University. Their terms allow personal, noncommercial use. Get permission before hosting this publicly.
The repo contains only code. The talk text is downloaded to your own computer when you run fetch.py, and it is never committed.
Every passage links to its original source, so you can read it in context.
The code is MIT. Talk content belongs to its owners; see Content.
List the speakers (with the slug to pass to search) and how many talks each has.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'List' implies a read-only operation, and the description discloses that the output includes slugs and talk counts, but it does not state side-effect behavior, permissions, or pagination expectations.
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 a single, front-loaded sentence with no wasted words. The parenthetical adds useful information without disrupting conciseness.
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?
Given the tool has zero parameters and an output schema, the description provides enough context to select and invoke it correctly. It could be slightly more complete by explicitly naming when to use it relative to list_talks, but nothing essential is missing.
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 tool has zero parameters, so there are no parameter semantics to explain. The baseline for zero-parameter tools is 4, and the description does not need to compensate for any schema gaps.
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 uses a specific verb+resource ('List the speakers') and adds the useful detail that each speaker includes a slug and talk count. It implicitly distinguishes this from list_talks by focusing on speakers and their talk counts, though it does not explicitly name the sibling tools.
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 parenthetical 'with the slug to pass to search' gives a clear usage hint that this tool is a precursor to the search tool. However, there is no explicit guidance on when to use this versus list_talks or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every talk and speech for one speaker slug, newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| speaker | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the sort order (newest first) and that the result is a complete enumeration ('every'), but says nothing about pagination, result limits, or permissions for a list operation.
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?
A single front-loaded sentence with zero filler; scope and ordering both land immediately.
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 one-parameter list tool with an output schema, the description covers what is listed, for which key, and in what order. Only pagination/limit behavior is left unstated, which is a minor gap against an otherwise complete definition.
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?
Schema description coverage is 0%, so the description must compensate. It adds one meaningful hint — the 'speaker' value is a slug — but does not clarify the slug format, whether it is an ID or a name-derived key, or error behavior for an invalid slug.
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?
States a specific verb and resource ('List every talk and speech') with a clear scope ('for one speaker slug') and ordering ('newest first'). It implicitly separates itself from the sibling 'search' by being a per-speaker enumeration, but never names that alternative explicitly.
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?
Usage is only implied: an agent can infer this is the tool to call when it has a speaker slug and wants all talks. There is no explicit when-to-use guidance, no exclusion of 'search', and no mention of what to do if the slug is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search talks by the First Presidency, the Twelve, apostles who died since 2021, and the Relief Society, Young Women and Primary general presidencies. Optionally limit to one speaker slug from list_speakers. Quote passages in the speaker's own words and cite each one with its Source link, title and date.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| speaker | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the load and does disclose the most important behavioral constraint: the fixed speaker corpus that bounds results. It also prescribes quoting in the speaker's own words with Source link, title and date, which shapes how results should be used. It omits failure/empty-result behavior and any default-result-size context, keeping it below a 5.
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 sentences, front-loaded with the corpus scope and followed by the one actionable option. The citation/quoting sentence blends response-formatting guidance with search guidance, but every clause is informative and there is no filler.
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?
An output schema exists, so return structure needn't be explained, and the description covers the corpus, the one filtering option, and how to present citations. The only meaningful gap is the unexplained `limit` default in an otherwise complete definition for a 3-parameter search tool.
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?
Schema description coverage is 0%, so the description must compensate, and it does for `speaker` (a slug sourced from list_speakers). The `limit` parameter and its default of 8 are never mentioned, so one of three parameters remains semantically opaque. Partial compensation supports a 3.
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?
Uses a specific verb (search) plus resource (talks) and, unusually, defines the corpus by speaker: First Presidency, the Twelve, apostles who died since 2021, and general presidencies. That scope statement distinguishes it from list_talks/list_speakers, though it never explicitly says how it differs from those siblings.
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?
"Optionally limit to one speaker slug from list_speakers" gives clear conditional usage and routes the agent to the sibling needed to obtain a valid slug. It stops short of stating when to prefer this over list_talks or what to do when a query returns nothing.
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.0list_speakerslist_talkssearchScored across 3 tools
Each tool has a clearly distinct purpose: content search, speaker listing, and per-speaker talk listing. Although search can be filtered by speaker slug and list_talks also uses speaker slugs, the descriptions make the boundary between finding passages and enumerating talks clear.
The set mostly follows a predictable snake_case verb_noun pattern with list_speakers and list_talks. The bare verb search is a minor deviation but remains readable and intuitive.
Three tools are well matched to this focused reference/search server, with no redundant or extraneous operations. Each tool supports a core workflow: discovering speakers, browsing their talks, and searching content.
The surface covers discovery and search well, but there is no explicit get_talk or full-transcript retrieval tool. That is a minor gap if users want to read an entire talk rather than search passages or list titles.
Search speech in podcasts, government meetings, and your own audio: speakers, entities, timestamps.
Search, read and act on your LiteScribe recordings: transcripts, summaries, action items, quotes.
Search and cite passages from a vetted, rights-cleared reference library.
Search Ellen G. White’s writings by keyword to surface relevant quotations. Retrieve exact passage…
