Skip to main content
Glama

The Living Bread

by org.living-bread.mcp
OverviewDiscussionsAdmin

Find a community to belong to, or Christian life at a university

find_communities
Read-onlyIdempotent

PURPOSE: Find ongoing Christian community to belong to: discoverable groups on The Living Bread (prayer groups, study groups, city and interest communities) with member counts, how to join and the next posted gathering; or the house's University Network page for a country, US state or city. WHEN TO USE: "is there a prayer group", "a Bible study community in Atlanta", "Christian community at universities in Kenya". WHEN NOT: church buildings: find_churches. One-off events: find_gatherings. A person to pray with now: find_people_to_pray_with. MODES (required parameters in brackets): to_join [none] communities, filtered by query words matched against name, description, kind, city and country (any word matches, so more words widen), paged with limit (1 to 20, default 10) and cursor. university [place] one country, US state or city. OUTPUT: mode, answered_by, and: to_join gives count, total, communities [{id, name, kind, description, where, people, join, next_gathering, rhythm, verified, freshness, handoff}], join_here and next_cursor; university gives matched (null when not held), title, url, summary, entries (up to 14 campus or region pages), suggestions and door. BEHAVIOR: read only. to_join reads live data and never lists private family rooms; university fetches living-bread.org at call time and returns page links, not a structured list of student groups. No match returns count 0, or matched null with the places held. Parameters a mode does not use are ignored and named in ignored_params. NETWORK MODE family [optional query, place, limit, cursor]: the discoverable Christian communities a lonely or new person could join, with an honest empty and a consent note; no member is named (answered by find_my_family). Access: no sign-in; shared limit of 300 requests a minute per IP.

Input Schema

NameRequiredDescriptionDefault
modeNoWhich kind of answer: to_join, university, family. Each mode, and the parameters it needs, is explained in the description. Leave it out and the answer says what each mode is for.
limitNoFor to_join: page size, 1 to 20 (default 10).
placeNoFor university: one country, US state or city by name: "Japan", "California", "Nairobi".
queryNoFor to_join: filter words, e.g. "prayer", "study", "Atlanta". Omit to list all.
cursorNoOpaque paging token: next_cursor from the previous answer of the same call. Omit for the first page.

Output Schema

NameRequiredDescriptionDefault
okNoAlways true on a successful answer (errors come back as isError, never here).
idsNoUp to 25 ids found in this answer, for follow-up calls.
modeYesThe mode that answered.
licenseNoLicense URL of the returned data (CC BY 4.0 unless stated).
evidenceNoPresent when Scripture was read: translation, canon, corpus version, attribution, and a SHA-256 per passage.
freshnessNoHow current the answer is: kind (scheduled | recently_observed | verified_live | record), retrieved_at, available_now (true only when activity was verified live).
source_urlNoThe first public web page this answer came from or points to.
visibilityNo"public" for shared data, "yours" for the signed-in believer's own data.
answered_byYesThe implementation that answered (the same tool name the signed-in endpoint lists).
attributionNoCredit line for the data: The Living Bread (living-bread.org).
next_actionsNoUp to 4 links the person can open next.
result_stateNo"empty" when nothing matched (count 0, no results); the text then says so plainly.
content_flagsNo["instruction_like_text_removed"] when retrieved text was withheld.
content_layersNoWhich fields are Scripture and which are human interpretation or reflection.
ignored_paramsNoParameters given that this mode does not use.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / mode / description
      Previous value: -"Which kind of answer: to_join, university, family. Each mode, and the parameters it needs, is explained in the description."New value: +"Which kind of answer: to_join, university, family. Each mode, and the parameters it needs, is explained in the description. Leave it out and the answer says what each mode is for."
    • removedInput schema / required
      Removed value: -[
-  "mode"
-]
  2. Changed2 schema fields changed
    • changedInput schema / properties / mode / description
      Previous value: -"Which kind of answer: to_join, university. Each mode, and the parameters it needs, is explained in the description."New value: +"Which kind of answer: to_join, university, family. Each mode, and the parameters it needs, is explained in the description."
    • changedInput schema / properties / mode / enum
      Previous value: -[
-  "to_join",
-  "university"
-]New value: +[
+  "to_join",
+  "university",
+  "family"
+]
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the readOnly/openWorld/idempotent annotations: discloses that to_join reads live data and never lists private family rooms, that university fetches living-bread.org at call time and returns page links rather than a structured student-group list, the empty-result behavior (count 0, or matched null), ignored_params handling, and a shared 300 requests/minute per-IP limit with no sign-in.

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?

Front-loaded and sectioned with PURPOSE / WHEN TO USE / WHEN NOT / MODES / OUTPUT / BEHAVIOR, which makes a dense definition scannable. Minor flaws: the MODES section lists only to_join and university while family is introduced later as a separate 'NETWORK MODE' block despite being an enum value, and the OUTPUT section duplicates detail the output schema already carries.

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?

For a multi-mode, zero-required-parameter tool with an open-world fetch, the description covers mode selection, per-mode parameters, empty-match behavior, access and rate limits, and privacy constraints. With an output schema present, return values are covered twice over — nothing an agent needs to invoke it correctly is missing.

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 baseline is 3; the description adds real semantic value by explaining that query words are matched against name, description, kind, city and country and that any word matches so more words widen the result set — a non-obvious OR-semantics not implied by the schema. It also restates limit bounds and default, and explains cursor as next_cursor from a prior answer of the same call.

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?

States a specific verb and resource (find ongoing Christian community / university network pages) and immediately scopes it by naming the sibling tools it is not: find_churches, find_gatherings, find_people_to_pray_with. An agent can route between siblings without opening any schema.

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 trigger phrases ("a Bible study community in Atlanta", "Christian community at universities in Kenya") plus an explicit WHEN NOT section naming three alternative tools and their domains. Mode selection guidance is also spelled out per mode with required parameters in brackets.

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 toolsInspect
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