rock-rms-mcp

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation5/5
Each 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.9/5 across 8 of 8 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
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. 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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
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 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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
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 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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
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 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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

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:

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

Score Badge

Copy to your README.md:

[![rock-mcp MCP server](https://glama.ai/mcp/servers/YesuCS/rock-mcp/badges/score.svg)](https://glama.ai/mcp/servers/YesuCS/rock-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/YesuCS/rock-mcp'

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