Mirobody
Lab results to LOINC codes and UCUM units, symptoms and diagnoses to ICPC-3. Offline, no API key.
作者提供的说明(英文原文)
Apprise notification fan-out: health, status, and tagged or one-off sends.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
你需要
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
打开 Claude Desktop → Settings → Developer → Edit Config,把下面的内容粘贴到 claude_desktop_config.json
{
"mcpServers": {
"notifyfan": {
"command": "npx",
"args": [
"-y",
"@reneturcios/notifyfan",
"mcp"
]
}
}
}在终端中运行这条命令
claude mcp add notifyfan -- npx -y @reneturcios/notifyfan mcp粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"notifyfan": {
"command": "npx",
"args": [
"-y",
"@reneturcios/notifyfan",
"mcp"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"notifyfan": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@reneturcios/notifyfan",
"mcp"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
这个服务器在你的电脑上运行,而 ChatGPT 只能连接互联网上的服务器。请选择其他应用。
你的选择通过 Cookie 保存在这台设备上,无需账户。
这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
它在你的电脑上运行;安装后,工具列表会显示在你的 AI 应用中。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月6日
注册名称已通过 GitHub 账户 CloudCorpRecords 验证,该账户拥有此仓库
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
它在你的电脑上运行,没有互联网端点
在你的电脑上运行,改用本地设置
它在你的电脑上运行;我们只能读取互联网端点的工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在你的电脑上运行。你的 AI 应用会在需要时启动它,数据不会经过作者的服务器(除非它自己调用在线服务)。
GitHub 仓库最后更新于–,最新版本(0.1.0)于4天前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 Node.js, Docker。
同一分类中有:Mirobody, FHIR MCP Server, Google Health MCP
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
Lab results to LOINC codes and UCUM units, symptoms and diagnoses to ICPC-3. Offline, no API key.
MCP server providing seamless access to FHIR APIs for AI tools and healthcare applications
Privacy-first unofficial Google Health API v4 MCP server for health, sleep, activity, HR agents
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
notifyfan sends notifications through an Apprise API server. A single tool, apprise, fans a message out to the destinations Apprise is configured with: send to one configured tag (or to every configured service), fire a one-off send at raw Apprise URL schemas, and check that the upstream server is alive — all through one action argument instead of a tool per operation. One binary serves a command-line interface and a stdio MCP server.
Two environment variables configure the upstream connection:
APPRISE_URL — the Apprise API server base URL. Defaults to http://localhost:8000.APPRISE_TOKEN — optional. When the upstream requires bearer auth, set it and notifyfan sends Authorization: Bearer on every upstream call. It is read from the environment only: it is never a CLI flag and never an MCP tool argument.The help action works with nothing configured at all.
npx @reneturcios/notifyfan health
Or run the container image:
docker run -i ghcr.io/cloudcorprecords/notifyfan
The container defaults to the MCP server. Pass CLI arguments to use it as a CLI instead.
notifyfan health
notifyfan status notifyfan help notifyfan notify "Deployment succeeded" --tag ops --title "Deploy complete" --type success notifyfan notify "Standup notes are posted" notifyfan notify-url "mailto://user@example.com" "Build finished" --type info
notifyfan --version
notify needs only a body; omit --tag to send to all configured services. notify-url takes the Apprise URLs first (one string; separate several URLs with commas) and then the body. Exit codes: 0 on success, 1 when a call fails (validation or upstream error), 2 for usage errors.
npx -y @reneturcios/notifyfan mcp
MCP client configuration:
{
"mcpServers": { "notifyfan": { "command": "npx", "args": ["-y", "@reneturcios/notifyfan", "mcp"], "env": { "APPRISE_URL": "http://localhost:8000" } } } }
Add APPRISE_TOKEN to the env block only when your Apprise API server requires it.
| Tool | Input | What it does |
|---|---|---|
apprise | action (string, required) plus the per-action parameters below | Runs the named action against the upstream Apprise API server. |
Actions:
| Action | Required | Optional | What it does |
|---|---|---|---|
health | — | — | Check Apprise API server health. |
status | — | — | Return authenticated deployment and runtime status. |
help | — | — | Return built-in markdown tool help. Makes no upstream call. |
notify | body | tag, title, type | Send to a configured Apprise tag, or to all configured services when tag is omitted. |
notify_url | urls, body | title, type | Send a stateless one-off notification to one or more Apprise URL schemas. urls is a single string; separate multiple URLs with commas. |
type is one of info (informational), success (successful operation), warning (non-critical warning), or failure (critical failure or error). Unknown actions, a missing body/urls, and an invalid type are errors raised before any upstream call.
Example call:
{
"name": "apprise", "arguments": { "action": "notify", "body": "Deployment succeeded", "tag": "ops", "title": "Deploy complete", "type": "success" } }
The action catalogue above is the documented surface. The upstream paths are documented reconstructions from the standard Apprise API: notify posts {body, tag?, title?, type?} to POST /notify, and notify_url posts {urls, body, title?, type?} to the same endpoint — the stateless form; the upstream API has no separate /notify_url route. health reads GET / (the upstream root) and status reads GET /details. Payload fields that were not supplied are omitted, never sent empty. Upstream failures surface the HTTP status plus the upstream message or error string when one is present, and a non-JSON success body is returned as raw text.
send_alert prompt are not reproduced; this rebuild is stdio-only.npm install
npm run build # tsc -> dist/ npm test # node test runner over test/*.test.ts, no network (fake fetch fixtures) npm run dev # run the CLI from source via tsx
MIT — see LICENSE.