Skip to main content
Glama
sanjibani

Realm MinistryPlatform MCP

by sanjibani
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Realm MinistryPlatform MCP

MCP server for Realm MinistryPlatform MCP — talk to your data from Claude, Cursor, or any MCP client.

What you can do with it

You:   "Find every record updated this week and group them by status."
Claude: *calls the appropriate MCP tools, summarises the result*

You:   "Create a new record with these fields..."
Claude: *calls the create tool, confirms the result*

Related MCP server: Procore MCP Server

Install

pip install -e .

Configure

export REALM_MP_USERNAME="..."
export REALM_MP_PASSWORD="..."

Who uses this?

  1. API Partners building tools on top of Realm MinistryPlatform MCP.

  2. Power users / agencies doing their own custom integrations.

If you don't have credentials yet, contact Realm MinistryPlatform MCP support to get set up.

Use with Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "realm_ministryplatform_mcp": {
      "command": "realm_ministryplatform_mcp",
      "env": {
        "REALM_MP_USERNAME": "your-username",
        "REALM_MP_PASSWORD": "your-password"
      }
    }
  }
}

Use with Claude Code

claude mcp add realm_ministryplatform_mcp -- realm_ministryplatform_mcp \
  --env REALM_MP_USERNAME=your-user --env REALM_MP_PASSWORD=your-pass

Tools

Tool

Type

What it does

health_check

Diagnostic

Verifies credentials by hitting a known endpoint

(TODO: list your actual tools here once defined)

Development

pip install -e ".[dev]"
pytest
realm_ministryplatform_mcp

License

MIT.

See also

Available Tools

1 tool
health_checkA

Verify credentials work. If this fails, all other tools will too.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior3/5

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

With no annotations, the description carries full burden. It states the tool verifies credentials, implying a read-only, non-destructive action. However, it does not describe what happens on success/failure (e.g., return format) or any additional behaviors like latency. Minimal but adequate for a health check.

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 with no wasted words. The key purpose is front-loaded, and the warning provides essential context efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple health check with zero parameters and an existing output schema, the description is complete. It explains the tool's purpose and its critical relationship to other tools. No additional details are necessary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, so the schema coverage is 100% and there is nothing to add. The description does not need to provide parameter information, making it fully sufficient.

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 'Verify credentials work,' which is a specific verb-verb and resource. It distinguishes itself from sibling tools (e.g., get_order, list_documents) by being a health check rather than a data retrieval or action tool. The warning that failure implies all other tools fail further clarifies its role.

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 implicitly recommends using this tool first, as 'If this fails, all other tools will too' strongly implies a prerequisite check. It does not explicitly mention alternatives, but given the sibling tools are all operational, the context is clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.1.0
    • First observedhealth_check
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool exists, so there is no ambiguity between tools.

Naming Consistency5/5

The single tool name 'health_check' follows snake_case consistently, and there are no other tools to cause inconsistency.

Tool Count1/5

A single health check tool is extremely thin for a server named 'Realm MinistryPlatform MCP', which implies a much richer set of operations.

Completeness1/5

The server only provides credential verification, missing all expected CRUD and lifecycle operations for a ministry platform, making it severely incomplete.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers