ChurchSuite Bookings MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct entity or action: specific 'find' tools for next booking by name vs resource, separate 'get' and 'list' for each data type (bookings, contacts, ministries, etc.). No overlapping purposes.
Naming Consistency5/5
All tool names use consistent snake_case with a verb_noun pattern ('list_', 'get_', 'find_'). No mixing of conventions, making the set predictable.
Tool Count4/5
With 16 tools, the set covers bookings, contacts, resources, and rotas comprehensively. Slightly above the ideal range but still well-scoped; each tool has a clear role.
Completeness2/5
The tool set is entirely read-only, lacking any create, update, or delete operations. For a 'Bookings' server, missing mutation tools is a significant gap that will hinder common tasks.
Average 3.5/5 across 16 of 16 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must disclose behavioral traits. It mentions filtering but inaccurately refers to 'status' (singular) while schema uses 'statuses' (plural). Does not mention pagination parameters (page, per_page) or ids, nor any side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded with verb. However, it omits important details like pagination, making it under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no schema descriptions, the description is incomplete. It only covers status and name filtering, leaving pagination and ids unexplained. Output schema exists but return format is not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description should explain parameters. Only hints at filtering by 'status or name' but does not define 'q' as name filter, ignores 'ids' and pagination. Misleading term 'status' instead of 'statuses'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists ministries with a specific verb 'List' and resource 'ministries', including examples. However, it does not distinguish from sibling tools like 'get_ministry' or 'list_ministry_teams'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites or exclusions mentioned. Only states optional filtering without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not mention read-only nature, side effects, pagination behavior, or return format. Minimal disclosure beyond the basic listing action.
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?
Single sentence, front-loaded with the action and examples. Efficient but lacks detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with zero description, the tool is incomplete. Output schema exists but is not leveraged to describe return values. Not enough for a list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 5 parameters (category, q, status, page, per_page). No value added over the schema.
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?
The description clearly states the tool lists bookable resources like rooms and equipment, and distinguishes from siblings such as 'get_resource' or 'list_booked_resources'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'list_booked_resources' or 'get_resource'. No context on filtering or pagination.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, and the description does not disclose behavioral traits such as read-only nature, pagination behavior, or filtering capabilities. The parameter details are absent.
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?
The description is a single, concise sentence. While it could include more detail, it is not verbose and carries no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is insufficient for an agent to use the tool correctly. It omits details about parameters and behavioral traits, leaving gaps in understanding how to invoke it properly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lacks any explanation of the four parameters (member_ids, ministry_ids, page, per_page). With 0% schema description coverage, the agent has no understanding of how to use filtering or pagination.
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?
The description clearly states the tool's purpose: listing roles like Worship Leader and Sound Engineer defined within Rotas ministries. It distinguishes itself from sibling tools (e.g., list_ministry_teams) by focusing specifically on roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or exclusions mentioned. The agent is left to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does not disclose behavioral traits. It hints at optional filtering but does not mention pagination (page, per_page parameters) or whether the output is sorted, limited, or includes any context about the response structure. The tool's behavior around empty or invalid booking IDs is also not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that communicates the core action and key filter option without redundancy. It is front-loaded and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and an output schema, the description is incomplete. It does not mention pagination, return structure, or the behavior when no booking ID is provided. More context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameter semantics. It only mentions 'filtered by booking ID' for booking_ids, but completely ignores page and per_page parameters, leaving their purpose and defaults ambiguous.
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?
The description clearly states the tool lists resources booked against ChurchSuite bookings, with optional filtering by booking ID. This specific verb+resource combination distinguishes it from sibling tools like list_resources (general resources) and list_bookings (listings of bookings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_bookings or list_resources. The description lacks any indication of when filtering is recommended or when the unfiltered output might be too broad.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose safety (read-only), error handling, auth requirements, or side effects. The description only lists what the tool returns, not behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 14 words, front-loaded with verb and resource. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description adequately mentions the key included fields. It does not need to detail return values since output schema exists, but it covers the main aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for its single parameter 'id'. The description merely says 'by its ID', which adds minimal context beyond the schema. It does not explain format, range, or any constraints.
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?
The description clearly states the tool retrieves a single ministry by ID, specifying included details (serving days, times, rotation type). This effectively distinguishes it from sibling tools like list_ministries (list all) or get_ministry_team (team-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list_ministries or get_ministry_team. The agent is not told about prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions filtering options but fails to describe pagination behavior (page, per_page), default ordering, or any side effects. For a listing endpoint, these are significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an additional clarifying sentence for the fuzzy search. It is front-loaded with the main purpose and filters, then usage guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and an output schema, the description covers the core functionality and usage context. However, it lacks explanation of pagination behavior, which is important for listing tools. The output schema likely describes return values, so that aspect is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description explains three parameters (status, tag_ids, q) and details what the fuzzy search matches. However, it completely omits page and per_page, leaving pagination parameters undocumented. With low schema coverage, the description should explain all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists addressbook contacts with optional filters. It also specifies a concrete use case (finding a numeric ID for find_serving_pattern). However, it does not explicitly differentiate from sibling list tools like list_ministry_members or list_ministries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this to find a contact's numeric ID... for use with find_serving_pattern.' This gives clear context for when to use it, but it does not mention when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only says 'Retrieve', implying a read operation, but does not disclose any behavioral traits like permissions, side effects, or rate limits. The output schema exists, which helps, but the description could add more context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise. However, it is underspecified and could be more informative without becoming verbose. It is not tautological, but it barely meets the minimum.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and only one parameter, the description is minimally complete for a straightforward retrieval. However, it lacks context about what a 'ministry team' is or how the ID relates to other resources, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for parameters. The description says 'by its ID', which adds minimal meaning beyond the schema's required integer 'id'. It does not clarify the ID format, range, or source. With low schema coverage, the description should compensate but fails to do so.
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?
Clearly states it retrieves a single Rotas ministry team by ID. The verb 'Retrieve' and the resource 'ministry team' are specific, and it distinguishes from sibling tools like list_ministry_teams (which lists all) and get_ministry (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The description implies it is for fetching a specific team by ID, but does not mention alternatives or prerequisites. It is adequate for a simple get-by-ID operation but lacks depth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only says 'list', implying read-only, but omits pagination behavior, performance, or any side effects. Essential behavioral details missing.
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?
Single clear sentence, no waste. Could be slightly expanded to cover pagination, but remains appropriately concise for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists but description lacks pagination info. For a list tool with 4 params and no annotations, additional behavior context (e.g., pagination limits) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, so description must compensate. It explains ministry_ids and team_ids as optional filters, but does not describe page and per_page parameters. Partial coverage.
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?
Description clearly states the tool lists teams within Rotas ministries with optional filtering. It distinguishes from siblings like 'get_ministry_team' (singular) and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions optional filters but no explicit guidance on when to use this tool vs alternatives (e.g., for a single team use get_ministry_team). Usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It provides a date format requirement but omits important behavioral details like pagination (page/per_page), default behavior, sorting, or limits.
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?
Two concise and front-loaded sentences clearly convey the core purpose. However, a third sentence about pagination would improve completeness without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema being present, the description lacks coverage of pagination parameters and default filtering behavior, which are crucial for a list tool with 8 optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for date parameters (YYYY-MM-DD format) and mentions filters like status, customer, type, q, but does not describe page, per_page, or other parameters. Schema coverage is 0%, so partial compensation.
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?
The description clearly states the verb 'List' and the resource 'ChurchSuite bookings', and it mentions optional filters, distinguishing it from siblings like get_booking or find_next_booking_by_name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool (to list bookings with optional filters) but does not explicitly exclude use cases or mention alternatives among siblings for specific lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Retrieve... by its ID' without disclosing behavior on missing IDs, authentication requirements, or any side effects. The existence of an output schema partially mitigates this for return values, but other behaviors remain opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 8 words with no filler. Every word is necessary and front-loads the purpose. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects, output schema present), the description is mostly complete. It covers the core action and selection criteria. Usage context and behavior details are lacking, but the tool is straightforward enough that this may be acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single required 'id' parameter, but its description is missing (0% schema coverage). The tool description adds only 'by its ID', which does not enhance meaning beyond the schema. However, the parameter is a straightforward integer identifier, so minimal additional semantics are needed.
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?
The description clearly states the verb 'Retrieve', the resource 'ChurchSuite booking', and the criteria 'by its ID'. This distinguishes it from sibling tools like list_bookings (which returns multiple) and find_next_booking_* (which search by criteria).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific booking ID, but does not explicitly state when to use this tool versus alternatives (e.g., list_bookings or find_next_booking_by_name). No exclusion criteria or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully convey behavior. Only says 'retrieve', omitting details like error handling (e.g., what if ID not found), authentication requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no excess text. Clearly communicates the essential action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with an output schema, the description is nearly complete. Lacks mention of error responses but is sufficient for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the parameter 'id' is self-explanatory (type integer). Description adds minimal value by mentioning 'by its ID'. Adequate for a simple parameter.
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?
Clearly states the tool retrieves a single contact by ID, using specific verb 'retrieve' and resource 'addressbook contact'. This distinguishes it from sibling tools like 'list_contacts' which retrieves multiple contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: use when needing a single contact by ID. However, no explicit guidance on when not to use or alternatives (e.g., consider list_contacts for multiple contacts).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It reveals fuzzy matching behavior, the q filter's broader matching scope, and the default for from_date. However, it omits details on what happens when no match is found, whether only one result is returned, or the role of the status parameter. This leaves notable gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each essential: purpose, search scope, and a key parameter detail. No filler, no repetition. Front-loaded with core function. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core purpose and critical behavioral nuance (fuzzy match, q filter scope, date default). However, it omits any mention of the status parameter, error handling, or whether the tool returns a single object. With an output schema present, return format is less critical, but the missing parameter documentation leaves a gap for an otherwise decent description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds semantics for two of three parameters: 'name/title fuzzy-matches' clarifies the name parameter's behavior, and 'from_date (YYYY-MM-DD) is inclusive and defaults to today' explains format and default. The status parameter is completely undocumented, leaving its allowed values and purpose unclear. Given low schema coverage (0%), partial compensation earns a 3.
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?
The description clearly states 'Find the next upcoming booking whose name/title fuzzy-matches the given string.' It specifies the verb (find), the resource (next upcoming booking), and the search method (fuzzy match by name/title). This distinguishes it from siblings like find_next_booking_for_resource, which focuses on resource-based filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the search uses a ChurchSuite q filter that also matches date, reference, and sequence_id, providing context on when the tool might return unexpected results. However, it does not explicitly state when to use this tool over alternatives like list_bookings or find_next_booking_for_resource, nor does it provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. 'Retrieve' clearly indicates a read operation with no side effects. Additional behavioral context (e.g., error handling) is not disclosed but acceptable for a simple retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with 7 words. Extremely concise and front-loaded. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval with one parameter and an output schema, the description adequately conveys the tool's purpose. Could mention what happens if ID is missing, but not essential for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add value. It mentions 'by its ID', which repeats the schema's parameter name without adding format or constraints. Minimal benefit over the schema alone.
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?
Clear verb ('Retrieve') and resource ('bookable resource') with method ('by its ID'). Distinguishes from siblings like list_resources because it retrieves a single resource by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or alternatives. Appropriate usage is implied (when you have a specific ID), but no exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that there is no server-side filter, so it fetches all booked resources and filters client-side, and warns about potential slowness. Describes fuzzy search logic for resource_name and inclusive from_date. Does not discuss error handling or side effects, but output schema covers return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences covering purpose, parameters, and performance. Front-loaded with the core purpose, then parameter usage, then warning. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with no schema descriptions, the description adequately covers their usage and defaults. Output schema exists, so return values are handled. The performance warning adds important context. Minor gap: could clarify what 'next upcoming' means exactly (e.g., chronological order), but overall sufficient.
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 0%, so description must add meaning. It explains that resource_id and resource_name are alternatives (implied at least one needed), describes resource_name fuzzy search and exact match requirement, and provides from_date format (YYYY-MM-DD) and default. Does not specify if resource_id is a ChurchSuite ID or other, but provides enough context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds the next upcoming booking for a specific resource, using verb 'Find' and resource 'booking'. It distinguishes from sibling 'find_next_booking_by_name' by focusing on resource rather than booking name, but does not explicitly differentiate from 'list_booked_resources' or 'list_bookings' which also deal with bookings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidelines: use either resource_id or resource_name, explains fuzzy search for resource_name and that it must match exactly one, and from_date format and default. Includes a performance warning about client-side filtering for large histories, which implicitly suggests caution. Does not explicitly mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden of behavioral disclosure. It transparently explains the API limitation (no individual slot assignments), what data is returned (ministries and recurrence pattern), and what is not (exact dates). This goes well beyond just stating the purpose.
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?
The description is well-structured with an important note section. It front-loads the primary purpose. While slightly verbose, every sentence adds value, and the structure aids readability. Could be trimmed slightly without loss.
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?
The tool has an output schema (true) and is moderately complex. The description sufficiently explains what the tool returns (ministries and recurrence pattern) and its limitations. Given the context, it provides complete coverage of what an agent needs to know to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite having 0% schema description coverage, the description adds no meaning to the two parameters (person_id, person_type). It does not explain the purpose of person_type (enum values) or any relationships. Given low schema coverage, this is a significant gap.
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?
The description clearly states the tool finds which Rotas ministries/teams/roles a person belongs to and their typical serving pattern. It uses specific verbs ('find') and resources ('ministries/teams/roles'), and distinguishes itself by explaining what it cannot do (exact dates), setting it apart from siblings like list_ministry_members.
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?
The description explicitly tells when to use this tool (to get ministry membership and recurrence pattern) and when not (to get exact next serving date). It provides an alternative: 'the user should check My ChurchSuite directly' for confirmed next serving dates. This is excellent guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that each member links to a person via person.id and person.type, and mentions the absence of a person filter. No annotations are provided, so this is valuable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, no superfluous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for the tool's complexity: covers filtering, linking, and a key limitation. Could mention pagination behavior, but output schema exists for return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explains ministry_ids, role_ids, and team_ids as optional filters, but does not detail pagination parameters or value constraints.
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?
Clearly states the verb 'list', resource 'members', and scoping by ministry, role, or team. Distinguishes from sibling tools like list_contacts and list_ministries.
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?
Explicitly states when to use the tool and provides a workaround for the lack of a person filter: 'list members for the relevant ministries/teams and filter the results by person.id client-side.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![churchsuite-mcp MCP server](https://glama.ai/mcp/servers/stevehaskew/churchsuite-mcp/badges/card.svg)](https://glama.ai/mcp/servers/stevehaskew/churchsuite-mcp)

Score Badge

Copy to your README.md:

[![churchsuite-mcp MCP server](https://glama.ai/mcp/servers/stevehaskew/churchsuite-mcp/badges/score.svg)](https://glama.ai/mcp/servers/stevehaskew/churchsuite-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/stevehaskew/churchsuite-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server