- Windows. The server is a Windows build (.NET 10).
- PowerShell 7 (pwsh). Every tool call runs the PesterForge module in a pwsh child process started with
-NoProfile -NonInteractive, so your profile scripts never interfere with a result. - The PesterForge module. By default the server resolves the bare module name
PesterForgethroughPSModulePath. If your copy lives somewhere else, pointPESTERFORGE_MODULE_PATHat itsPesterForge.psd1. - PesterForge.MCP itself. [NEEDS KEITH: distribution method. No public download, package, or installer for PesterForge.MCP is verified as of this writing. This bullet needs the real link once one exists.]
PesterForge MCP is a stdio server by default: your MCP client starts PesterForge.MCP.exe as a child process and talks JSON-RPC over stdin/stdout. No command-line arguments are required or read for configuration. Every setting is an environment variable with the PESTERFORGE_ prefix, set on the child process by your client:
| Variable | What it does | Default |
|---|---|---|
PESTERFORGE_TRANSPORT | stdio or http | stdio |
PESTERFORGE_PORT | Port for HTTP mode | 5150 |
PESTERFORGE_MODULE_PATH | Path to PesterForge.psd1 | Bare name PesterForge, resolved via PSModulePath |
PESTERFORGE_MCP_CONFIG | Path to the server's one config file | PesterForge.MCP.config.json beside the exe |
PESTERFORGE_ENTITLEMENT_CODE | Entitlement code for gated tools | (none) |
So a client entry needs three things: the path to PesterForge.MCP.exe as the command, no arguments, and any PESTERFORGE_* variables you want to set.
[NEEDS VERIFICATION: exact client config. The copy-paste JSON block for Claude Code, Claude Desktop, and other clients belongs here once it has been verified against the shipped server, per the no-guessed-config rule. Until then, the facts above are the complete contract any MCP client entry has to satisfy.]
You can tell it started: the server prints PesterForge.MCP (stdio) ready. to stderr. All logging goes to stderr, and stdout carries JSON-RPC lines only. The server's conformance gate checks that separation on every run; the passing step reads "stdio clean: stdout carried JSON-RPC lines only, all session -- no contamination".
Prefer HTTP? Set PESTERFORGE_TRANSPORT=http and the server serves MCP at /mcp, with a /health endpoint, on PESTERFORGE_PORT.
Ask your client, in plain English:
Generate Pester tests for the function in .\Get-InventoryReport.ps1
Your agent calls the generate_tests tool and comes back with Pester tests for that function. The full tool list, with arguments and behavior for each, is on the tool reference page.
For a quick liveness check, ask for the server version. get_version returns the provenance block that every tool response also carries:
{
"pesterForgeVersion": "2.0.0",
"mcpServerVersion": "1.0.0",
"schemaVersion": "1.0",
"pwshVersion": "7.6.3"
}
The server reads the module version live from the manifest on your machine each time. Every response is stamped with these four fields, so you can tie any answer back to the module version that produced it.
- PesterForge MCP overview: what the server is and why you would put it in front of your agent.
- Tool reference: every tool, its arguments, and what it returns.
- PesterForge: the module the server wraps.