Skip to main content
Glama

Find real churches near a place, or one church by id

find_churches
Read-onlyIdempotent

PURPOSE: Find real churches near a place, nearest first, merged live from churches on The Living Bread and an open worldwide directory of about 120,000 churches; or read one directory church's open data record by its id. WHEN TO USE: "a Baptist church in Dallas", "a parish near Manchester", or after another answer returned an lb:church id. WHEN NOT: services or events at a time: find_gatherings. Groups to join or student communities: find_communities. What a tradition is: learn_the_faith (mode heritage). MODES (required parameters in brackets): near [lat and lng, or city] churches within 250 km (denomination filters by one lowercase word such as "baptist" or "catholic"; limit 1 to 20, default 8). by_id [id, or country and slug] one church: pass the whole lb:church:/ as id, or its two parts. OUTPUT: mode, answered_by, and: near gives searched, count, churches [{id, name, where, distance_km, denomination, on_living_bread, url}], find_a_church and gatherings links, plus honest and nearest_we_hold when count is 0; by_id gives id, name, url, denomination, country, website, verified and provenance. BEHAVIOR: read only; reads the live directory and geocodes the city. City level by design: names, city and distance, never street addresses or contacts. No church within 250 km returns count 0 with an honest sentence and the nearest one held, if any. An unknown id returns a not_found error. The search words (never a user id) are logged anonymously. Parameters a mode does not use are ignored and named in ignored_params. Access: no sign-in; shared limit of 300 requests a minute per IP.

Input Schema

NameRequiredDescriptionDefault
idNoFor by_id: the full id, e.g. "lb:church:colombia/iglesia-la-capuchina".
latNoLatitude in decimal degrees, only if the person shared their location; pair with lng. Coordinates win over city.
lngNoLongitude in decimal degrees, paired with lat.
cityNoFor near: a city, region or country, used when there are no coordinates: "Dallas", "Lagos". Geocoded to its centre.
modeNoWhich kind of answer: near, by_id. Each mode, and the parameters it needs, is explained in the description. Leave it out and the answer says what each mode is for.
slugNoFor by_id without id: the church slug, e.g. "iglesia-la-capuchina".
limitNoFor near: maximum churches, 1 to 20 (default 8).
countryNoFor by_id without id: the country slug, e.g. "colombia".
denominationNoFor near: one lowercase tradition word: "baptist", "catholic", "methodist", "pentecostal", "orthodox", "anglican".

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: near, by_id. Each mode, and the parameters it needs, is explained in the description."New value: +"Which kind of answer: near, by_id. 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. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile, but the description adds substantial non-redundant behavior: live directory reads with geocoding, a 250 km radius, city-level privacy by design (no street addresses or contacts), count 0 with 'nearest_we_hold' instead of an error, not_found for unknown ids, anonymous logging of search words, unused parameters reported in ignored_params, and a 300 req/min per-IP shared 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?

Long but tightly sectioned with PURPOSE / WHEN TO USE / WHEN NOT / MODES / OUTPUT / BEHAVIOR labels, so the key routing and mode requirements are front-loaded. Some of the OUTPUT field enumeration overlaps what the output schema already provides and could be trimmed.

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 dual-mode, nine-parameter, open-world lookup, nothing an agent needs is missing: both modes' required parameters, radius, defaults, filtering constraints, failure semantics, privacy scope, and rate limits are all stated, and return values are additionally covered by the output schema.

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 already 100%, so the baseline is 3; the description still adds cross-parameter rules the schema does not state — which parameters each mode requires, that coordinates win over city, that denomination must be one lowercase word, and that unused parameters are ignored and named in ignored_params.

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 real churches near a place, nearest first') plus the second mode ('read one directory church's open data record by its id'), and names the data sources. An agent can distinguish it from find_gatherings and find_communities 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?

Explicit WHEN TO USE with concrete example queries, explicit WHEN NOT routing three sibling tools (find_gatherings for services/events, find_communities for groups, learn_the_faith for tradition definitions), and a clear trigger from an lb:church id.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources