Transporty

urirun trzyma kontrakt URI oddzielnie od transportu. Ten sam URI można wywołać lokalnie, przez endpoint usługi albo przez orkiestrator flow. Registry, JSON Schema i bramka polityki to kontrakt; transport jedynie przenosi {uri, payload} tam, gdzie runtime to wykonuje.

Lokalnie i shell

• local-function — wywołuje funkcję w procesie zarejestrowaną przez kod.
• argv-template — renderuje listę argv i wykonuje ją bez shella.
• shell-template — renderuje string powłoki i wymaga jawnej zgody polityki.

Kolejka i serverless

• Konsument kolejki/zdarzeń mapuje wiadomość z tematu na uruchomienie URI (MQTT/NATS/Kafka).
• Funkcja serverless to czyste handler(event), które per żądanie uruchamia URI, z registry skompilowanym w pamięci.

Docker

Przykłady Docker używają targetów URI jako nazw usług:

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

HTTP i przeglądarka

Backend ładuje dokument bindingów, renderuje formularze URI i wykonuje je przez POST /api/run. Z tego samego registry można wystawić logi, ostatnie wywołania, narzędzia MCP i karty A2A — więc akcje frontendu używają tych samych nazw URI co backend. To dokładnie ten sam kontrakt, którego używa IFURI w swoim flow.

gRPC

urirun.v2_grpc udostępnia mały interfejs RPC: listowanie tras, wywołania unary i strumieniowe.

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

MCP i A2A

Ponieważ bindingi zawierają JSON Schema, registry można rzutować na:

• MCP tools/list
• MCP tools/call
• umiejętności karty agenta A2A

Wykonanie i tak przechodzi przez tę samą bramkę polityki urirun.