ichilov-mcp lets an AI assistant read your own Ichilov (beWell) medical records — documents, their PDFs, and upcoming appointments — after you sign in on a page it serves locally.
Sign in (ichilov_login): returns a localhost link where you enter your ID, mobile number and SMS/voice one-time code — never in the chat.
Check the session (ichilov_session_status): whether you're signed in, since when, until when, or the sign-in link if not.
Sign out (ichilov_logout): ends and forgets the beWell session.
List documents (list_documents): lab results, imaging reports, visit/hospitalization summaries, newest first; filter by kind (lab, imaging, other), date range, or text search.
Fetch a document (get_document_pdf): one document as a base64 PDF, using the type/number/version/part from the listing — lab values appear only inside the PDFs.
List appointments (list_appointments): your upcoming hospital appointments.
Boundaries: read-only, your own records only; no bookings, cancellations or changes, and beWell has no prescriptions.
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., "@ichilov-mcp what were my last blood test results at Ichilov?"
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.
Read your own records from beWell, the patient portal of Tel Aviv Sourasky Medical Center (Ichilov, איכילוב), from an AI assistant over MCP: lab results, imaging reports and visit summaries as PDFs, and upcoming appointments.
Unofficial. Not affiliated with the hospital. It uses the same API as the beWell website, which can change without notice.
Everything runs on your machine. You sign in on a page this server serves, the session is saved only on your computer, and this project has no hosted backend and collects nothing. Whatever your AI client requests is passed to that client and handled under its provider's privacy terms.
Own records only.
Read-only. No bookings, cancellations or changes at the hospital.
The session file is secret. It holds beWell's session cookies, is saved with mode 0600 under ~/.config/ichilov-mcp/, and must never be committed or pasted.
Related MCP server: MyChart Care Record Connector
git clone https://github.com/tadnir/ichilov-mcp.git
cd ichilov-mcp
npm install
npx playwright install chromium
npm test{
"mcpServers": {
"ichilov": {
"command": "npx",
"args": ["tsx", "src/main.ts"],
"cwd": "/absolute/path/to/ichilov-mcp"
}
}
}For Claude Desktop, use absolute paths: "command": "/absolute/path/to/node" with "args": ["/absolute/path/to/ichilov-mcp/node_modules/.bin/tsx", "/absolute/path/to/ichilov-mcp/src/main.ts"].
Ask your assistant something, for example "what were my last blood test results at Ichilov?".
While nobody is signed in, the tools answer with a link to a sign-in page this server serves on http://localhost:8767/. ichilov_login returns the same link.
Open it, enter your ID number (or passport) and the mobile number the hospital has on file, and pick how long to stay signed in (1 hour to 30 days). The hospital sends a one-time code by SMS, or by a voice call to a landline; enter it on the page.
Ask again.
Your ID, phone number and the code are only ever typed on that page and sent to the hospital. The assistant only ever sees the link.
beWell protects its sign-in with an invisible reCAPTCHA that only its own page can run, so the server does each step inside a Chromium browser open on the hospital's sign-in page. When reCAPTCHA wants a picture puzzle, the sign-in page shows it, and you solve it there by clicking the picture; nothing is solved automatically. The browser keeps its profile (Google's cookies included) in ICHILOV_CONFIG_DIR/browser, so reCAPTCHA asks fewer puzzles after the first sign-in.
beWell has no refresh token, and ends a sign-in about 20 minutes after it starts, however active it is: neither its own session check nor data calls extend it. So sign in just before you want your assistant to read your records. While the MCP server runs it checks the session every 2 minutes with a small data call (beWell's session check keeps answering "OK" after the sign-in has ended), saves the session's cookies, and shows the session as ended as soon as beWell refuses it. A restart picks the saved session back up if it hasn't ended in between.
Tool | What it reads |
| Lab results, imaging reports, visit and hospitalization summaries, newest first; filter by kind, date or text |
| One of those documents as a PDF (lab values are only in the PDFs) |
| Upcoming appointments |
| The sign-in link, whether a session is live and until when, and sign-out |
beWell has no prescriptions.
Variable | Default | Meaning |
|
| Where the session and the sign-in browser's profile are saved |
|
| Address the sign-in page listens on |
|
| Its port; a free one is used if another copy holds it |
|
| The link handed out, when the page sits behind a reverse proxy. When set, the page starts with the server. |
|
|
|
|
| |
| Playwright's Chromium | Another Chromium to sign in with |
To share one session between several clients, run a single copy on an always-on machine at home and put a stdio-to-HTTP MCP proxy in front of it, such as TBXark/mcp-proxy, with a bearer token per client. Keep it on your own network or a private VPN, never on the internet. Put the sign-in page behind your own authentication and set ICHILOV_LOGIN_URL to its address (and ICHILOV_LOGIN_HOST=0.0.0.0 inside a container). Its links and forms are relative, so it can sit at the root of a host or under a path whose prefix the reverse proxy strips (ICHILOV_LOGIN_URL=https://mcp.example.com/ichilov/login/, with the trailing slash).
Every token holder reads the records of whoever signed in on the page; the proxy's tokens and the beWell session are unrelated. For a second person, run a second copy with its own ICHILOV_CONFIG_DIR, tokens and sign-in page.
The Dockerfile builds an image of the stdio server with Chromium, published as ghcr.io/tadnir/ichilov-mcp from master, with the session in /data and the page on port 8767. Run it with docker run -i, or use it as a base for an image that adds your MCP proxy.
The sign-in page answers only to localhost, 127.0.0.1 and the host in ICHILOV_LOGIN_URL, and each form carries a per-process token. Anyone who can open the page can sign in or out, so keep it on loopback or behind your own authentication.
Download one document from list_documents as a PDF (base64).
| Name | Required | Description | Default |
|---|---|---|---|
| part | Yes | DOKTL of the document. | |
| type | Yes | DOKAR of the document, e.g. LAB. | |
| number | Yes | DOKNR of the document. | |
| version | Yes | DOKVR of the document. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the return encoding (base64), which is genuinely useful for an agent handling the payload, but it says nothing about session/auth requirements (relevant given the login/session_status/logout siblings) or size/rate 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?
A single front-loaded sentence with no waste: action, scope, source, and format all in one line. Nothing is redundant or padded.
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 simple 4-identifier read tool with no output schema, the description usefully names both the source of the IDs and the response format. The remaining gap is the unstated authentication/session prerequisite implied by the sibling login tools.
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% — each of the four SAP fields (DOKAR, DOKNR, DOKVR, DOKTL) is documented inline — so the baseline of 3 applies. The description adds no additional meaning about the parameters beyond pointing at their source.
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?
States a specific verb (Download), a scoped resource (one document, sourced from list_documents), and the output format (PDF, base64). This cleanly separates it from the list_documents sibling, which only enumerates documents.
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?
"from list_documents" implies the intended workflow — call the list tool first to obtain the identifiers — but there is no explicit when-to-use/when-not statement or mention of alternatives. Usage is implied rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the link where the user signs in to beWell (ID, mobile number and one-time code are typed on that page, never in the chat). Returns the status when already signed in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose two important traits: the credential handling happens off-chat, and it self-detects an already-signed-in state. Still missing are failure behavior, link validity/expiry, and whether it invalidates an existing session.
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?
Two dense sentences with the core action front-loaded and the security constraint kept to one parenthetical. Nothing is redundant, though the closing status clause adds a second, different behavior that could have been split or dropped.
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 tool with no annotations and no output schema, the description covers the essential mechanics and the critical security note. It stops short of explaining how the returned link is consumed, what the already-signed-in status looks like, or how it relates to the session-status sibling.
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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-argument tool is 4.
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?
Names a specific verb and resource: it fetches the sign-in link for beWell. The trailing clause about returning status when already signed in correctly signals one branch of behavior, though it partially overlaps with the sibling ichilov_session_status, which weakens the differentiation slightly.
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 parenthetical makes the intended channel clear (credentials typed on the page, never in chat), which is real usage guidance. However, it never states when to call this versus ichilov_session_status or ichilov_logout, so the agent must infer the sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sign out of beWell here: end the session and forget it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It adds useful context by stating the session is ended and forgotten, but it does not disclose what happens if no session exists, whether the operation can fail, or any authentication/state requirements.
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 with no filler. Every phrase earns its place by naming the action and clarifying the effect.
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 logout tool, the description provides enough to understand the core action and effect. It could be slightly richer by mentioning session-state edge cases, but the complexity is minimal and no critical detail is missing.
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 information because there are no parameters to describe, and the empty schema already fully covers the input contract.
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 explicitly states the specific verb and resource: 'Sign out of beWell' and further clarifies 'end the session and forget it.' This is unambiguous and clearly distinguishes the tool from sibling ichilov_login and ichilov_session_status.
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?
Usage is implied by the action itself: an agent can infer it should call this when it wants to end a session. However, there is no explicit when-to-use guidance, no mention of alternatives such as checking session status first, and no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Whether this server is signed in to beWell, since when, until when, and the sign-in link when it is not.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It usefully describes the return content (sign-in state, timestamps, link when signed out), but does not explicitly state that it is read-only and side-effect-free, nor does it mention any auth or rate-limit considerations.
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?
A single, front-loaded sentence that conveys the core return fields with no filler. Every clause earns its place by naming a distinct piece of returned 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?
For a zero-parameter status tool with no output schema and no annotations, the description adequately enumerates the information returned. It could better connect to the ichilov_login/ichilov_logout flow, but nothing essential to calling it correctly is missing.
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 takes zero parameters, so there is no parameter semantics to document; the baseline for a no-parameter tool is 4. The empty schema is consistent with the description, which requires no input.
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 this is a session-status query for beWell, specifying the information returned (signed in, since, until, sign-in link). It implicitly distinguishes itself from login/logout siblings by being a status check, though it never explicitly names those alternatives.
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 when-to-use guidance or alternatives are provided. It does not say to call this before other operations, when to prefer it over ichilov_login, or what to do with the sign-in link, leaving usage entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The patient's upcoming appointments at the hospital.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose two real behavioral traits an empty schema cannot convey: the results are scoped to the authenticated patient (no user parameter) and filtered to 'upcoming' appointments only. However, it says nothing about ordering, result limits, or the session/auth requirement implied by the ichilov_login siblings.
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?
A single sentence fragment with zero filler, front-loaded on the resource being returned. It is arguably under-specified rather than over-long, so conciseness itself is good.
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 list tool with no output schema and no annotations, the description covers what is returned but not how: no return-field structure, ordering, or session prerequisite. It is minimally adequate but leaves the auth dependency (evident from the login siblings) unstated.
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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The absence of any filtering parameters (date range, department) is consistent with the 'upcoming' scoping stated in the description.
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?
Names the specific resource (appointments) with two scoping qualifiers: 'the patient's' and 'upcoming', plus the location. An agent can tell this retrieves the current patient's future appointments, and it is clearly distinct from the sibling list_documents. It loses a point for being a noun phrase rather than an explicit verb+resource statement.
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 when-to-use or when-not-to-use guidance is given, and no alternatives are named. The only routing signal is implicit: sibling names like ichilov_login suggest a session may need to exist first, but the description never says so.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The documents in the patient's file (lab results, imaging, visit and hospitalization summaries), newest first, with the type, number, version and part get_document_pdf takes.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Only documents on or before this day, yyyy-MM-dd. | |
| from | No | Only documents on or after this day, yyyy-MM-dd. | |
| kind | No | lab: lab results; imaging: radiology reports; other: summaries and the rest. | |
| search | No | Only documents whose title or department contains this text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It mentions ordering (newest first) and that identifiers feed get_document_pdf, but doesn't disclose authentication needs, pagination, rate limits, or what fields are returned beyond identifiers. A call to action like 'requires login' is absent.
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?
One compact sentence with no waste, front-loading the resource and ordering. Slightly dense but all elements earn their 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 read-only listing tool with no annotations, the description should say more about auth requirements (the sibling tools suggest login needed) and return format. It covers the essentials but leaves gaps for a tool in a session-based 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?
Schema coverage is 100%, so baseline is 3; but description adds that the listed items include 'type, number, version and part' which are the identifiers for get_document_pdf, giving context beyond schema. However, it doesn't explain filtering parameters (from/to/kind/search) beyond what schema says.
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 it lists documents in the patient's file, enumerating types (lab results, imaging, visit/hospitalization summaries). It implicitly distinguishes from get_document_pdf by referring to it, though it doesn't name an alternative listing tool (none exists).
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?
Usage is implied: list documents, then use get_document_pdf with the returned type/number/version/part. No explicit when-to-use versus alternatives or exclusions, but the connection to the sibling tool is hinted.
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.0get_document_pdfichilov_loginichilov_logoutichilov_session_statuslist_appointmentslist_documentsScored across 6 tools
Auth tools (login, session_status, logout) and data tools (list_documents, list_appointments, get_document_pdf) are clearly separated. The only mild overlap is ichilov_login and ichilov_session_status both returning the sign-in link, but their purposes differ.
Half the tools use an ichilov_ prefix (auth) while the other half use bare verb_noun names (data), with no clear rule. Mixed verb styles and prefixes across the set reduce predictability.
Six tools is a tight, reasonable surface for an authenticated document/appointment reader. Nothing feels extraneous, though it is on the leaner side.
Read path is well covered (list then fetch PDF), and auth lifecycle is complete. However, there is no tool to view appointment details, cancel/reschedule, or fetch documents by filter—notable gaps for an agent working in this domain.
Your MedNode health vault in your AI assistant — records, summaries, labs, appointments.
Your labs, wearables, DNA and notes as one health record your AI agent can read (OAuth 2.1).
Your own health records from Vora, Still, Stackwell and Joiva in your AI assistant (OAuth).
Read patient-authorized EHR records: medications, labs, conditions, allergies. Consent-bounded.
