Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add aks129/HealthClawGuardrails --skill fhir-upstream-proxygit clone --depth 1 https://github.com/aks129/HealthClawGuardrailsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/aks129/healthclawguardrails/fhir-upstream-proxy)<a href="https://agentmods.dev/skills/aks129/healthclawguardrails/fhir-upstream-proxy"><img src="https://agentmods.dev/badge/skills/aks129/healthclawguardrails/fhir-upstream-proxy/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/aks129/healthclawguardrails/fhir-upstream-proxy"><img src="https://agentmods.dev/badge/skills/aks129/healthclawguardrails/fhir-upstream-proxy.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00091 | $0.00972 |
| Opus 5 | $0.00046 | $0.00486 |
| Sonnet 5 | $0.00018 | $0.00194 |
| Haiku 4.5 | $0.00009 | $0.00097 |
Grade A, and why
fhir-upstream-proxy scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 12d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 112 lines — stays where its author put it; the contents beside it link to each section on GitHub.
FHIR Upstream Server Proxy
Connect to real FHIR servers while keeping the full MCP guardrail stack active.
Client -> MCP Server -> Flask (guardrails) -> Upstream FHIR Server
|
redaction, audit, step-up,
tenant isolation, disclaimers,
URL rewriting
When to Use This Skill
- You need to connect an AI agent to a real FHIR server (HAPI, SMART, Epic)
- You want automatic PHI redaction on upstream server responses
- You need audit trails for agent access to production clinical data
- You want URL rewriting so upstream server details never leak to clients
Configuration
Set the FHIR_UPSTREAM_URL environment variable to enable proxy mode:
# HAPI FHIR R4 (open, no auth)
FHIR_UPSTREAM_URL=https://hapi.fhir.org/baseR4 python main.py
# SMART Health IT (open, no auth)
FHIR_UPSTREAM_URL=https://r4.smarthealthit.org python main.py
# HAPI FHIR R5 (open, no auth)
FHIR_UPSTREAM_URL=https://hapi.fhir.org/baseR5 python main.py
# Local HAPI instance
FHIR_UPSTREAM_URL=http://localhost:8080/fhir python main.py
# Docker Compose with upstream
FHIR_UPSTREAM_URL=https://hapi.fhir.org/baseR4 docker-compose up -d --build
Environment Variables
| Variable | Default | Description |
|---|---|---|
FHIR_UPSTREAM_URL |
(empty) | Upstream FHIR server base URL. Enables proxy when set. |
FHIR_UPSTREAM_TIMEOUT |
15 |
HTTP timeout for upstream requests (seconds) |
FHIR_LOCAL_BASE_URL |
(empty) | Local server URL for URL rewriting in responses |
What the Proxy Does
Reads
Fetched from upstream, then redacted + audited + disclaimers added. The agent never sees unredacted upstream data.
Searches
All query parameters forwarded to upstream. Results redacted per entry. Upstream's full search capabilities are available (chaining, _include, etc.).
Writes
Validated locally first (structural checks), then forwarded to upstream with step-up auth verification. Both local and upstream audit records created.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 12d ago First seen · 112 lines · 91 tokens per session scan A b5a5fd540278
fhir-upstream-proxy is a skill published in the GitHub repository aks129/HealthClawGuardrails (30 stars, last pushed today), licensed MIT. It adds 91 tokens to every session and 972 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
healthcare-fhir
Design RESTful clinical data exchanges using HL7 FHIR standards.
event-store-design
Design and implement event stores for event-sourced systems. Use when building event sourcing infrastructure, choosing event store technologies, or implementing event persistence patterns.
cqrs-implementation
Implement Command Query Responsibility Segregation for scalable architectures. Use when separating read and write models, optimizing query performance, or building event-sourced systems.
workflow-orchestration-patterns
Design durable workflows with Temporal for distributed systems. Covers workflow vs activity separation, saga patterns, state management, and determinism constraints. Use when building long-running processes, distributed transactions, or microservice orchestration.
microservices-patterns
Design microservices architectures with service boundaries, event-driven communication, and resilience patterns. Use when building distributed systems, decomposing monoliths, or implementing microservices.
python-sdk
Implement or modify Python SDK behavior under python/composio, including tools, toolkits, sessions, auth configs, connected accounts, client integration, and shared Python models. Use for Python core runtime/API work; pair with python-testing and cross-sdk-parity when TypeScript must match.