get_churchGet the full profile for one church by its slug (the last path segment of its gospelchannel.com/church/ URL): worship styles, denomination, language, summary, top worship songs, contact, and recorded service times if available.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The church slug, e.g. hillsong-church-london. |
| Name | Required | Description | Default |
|---|---|---|---|
| church | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavioral context by enumerating the fields returned (worship styles, denomination, language, etc.) and notes availability depends on 'if available.' No contradictions with annotations.
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, well-structured sentence that front-loads the core purpose (get profile by slug) and then lists relevant output fields. No filler or redundant content; every clause adds value.
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 one clearly documented parameter, annotations for read/destructive behavior, an output schema, and sibling context, the description fully supports correct invocation. It covers the key inputs, expected output, and differentiation from related tools.
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 schema covers the slug parameter (100% coverage) with an example. The description adds extra semantic value by explaining the slug is the last path segment of a specific URL pattern, which is not in the schema. This helps the agent construct a valid 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?
The description states a specific action ('Get the full profile for one church') with a precise resource identifier (slug) and explicitly defines the slug via URL pattern. It clearly distinguishes from siblings that search/find churches by listing the profile contents, so an agent can select it without ambiguity.
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 makes clear this tool is for retrieving a single known church profile via slug. It does not explicitly mention when not to use it or direct to siblings for searching, but the sibling names and context imply that. Lacks explicit exclusions, yet the usage context is easily inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clear, distinct purpose: searching by city, searching by proximity, and retrieving a full church profile. The first two could be confused at a glance, but their descriptions explicitly differentiate the input and ranking method.
All tool names follow a consistent verb_noun pattern: find_churches_in_city, find_churches_near, get_church. The use of 'find' for searches and 'get' for retrieval is logical and predictable.
Three tools is the right size for this server's scope: two search methods and one detail lookup. No redundant tools, and each serves a distinct user need.
The domain is a church finder, and the tool surface covers the essential workflow: discover churches via city or proximity, then view detailed profiles. No obvious gaps for read-only directory functionality.