Skip to main content
Glama
m2ai-mcp-servers

mcp-ratchet-clinical-charting

by m2ai-mcp-servers
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Server Quality Checklist

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

  • Latest release: v0.1.0

  • Disambiguation5/5

    Each tool has a distinct, non-overlapping purpose: searching for patients, retrieving visit history, and creating new visit notes. No ambiguity exists between them.

    Naming Consistency5/5

    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.

    Tool Count4/5

    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.

    Completeness3/5

    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.

  • Average 3.7/5 across 3 of 3 tools scored.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 0 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

  • Behavior2/5

    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.

    Conciseness4/5

    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.

    Completeness3/5

    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.

    Parameters3/5

    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.

    Purpose5/5

    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.

    Usage Guidelines4/5

    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.

  • 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 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.

    Conciseness5/5

    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.

    Completeness2/5

    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.

    Parameters3/5

    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.

    Purpose5/5

    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.

    Usage Guidelines4/5

    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.

  • Behavior3/5

    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.

    Conciseness5/5

    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.

    Completeness4/5

    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.

    Parameters3/5

    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.

    Purpose5/5

    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.

    Usage Guidelines4/5

    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.

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

chartinghero MCP server

Copy to your README.md:

Score Badge

chartinghero MCP server

Copy to your README.md:

Latest Blog Posts

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/m2ai-mcp-servers/chartinghero'

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