Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@perimeter-mcp scan the files I just changed for health-data mistakes"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for coding assistants such as Claude Code and Codex. It does two things:
Checks code for common health-data mistakes. This runs on your machine, needs no account, and uploads nothing.
De-identifies clinical text through a perimeter core service, if you run one. Core is not publicly available yet.
It reduces exposure and keeps a record. It does not certify anything, and a clean check is not a compliance review.
Claude Code
claude mcp add perimeter -- npx -y perimeter-mcpOr, to share it with everyone working on a project, add .mcp.json at the project root:
{
"mcpServers": {
"perimeter": { "command": "npx", "args": ["-y", "perimeter-mcp"] }
}
}On Windows outside WSL, use "command": "cmd" with "args": ["/c", "npx", "-y", "perimeter-mcp"].
Codex (~/.codex/config.toml)
[mcp_servers.perimeter]
command = "npx"
args = ["-y", "perimeter-mcp"]Claude Desktop (claude_desktop_config.json): the same mcpServers block as above.
Related MCP server: trestle
Tool | Needs core | What it does |
| no | Checks files or folders and returns findings with a suggested fix |
| yes | Replaces identifiers in text with placeholders such as |
| yes | Restores placeholders, for showing a result to the data's owner |
| yes | Adds an entry to the tamper-evident audit log |
The last three only appear when a core is configured, so an assistant is never offered a tool that cannot work:
{
"mcpServers": {
"perimeter": {
"command": "npx",
"args": ["-y", "perimeter-mcp"],
"env": {
"PERIMETER_URL": "http://localhost:8000",
"PERIMETER_API_KEY": "<a secret from PERIMETER_API_KEYS in core's settings>"
}
}
}
}Finding | Severity |
Health data saved in browser storage or cookies | blocking |
Analytics or tracking code | blocking |
A script loaded from another site | blocking |
A request over http:// or ws:// | blocking |
A request to a host that is not approved | blocking |
A secret key written in the code | blocking |
eval, new Function | blocking |
postMessage to any window ( | blocking |
Personal data written to the log | warning |
A font, stylesheet or image from another site | warning |
A personal-data form with no privacy notice | warning |
innerHTML and similar with a non-fixed value | warning |
It reads HTML, CSS, JavaScript and TypeScript (including JSX, Vue and Svelte files). It does not read server-side languages, and it does not judge whether a tool's clinical content is correct.
npx -y perimeter-mcp scan # the current folder
npx -y perimeter-mcp scan src --json # machine-readable
npx -y perimeter-mcp scan --allow-host api.example.orgThe command exits with code 1 when there is a blocking finding, so it can gate a commit or a CI job.
A hook runs the check each time Claude Code writes a file, and hands any blocking
finding straight back to it. Add this to .claude/settings.json in the project:
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit|MultiEdit",
"hooks": [{ "type": "command", "command": "npx -y perimeter-mcp hook" }]
}
]
}
}It stays silent unless it finds something blocking.
Assistants read a notes file in each project (CLAUDE.md for Claude Code,
AGENTS.md for Codex). If a project handles health information, a short note
helps. Edit this one to fit:
## Health data
This project handles health information. When writing or changing code here:
- Do not save patient or health data in localStorage, sessionStorage, cookies or
IndexedDB. Keep it in memory, or send it to our own server over HTTPS.
- Do not add analytics, trackers, or scripts, fonts and images loaded from other
sites.
- Do not write patient details, form values or identifiers to logs.
- Do not put keys or passwords in the code.
- Use invented data in examples, tests and fixtures. Never real patient records.
If the `perimeter_scan_code` tool is available, run it on the files you changed
before reporting the work as done, and fix what it flags as blocking.
If you need to put clinical text into a prompt, a fixture or an issue and
`perimeter_deidentify` is available, pass the text through it first. It misses
things, so still read the result.
These are precautions, not a compliance review. Say so if asked whether the code
is compliant with a regulation.Checks web code for common mistakes with patient or health data: data saved in browser storage, analytics trackers, scripts or fonts loaded from other sites, personal data written to logs, unencrypted or unapproved network requests, secret keys in the code, forms with no privacy notice, and eval-style code. Runs on this machine; nothing is uploaded. Useful after writing or changing code that handles health information. Returns each finding with its file, line, a plain explanation and a suggested fix. It looks for a fixed list of mistakes: a clean result is not a compliance review.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | File contents to check directly, instead of or as well as paths. | |
| paths | No | Files or folders to check, relative to the working directory. | |
| allowed_hosts | No | Hosts the code may send requests to, for example api.example.org. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so 'Runs on this machine; nothing is uploaded' partly restates that, but the description adds genuinely new behavioral context: the scan is restricted to a fixed checklist and a clean result is explicitly not proof of compliance. That caveat is the kind of thing an agent cannot infer from annotations.
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 purpose is front-loaded in the first clause, followed by evidence, a privacy note, a usage hint, and a return-value summary. The enumerated mistake list is long but each item is substantive; the only mild redundancy is the local-execution statement overlapping with openWorldHint.
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?
With no output schema, the description explains the return shape ('each finding with its file, line, a plain explanation and a suggested fix'), covers invocation context, privacy behavior, and limitations. An agent has everything needed to call it and interpret results.
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?
Schema description coverage is 100%, with files, paths, and allowed_hosts all documented in the schema itself, so the baseline of 3 applies. The description mentions none of the parameters (e.g. it never says paths and files can be combined, nor how allowed_hosts affects the network-request findings), so it adds nothing beyond the schema.
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 names a specific verb and resource ('Checks web code for common mistakes with patient or health data') and then enumerates the exact class of findings it produces, so an agent knows precisely what the tool does without opening the schema.
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?
It states a clear usage context ('Useful after writing or changing code that handles health information') and a scope boundary ('a clean result is not a compliance review'). It doesn't name an alternative tool, but there are no siblings to distinguish from, so this is close to complete guidance.
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.
v0.1.0perimeter_scan_codeScored across 1 tool
With only one tool in the set, there is no possibility of tool-to-tool confusion. The single tool has a clearly stated, narrow purpose (scanning code for health-data privacy mistakes), so selection is unambiguous.
The lone name, perimeter_scan_code, follows a clean snake_case verb_noun-ish convention and is internally consistent with the server's 'perimeter' branding. No mixed conventions exist to conflict with it.
One tool is thin for a server surface, though the tool itself is substantive rather than trivial and the domain (a fixed-rule static scanner) is narrow enough that a single entry point is defensible. It sits on the borderline between well-scoped and under-provisioned.
The core operation—scan and report findings—is covered, but a scanning domain typically also wants rule enumeration, rule suppression/configuration, and directory- or repo-level scanning rather than a single invocation. These are notable gaps an agent cannot work around with the current surface.
Privacy-preserving synthetic health data generation. FHIR R4/R5 compliant.
HealthGuard - 12-tool health/medical AI safety MCP: PII redaction, HIPAA, GDPR Art.9.
Governance copilot for AI-assisted coding. 72 packs, 532 rules, proof bundles.
Detect and redact PII and secrets before text reaches an LLM, with reversible placeholders.
