home / mcp / mcp-pif server

MCP-PIF Server

An experimental MCP implementation of the personal intelligence framework (PIF) in Haskell.

Installation
Add the following to your MCP client configuration file.

Configuration

View docs
{
  "mcpServers": {
    "hungryrobot1-mcp-pif": {
      "command": "cabal",
      "args": [
        "run",
        "mcp-pif"
      ],
      "env": {
        "MCP_DEBUG": "1"
      }
    }
  }
}

MCP-PIF is a JSON-native lambda calculus runtime that enables language models to evolve tools through metaprogramming while keeping execution deterministic and fuel-bounded. It exposes a lightweight set of primitives for pure computation and safe tool management, enabling you to explore metaprogramming workflows with clearly defined boundaries.

How to use

To use MCP-PIF, you run the server locally and connect an MCP client that can send tool management and evaluation requests. You can create new tools that live in the server’s registry, execute tools, or inspect existing tools and their source. The system supports a clear separation between tool creation (which mutates the registry) and tool execution (which runs tools in a deterministic, isolated environment). You control the interaction flow through the MCP client, handling the JSON-based protocol via standard input/output or through a dedicated transport that your client library provides.

How to install

# prerequisites: install a Haskell toolchain (GHC and Cabal)
# ensure Cabal is up to date
cabal update

# Build the MCP-PIF server
cabal build

# Run in debug mode to see detailed evaluation tracing
MCP_DEBUG=1 cabal run mcp-pif
```

To run without debug tracing, omit MCP_DEBUG when starting the server:
```
cabal run mcp-pif
```

If you prefer to start from a clean state after building, you can stop the process and start again with the same commands.

Configuration and runtime behavior

MCP-PIF runs as a server that communicates with an MCP client over a defined protocol. It accepts a registry of tools, supports creating new tools through the evolve operation, and executes tools via the run operation. The server enforces a finite evaluation budget (fuel) to guarantee termination, and it maintains a clear separation between pure computation and potential side effects. You can enable verbose evaluation tracing by setting MCP_DEBUG, which will show each evaluation step, environment keys, closures, and tool lookups.

Security and safety notes

The evaluation model is fuel-bounded and pure, meaning each evaluation consumes a bounded amount of steps without performing I/O or external effects during computation. Tools are isolated in the runtime, and registry changes occur only through explicit evolve operations. Variables from user code are preserved across evaluations, while system-related context is sanitized during eval to prevent leakage of tool metadata.

Examples of typical workflows

- Create a new tool that implements a simple computation or transformation, then use the run operation to execute that tool with your input. - Inspect existing tools to understand their interfaces and how they are defined. - Use the help tool to discover documentation for primitives and system tools.

Troubleshooting

If you encounter issues starting the server, verify that the Haskell toolchain (GHC/Cabal) is installed and that all dependencies are up to date. Ensure you run the exact start command with the appropriate environment variables and that you have the necessary permissions to execute the binary produced by cabal. If the server starts but the MCP client cannot connect, check that the client is configured to communicate with the server’s stdin/stdout transport or the transport method you are using and that the tool registry is initialized correctly before issuing evolve or run requests.

Notes

You can selectively enable debugging to trace the evaluation process, including steps, environment state, and tool code lookups. The system intentionally keeps the core evaluation pure and deterministic, with a clear boundary between runtime evaluation and tool registry modification.

Other sections

For ongoing development and experimentation, you may want to explore adding new tools, adjusting tool descriptions, and analyzing tool code via the code_of primitive. Always design tools to stay within the fuel budget and avoid introducing side effects into pure evaluation paths.

Available tools

evolve

Create new tools and mutate the tool registry through explicit, authored tool definitions.

run

Execute tools or inline lambda expressions against inputs, returning results and handling continuations within the MCP framework.

list

Show all registered tools and their descriptions from the current registry.

help

Display documentation for primitives and system tools to guide usage of MCP-PIF features.