mhl-serving

mhl serving

Assumes the mhl-language and mhl-workflows skills. mhl serve turns a directory of .mh files into a server with no server code: each pipeline, workflow or alias becomes one MCP tool or A2A skill, published by the file that declares it. This skill is the server side. Calling someone else's server is extension mcp, covered in mhl-tools.

Design the workflow as an API

The declaration is the tool contract, so write it for the calling model:

enum Severity { low, high }

type TriageInput = { title: string, body: string, severity?: Severity }
type TriageOutput = { priority: string, reason: string }

tool Rules {
    priority(title: string): string -> if (title.contains("outage")) "urgent" else "normal"
}

// The description is all a calling model sees, so state what the tool does.
workflow TriageIssue(req: TriageInput): TriageOutput {
    description: "Classifies an incoming issue and explains the priority."

    var priority = "normal"

    step Classify {
        self.priority = Rules.priority(req.title)
    }

    output: {
        priority: priority
        reason: "matched on title: ${req.title}"
    }
}

test triage_issue {
    describe outage_is_urgent {
        var result = TriageIssue.run(inputs: {title: "api outage", body: "down"})
        are_equal(result.output.priority, "urgent")
    }
}

Then shape the surface:

• Mark helpers internal workflow. Publish only what callers should invoke.
• Use aliases to publish one flow as several narrow tools: workflow Delivery = ArtifactFlow with { level: Level.delivery } { description: "..." }.
• Always declare output: on a served workflow. It keeps intermediate state, prompts and tokens out of responses.
• A workflow imported by several files is published once, by its declaring file.