Tool Execution Workflow

Every DPU tool call passes through the same narrow execution path, whether the agent is hosted by Ploinky or by the standalone Model Context Protocol (MCP) server.

Why The Execution Path Is Narrow

The agent should not have multiple competing ways to validate input, extract auth context, or mutate storage. The Model Context Protocol (MCP) wrapper exists so those concerns are handled in one place before domain logic runs.

Practical Request Flow

A DPU tool call starts in mcp-config.json, which maps the tool to tools/dpu_tool.sh. That wrapper launches tools/dpu_tool.mjs, which reads the MCP envelope from stdin, extracts the verified metadata.invocation grant, validates the normalized input, and dispatches into the corresponding function in lib/dpu-store.mjs.

Inside dpu-store.mjs, the actor is resolved against the permissions manifest, user state is materialized if needed, and the requested operation runs under the storage lock when it mutates state. The final response is then serialized back to the MCP caller.

What Stays Stable Across Runtime Modes

The hosting mode changes how the request reaches the agent, not how the domain logic behaves. The standalone server still loads mcp-config.json, still routes through dpu_tool.mjs, and still executes the same storage and access control list (ACL) code as the embedded runtime.

Concurrency note: mcp-config.json sets maxParallelTasks to 1, and mutating storage operations also run through the DPU file lock.