Click on "Deploy 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., "@mcp-ratchet-clinical-charting Search for patient Eleanor Thompson"
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.
MCP server for clinical charting with Claude (codename: Ratchet) - Enables Claude to document patient visits directly into Electronic Medical Records, reducing administrative burden for home health nurses.
Note: Currently runs in Mock Mode for development/testing. Production EMR integration coming soon.
Component | Status |
MCP Server | ✅ Working (Mock Mode) |
Unit Tests | ✅ 20/20 Passing |
Claude Desktop | ✅ Ready for Testing |
PointCare API | ⏳ Pending API Documentation |
Current Mode: Mock Mode - Uses realistic test data for development and testing.
Related MCP server: openemr-mcp
npx mcp-ratchet-clinical-chartinggit clone https://github.com/m2ai-mcp-servers/mcp-ratchet-clinical-charting.git
cd mcp-ratchet-clinical-charting
npm install
npm run build
npm run dev # Development mode
npm test # Run testsRatchet runs in mock mode by default when POINTCARE_API_URL is not configured. Mock mode:
Uses 5 fictional test patients
Stores visit notes in memory
Returns realistic responses
Perfect for development and Claude Desktop testing
Tool | Description | Mock Mode |
| Find patient by name, ID, or phone | ✅ Working |
| Document a patient visit with vitals | ✅ Working |
| Retrieve patient visit history | ✅ Working |
"Search for patient Eleanor Thompson"
→ Returns patient PT-10001 with demographics and status
"Create a visit note for PT-10001 with blood pressure 120/80"
→ Creates and stores visit note with vitals
"Get visit history for PT-10001"
→ Returns list of previous visitsAdd to your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"ratchet": {
"command": "npx",
"args": ["-y", "mcp-ratchet-clinical-charting"]
}
}
}For production mode with EMR integration:
{
"mcpServers": {
"ratchet": {
"command": "npx",
"args": ["-y", "mcp-ratchet-clinical-charting"],
"env": {
"POINTCARE_API_URL": "https://api.pointcare.com",
"POINTCARE_API_KEY": "your-api-key"
}
}
}
}Restart Claude Desktop to load the new MCP server.
In Claude Desktop, you should see:
search_patient tool available
create_visit_note tool available
get_patient_history tool available
Try: "Search for patient Eleanor"
ID | Name | Status | Primary Diagnosis |
PT-10001 | Eleanor Thompson | Active | Type 2 Diabetes, CHF |
PT-10002 | Robert Martinez | Active | COPD, Post-surgical |
PT-10003 | Margaret Wilson | Active | Parkinson's Disease |
PT-10004 | James Thompson | Active | Post-stroke rehab |
PT-10005 | Dorothy Anderson | Discharged | Hip replacement |
Ratchet evolved from the M2AI NurseCall n8n workflow, built to help home health nurses with visit documentation:
Current Flow (M2AI NurseCall):
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ Twilio │───>│ n8n │───>│ VAPI │───>│ Email │
│ SMS │ │ Workflow│ │ Call │ │ Summary │
└─────────┘ └─────────┘ └─────────┘ └─────────┘The Problem: Visit notes go to email but still need manual entry into PointCare EMR.
Ratchet's Solution:
Future Flow (with Ratchet):
┌─────────┐ ┌─────────┐ ┌──────────┐ ┌───────────┐
│ Twilio │───>│ n8n │───>│ Ratchet │───>│ PointCare │
│ SMS │ │ Workflow│ │ MCP │ │ EMR │
└─────────┘ └─────────┘ └──────────┘ └───────────┘Variable | Required | Description |
| No* | PointCare API base URL |
| No* | API key or token |
| No | Force mock mode ( |
| No | Logging level ( |
*Required for production use. Mock mode activates when not set.
ratchet/
├── src/
│ ├── index.ts # MCP server entry point
│ ├── config.ts # Configuration management
│ ├── tools/ # Tool implementations
│ │ ├── search-patient.ts
│ │ ├── create-visit-note.ts
│ │ └── get-patient-history.ts
│ ├── services/ # Business logic
│ │ ├── patient-service.ts
│ │ └── mock-data.ts
│ ├── types/ # TypeScript types
│ └── utils/ # Logger, errors
├── tests/
│ └── patient-service.test.ts
├── dist/ # Compiled output
├── prds/
│ └── RATCHET-PRD.yaml
├── docs/
│ └── API_REQUIREMENTS.md
├── package.json
├── tsconfig.json
└── jest.config.js# Run in watch mode
npm run dev
# Run tests
npm test
# Run tests with coverage
npm test -- --coverage
# Lint
npm run lintAcquire PointCare API documentation - See docs/API_REQUIREMENTS.md
Complete PRD - Fill in tool specifications with real API details
Implement real API calls - Replace mock responses
Integration testing - Test with PointCare sandbox
GRIMLOCK - Autonomous MCP Server Factory
ratchet-demo-emr - Demo EMR React app for testing
MIT
Built with GRIMLOCK - Autonomous MCP Server Factory
Create a visit note for a patient in the PointCare EMR system.
This tool documents a home health visit including vital signs, assessment, and care plan. Use search_patient first to get the patient ID.
Required fields: patientId, visitType, visitDate, timeIn, timeOut Recommended fields: vitalSigns, subjective, objective, assessment, plan
| Name | Required | Description | Default |
|---|---|---|---|
| patientId | Yes | Patient ID from search_patient (e.g., PT-10001) | |
| visitType | Yes | Type of visit | |
| visitDate | Yes | Date of visit (YYYY-MM-DD format) | |
| timeIn | Yes | Time nurse arrived (HH:MM format, 24-hour) | |
| timeOut | Yes | Time nurse departed (HH:MM format, 24-hour) | |
| vitalSigns | No | Vital signs recorded during visit | |
| subjective | No | Patient's reported symptoms, concerns, and statements | |
| objective | No | Nurse's observations and physical assessment findings | |
| assessment | No | Clinical assessment and interpretation of findings | |
| plan | No | Care plan and next steps | |
| interventions | No | List of interventions performed during visit | |
| patientResponse | No | How patient responded to care/interventions | |
| education | No | Patient education topics covered | |
| nextVisitDate | No | Scheduled next visit date (YYYY-MM-DD) | |
| notes | No | Additional notes or comments |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It only states 'Create a visit note' without discussing idempotency, permissions, side effects, error handling, or constraints. This leaves significant gaps for an AI agent.
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 concise with 5 sentences, each earning its place. It front-loads the purpose, then adds context and field guidance. 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?
Given the complexity (15 parameters, nested objects, no output schema), the description covers core purpose and field groups but lacks return value details, error handling, and more nuanced usage context. It is adequate but 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 coverage is 100%, so baseline is 3. The description adds value by grouping fields into required/recommended and linking patientId to search_patient. However, it does not elaborate beyond the schema descriptions for individual parameters.
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 tool creates a visit note in the PointCare EMR system, specifying the verb ('Create'), resource ('visit note'), and context ('home health visit'). It distinguishes from siblings by mentioning the need to use search_patient first, which is a dependency not shared by the other tools.
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 provides explicit guidance by stating 'Use search_patient first to get the patient ID' and lists required and recommended fields. However, it does not mention when not to use the tool or compare with alternatives like get_patient_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve visit history for a patient from the PointCare EMR system.
Returns a list of previous visits with dates, types, and key information. Use this to review patient history before creating a new visit note.
Use search_patient first to get the patient ID.
| Name | Required | Description | Default |
|---|---|---|---|
| patientId | Yes | Patient ID from search_patient (e.g., PT-10001) | |
| limit | No | Maximum number of visits to return (default: 10, max: 50) | |
| startDate | No | Filter visits on or after this date (YYYY-MM-DD) | |
| endDate | No | Filter visits on or before this date (YYYY-MM-DD) | |
| visitType | No | Filter by visit type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it retrieves and returns list of visits, implying read-only, but doesn't explicitly mention side effects, auth needs, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, return summary, usage context. No extraneous words, efficient and front-loaded.
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?
Covers purpose, parameters, prerequisites, and usage context. No output schema, but description mentions return fields. Complete for a retrieval 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 100%, so baseline is 3. Description adds workflow context (using search_patient) but doesn't enhance parameter semantics beyond the 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?
Clearly states it retrieves visit history for a patient from the PointCare EMR system. Distinguishes from siblings by mentioning search_patient as prerequisite and create_visit_note as subsequent action.
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 says to use before creating a new visit note and to use search_patient first for patient ID. Provides context but lacks explicit when-not-to-use info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for a patient in the PointCare EMR system by name, ID, or phone number.
Returns matching patient records with basic information. Use this tool to find patients before creating visit notes or retrieving history.
Examples:
Search by name: "Eleanor Thompson"
Search by ID: "PT-10001"
Search by phone: "555-0101"
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term: patient name, ID (e.g., PT-10001), or phone number | |
| searchType | No | Type of search to perform. Defaults to "all" which searches across all fields. | |
| status | No | Filter by patient status. If not specified, returns all statuses. | |
| limit | No | Maximum number of results to return (default: 10, max: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states 'returns matching patient records with basic information', but does not disclose any behavioral traits such as read-only nature, authentication needs, pagination behavior, or rate limits. This is insufficient for a search tool.
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 extremely concise with three sentences: purpose, use-case, and examples. No fluff. Front-loaded with the most important information. Every sentence earns its place.
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?
Tool returns 'matching patient records with basic information', but no output schema is provided and description does not specify which fields are returned (e.g., name, ID, phone, status). With no output schema, description should clarify return structure. Also, parameters are well-documented in schema, but behavioral context is lacking.
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 baseline is 3. The description adds examples of query values ('Eleanor Thompson', 'PT-10001', '555-0101') which provide practical context, but does not add new semantic meaning beyond what the schema already provides. Minimal additional value.
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 verb 'Search for a patient', the resource 'patient in the PointCare EMR system', and the search criteria 'by name, ID, or phone number'. It distinguishes from sibling tools like create_visit_note and get_patient_history by specifying the return of 'basic information' and use case before creating notes or retrieving history.
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 recommends usage 'before creating visit notes or retrieving history', providing context. While it doesn't explicitly list alternatives or when not to use, the context is clear enough for an AI to decide.
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.
v0.1.0create_visit_noteget_patient_historysearch_patientScored across 3 tools
Each tool has a distinct, non-overlapping purpose: searching for patients, retrieving visit history, and creating new visit notes. No ambiguity exists between them.
All tools follow a consistent verb_noun pattern (search_patient, get_patient_history, create_visit_note) using snake_case, making it predictable and easy to understand.
With only 3 tools, it is on the lower end but still appropriate for a focused clinical charting server. They cover the core workflow of searching, reviewing history, and creating notes without unnecessary bloat.
The tool set covers essential operations (search, history, create) but lacks update and delete functionalities for visit notes, which are notable gaps for a complete CRUD lifecycle in clinical charting.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Hosted MCP server exposing US hospital procedure cost data to AI assistants
MCP server giving Claude AI access to 22+ NYC public-record databases for real estate due diligence
Hosted MCP server for Cliniko — patients, appointments, availability, and invoices for AI agents.
