urirun

Transports

urirun keeps the URI contract separate from the transport. The same URI can be called locally, through a service endpoint, or by a flow orchestrator. The registry, JSON Schema and policy gate are the contract; a transport only moves {uri, payload} to where v2.run executes it.

v2/examples/transports drives one registry over five transports (in-process, queue, serverless, HTTP, gRPC) and ships a one-command scan_and_run.py.

Local and shell

Queue and serverless

Docker

Docker examples use URI targets as service names:

python://python-worker/text/normalize
node://node-worker/text/slugify
shell://shell-worker/report/write

See v2/examples/docker_uri_flow for a Compose flow where services publish bindings and an orchestrator runs a multi-step URI flow.

HTTP and browser

The HTML example in v2/examples/html_uri_app loads a binding document, renders URI forms, and calls a Python backend through POST /api/run.

The backend can expose logs, recent calls, MCP tools, and A2A cards from the same registry, so frontend actions use the same URI names as backend actions.

gRPC

urirun.v2_grpc provides a small RPC surface for route listing, unary calls, and stream-style calls. Install the optional dependency set when using it:

pip install "urirun[grpc] @ git+https://github.com/tellmesh/urirun.git@main#subdirectory=adapters/python"

v2/examples/multi_transport is a Docker stack that mixes HTTP and gRPC workers, auto-generates one registry from their /routes and ListRoutes, detects route conflicts, and runs a cross-environment flow whose steps land on both transports.

MCP and A2A

Because v2 bindings include JSON Schema, the registry can be projected into:

Execution still goes through the same urirun policy gate.