LinkedRun
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@LinkedRunSubmit a task graph: train a model, then cluster its embeddings and compute ARI."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
LinkedRun
LinkedRun is a persistent local Task–Artifact DAG executor exposed as an MCP server.
Tasks consume immutable artifacts and produce immutable artifacts. A new task may depend on outputs from tasks submitted in the same batch or from any earlier submission. The graph therefore grows incrementally instead of being bounded by one workflow run.
LinkedRun is deliberately a mechanism-only kernel. It does not know what training, evaluation, cell clustering, ARI, a model, or an experiment protocol means. It also does not predict resource requirements: the submitting Agent declares resources and LinkedRun trusts that declaration, subject only to machine-capacity limits and runtime reservation.
Why
The intended split is:
task Agent: decides what to run and declares resource needs;
project tooling: predicts resources, validates models, builds workflows, computes metrics;
LinkedRun: persists dependencies, waits without busy polling, reserves declared resources, runs and cancels processes, commits artifacts, and records durable events.
Core model
Artifact -> Task -> Artifact
\\-> Task -> ArtifactA data dependency is also an execution dependency. Pure ordering constraints are available through
after when no artifact is consumed.
MCP tools
submit_tasksubmit_graphget_tasklist_taskscancel_taskretry_tasklist_artifactsget_artifactget_graphget_eventswatch_eventsresource_status
watch_events is a durable long-poll interface: clients resume from the last event_id, so they do
not need tight polling loops. A future release can map execution handles onto the MCP
io.modelcontextprotocol/tasks extension when host support is sufficiently common.
Install
pip install -e .Python 3.11+ is required. LinkedRun targets MCP Python SDK v2 / MCP 2026-07-28.
Start
Persistent local HTTP service (recommended when several Agents/clients need the same graph):
export LINKEDRUN_HOME="$HOME/.linkedrun"
linkedrun --transport streamable-http --host 127.0.0.1 --port 8765The MCP endpoint is http://127.0.0.1:8765/mcp.
For a host that manages the MCP process itself:
linkedrun --transport stdioSQLite state and content-addressed artifacts are stored below LINKEDRUN_HOME.
Submit one task
Conceptually, an MCP call to submit_task looks like:
{
"name": "train",
"command": ["python", "train.py"],
"outputs": {
"model": "outputs/model.pt",
"embedding": "outputs/embedding.zarr"
},
"resources": {
"cpu_cores": 8,
"memory_bytes": 34359738368,
"gpu_count": 1,
"gpu_mode": "exclusive"
}
}Commands are argv arrays, not shell strings. Use ["bash", "-lc", "..."] explicitly when shell
semantics are required.
Same-submission dependencies
submit_graph supports local references:
{
"tasks": [
{
"name": "train",
"command": ["python", "train.py"],
"outputs": {"embedding": "outputs/embedding.zarr"}
},
{
"name": "cluster",
"command": ["python", "cluster.py"],
"inputs": {"embedding": "@train/embedding"},
"outputs": {"clusters": "outputs/clusters.parquet"}
},
{
"name": "ari",
"command": ["python", "ari.py"],
"inputs": {"clusters": "@cluster/clusters"}
}
]
}The complete batch is registered atomically after cycle detection.
Cross-submission dependencies
If an older training task has ID task_abcd and produced embedding, a task submitted later may use:
{
"inputs": {
"embedding": "task:task_abcd/artifact:embedding"
}
}A committed artifact can also be referenced directly:
artifact:art_abcdThe graph is therefore persistent and incremental: no top-level "workflow run" boundary is required.
Runtime contract
Before a task starts, LinkedRun creates a private attempt directory and sets:
LINKEDRUN_TASK_ID
LINKEDRUN_ATTEMPT_ID
LINKEDRUN_WORKDIR
LINKEDRUN_OUTPUT_DIR
LINKEDRUN_INPUT_<NAME>Each input is a read-only-by-convention symlink to immutable content-addressed storage. Declared output
paths must remain inside the attempt directory. On successful process exit, outputs are hashed and
committed to the artifact store before the task becomes SUCCEEDED.
Task states
PENDING -> READY -> RUNNING -> SUCCEEDED
\\----> FAILED
PENDING --------------------> BLOCKED (upstream failed/missing artifact)
PENDING --------------------> UNSCHEDULABLE (declared request exceeds machine capacity)
PENDING/RUNNING ------------> CANCELEDRetry increments a per-task generation. An old attempt may not commit after its generation becomes stale; this is the first implementation of LinkedRun's fencing rule.
Resource policy
LinkedRun does not infer resource usage. It accepts:
cpu_cores
memory_bytes
gpu_count
gpu_mode=exclusive
gpu_memory_bytes_hint
walltime_seconds
scratch_bytesgpu_memory_bytes_hint is evidence/metadata only in v0.1. GPU scheduling is exclusive-device
allocation. CPU and memory are reservation accounting; walltime_seconds is enforced. OS-level hard
CPU/memory/scratch isolation is intentionally left for a later sandbox module rather than adding
experiment-specific admission logic to the kernel.
Current v0.1 boundaries
Implemented:
SQLite/WAL persistent task, attempt, dependency, artifact, and event state;
atomic same-batch graph registration and cycle detection;
cross-submission task/artifact references;
background dependency scheduling;
caller-declared CPU/memory/GPU reservations;
exclusive GPU assignment through
CUDA_VISIBLE_DEVICES;subprocess execution, cancellation, walltime limit;
content-addressed immutable file/directory artifacts;
durable events and reconnectable long polling;
retry generation/fencing;
stdio and Streamable HTTP MCP transports.
Not yet hardened:
OS cgroup/job-object hard limits for CPU, memory, and scratch;
surviving a machine/kernel crash while reattaching already-running children (v0.1 safely marks an interrupted attempt failed and requires explicit retry);
authentication for non-local HTTP exposure;
MCP Tasks extension mapping;
artifact garbage collection and retention policy;
remote workers or distributed scheduling (not currently a goal).
These omissions are deliberate: v0.1 establishes the minimal kernel boundary before adding optional mechanisms.
Development
python -m venv .venv
. .venv/bin/activate
pip install -e '.[dev]'
pytest -q
ruff check .Architecture rule
If a feature can be moved outside LinkedRun without breaking generic task persistence, dependency scheduling, process lifecycle, artifact commit, or event durability, it should stay outside LinkedRun. In particular, model/protocol validation, resource prediction, experiment semantics, metric semantics, and formal result publication are external concerns.
This server cannot be installed
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
Agent-native collaboration network: orchestrate a team of long-running agents from any MCP client.
Workflow diagnostics, capability routing, and x402 settlement for MCP-compatible agents.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ShiroganeKaichou/LinkedRun'
If you have feedback or need assistance with the MCP directory API, please join our Discord server