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., "@openemr-wiki-mcp search OpenEMR wiki for billing"
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.
A quick local-first MCP server for OpenEMR documentation.
I made this as a small practical implementation so I could get fast local access to OpenEMR wiki pages, the Users Guide, and selected API docs inside desktop AI apps, coding agents, and other MCP-capable tools.
This repository is intentionally focused on local usage. It does not try to be a full hosted platform or production-ready remote service.
Tool | Description | Key Parameters |
| Search the OpenEMR wiki for any topic. Returns titles, summaries, and URLs. |
|
| Fetch the plain-text content of a specific wiki page by title, optionally narrowed to a section. |
|
| Fetch the table of contents from the OpenEMR 8.0.0 Users Guide. | (none) |
| Fetch selected OpenEMR API documentation from the OpenEMR GitHub repository. |
|
| List wiki pages in a given MediaWiki category. |
|
Related MCP server: crc-doc-mcp
Node 18+
npm
This is a local stdio MCP server. That is the supported usage mode in this repo today.
git clone https://github.com/rucister/openemr-wiki-mcp.git
cd openemr-wiki-mcp
npm install
npm run build
npm install -g .Verify the global binary if you want to use the npm-installed command directly:
which openemr-wiki-mcpIf you want the MCP server to run inside WSL, do the install from your WSL shell, not from Windows PowerShell:
cd /path/to/openemr-wiki-mcp
npm install
npm run build
npm install -g .
which openemr-wiki-mcpThe last command should print a Linux path inside WSL, for example:
/home/ubuntu/.nvm/versions/node/v22.16.0/bin/openemr-wiki-mcpOpen the Command Palette and run MCP: Open User Configuration, then add:
{
"servers": {
"openemr-wiki": {
"type": "stdio",
"command": "openemr-wiki-mcp"
}
}
}If VS Code cannot find the global binary, replace openemr-wiki-mcp with the absolute Linux or macOS path returned by which openemr-wiki-mcp.
Register the local stdio server:
claude mcp add --scope user --transport stdio openemr-wiki openemr-wiki-mcpVerify:
claude mcp listIf the command is not found because the client does not load your shell profile, register the absolute binary path instead of openemr-wiki-mcp.
Config file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux/WSL: ~/.config/Claude/claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
If Claude Desktop and the MCP server run in the same Linux or macOS environment, use this local stdio configuration:
{
"mcpServers": {
"openemr-wiki": {
"command": "openemr-wiki-mcp"
}
}
}If Claude Desktop is running on Windows and the MCP server is installed inside WSL, use wsl.exe and the exact distro name:
{
"mcpServers": {
"openemr-wiki": {
"command": "wsl.exe",
"args": [
"-d",
"Ubuntu-22.04",
"-e",
"/home/your-user/.nvm/versions/node/v22.16.0/bin/node",
"/home/your-user/path/to/openemr-wiki-mcp/dist/index.js"
]
}
}
}Notes:
Replace Ubuntu-22.04 with the exact output of wsl -l -q from Windows.
Using the built dist/index.js path is more reliable than depending on the global shim.
Restart Claude Desktop after saving the config.
This repository does not include a remote HTTP MCP transport or deployment setup.
If you want to put this online, use this project as a starting point and add the pieces that a public or shared deployment needs:
remote MCP transport
authentication and access control
rate limiting
caching
deployment and monitoring
If someone wants to take this local-first implementation and evolve it into a hosted version, that is a good next step for a fork or contribution.
git pull && npm run build && npm install -g .If openemr-wiki-mcp is not found after npm install -g ., your npm global bin directory is probably not in PATH.
If Claude Code or Claude Desktop does not pick up your shell profile, use the absolute path from which openemr-wiki-mcp instead of the bare command name.
If Claude Desktop on Windows launches the server through WSL, the distro name after -d must exactly match the output of wsl -l -q, for example Ubuntu-22.04.
This is a stdio MCP server, so do not use console.log() for debugging. Write diagnostics to stderr with console.error().
MIT. See LICENSE.
Fetch developer API documentation from the OpenEMR GitHub repository. Covers the REST and FHIR APIs that are NOT documented on the wiki. Use this for anything related to FHIR, REST endpoints, authentication, or SMART on FHIR.
| Name | Required | Description | Default |
|---|---|---|---|
| doc | Yes | Which API doc to fetch: 'fhir' — FHIR R4 API resources and endpoints; 'standard' — Standard REST API (patient, encounter, etc.); 'smart_on_fhir' — SMART on FHIR launch and OAuth2 flow |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the source and scope of the fetch, but says nothing about return format, pagination, or whether network/GitHub access constraints apply. It's adequate for a low-risk read operation but not rich.
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?
Three short sentences, front-loaded with the action and source, then scope, then usage triggers. No filler or repetition of the schema.
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 single-enum-parameter fetch tool with no output schema and no annotations, the description conveys enough to call it correctly: source, coverage, and when to use it. Minor gaps remain around the returned document format.
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%: the single 'doc' parameter is fully documented in the schema, including the meaning of each enum value. The description adds no parameter detail beyond that, so the baseline of 3 applies.
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 and resource ('Fetch developer API documentation') and pins down the source (OpenEMR GitHub repository). It explicitly distinguishes its scope from the sibling wiki tools by noting it covers REST/FHIR APIs NOT documented on the wiki.
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?
Gives clear usage guidance ('Use this for anything related to FHIR, REST endpoints, authentication, or SMART on FHIR') and implicitly routes wiki-type queries elsewhere. It doesn't name a specific sibling as the alternative, so it stops short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the plain-text content of an OpenEMR wiki page. Optionally fetch a single section by heading name to avoid the 8000-character truncation limit on long pages.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Wiki page title — e.g. 'OpenEMR_FHIR_API' or 'OpenEMR 8.0.0 Users Guide'. Spaces or underscores both work. | |
| section | No | Optional section heading to fetch (case-insensitive partial match) — e.g. 'Billing' or 'Configuration'. Use this on long pages to avoid truncation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It usefully reveals two behavioral traits: output is plain text, and long pages are truncated at 8000 characters. It does not mention auth requirements, rate limits, or what happens when a title or section is not found.
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 tight sentences with zero filler; the primary action is front-loaded and the optional-section behavior follows immediately. Every clause earns its 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 low-complexity two-parameter read tool with no output schema, the description covers what is returned (plain text) and the key edge case (truncation). Minor gaps around error behavior for missing pages/sections keep it short of a 5.
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%, so both parameters are already fully documented in the schema, including the case-insensitive partial-match semantics and truncation rationale. The description adds no parameter detail beyond what the schema provides, making the baseline 3 appropriate.
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 (fetch) and resource (OpenEMR wiki page content), and names the return format (plain-text). It implicitly separates itself from search_openemr_wiki and get_users_guide_toc by being the page-content fetcher, but never names those siblings or contrasts with them explicitly.
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?
Gives a clear when-to-use condition for the optional section parameter (long pages, to avoid truncation), which is genuinely useful guidance. However it offers no routing guidance versus search_openemr_wiki or get_users_guide_toc, so the agent must infer when this tool is the right entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the table of contents from the OpenEMR 8.0.0 Users Guide. Use this to orient yourself before fetching a specific section.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the behavioral burden, but it only reveals that the tool returns a table of contents. It never states that the call is read-only, requires no authentication, or what the TOC entries look like. For a zero-parameter fetch this is a modest gap rather than a critical one.
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 short sentences, purpose first, usage second, with no padding or restating of the tool name. Every sentence earns its 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?
With no output schema and no annotations, the description covers the essentials: what is returned, which version of the guide, and how it fits into a workflow. Returning entries' shape or an indication that the TOC is static/versioned would close the remaining gap.
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 schema declares zero parameters, so there is nothing for the description to clarify; baseline 4 applies. The description correctly implies no inputs are needed.
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 and resource ('Fetch the table of contents') and pins the source to 'the OpenEMR 8.0.0 Users Guide', which separates it from the wiki and API-doc siblings. It doesn't explicitly contrast itself with search_openemr_wiki or get_openemr_wiki_page, so it stops short of a 5.
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?
'Use this to orient yourself before fetching a specific section' gives clear sequencing guidance for when to call it. No alternative tool is named for the case where the agent already knows the section or doesn't need the guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all wiki pages in a given category. Use this when search returns no results — browse by topic area instead. Useful categories: 'Developer Guide', 'User Guide', 'Configuration Guide', 'Clinic Work Flow', 'Features', 'Installation', 'Security', 'Frequently Asked Questions', 'Backup', 'User Documentation'.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category name (without the 'Category:' prefix) — e.g. 'Developer Guide' or 'Installation' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies a read-only listing, but says nothing about return size, pagination, whether subcategories are included, or category-name case sensitivity. The enumerated categories add some practical value but the behavioral picture is only partially filled in.
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 sentences, front-loaded with the purpose, followed by the usage trigger and a helpful category list. The category enumeration is long but every entry earns its place as a valid input value; there is no filler prose.
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 single required-parameter, read-only browsing tool with no output schema and full schema description coverage, the definition supplies purpose, trigger condition, and valid values — enough to call it correctly. Only the return-shape/pagination behavior is unaddressed, which is minor here.
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 the baseline is 3, but the description goes beyond the schema by enumerating ten concrete valid category values ('Developer Guide', 'User Guide', 'Configuration Guide', etc.). That enumeration meaningfully reduces the chance of a bad category value, which the schema's single example does not.
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 opens with a specific verb+resource ('List all wiki pages in a given category') and immediately scopes it against the sibling search tool by naming the browsing use case. An agent can distinguish this from search_openemr_wiki and get_openemr_wiki_page without opening either 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 gives an explicit selection condition ('Use this when search returns no results — browse by topic area instead'), which names both the trigger and the alternative behavior. That is exactly the routing guidance an agent needs between this tool and the search sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the OpenEMR wiki for documentation on any topic. Returns page titles, summaries, and URLs. Falls back to title search automatically if full-text search returns no results. Use this first to find relevant pages before fetching full content.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return (1–10, default 5) | |
| query | Yes | Search query — e.g. 'patient portal setup' or 'calendar appointment types' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses a key fallback behavior: 'Falls back to title search automatically if full-text search returns no results,' which is important for understanding results. It also states what the tool returns. However, it doesn't mention rate limits, pagination, or error conditions, which prevents a perfect score.
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 extremely concise, front-loading the purpose and usage in two sentences with zero waste. Every sentence earns its 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?
Given no annotations, no output schema, and a simple 2-parameter tool, the description covers purpose, usage sequencing, return format, and fallback behavior. It's nearly complete, though it could mention rate limits or that results are limited to 10.
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%, so the schema already fully documents both parameters (query and limit) with examples and constraints. The description adds no additional parameter syntax or meaning beyond what the schema provides. Baseline score of 3 is appropriate.
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 states a specific verb (Search) and resource (OpenEMR wiki) and explicitly names the scope ('documentation on any topic'). It distinguishes itself from siblings by positioning itself as the entry point before fetching full content.
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 provides an explicit sequencing instruction: 'Use this first to find relevant pages before fetching full content.' This clearly directs the agent to use this tool before alternatives like get_openemr_wiki_page, establishing both when to use it and when to use other tools.
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_openemr_api_docsget_openemr_wiki_pageget_users_guide_toclist_wiki_pages_by_categorysearch_openemr_wikiScored across 5 tools
Each tool has a distinct role: search (discovery), get_page (content retrieval), get_toc (orientation), get_api_docs (developer reference), and list_by_category (browse fallback). There is mild overlap between search_openemr_wiki and list_wiki_pages_by_category as discovery mechanisms, but descriptions clearly explain when to prefer each.
All tools follow a consistent snake_case verb_noun pattern (search_, get_, get_, get_, list_). The naming is predictable and readable throughout, with no mixing of conventions.
Five tools is well-scoped for a read-only documentation retrieval server, with each tool earning its place (search, fetch, TOC, API docs, browse). No redundant or filler tools.
The surface covers discovery, content fetching, section-level fetching, API docs, and category browsing, which is solid for a documentation server. A minor gap is the lack of a generic way to list a single page's section headings, though the Users Guide TOC partially mitigates this.
MCP server for querying Forkast documentation
MCP server for accessing curated awesome list documentation
MCP server for opencode documentation, generated by doc2mcp.
Token-free MCP server for structured RevoGrid Core, Pro, and Enterprise knowledge retrieval.
