Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@rock-rms-mcp Find people named Smith"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A thin, read-only MCP server for Rock RMS. Lets Claude Desktop / Cowork query People, Groups, Group Members, and Attendance from your Rock instance over its REST API. GET-only by design; there is no code path that writes to Rock.
This is a stopgap. Native MCP support lands in Rock v21; when you upgrade, retire this project and switch to the built-in server.
The REST key's permissions are the real security boundary here, so set it up with least privilege:
Create a service person record in Rock, e.g. "Claude MCP Agent" (record type: Business or a regular Person record; either works for REST keys). Do NOT attach the key to your own admin account.
Create a security role, e.g. RSR - Claude MCP Read Only, and add the
service person to it.
Create the REST key: Admin Tools > Security > REST Keys > add a key attached to the service person. Copy the key; you'll put it in the config below.
Grant controller permissions: Admin Tools > Security > REST Controllers. Grant the role View (only View) on:
People
Groups
GroupMembers
Attendances
Campuses (optional, cheap and useful)
Leave everything else, especially all Financial* controllers, unpermitted.
Verify default-deny: as long as the service person isn't in any broader security roles, controllers you didn't explicitly grant will return 401/403.
Related MCP server: humaans-mcp
Requires Node.js 18+.
cd rock-mcp
npm install
npm run buildThis compiles src/index.ts to dist/index.js.
Edit claude_desktop_config.json:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Add (adjust the path and values):
{
"mcpServers": {
"rock-rms": {
"command": "node",
"args": ["C:\\Users\\[ User ]\\rock-mcp\\dist\\index.js"],
"env": {
"ROCK_BASE_URL": "https://rock.[ your church ].org",
"ROCK_API_KEY": "PASTE-REST-KEY-HERE"
}
}
}
}Fully quit and reopen the Claude app (tab close is not enough).
Key handling: the REST key sits in this config file in plain text. That's normal for local MCP servers, but treat the file accordingly; it's another reason the key must be least-privilege, not admin-level.
In a Cowork session, try:
"Search Rock for people named Smith"
"List active groups whose name contains 'ESL'"
"Who are the active members of group 1234?"
"Show attendance for group 1234 between 2026-06-01 and 2026-07-01"
And confirm the security boundary holds:
"Use rock_get to fetch /api/FinancialTransactions?$top=1" should come back 401/403. If it doesn't, revisit step 1.
Tool | Purpose |
| Name search via /api/People/Search |
| Single person by PersonId |
| Groups, filterable by GroupTypeId / name fragment |
| Active members of a group, with Person + role expanded |
| Attendance in a date range, optionally per group |
| Constrained generic GET (must start with /api/, GET only) |
Rock's REST API uses OData v3 query syntax ($filter, $expand, $top,
$orderby, substringof(...)).
Remember many Rock tables join on PersonAliasId, not PersonId; expand
through PersonAlias when a raw endpoint hands you alias ids.
Get attendance records filtered by PersonAliasId and/or OccurrenceId (at least one is required; unfiltered attendance pulls are too large to be useful). Date range is optional; omit it for the person's most recent attendance. For group attendance, call list_attendance_occurrences first to get OccurrenceIds. Note: person attendance joins on PersonAliasId, not PersonId; get_person returns PrimaryAliasId. Dates are YYYY-MM-DD. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| endDate | No | Optional exclusive end date | |
| startDate | No | Optional start date, inclusive | |
| occurrenceId | No | ||
| personAliasId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully handles transparency: declares read-only, warns about unfiltered pulls being too large, specifies date format YYYY-MM-DD, and explains the join on PersonAliasId.
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?
Concise and well-structured: opens with purpose and filters, then provides usage guidance and important notes. Every sentence adds unique value with no redundancy.
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?
Despite 5 parameters and no output schema, the description covers essential context: required filters, date handling, linkage to sibling tools, size warning, and read-only nature. Leaves no significant gaps for the agent to infer.
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?
Adds meaning beyond schema: declares required constraint (at least one of personAliasId/occurrenceId) not present in schema, explains optional date behavior, and clarifies parameter usage. However, does not document the 'top' parameter explicitly.
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?
Clearly states 'Get attendance records filtered by PersonAliasId and/or OccurrenceId', specifies required filters, and distinguishes from sibling tools by advising to use list_attendance_occurrences for group attendance and referencing get_person for PrimaryAliasId.
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?
Provides explicit guidance: at least one filter required, date range optional (omit for most recent), and directs to list_attendance_occurrences for group attendance. Also explains join nuances with PersonAliasId vs PersonId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active members of a group by GroupId. Returns slim rows: person id, alias id, name, and role. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| groupId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares the tool is 'Read-only,' which is helpful for safety. It also describes the return fields. However, there are no annotations to supplement behavioral context. Missing details include error handling, rate limits, the behavior of the 'top' parameter (pagination), and what constitutes 'active' members.
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?
The description is extremely concise—three short, informative fragments. Every sentence adds value: purpose, output fields, and safety trait. No unnecessary words or redundancy.
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 2 parameters, no output schema, and no annotations, the description covers the core purpose and output shape but omits critical details about the 'top' parameter's function and limits. An agent might not know how to control result size, making the description moderately incomplete.
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?
Schema description coverage is 0%, so the description must compensate. It implicitly references 'groupId' in the purpose but does not explain the 'top' parameter (e.g., its purpose as a result limit). Adding brief explanations for both parameters would significantly improve usability.
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 clearly states the action ('List'), resource ('active members of a group'), and the key parameter ('by GroupId'). It distinguishes from siblings like list_groups (lists groups) and get_person_groups (groups a person belongs to), making the tool's specific purpose unambiguous.
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 implies when to use the tool (to list group members), but it does not explicitly state when not to use it or mention alternative tools for related tasks (e.g., listing groups, searching people). No exclusions or context for choosing this over siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a person by PersonId. Returns a slim summary including their primary alias id (PrimaryAliasId), which is what most other Rock tables join on. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| personId | Yes | The Rock PersonId |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description declares 'Read-only', which is a key behavioral trait. However, it does not disclose what happens if the personId is invalid, or any other side effects. It adds some context about the return value but lacks depth.
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?
Two sentences, 30 words, front-loaded with purpose. Every sentence provides value with no redundancy.
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?
For a simple tool with one parameter and no output schema, the description is nearly complete. It states purpose, output content, and read-only nature. Lacks mention of error handling or typical failure modes, but overall adequate.
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?
Schema coverage is 100%, so the schema already documents the single parameter adequately. The description doesn't add significant meaning beyond repeating 'PersonId' and indicating the output includes the primary alias id, which is not parameter-related.
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 clearly states 'Get a person by PersonId', with a specific verb and resource. It also distinguishes the output from other tools by mentioning the primary alias id, which is unique among siblings.
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?
No guidelines on when to use this tool versus alternatives like 'search_people' or 'rock_get'. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the active groups a person belongs to, by PersonId (not alias id). Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| personId | Yes | The Rock PersonId |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It only mentions 'Read-only' but fails to disclose error handling (e.g., invalid personId), pagination, or whether results are always the full set of active groups. This is insufficient for safe selection.
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?
The description is a single concise sentence that front-loads the core action and constraint. It wastes no words, though it could be restructured to separate constraints and behaviors.
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 2 parameters, no output schema, and no annotations, the description leaves critical gaps: no information on return format, error cases, or pagination behavior. The tool is underspecified for reliable autonomous invocation.
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 description adds meaning to personId by re-emphasizing it is not an alias ID, which complements the schema's 'The Rock PersonId'. However, it does not reference the top parameter at all, missing a chance to explain its purpose (limit results). With 50% schema coverage, this partial compensation is mediocre.
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 clearly states the verb 'List' and resource 'active groups a person belongs to', and specifies key input constraint 'by PersonId (not alias id)'. This distinguishes it from sibling tools like search_people or list_groups.
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 implies usage for retrieving groups by PersonId and notes it is read-only, but does not explicitly state when to use this tool versus alternatives like get_group_members or list_groups. No exclusion conditions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List attendance occurrences for a group in a date range. Use this first when you want group attendance: it returns OccurrenceIds you can pass to get_attendance. Dates are YYYY-MM-DD. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| endDate | Yes | Exclusive end date | |
| groupId | Yes | ||
| startDate | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It declares read-only nature, date format, and return value (OccurrenceIds). However, it does not mention pagination via the 'top' parameter or handling of empty results.
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?
Three sentences that are front-loaded with purpose, then usage guidance, then behavioral info. No fluff or redundancy.
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?
The description covers purpose, workflow, and read-only nature, but lacks details about response format (array or object), pagination behavior, and potential error cases for invalid IDs. With no output schema, more completeness would be helpful.
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?
Schema description coverage is only 25% (only endDate has a description). The description adds date format context for startDate and endDate, but provides no additional meaning for 'groupId' or 'top', which are left to schema defaults and minimums.
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 clearly states 'List attendance occurrences for a group in a date range', which is a specific verb+resource combination. It also distinguishes from sibling by describing the workflow of using this tool first and then passing OccurrenceIds to get_attendance.
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?
Explicitly tells when to use this tool ('Use this first when you want group attendance') and what to do with the results ('returns OccurrenceIds you can pass to get_attendance'). Also specifies date format as YYYY-MM-DD.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active groups, optionally filtered by GroupTypeId and/or a name fragment (case-sensitive). Returns slim group summaries. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| groupTypeId | No | ||
| nameContains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides some behavioral context: read-only, active groups only, case-sensitive name filter. However, it omits details like pagination behavior, default top value, and any rate limits or authentication needs.
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?
The description is extremely concise with two sentences, no repetition, and front-loaded key actions. Every word 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?
For a list tool with 3 parameters and no output schema, the description conveys the core function but lacks details on the 'top' parameter and return format. It mentions 'slim group summaries' but not fields or structure.
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?
Schema coverage is 0%, so the description must explain parameters. It mentions groupTypeId and nameContains (with case-sensitivity) but completely omits the 'top' parameter (integer with default 25, max 100). This is a significant gap.
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 clearly states it lists active groups with optional filters, using a specific verb and resource. It mentions 'slim group summaries' and 'read-only' but does not explicitly differentiate from sibling tools like get_person_groups or search_people.
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?
No guidance on when to use this tool versus alternatives. The description does not mention any exclusions or context for selecting this over other group-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Arbitrary READ-ONLY GET against the Rock REST API for anything the dedicated tools don't cover. Path must start with /api/ and supports OData v3 options ($filter, $select, $expand, $top, $orderby). ALWAYS use $select and $top; raw Rock entities are large. Nav-property filters (e.g. Occurrence/GroupId) are unreliable in this build; filter on FK columns directly. The REST key's Rock permissions are the security boundary; denied controllers return 401/403.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Full API path with query string, e.g. /api/Campuses?$filter=IsActive eq true&$select=Id,Name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully covers behavior: read-only, security boundary via REST key permissions, 401/403 on denial, and unreliability of nav-property filters. Comprehensive and honest.
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?
Description is front-loaded with purpose, uses imperative tone, and is mostly concise. Slight redundancy in discussing permissions and error codes, but overall efficient.
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 no output schema and generic nature, description covers usage, constraints, and behavior well. Missing explicit return format, but acceptable for a generic GET tool.
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?
Only one parameter path is fully described in schema (100% coverage). Description adds value by explaining OData v3 options and providing example usage, but does not add new meaning beyond schema.
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?
Description explicitly states it's a READ-ONLY GET for any Rock REST API endpoint not covered by dedicated tools, clearly distinguishing it from siblings like get_attendance and get_group_members.
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?
Provides explicit when-to-use (for anything dedicated tools don't cover) and best practices (use $select/$top, filter on FK columns, avoid nav-property filters). No when-not-to but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for people in Rock RMS by name. Returns slim person summaries (Id, name, age, connection status, campus). Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| name | Yes | Full or partial name, e.g. 'John Sm' or 'Smith, John' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry behavioral info. It declares 'Read-only' and lists return fields, which is helpful. However, it omits details like result limiting (max 50 via top parameter) and pagination behavior.
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?
Two concise sentences: first states purpose, second states return format and read-only nature. No wasted words, front-loaded with key information.
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?
With no output schema, the description provides useful return fields. It covers the basic purpose and constraints. However, missing details on error handling, result ordering, or when to prefer alternative tools. Adequate for a simple search tool.
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?
Schema description coverage is 50% (top parameter lacks description). The tool description adds no clarification for top, only repeats 'by name' for the name parameter. It fails to explain the top parameter's purpose or constraints.
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?
Description clearly states the tool searches for people in Rock RMS by name, using a specific verb and resource. It implicitly distinguishes from siblings like get_person (which returns full details) and get_group_members (which filters by group).
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 indicates usage when searching by name for slim summaries, but lacks explicit alternatives or when-not-to-use guidance. Sibling tools like get_person or get_group_members are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.0get_attendanceget_group_membersget_personget_person_groupslist_attendance_occurrenceslist_groupsrock_getsearch_peopleEach tool has a clear, distinct purpose. get_person, get_person_groups, get_group_members, list_groups, list_attendance_occurrences, get_attendance, search_people, and rock_get all target different aspects of Rock RMS with minimal overlap. The descriptions clarify any potential ambiguity, such as the use of PersonAliasId vs PersonId.
Most tools follow a consistent verb_noun pattern in snake_case (e.g., get_person, list_groups, search_people). The exception is rock_get, which breaks the pattern by not starting with a verb like 'get', but it is still clear and fits the generic purpose. Overall, naming is predictable and readable.
With 8 tools, the server is well-scoped for read-only access to Rock RMS. Each tool covers a core domain entity (people, groups, attendance), and the generic rock_get tool provides an escape hatch for other endpoints. The count feels appropriate for the intended functionality.
The tool set covers key read operations: people search, person details, person groups, group listing, group members, attendance occurrences, and attendance records. The generic rock_get tool fills gaps for other entities like campuses or locations. A minor gap is the lack of a direct get_group_by_id tool, but rock_get can handle it.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The official Planning Center MCP server for interacting with your ministry's data.
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
MCP server providing attendance data queries via the CloudTime API.
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/YesuCS/rock-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
