Mirobody
Lab results to LOINC codes and UCUM units, symptoms and diagnoses to ICPC-3. Offline, no API key.
Description from the maker (original English)
Search and export FDA drug labels by brand name, generic ingredient, or UNII code.
These three are never merged into one score: opinions, measurements and popularity are different things.
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
Pick the AI app you use, then copy the settings.
You need
Which app do you use?
Pick your app above. We remember it, so next time the button says “Install in …”.
Works in Claude on the web, desktop and mobile:
https://www.medrecpro.com/mcpRun this in your terminal
claude mcp add --transport http drug-label https://www.medrecpro.com/mcpPaste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"drug-label": {
"url": "https://www.medrecpro.com/mcp"
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
Paste into .vscode/mcp.json in your project
{
"servers": {
"drug-label": {
"type": "http",
"url": "https://www.medrecpro.com/mcp"
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
ChatGPT connects only to servers on the internet:
https://www.medrecpro.com/mcpMenu names can differ slightly by plan and over time.
Your choice stays on this device in a cookie; no account needed.
These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
We have not read this server’s tool list yet; we check endpoints in rotation.
We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 8, 2026
The registry name was verified against the domain medrecpro.com (the registry checks domain ownership)
We have not read this repo from GitHub yet
We have not read this repo from GitHub yet
Not checked yet; we check endpoints in rotation
Not checked yet; we check endpoints in rotation
Not checked yet; we read the tool list when we check the endpoint
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.
The registry does not list a required key, though some servers ask you to sign in on first use.
It runs in the maker’s cloud. Connect over the internet with nothing to install, but what you send passes through the maker’s servers.
The GitHub repo last changed –, and the latest version (1.0.3) reached the registry 8 months ago.
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. It connects by URL, so apps that accept remote MCP servers work too, such as ChatGPT in developer mode.
In the same category: Mirobody, FHIR MCP Server, Google Health MCP
Servers in the same category from other makers, sorted by stars.
Reading a card:★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
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
Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.
MCP (Model Context Protocol) server for the MedRecPro application. Acts as an OAuth 2.1 gateway between MCP clients (Claude, etc.) and the MedRecPro Web API.
Version: 1.0.0 Runtime: ASP.NET Core 8.0 Production URL: https://www.medrecpro.com/mcp
Azure App Service: "MedRecPro" (Windows, IIS)
+--------------------------------------------------+ | | +------------------+ | / site\wwwroot MedRecProStatic | | Claude / MCP | HTTPS | /api site\wwwroot\api MedRecPro API | | Client |------->| /mcp site\wwwroot\mcp MedRecProMCP | +------------------+ | | | +--------------------------------------------------+ v | +------------------+ v | Cloudflare | +------------------+ | (CDN/WAF/DNS) | | Azure Key Vault | +------------------+ | (medrecprovault)| +------------------+
The MCP server runs as an IIS virtual application at /mcp on the same Azure App Service as the main MedRecPro UI and API. IIS handles path-based routing to three separate ASP.NET Core processes:
| Virtual Path | Physical Path | Project | Purpose |
|---|---|---|---|
/ | site\wwwroot | MedRecProStatic | UI / Static content |
/api | site\wwwroot\api | MedRecPro | Web API |
/mcp | site\wwwroot\mcp | MedRecProMCP | MCP Server (this project) |
All endpoints are externally prefixed with /mcp by the IIS virtual application.
| External URL | Method | Description |
|---|---|---|
/mcp | POST | MCP Streamable HTTP transport (JSON-RPC) |
/mcp/health | GET | Health check (returns JSON status) |
/mcp/docs | GET | HTML technical documentation page |
/mcp/getting-started | GET | HTML getting-started page (user-facing, for directory listing) |
/mcp/docs/images/{filename} | GET | Serves embedded screenshot images (PNG) |
/mcp/.well-known/oauth-protected-resource | GET | Protected Resource Metadata (RFC 9728) |
/mcp/.well-known/oauth-authorization-server | GET | Authorization Server Metadata (RFC 8414) |
/mcp/oauth/authorize | GET | OAuth authorization endpoint |
/mcp/oauth/token | POST | Token exchange endpoint |
/mcp/oauth/register | POST | Dynamic Client Registration (RFC 7591) |
/mcp/oauth/callback/google | GET | Google OAuth callback |
/mcp/oauth/callback/microsoft | GET | Microsoft OAuth callback |
Note:
GET /mcpreturns HTTP 405 (Method Not Allowed). This is correct behavior. The MCP transport only accepts POST requests. For browser-accessible pages, use/mcp/docs(technical documentation) or/mcp/getting-started(user-facing guide).
1. Claude sends POST to /mcp (unauthenticated)
sub claim (standard JWT name), redirects to Claude
During the OAuth callback (step 9), the MCP server must map the upstream identity provider's identifier (Google sub / Microsoft GUID) to a numeric MedRecPro database user ID. The API's getEncryptedIdFromClaim() method expects a numeric NameIdentifier claim — without this resolution, all API calls would fail with 401.
How it works:
OAuthEndpoints.cs extracts email, display name, and provider from upstream IdP claimsUserResolutionService generates a temporary MCP JWT and calls POST /api/users/resolve-mcpUsersController.ResolveMcpUser() looks up the user by email:AuthController.createUserForExternalLogin() defaults: EmailConfirmed=true, Timezone="UTC", Locale="en-US", no password), then returns the encrypted IDUserResolutionService decrypts the encrypted ID using the shared Security:DB:PKSecret via StringCipherOAuthEndpoints.cs replaces the upstream NameIdentifier claim with the numeric database user IDMcpTokenService.normalizeClaimType() converts ClaimTypes.NameIdentifier to the standard JWT sub claim during token creation, and OutboundClaimTypeMap is cleared to prevent double-mappingsub claim, enabling all API calls to succeedKey architecture:
TokenForwardingHandler forwards the MCP JWT directly to the API (not the upstream Google/Microsoft token). The API's McpBearer authentication scheme validates these MCP-signed JWTs.Security:DB:PKSecret from Azure Key Vault for StringCipher encryption/decryption of user IDs.UserResolutionService uses a dedicated "MedRecProApiDirect" named HttpClient (without TokenForwardingHandler) to avoid circular token forwarding during resolution.McpTokenService normalizes .NET ClaimTypes URIs to standard JWT short names (sub, name, email, given_name, family_name) before token creation. Both JWT handlers set MapInboundClaims = false so claims retain their short names when read back. The API's ClaimHelper resolves user IDs from both ClaimTypes.NameIdentifier (cookie auth) and "sub" (MCP JWT auth).Route paths use compiler directives to handle IIS virtual application path stripping. This follows the same pattern as ApiControllerBase in the MedRecPro API project.
Problem: IIS strips the /mcp prefix from requests before forwarding to the app. A request to www.medrecpro.com/mcp/oauth/authorize arrives at Kestrel as /oauth/authorize. Routes must account for this.
| Component | DEBUG (local dev) | RELEASE (Azure/IIS) |
|---|---|---|
| MCP transport | MapMcp("/mcp") | MapMcp("/") |
| Health check | GET / | GET /health |
| Documentation | GET /mcp/docs | GET /docs |
| Getting started | GET /mcp/getting-started | GET /getting-started |
| Image serving | GET /mcp/docs/images/{filename} | GET /docs/images/{filename} |
| OAuth group | /mcp/oauth | /oauth |
| Well-known metadata | /mcp/.well-known/* | /.well-known/* |
| PRM redirect | /mcp/.well-known/oauth-protected-resource redirects to SDK path | Not needed (IIS handles) |
Files with compiler directives:
Program.cs - MCP transport, health check, docs, getting-started, image serving, PRM redirectEndpoints/OAuthEndpoints.cs - OAuth route group prefixEndpoints/OAuthMetadataEndpoints.cs - Well-known metadata pathsConfig-driven (no directives needed):
McpServer:ServerUrl at runtimeMcpServer:ServerUrl at runtimeMcpServer:ServerUrl at runtimemedrecprovault)medrecpro.com domaingit clone <repo-url>
cd MedRecProMCP dotnet restore
dotnet user-secrets init
dotnet user-secrets set "McpServer:JwtSigningKey" " " dotnet user-secrets set "Jwt:Key" " " dotnet user-secrets set "Jwt:Issuer" "http://localhost:5233/mcp" dotnet user-secrets set "Jwt:Audience" "http://localhost:5233/mcp" dotnet user-secrets set "Jwt:ExpirationMinutes" "60" dotnet user-secrets set "Jwt:UpstreamTokenEncryptionKey" "<32-char-aes-key>" dotnet user-secrets set "Authentication:Google:ClientId" " " dotnet user-secrets set "Authentication:Google:ClientSecret" " " dotnet user-secrets set "Authentication:Microsoft:ClientId" " " dotnet user-secrets set "Authentication:Microsoft:ClientSecret:Dev" " " dotnet user-secrets set "Authentication:Microsoft:TenantId" " " dotnet user-secrets set "Security:DB:PKSecret" " "
dotnet run
The server runs at http://localhost:5233. In DEBUG mode, endpoints include the /mcp prefix:
In Azure Portal:
/mcpsite\wwwroot\mcpEnsure the following secrets exist in Azure Key Vault (medrecprovault). These are shared with the MedRecPro API since both apps use the same Key Vault:
| Secret Name | Description |
|---|---|
McpServer--JwtSigningKey | JWT signing key for MCP tokens (min 32 chars) |
Jwt--Key | JWT signing key |
Jwt--Issuer | JWT issuer claim |
Jwt--Audience | JWT audience claim |
Jwt--ExpirationMinutes | Token expiration (e.g., 60) |
Jwt--UpstreamTokenEncryptionKey | AES encryption key for upstream tokens |
Authentication--Google--ClientId | Google OAuth Client ID |
Authentication--Google--ClientSecret | Google OAuth Client Secret |
Authentication--Microsoft--ClientId | Microsoft Entra App ID |
Authentication--Microsoft--ClientSecret--Prod | Microsoft client secret (production) |
Authentication--Microsoft--TenantId | Azure AD Tenant ID |
Security--DB--PKSecret | Shared encryption key for user ID encryption/decryption (must match API) |
Note: Key Vault uses
--as separator. ASP.NET Core maps these to:in configuration (e.g.,Jwt--KeybecomesJwt:Key).
The App Service must have a system-assigned managed identity with Get and List permissions on Key Vault secrets. Since the MCP virtual application shares the same App Service as the API, the existing managed identity should already have access.
https://www.medrecpro.com/mcp/oauth/callback/google (production)http://localhost:5233/mcp/oauth/callback/googleOnly the beginning is shown; read the rest in the repo