Pidgeon’s public beta gives engineers three ways into the same local-first
workflow: the .NET engine packages, the pidgeon command-line tool, and a thin
Model Context Protocol adapter. Start with the CLI unless you are embedding
the engine into an application or connecting an MCP client.
These are beta packages. Pin the exact versions below, review the known limits,
and test the workflow before relying on it in a controlled environment. The
desktop products are distributed separately from these community packages.
Choose an entry point
Run the CLI locally
Install the .NET tool:
Generate a deterministic synthetic HL7 v2 message, validate it, and preserve
the output for review:
The seed makes the generated example repeatable. The validation result is
evidence about that input and the supported rules, not a certification or a
guarantee about a production interface.
Embed Core and Baseline
Add both packages when an application needs the public engine and its admitted
offline resource set:
Register the baseline package explicitly with AddPidgeonBaselineData() in
your dependency-injection composition. Core does not silently reach into the
legacy data tree, and an absent required data package degrades with a typed
result rather than pretending the resource exists.
Connect an MCP client
Use the governed adapter package:
Do not substitute @pidgeonhealth/mcp. That name is a contained legacy
package and is not part of the governed public beta release train.
Verify before expanding
- Pin the package versions in source control.
- Run a synthetic example without patient data.
- Review the generated output and validation result.
- Record the command, version, seed, and result when repeatability matters.
- Report a reproducible issue through the relevant
Pidgeon Health repository.
Next, read the test-data field guide
or the human-and-agent workflow map. 