Skip to main content
Register an MCP server on the Community Hub so you and other clinicians can install it from the Isa Hub. Once installed, its tools are available to the Primary Agent in Patient Chat alongside the Primary Agent’s other tools.
Registering an MCP server is a technical workflow — you need to know the server’s transport URL (or, for a local server, its package config) and the configuration it requires. If you’re not sure where to start, ask in the Isaree Discord.
What “registering” means: on the Community Hub you’re publishing how to reach the server, not the server itself. For a remote server — a public service you’re pointing to, or one you’ve deployed yourself — that’s the transport URL, the configuration it needs, and the metadata that helps others discover it. For a local server, it’s the package config Isa uses to run the server on the user’s own machine. You can register from scratch or duplicate an existing MCP server on the Community Hub and adapt it.

​
Prerequisites

  • A Community Hub account
  • An MCP server to publish — a remote one you can point to (public or self-hosted, reachable from the devices Isa runs on), or a local package (npm, PyPI, OCI, NuGet) that runs on the user’s machine
  • The configuration the server expects (API keys, base URLs, tenant IDs) so you can declare it on the Community Hub

​
Open the form

Sign in to the Community Hub and register a new MCP server from the Build menu in the top navigation. The form opens with the MCP server’s fields ready to fill in.

​
Name your server

Your server’s name is how other clinicians find it in the Isa Hub — prefer something concrete like EMR Lab Lookup over My MCP Server.

​
Describe the intended use

The Intended Use field is what other clinicians see when they find your MCP server in the Isa Hub. Write one or two sentences on what tools the server exposes, what system it connects to, and when to reach for it.

​
Pick the server type

  • Remote (HTTP) — an HTTP-based server reachable via URL. The Community Hub can verify connectivity and discover its tools automatically.
  • Local Package — a locally installed package (npm, PyPI, OCI, or NuGet) that runs on the user’s own machine and talks to Isa via stdio. Its tools are attested on the client when it runs — there’s no manual attestation step. Local servers work in Isa on the Mac only.
The next sections cover the remote fields. For a local server, skip ahead to Publish a local server.

​
Set the transport URL

Enter the endpoint where your MCP server lives — this is what the Primary Agent calls when it uses one of the server’s tools. Pick the transport — streamable-http (the default) or SSE — and use HTTPS; plain HTTP is rejected.

​
Pick a category and add keywords

  • Category — Admin or Clinical.
  • Keywords — comma-separated tags that help others find your MCP server when searching. Add a few that match the system it connects to, the data it exposes, or the use case (e.g. lab, EMR, epic).
  • Icon URL — optional square logo shown on the server card and detail page.

​
Define the configuration schema

Declare the values your MCP server needs to work — an API key, a base URL, a tenant ID, anything the server can’t infer on its own. Expose only what’s actually required. Add a config field for each value the server needs. Each field has:
  • Field Key — the key sent to the server. Use snake_case (api_key, not API Key).
  • Title — the label for the field.
  • Type — the data type (String, Number, Boolean).
  • Input Type — how the field is rendered (Text, Secure Text, Dropdown, Toggle, URL).
  • Description — a short hint about what value to provide.
  • Placeholder — example text shown inside the empty field.
  • Default Value — pre-filled value if there’s a sensible default.
  • Secret — tick if the field holds a secret like an API key. Secrets are hidden in the UI and handled separately from non-secret values.
  • Required — tick if the server can’t run without this field.
  • Display Order — controls the order the fields appear.

​
Set HTTP headers

Headers are the only place to configure authentication — nothing is injected automatically, so a server that expects a bearer token won’t receive one unless you define the header here. Add each header the server needs, and use {fieldName} to reference a configuration schema key — the value the user enters at install time is filled in when Isa calls the server.

​
Register the server

Once the required fields — Server Name, Intended Use, and Transport URL — are filled in, add the server. It now exists on the Community Hub and is ready to install from the Isa Hub.

​
Publish a local server

Switch Server Type to Local Package and the URL, header, and configuration schema fields give way to a single Server Config box. Paste your MCP server config — the same JSON you’d add to Claude Desktop, Cursor, or Cline:
The config is stored and run as-is, so replace machine-specific paths (/Users/you/…) and secret values before you publish — the entry has to work on someone else’s machine. Two things the person installing it needs to know:
  • Mac only. A local server runs on the user’s own machine via stdio — that works in Isa on the Mac, not on iPhone or iPad. See MCP servers.
  • The runtime must be installed. Isa runs the command from the config, so whatever it calls — Node for npx, Python for uvx — has to be installed on the user’s Mac.

​
See how the tools become available

Once a clinician installs your MCP server in Isa, its tools become available to the Primary Agent in Patient Chat. The user doesn’t invoke the MCP server directly — they chat with the Primary Agent, which picks up the tools automatically.
Only the Primary Agent can call MCP servers today — Agents cannot (yet). If you’re building an Agent that needs external tools, plan around the Primary Agent being the entry point.

​
Next

MCP servers

Understand what MCP servers are and how the Primary Agent reaches them.

Primary Agent

Set the agent in Isa that calls your MCP server’s tools.

Build an agent

Build an Agent for Patient Chat or Workspace.