MCP overview
Two Model Context Protocol surfaces — one lets an agent build workflows, the other turns your workflows into the agent's tools.
GoRunner speaks the Model Context Protocol natively, in both directions:
The build server
POST /mcp/build — 12 tools that let any MCP client search pieces, author, validate, publish, run and diagnose workflows in your workspace.
Workflows as tools
POST /mcp/tools — publish a workflow with the MCP Tool trigger and it becomes a tool your agent calls by name, like look_up_order_total.
Both endpoints live on your workspace URL, authenticate with the same grt_ bearer tokens as the HTTP API, and speak streamable HTTP JSON-RPC — the transport every current MCP client supports.
Built as a client of its own API
The build server's tools do not reach into the database — each one constructs a real HTTP request and serves it through the same router a browser hits, carrying your token's own Authorization header. The consequence is worth spelling out: MCP grants an agent exactly what the token's scopes grant, nothing more. A run:read token can list runs through MCP and is refused workflow writes through MCP, with the same FORBIDDEN the HTTP API answers. There is no second authorization system to audit or to drift.
Safety posture for agent-driven writes
Three facts the per-tool tables can't carry: nothing an agent creates is live until something publishes it; every run-class tool takes an idempotencyKey so a timed-out call can be retried without running twice; and agent-initiated runs are recorded as trigger mcp, labelled "Agent" in the runs list — attribution is a recorded fact, not a client claim.