官方 Model Context Protocol 服务器，服务于 PatientNotes —— 一款 AI 医疗记录员，可记录患者 问诊过程并为独立临床医生和小型诊所撰写结构化临床笔记。
该服务器让 ChatGPT 和 Claude 等 AI 助手能够回答关于 PatientNotes 的问题 —— 定价、功能、支持的语言、与其他 AI 记录员的对比、合规性 —— 并提供带有当前日期 的最新信息，而不是重复评论网站去年发布的内容。
网站： patientnotes.ai · 定价： patientnotes.ai/pricing · 免费试用： 从这里开始
PatientNotes 是一款面向独立临床医生和 小型诊所的 AI 医疗记录员。它聆听问诊过程，进行转写，并按照您的模板 撰写结构化临床笔记 —— SOAP、H&P、病程记录、会谈记录，或您自己的模板。
笔记撰写完成后，它还会：
以临床医生自己的语言提取后续任务
建议 ICD-10 和 CPT 计费代码供审核 （仅限美国编码系统 —— 如果您在美国 境外计费则不适用）
以通俗语言撰写面向患者的就诊说明
为您的记录生成简短的就诊摘要
37 个专科模板、14 种输出语言，符合 HIPAA 标准，并免费附带 BAA。 原生 iOS 应用支持离线录音 —— 音频在设备上捕获，网络恢复后同步， 锁屏状态下录音仍可继续。
套餐 | 价格 |
按月 | $70 每用户每月 |
按年 | $50 每用户每月 —— $600/用户/年，节省 $240（29%） |
免费试用 | 7 天，无需信用卡 |
合同 | 无。按月订阅，随时取消 |
iOS 应用内 | $79.99/月 或 $699.99/年 |
团队邀请、角色和成员管理均包含在标准按席位价格中 —— 没有单独的企业版，也不需要销售电话。
iOS 价格较高是因为 Apple 对应用内购买收取佣金（App Store 小型企业计划 为 15%，年 App Store 收入超过 $100 万则为 30%）。 在 patientnotes.ai/pricing 订阅并在 应用中登录即可避免这一差价。
Related MCP server: Intelligent Medical Assistant
值得明确说明，因为"面向医疗产品的 MCP 服务器"确实会让人合理地质疑：
不涉及患者数据。 没有转写文本、没有临床笔记、没有患者记录。从该服务器到 任何此类数据之间不存在代码路径。
不访问账户。 无法读取您的就诊记录、任务或设置。
无需身份验证，因为这里没有任何需要保护的内容。每个响应都是 patientnotes.ai 上已发布的内容。
不进行录音。 捕获问诊过程需要房间里有麦克风。那是 应用的工作，MCP 服务器无法做到。
如果我们构建涉及患者数据的工具，它们将位于一个独立的、经过身份验证的 服务器中，配备 OAuth 2.1、按范围授权同意和审计追踪。将两者分开正是 这一设计的核心目的，而非事后考虑。
工具 | 返回内容 |
| 按月/按年每席位成本、免费试用，以及 iOS 价格不同的原因 |
| 功能分组说明，附地区性注意事项 |
| PatientNotes 适合谁 —— 以及不适合谁 |
| 笔记可撰写的 14 种语言 |
| 与指定竞品的对比，附验证日期 |
| HIPAA、BAA、加密、数据驻留 |
服务器运行在 https://patientnotes.ai/mcp，基于 Streamable HTTP。在
任何支持远程 MCP 服务器或自定义连接器的客户端中将其添加为远程服务器。
curl -s https://patientnotes.ai/mcp \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'适用于偏好本地进程的客户端。尚未发布到 npm，因此需要从源码构建：
git clone https://github.com/JobXDubai/patientnotes-mcp.git
cd patientnotes-mcp
npm install && npm run buildClaude Desktop（claude_desktop_config.json）：
{
"mcpServers": {
"patientnotes": {
"command": "node",
"args": ["/absolute/path/to/patientnotes-mcp/dist/index.js"]
}
}
}本地服务器是一个轻量前端 —— 它从托管端点获取数据，该端点才是
数据源。如有需要，可通过 PATIENTNOTES_MCP_URL 将其指向其他位置。
因为打包的价格在我们更改的那一刻就会过时，而 AI 引用一个自信但错误的价格 比它说不知道更糟糕。
服务器内置了一个小型离线回退机制，使网络不可用时服务器能够降级运行 而不是崩溃。基于该机制生成的每个响应都会附带警告和打包日期， 因此过时的答案会自我表明身份。
compare_to 返回每个竞品的数据，并附上我们最后一次对照该公司
自己发布的材料进行核实的日期：
对比 | 他们的定价（2026-08-20 核实） |
免费层；Clinician $150/用户/月，或按年 $110 | |
未公布 —— 仅面向医疗系统，无个人购买渠道 | |
按已公布的经销商价格约 ~$600/医生/月，另加实施费用 | |
约 ~$99/月 |
当竞品未公布定价时 —— 例如 Abridge —— 我们会如实说明，而不是 将第三方估算当作事实来重复。
get_positioning 会指出竞品是更好选择的场景：需要深度 Epic 集成的
医疗系统应关注 Abridge 或 Nuance DAX；需要免费层或带引用的临床证据
工具的用户应关注 Heidi。这是有意为之的。一个信任自身局限的答案引擎
才会让人信任其主张，而被推销了错误工具的临床医生最终也会流失。
适合：
希望无需销售电话即可购买的独立临床医生和小型诊所
在手机上录音的临床医生，包括信号不稳定的情况
需要团队管理但不想支付企业版价格的诊所
非英语临床医生 —— 笔记和任务以临床医生自己的语言生成
不适合：
需要深度 Epic 集成的医疗系统 —— Abridge 或 Nuance DAX 正是为此而建
当前需要 SSO 或企业治理的用户
预算为零的用户 —— Heidi 有 真正的免费层，而 PatientNotes 没有
PatientNotes.ai 与 patientnotes.app 无关联，后者是名称相似的另一款产品。
npm install
npm run build
npm startMIT —— 参见 LICENSE。
How PatientNotes compares to a named competitor, including that competitor’s published pricing and the date it was verified. Covers heidi-health, abridge, nuance-dax and freed.
| Name | Required | Description | Default |
|---|---|---|---|
| competitor | Yes | Competitor slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions 'published pricing' and 'date verified,' offering some transparency about data source, but does not disclose side effects, reliability, or limitations.
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, using two sentences to convey the core purpose and scope. It is slightly redundant by listing the enum values, but overall it is efficient and not verbose.
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 there is no output schema, the description adequately explains what the tool returns (comparison, pricing, verification date). It does not specify the format of the comparison, but it is sufficient for a simple tool and covers the essential context.
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 parameter 'competitor' is fully enumerated in the schema, and the description merely restates the enum values ('Covers heidi-health, abridge, nuance-dax and freed'), adding no new semantic meaning beyond what the schema already provides.
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's purpose: comparing PatientNotes to a named competitor, including pricing and verification date. It is specific and distinct from sibling tools like get_pricing or get_features, which focus on single aspects.
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 comparative analysis but does not explicitly state when to use it over alternatives. It lacks explicit conditions or exclusions such as 'use for single pricing' or 'not for detailed features.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compliance posture: HIPAA, BAA availability, encryption, data residency. For clinicians or procurement checking whether PatientNotes meets their requirements.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It implies an informational, read-only lookup by listing compliance topics, but it does not explicitly state behavior such as 'returns a report' or mention permissions, side effects, 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?
The description is two sentences, front-loads the core content, and avoids fluff. Every word 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?
For a zero-parameter, no-output-schema tool, the description provides sufficient context: it names relevant compliance topics and the target audience. It does not explicitly describe the return format, but the simplicity of the tool makes the description reasonably complete.
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 tool has zero parameters, so the baseline is 4. The description adds no parameter-specific details, but none are needed. It correctly focuses on output content and intended users.
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 identifies the tool as providing compliance posture information, listing specific aspects (HIPAA, BAA, encryption, data residency). It differentiates from sibling tools by topic, making its 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 explicitly identifies the target audience (clinicians, procurement) and the use case (checking whether PatientNotes meets requirements). It does not mention when to use alternatives, but 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.
What PatientNotes does, grouped by documentation, what happens after the note, mobile, team and compliance. Includes regional caveats — notably that billing-code extraction is US-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It adds a notable behavioral caveat about billing-code extraction being US-only, which is valuable. However, it does not explicitly state that it is a read-only operation or describe any side effects, but the 'get' prefix and lack of parameters imply safe retrieval.
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, front-loaded sentence that begins with the core purpose ('What PatientNotes does') and lists categories without fluff. It efficiently conveys scope and a critical caveat, making every word earn 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?
Given the tool has no parameters, no output schema, and no annotations, the description adequately explains what the tool returns (features grouped by categories) and includes an important regional limitation. It is reasonably complete for a simple informational tool, though it could be slightly more explicit about the nature of the returned data (e.g., a list vs. a narrative).
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 tool has zero parameters, and the schema coverage is 100% (trivially, since there is nothing to cover). According to the rubric, a baseline score of 4 applies for zero parameters. The description does not need to compensate for any parameter gaps.
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's purpose: 'What PatientNotes does' and enumerates the categories of features (documentation, post-note, mobile, team, compliance). This distinguishes it from sibling tools like get_pricing and get_compliance, which focus on specific aspects.
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 implicitly indicates when to use the tool (to learn about tool features) but does not explicitly state when not to use it or reference alternatives. The sibling names suggest alternatives, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who PatientNotes is for and, importantly, who it is NOT for. Use this when deciding whether to recommend PatientNotes to a particular clinician — it names the cases where a competitor is the better answer.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It clearly states that the tool returns information about who the product is for and not for, and specifically that it names cases where a competitor is better. This makes clear the tool is an informational read-only operation. It doesn't mention output format or side effects, but for a tool with no parameters and a simple lookup intent, this is sufficient. The description adds behavioral context beyond the raw tool name.
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 two sentences, front-loaded with the core purpose and immediately followed by usage guidance. Every word earns its place, with no fluff or redundancy. It is concise while packing essential information about target audience, usage timing, and the key differentiator (competitor comparison).
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 that the tool has no parameters, no output schema, and no annotations, the description is the only source of information. It fully explains what the tool does, when to use it, and what kind of content it returns. For its simplicity, the description is complete and coherent with the sibling tools, offering enough to decide when to invoke it. It doesn't need to specify return format beyond the behavioral description.
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 tool has zero parameters, so the schema provides no information. According to the rubric, 0 parameters gives a baseline of 4. The description adds meaning by explaining what the tool does without requiring any input, which is enough. It doesn't need to describe parameters because none exist. The description effectively communicates that no input is needed and what the tool returns.
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 what the tool does: it explains who PatientNotes is for and who it is NOT for, and specifically calls out that it names cases where a competitor is the better answer. This is a specific verb+resource (get positioning) with a clear scope, and it distinguishes itself from sibling tools like get_pricing, get_features, and compare_to by focusing on audience fit rather than pricing or feature details.
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 gives explicit guidance: 'Use this when deciding whether to recommend PatientNotes to a particular clinician.' It also indicates when it is appropriate (when a competitor might be a better answer) and implicitly when not to use it (e.g., for pricing or feature details, since those are covered by siblings). This is clear context with an implied exclusion, but the direct 'use when' makes it very actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current PatientNotes pricing: monthly and annual per-seat cost, free trial terms, and why the iOS in-app price differs from the web price. Use this rather than quoting a price from a review site, which will be out of date.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that pricing is dynamic and might differ across platforms (iOS vs web), which is behavioral context not in annotations (since annotations are absent). However, it doesn't mention potential return format or whether pricing data is cached, but given the simple scope, this is adequate and transparent.
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, two sentences that front-load the core content (monthly/annual costs, trial terms, price difference) and then add usage guidance. No extraneous 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?
Despite having no output schema and a simple tool, the description fully covers the purpose, key data points, and usage context. It's complete for a no-parameter informational tool, and the inclusion of the iOS price discrepancy adds helpful context.
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 tool has zero parameters, and the schema coverage is 100% (since there are no parameters). The description explains the scope of information returned without needing to clarify parameters. Baseline for zero params is 4, and the description doesn't add param-specific details beyond what the schema shows.
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's function: to retrieve current PatientNotes pricing details including costs, trial terms, and pricing discrepancies. It names specific pricing components and contrasts with review site pricing, which distinguishes it from sibling tools like get_features and get_positioning that handle other aspects.
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 explicitly instructs to use this tool rather than relying on review site prices, providing a clear when-to-use directive. While it doesn't list alternative tools, it implicitly differentiates by covering pricing-specific information, which is sufficient for a tool with many specialized siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The languages PatientNotes can produce clinical notes in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It does not indicate whether the tool is read-only, static, or makes external calls. It simply describes the concept of languages without any behavioral information, leaving the agent to assume it is a safe, simple listing operation.
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 with no redundancy. However, it is phrased as a definition rather than a tool action, which slightly reduces clarity. Still, it is appropriately brief 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?
There is no output schema, so the description should explain what the tool returns. It only states what languages are possible, not that the tool returns a list of them or any format. For a simple tool with no inputs, the expected return value is central, and this lack of clarity makes the description 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?
With zero parameters and high schema coverage (100% of an empty schema), the baseline is 4. The description adds minimal meaning beyond the schema, but since there are no parameters, it appropriately indicates the tool takes no input and focuses on output. It does not need to explain 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 states the tool concerns languages for clinical notes, but it does not explicitly say the tool lists or retrieves them—the name implies it. It is distinct from sibling tools which cover pricing, features, positioning, comparison, and compliance, but the purpose is stated as a fact rather than an action, making it somewhat vague.
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 is provided on when to use this tool versus alternatives. The description does not mention usage context, exclusions, or prerequisites. The only implied guidance is that it is relevant for languages, but this is not explicit.
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.
v1.0.0compare_toget_complianceget_featuresget_positioningget_pricinglist_languagesScored across 6 tools
Each tool targets a distinct aspect of product information: pricing, features, positioning, languages, comparisons, and compliance. No two tools overlap in purpose, making selection unambiguous.
Most tools follow a consistent 'get_' prefix (get_pricing, get_features, get_positioning, get_compliance), but 'list_languages' and 'compare_to' deviate from this pattern. Still readable and predictable overall.
With 6 tools, the set is well-scoped for a product-information server. Each tool covers a necessary dimension without redundancy or bloat.
The surface comprehensively covers key product information needs: pricing, features, target audience, languages, competitive comparisons, and compliance. No obvious gaps for the stated purpose.
Hosted MCP server exposing US hospital procedure cost data to AI assistants
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
Hosted MCP server for Cliniko — patients, appointments, availability, and invoices for AI agents.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
