The Living Bread

Search The Living Bread

search

Read-onlyIdempotent

PURPOSE: Search everything The Living Bread holds with one free-text query: a flat list of results with ids for search then fetch (mode results, the default, the ChatGPT connector contract), one grounded answer with sourced entities and up to 3 verses (mode answer), or one lb: URN resolved to its public object and JSON Schema (mode protocol). WHEN TO USE: a question no other tool fits, deep research that wants ids to fetch, or an lb: URN to resolve. WHEN NOT: a known reference or exact words: read_scripture. A feeling: find_scripture_for. Churches by place: find_churches. One named denomination or saint: learn_the_faith (mode heritage). MODES (required parameters in brackets): results [query] tried in order as a Bible reference, a need, an entity question, a place, and community words. answer [query, one question per call]. protocol [query, an lb: URN such as lb:ministry:hope-for-a-good-life]. OUTPUT: mode, answered_by, and: results gives results [{id, title, text, url}], never empty (no match returns one result linking home); answer gives question, answer (null when nothing sourced), entities [{id, type, name, url, source}], scripture {topic, url, verses} or null, road_to_christ, next_steps and grounding; protocol gives found, protocol_kind, object, schema and source. BEHAVIOR: read only; queries the Christian Knowledge API live. answer stays null and entities empty rather than a guess. The query text (never a user id) is logged anonymously. NETWORK MODE discover [query, the person's wish in a sentence]: capability negotiation for the Living Bread Intelligence Invitation Protocol; names at most three capabilities that answer it and how to call each, reads no data and sends nothing (answered by discover_the_kingdom). Access: no sign-in; shared limit of 300 requests a minute per IP.

Input Schema

Name	Required	Description	Default
`mode`	No	Which kind of answer: results, answer, protocol, discover. Default results. Each mode is explained in the description.	results
`query`	Yes	Free text, 1 to 300 characters: a reference ("Psalm 23"), a need ("anxiety"), a name ("Augustine"), a place ("Lagos"), a question, or an lb: URN for mode protocol.

Output Schema

Name	Required	Description
`ok`	No	Always true on a successful answer (errors come back as isError, never here).
`ids`	No	Up to 25 ids found in this answer, for follow-up calls.
`mode`	Yes	The mode that answered.
`license`	No	License URL of the returned data (CC BY 4.0 unless stated).
`evidence`	No	Present when Scripture was read: translation, canon, corpus version, attribution, and a SHA-256 per passage.
`freshness`	No	How current the answer is: kind (scheduled \| recently_observed \| verified_live \| record), retrieved_at, available_now (true only when activity was verified live).
`source_url`	No	The first public web page this answer came from or points to.
`visibility`	No	"public" for shared data, "yours" for the signed-in believer's own data.
`answered_by`	Yes	The implementation that answered (the same tool name the signed-in endpoint lists).
`attribution`	No	Credit line for the data: The Living Bread (living-bread.org).
`next_actions`	No	Up to 4 links the person can open next.
`result_state`	No	"empty" when nothing matched (count 0, no results); the text then says so plainly.
`content_flags`	No	["instruction_like_text_removed"] when retrieved text was withheld.
`content_layers`	No	Which fields are Scripture and which are human interpretation or reflection.
`ignored_params`	No	Parameters given that this mode does not use.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 18, 2026

changedInput schema / properties / mode / description

Previous value: -"Which kind of answer: results, answer, protocol. Default results. Each mode is explained in the description."New value: +"Which kind of answer: results, answer, protocol, discover. Default results. Each mode is explained in the description."

changedInput schema / properties / mode / enum

Previous value: -[
-  "results",
-  "answer",
-  "protocol"
-]New value: +[
+  "results",
+  "answer",
+  "protocol",
+  "discover"
+]

Changed7 schema fields changedOct 6, 2026

addedInput schema / properties / mode

Added value: +{
+  "default": "results",
+  "description": "Which kind of answer: results, answer, protocol. Default results. Each mode is explained in the description.",
+  "enum": [
+    "results",
+    "answer",
+    "protocol"
+  ],
+  "type": "string"
+}

changedInput schema / properties / query / description

Previous value: -"Free text, 1 to 300 characters: a reference (\"Psalm 23\"), a need (\"anxiety\"), a name (\"Augustine\"), a place (\"Lagos\"), or a topic."New value: +"Free text, 1 to 300 characters: a reference (\"Psalm 23\"), a need (\"anxiety\"), a name (\"Augustine\"), a place (\"Lagos\"), a question, or an lb: URN for mode protocol."

addedOutput schema / properties / answered_by

Added value: +{
+  "description": "The implementation that answered (the same tool name the signed-in endpoint lists).",
+  "type": "string"
+}

addedOutput schema / properties / ignored_params

Added value: +{
+  "description": "Parameters given that this mode does not use.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / mode

Added value: +{
+  "description": "The mode that answered.",
+  "type": "string"
+}

removedOutput schema / properties / results

Removed value: -{
-  "description": "Matches with id (verse:<ref>, need:<slug>, church:<uuid>, gathering:<uuid>, community:<uuid>, or an lb: id), title, one-line text and a web URL. Pass id to fetch.",
-  "items": {
-    "additionalProperties": {},
-    "properties": {
-      "id": {
-        "type": "string"
-      },
-      "text": {
-        "type": "string"
-      },
-      "title": {
-        "type": "string"
-      },
-      "url": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "id",
-      "title",
-      "text",
-      "url"
-    ],
-    "type": "object"
-  },
-  "type": "array"
-}

changedOutput schema / required

Previous value: -[
-  "results"
-]New value: +[
+  "mode",
+  "answered_by"
+]

Changed14 schema fields changedOct 6, 2026

addedInput schema / properties / query / description

Added value: +"Free text, 1 to 300 characters: a reference (\"Psalm 23\"), a need (\"anxiety\"), a name (\"Augustine\"), a place (\"Lagos\"), or a topic."

addedOutput schema / properties / attribution

Added value: +{
+  "description": "Credit line for the data: The Living Bread (living-bread.org).",
+  "type": "string"
+}

addedOutput schema / properties / content_flags

Added value: +{
+  "description": "[\"instruction_like_text_removed\"] when retrieved text was withheld.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / content_layers

Added value: +{
+  "additionalProperties": {},
+  "description": "Which fields are Scripture and which are human interpretation or reflection.",
+  "properties": {},
+  "type": "object"
+}

addedOutput schema / properties / evidence

Added value: +{
+  "additionalProperties": {},
+  "description": "Present when Scripture was read: translation, canon, corpus version, attribution, and a SHA-256 per passage.",
+  "properties": {},
+  "type": "object"
+}

addedOutput schema / properties / freshness

Added value: +{
+  "additionalProperties": {},
+  "description": "How current the answer is: kind (scheduled | recently_observed | verified_live | record), retrieved_at, available_now (true only when activity was verified live).",
+  "properties": {},
+  "type": "object"
+}

addedOutput schema / properties / ids

Added value: +{
+  "description": "Up to 25 ids found in this answer, for follow-up calls.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / license

Added value: +{
+  "description": "License URL of the returned data (CC BY 4.0 unless stated).",
+  "type": "string"
+}

addedOutput schema / properties / next_actions

Added value: +{
+  "description": "Up to 4 links the person can open next.",
+  "items": {
+    "additionalProperties": {},
+    "properties": {
+      "label": {
+        "type": "string"
+      },
+      "url": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "label",
+      "url"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / ok

Added value: +{
+  "description": "Always true on a successful answer (errors come back as isError, never here).",
+  "type": "boolean"
+}

addedOutput schema / properties / result_state

Added value: +{
+  "description": "\"empty\" when nothing matched (count 0, no results); the text then says so plainly.",
+  "enum": [
+    "useful",
+    "empty"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / results / description

Added value: +"Matches with id (verse:<ref>, need:<slug>, church:<uuid>, gathering:<uuid>, community:<uuid>, or an lb: id), title, one-line text and a web URL. Pass id to fetch."

addedOutput schema / properties / source_url

Added value: +{
+  "description": "The first public web page this answer came from or points to.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / visibility

Added value: +{
+  "description": "\"public\" for shared data, \"yours\" for the signed-in believer's own data.",
+  "type": "string"
+}

First observedOct 6, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only/idempotent/open-world, and the description goes well beyond them: live API querying, anonymous query logging (never user ids), a shared 300 requests/minute per IP limit, no sign-in, the deliberate refusal to guess (answer null, entities empty), and the guarantee that results is never empty. These are exactly the operational facts an agent needs and cannot get from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Long but strongly front-loaded and labeled (PURPOSE, WHEN TO USE, WHEN NOT, MODES, OUTPUT, BEHAVIOR), so an agent can scan to the relevant section. Some content is duplicative — the OUTPUT block restates return fields that the output schema already defines, and mode semantics are repeated between schema and description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite four modes, a network mode, anonymous logging and rate limits, nothing an agent needs to call this correctly is missing; the output schema exists yet the description still summarizes shapes, which is a bonus rather than a requirement. The discover mode's no-data-read nature is called out explicitly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so the baseline is 3, and the description adds real value on top: it lists which parameter is required in each mode (results [query], answer [query], protocol [query, lb: URN], discover [query]) and explains how the query text is interpreted in order (reference, need, entity question, place, community words). Minor gap: the 300-character bound is only in the schema, not the prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource (search everything The Living Bread holds via free-text query) and immediately names the three response shapes it can produce. It explicitly differentiates itself from siblings like read_scripture, find_scripture_for, find_churches and learn_the_faith in the WHEN NOT block.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to-use cases (no other tool fits, deep research wanting ids, an lb: URN to resolve) and explicit when-not cases with the correct alternative tool named for each. This is about as complete a routing guide as a description can carry.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All The Living Bread tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?