Paper deep dive
Beyond Static Endpoints: Tool Programs as an Interface for Flexible Agentic Web Services
Mugeng Liu, Shuoqi Li, Yixuan Zhang, Yun Ma
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 96%
Last extracted: 6/21/2026, 4:54:14 AM
Summary
The paper introduces TOOLPRO, a novel interface for LLM-based agents that replaces static API endpoints with executable 'tool programs.' While traditional static endpoints require agents to perform multiple round-trips for complex workflows (loops, conditionals), TOOLPRO allows agents to submit a single, structured program to a service-side runtime. This approach addresses three key challenges: executability (via constraint-guided construction and compiler feedback), side-effect safety (via effect-aware replay for exactly-once WRITE semantics), and efficiency (via a profile-driven policy). Experimental results show that TOOLPRO can reduce end-to-end latency by up to 53.4% and client-side traffic by up to 96.1% compared to stepwise endpoint calling.
Entities (8)
Relation Signals (5)
Tool Program â contains â READ
confidence 100% ¡ distinguish state-preserving READ operations from state-modifying WRITE operations
Tool Program â contains â WRITE
confidence 100% ¡ distinguish state-preserving READ operations from state-modifying WRITE operations
TOOLPRO â implements â Tool Program
confidence 100% ¡ We present TOOLPRO, which represents an agent's tool intent as an executable tool program
TOOLPRO â uses â WebAssembly
confidence 100% ¡ We instantiate TOOLPRO over MCP-style services with WebAssembly sandboxing
LLM-based Agent â uses â TOOLPRO
confidence 90% ¡ In the agentic web era, LLM-based agents increasingly invoke web services as tools... We present TOOLPRO...
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:In the agentic web era, LLM-based agents increasingly invoke web services as tools, yet most interfaces remain \emph{static endpoints} that poorly express long-horizon workflows with loops, conditionals, joins, and retries. We present ToolPro, which represents an agent's tool intent as an \emph{executable tool program} that compactly encodes multi-step service interactions with explicit effect types. ToolPro combines constraint-guided program construction, effect-aware replay for exactly-once state-modifying calls, and a profile-driven policy that decides when program execution outperforms stepwise calling. We instantiate ToolPro over MCP-style services with WebAssembly sandboxing and evaluate it on diverse workflows of real-world applications. ToolPro reduces end-to-end latency by up to 53.4\% and client-side traffic by up to 96.1\%, with larger gains under higher network latency and workflow complexity.
Tags
Links
- Source: https://arxiv.org/abs/2606.19992v1
- Canonical: https://arxiv.org/abs/2606.19992v1
Trouble viewing inline? Open PDF directly â
Full Text
58,705 characters extracted from source content.
Expand or collapse full text
Beyond Static Endpoints: Tool Programs as an Interface for Flexible Agentic Web Services Mugeng Liu 1 Shuoqi Li 2 Yixuan Zhang 1 Yun Ma 3 Abstract In the agentic web era, LLM-based agents increas- ingly invoke web services as tools, yet most in- terfaces remain static endpoints that poorly ex- press long-horizon workflows with loops, condi- tionals, joins, and retries. We present TOOLPRO, which represents an agentâs tool intent as an ex- ecutable tool program that compactly encodes multi-step service interactions with explicit effect types. TOOLPRO combines constraint-guided pro- gram construction, effect-aware replay for exactly- once state-modifying calls, and a profile-driven policy that decides when program execution out- performs stepwise calling. We instantiate TOOL- PRO over MCP-style services with WebAssembly sandboxing and evaluate it on diverse workflows of real-world applications. TOOLPRO reduces end-to-end latency by up to 53.4% and client-side traffic by up to 96.1%, with larger gains under higher network latency and workflow complexity. 1. Introduction LLM-based agents (Yao et al., 2023; Schick et al., 2023; Liu et al., 2024; Qin et al., 2024; Liu et al., 2026) are in- creasingly expected to complete long-horizon workflows by orchestrating web services. Yet most services are still ex- posed through static API endpointsâan interface designed for single-shot queries, not for procedural, multi-step in- teraction. When a task requires control flow (e.g., loops, conditionals), intermediate bindings, or intent-dependent data access, an agent must externalize the workflow into a brittle sequence of endpoint calls interleaved with multi- round reasoning (Yao et al., 2022; Deng et al., 2023; Zhou 1 School of Computer Science, Peking University, Beijing, China 2 School of Software & Microelectronics, Peking Univer- sity, Beijing, China 3 Institute for Artificial Intelligence, Peking University, Beijing, China.Correspondence to: Yun Ma <mayun@pku.edu.cn>. Proceedings of the43 rd International Conference on Machine Learning, Seoul, South Korea. PMLR 306, 2026. Copyright 2026 by the author(s). et al., 2024). The stepwise interface scales poorly, multiply- ing network turns, systematically over- and under-fetching data, and triggering cascading retries with inconsistent side effects upon partial failure. Our insight is that the inefficiency is fundamentally repre- sentational, as shown in Figure 1. Endpoint sequences are a weak interface for expressing tool intent, because they fragment a coherent multi-step plan into local decisions conditioned on intermediate responses. As a result, both clientâservice round trips and agent reasoning rounds grow with the number of procedural steps, while failures amplify as a single mismatch can cascade into retries and state in- consistencies. Agentic workflows need an interface that can express âperform this multi-step interactionâ as a sin- gle, composable object whose execution can be delegated, optimized, and checked. To this end, we propose tool programs as an executable representation of tool intent. These programs compactly en- code a multi-step service interaction, complete with control flow and intermediate bindings. Furthermore, they feature explicit effect types that distinguish state-preserving READ operations from state-modifying WRITE operations. Rather than repeatedly selecting endpoints on the client, an agent synthesizes a tool program and delegates its execution to a controlled service-side runtime. Making intent first-class en- ables three capabilities that static endpoints do not provide, including (i) turn reduction by consolidating multi-step in- teractions into fewer network round trips, (i) effect-aware execution by enforcing different semantics for READ ver- sus WRITE, and (i) safe re-execution under repair without duplicating side effects. Realizing tool programs in practice raises three challenges: (1) Executability. LLM-produced programs may fail to compile or crash at runtime under a typed, sandboxed substrate. (2) Side effects under repair. Partial success before failure makes naive re-execution du- plicate WRITEs and corrupt service state. (3) When to consolidate. For short workflows or low-latency networks, program construction overhead can outweigh the savings from turn reduction. By addressing these challenges, we present TOOLPRO, the first agentic web service runtime that operationalizes Tool Programs as an interface for flexible agentic web services. 1 arXiv:2606.19992v1 [cs.SE] 18 Jun 2026 Beyond Static Endpoints: Tool Programs as an Interface for Flexible Agentic Web Services Client Agent MCP Server list_hotels() get_hotel_details(hid) * n book_hotel(best_hotel_id) Client Agent MCP Server hotels = [] forhid inlist_hotels(): hotels.append(get_hotel_details(hid)) best_hotel= sorted_by_rate(hotels)[0] book_hotel(best_hotel['id']) Bookthe highest rating hotel. Task Instruction Static MCP Endpoint 1+n+1 Requests / Reasoning Rounds ToolPro 1 Request / Reasoning Round Dubai Sydney Reasoning Round (R)* 1 R*n R*1 R*1 Figure 1. From static endpoints to tool programs. Stepwise endpoints force the agent to repeatedly call endpoints and re-prompt to realize control flow. Tool programs (TOOLPRO) instead package a multi-step interaction as one executable object with explicit effects, enabling service-side execution and safe re-execution under repair. Specifically, to improve executability, TOOLPRO introduces constraint-guided program construction, which combines lightweight formatting constraints with compiler/runtime feedback, and resolves common failures via service-side repair to avoid repeated clientâserver back-and-forth. To control side effects, TOOLPRO enforces effect-aware replay that provides exactly-once semantics for WRITE operations across iterative repair and re-execution. To decide when consolidation is worthwhile, TOOLPRO applies a profile- driven consolidation rule that adaptively selects between stepwise calling and program execution. We implement TOOLPRO over MCP-style web services us- ing WebAssembly sandboxing and evaluate it on diverse workflows within realistic applications. TOOLPRO reduces end-to-end latency by up to 53.4% and client-side traffic by up to 96.1%, with gains increasing under higher network la- tency and workflow complexity. These results highlight that TOOLPRO lays an important foundation for agent-facing service interfaces in the emerging agentic web. This paper makes the following contributions. 1 â˘We identify static endpoints as a representational bottle- neck for agentic web workflows and propose tool pro- grams as an agent-facing service interface. â˘We present TOOLPRO to make tool programs practical by addressing core challenges. It employs constraint-guided construction for executability, effect-aware replay with exactly-once semantics for safe repairs, and a profile- driven policy for adaptive consolidation. â˘We evaluate TOOLPRO on real applications and work- flows, demonstrating substantial reductions in latency and client-side traffic, highlighting a promising direction to build an efficient agentic web. 1 Code is publicly available athttps://github.com/m orgen52/toolpro_icml26. 2. Problem Formulation We study agentic web-service tool use where a client-side LLM agent orchestrates server-side web services to com- plete procedural workflows. A tool-facing service exposes a set of endpointsEover an internal service states. A call is CALL(e,a)foreâEand argumentsa, returning an output o(or an error) and possibly updatings. We focus on proce- dural agentic workflows that inherently require control flow, intermediate bindings, and intent-dependent data access. Bottleneck: stepwise endpoint sequences. With static end- points, an agent realizes an intent via a stepwise interaction loop. At stepi, it decides the next call(e i ,a i )conditioned on the task context and past observations(o 1 ,...,o iâ1 ), then issues the request and observeso i . This yields a call se- quenceĎ =â¨(e 1 ,a 1 ),..., (e N ,a N )âŠinterleavingNclientâ service round trips withNclient-side decision rounds. This interface makes the procedure reactive, which fragments a coherent procedure into client-side next-call decisions. As procedural length grows, this interface (i) inflates latency via repeated RTT and per-step decision overhead, (i) in- duces over-/under-fetching because control logic must be implemented outside the service, and (i) makes recovery brittle, with partial failures triggering retries that can dupli- cate state-modifying operations and corrupt state. Key idea: tool programs as an interface. We propose to make tool intent first-class by representing a workflow as an executable tool program. A tool programPis a pro- cedure whose atomic operations are endpoint invocations CALL(e,a), composed with structured control flow and in- termediate bindings. Given an initial states, executingP produces a resultyand a (possibly updated) states Ⲡ. This shifts the interface from next-call selection to program sub- mission, enabling service-side execution, optimization, and checking while preserving the serviceâs observable behavior. 2 Beyond Static Endpoints: Tool Programs as an Interface for Flexible Agentic Web Services Goals. We aim to make tool programs practical without changing the observable outcomes of the underlying ser- vice interaction and without introducing prohibitive over- head compared to stepwise calling. Concretely, we target (G1) effect-safe observable semantics under failures and retries; and (G2) improved end-to-end efficiency in latency and client-side traffic. (G1) Executing a tool program may fail (e.g., due to runtime errors in generated code), triggering repair and re-execution. We aim for an interface-level guarantee: re-execution for the same high-level intent must not introduce additional side effects beyond stepwise execution. Note that we do not attempt to eliminate endpoint-level failures, which are inherent to the underlying service and can equally occur under stepwise execution. To reason about side effects, we assume each endpoint has an effect labeleff(e) â READ, WRITE, distin- guishing state-preserving queries from state-modifying operations.An execution induces a traceĎ (P ) = â¨(e 1 ,a 1 ,o 1 ),..., (e N ,a N ,o N )âŠ, where onlyWRITEcalls may changes. We target two interface-level properties: (i) observational equivalence: conditioned on the same under- lying sequence of endpoint outcomes, program execution exposes the same outputs/errors as stepwise execution; and (i) retry safety: across repair-driven re-executions for the same intent,WRITEeffects are not duplicated, yielding interface-level exactly-once semantics. (G2) Tool programs are beneficial only when their one-time construction cost is amortized by reducing round trips. A simple latency model contrasts stepwise calling and program execution, as follows: T STEP â N X i=1 T RTT + T DEC + T API , T PROG â T BUILD + T RTT + N X i=1 T API , (1) whereT RTT is clientâservice RTT,T DEC is per-step decision overhead on the client-side agent,T API is endpoint execu- tion time, andT BUILD includes program construction, com- pilation, and potential repair. Client-side traffic follows a similar trade-off. Stepwise calling repeatedly transmits re- quests and prompts acrossNrounds, whereas tool programs consolidate interaction into a small number of uploads and responses. Challenges. This formulation surfaces three challenges in operationalizing tool programs in practice: (C1) executabil- ity of LLM-produced programs under a typed, sandboxed substrate; (C2) exactly-once effect semantics forWRITE calls under repair and re-execution; and (C3) adaptive con- solidation to decide when program execution is more effi- cient than stepwise calling. 3. TOOLPRO Design TOOLPRO makes tool programs a first-class service inter- face for agentic workflows. Given an intent instance and tool specifications, the agent submits a single effect-typed programP; the service-side runtime then compiles, option- ally repairs, and executesPas a unit while enforcing an interface contract. TOOLPRO achieves this interface shift by addressing the three challenges (introduced in §2) in operationalizing tool programs in practice. TOOLPRO follows a synthesizeâprojectâcompileâexecute pipeline with a conservative fallback path. (1) Given task in- tent and service endpoints, the client synthesizes a candidate tool program and performs lightweight structural checks to reject obviously misaligned programs early. (2) The server projects the program into a constrained interface-program surface that is analyzable and enforceable, then compiles and executes it in a sandbox. (3) If compilation or execu- tion fails, the server performs bounded in-place repair using compiler diagnostics and runtime traces as verifiable feed- back. During any execution and re-execution, the runtime mediates external calls and enforces effect-aware replay to prevent duplicatedWRITEeffects. Finally, a profile-driven consolidation policy decides whether to use program execu- tion or revert to stepwise calling for the current task. 3.1. Tool Programs as an Interface TOOLPRO employs the tool program as the submitted in- terface object and the contract that the runtime enforces for any accepted program. The tool program serves as the interface object, which is the unit of interaction at the interface. A client represents an agentic workflow as a tool programP(defined in §2) and submits it to the runtime for execution as a unit. The only way forPto interact with the underlying service is via a unified stubCALL(e,a), where each dynamic call (a runtime instance ofCALL) triggers one endpoint invocation and returns an output (or error) observable to the program. This makes the workflow logic explicit and inspectable on the server side. To make such a programPenforceable and safe as an inter- face, the runtime cannot accept arbitrary code, which moti- vates a constrained surface. TOOLPRO restricts submitted programs to a constrained surface that expresses service- interaction logic rather than arbitrary application logic. Con- cretely, the runtime enforces: (i) structured control flow only (if/else,for/while); (i) external interaction only throughCALL(¡)with explicit effect annotations at each call site; (i) no exceptions, threads, dynamic linking, or un- safe memory operations; and (iv) no ad-hoc networking or filesystem access beyond the tool-facing service boundary. These restrictions ensure that compilation errors, runtime 3 Beyond Static Endpoints: Tool Programs as an Interface for Flexible Agentic Web Services Agent Task Instruction ClientServer MCP Services Consolidation Policy (§3.4) Stepwise Access Effect-Aware Replay (§3.3) ToolPro Constraint-Guided Construction with Compiler and Runtime Feedback (§3.2) Consolidated Access APIAccess Tasks (OPT1) (OPT2) APIAccess Figure 2. Three mechanisms of TOOLPRO. traces, and call events refer to a stable, analyzable surface that the runtime can repair and mediate reliably. Moreover, TOOLPRO makes side effects explicit via effect typing. Concretely, every external call site inPmust declare an effect label (READ/WRITE), which the runtime checks against the endpointâs declared effecteff(e). These annota- tions serve as the handle for retry protection.READcalls may be safely re-issued, whereas completedWRITEcalls must be replay-protected under repair-driven re-execution. Building on the interface object, constrained surface, and effect-typed boundaries, TOOLPRO enforces the following contract for any well-formed program P . â˘Program order. TOOLPRO processes dynamic calls in program order and never reorders external invocations. â˘Observable preservation. Conditioned on identical end- point outcomes (including inherent service errors), TOOL- PRO exposes the same per-call outputs/errors as step- wise execution. Across repair-driven re-executions for the same intent instance, completedWRITEeffects are not duplicated at the service boundary. â˘Safe fallback. If construction or repair exceeds the at- tempt budget, violates constraints, or encounters unsup- portedWRITEsemantics, TOOLPRO falls back to step- wise endpoint calling and surfaces diagnostics. The contract is realized by three mechanisms, each address- ing one of the three challenges (introduced in §2), as shown in Figure 2. 3.2. Constraint-Guided Construction with Compiler and Runtime Feedback The first challenge to realize tool programs is to ensure reli- able program execution (C1). In practice, LLM-produced programs are often structurally plausible yet fail under a typed sandbox due to unsupported libraries, type mis- matches, missing imports, or brittle error handling. TOOL- PRO addresses this gap with a constraint-guided construc- tion pipeline with four steps, which turns failures into bounded, checkable repairs using compiler and runtime feedback. Step 1: client-side synthesis with lightweight interface checks. Given the task intent and tool specifications, the client synthesizes a candidate programPand performs con- servative checks that are cheap yet effective at filtering ob- viously misaligned candidates. Concretely, it verifies (i) endpoint coverage (required endpoints appear), (i) a control- flow skeleton consistent with the intent (e.g., a bounded loop and necessary conditionals), and (i) basic value-flow sanity (outputs of earlierREADcalls can be bound and used as inputs to later calls). These checks avoid sending clearly ill-formed programs into server-side compilation. Step 2: server-side projection into a constrained surface. Upon receivingP, the server applies a deterministic projec- tionÎ (¡)to rewrite it into the constrained interface-program surface. The projection (i) rewrites all external interactions to the unified stubCALL(¡)with explicitREAD/WRITEan- notations, (i) removes or replaces unsupported imports and patterns, and (i) rejects any syntax or language features outside the allowed surface. The result, a canonical form Î (P ), ensures that subsequent diagnostics and traces are expressed over a stable surface that the runtime can interpret, enforce, and modify reliably. Step 3: compile and execute with feedback-driven, bounded in-place repair. The server then compiles and executesÎ (P )in a sandbox and uses the resulting feed- back to repair and re-run within a fixed attempt budget. On compilation failure, the compiler returns precise diagnostics that localize missing symbols, type mismatches, and offend- ing code spans. On runtime failure, the runtime records a lightweight trace that identifies the failing region together with the prefix of dynamic calls already observed. TOOL- PRO applies in-place repairs conditioned on this verifiable feedback and re-enters the loop. It re-projects the revised program if needed, recompiles, and re-executes until suc- cess or the budget is exhausted. Repairs are localized when- ever possible. Invocation errors trigger edits at the relevant call site (endpoint, arguments, or effect annotation), while control-flow/logic errors trigger rewrites of the minimal affected block with the rest preserved. Step 4: Safe fallback with diagnostics. If the attempt bud- get is exceeded or a repair violates the constrained surface, TOOLPRO falls back to stepwise endpoint calling and sur- faces the diagnostics collected during steps. This ensures that program execution is attempted only when it is demon- strably viable, and that failures are surfaced with auditable diagnostics rather than silently ignored. 4 Beyond Static Endpoints: Tool Programs as an Interface for Flexible Agentic Web Services 3.3. Effect-Aware Replay for Retry-Safe Semantics The second challenge (C2) is retry safety under repair-driven re-execution. A tool program may partially succeed be- fore failing. Naively re-running repaired code can re-emit state-modifyingWRITEcalls, duplicating side effects and corrupting service state. TOOLPRO prevents this by medi- ating runtime calls at the interface boundary and replaying outcomes of completed WRITE calls across re-executions. Because retry safety must hold at runtime, TOOLPRO inter- cepts each dynamic call (a runtime instance ofCALL(e,a)) along the taken control-flow path.READcalls are always forwarded to the service, since re-issuing them does not introduce new side effects. In contrast,WRITEcalls are replay-protected. Once aWRITEcompletes, subsequent re- executions must not re-emit it, while the program continues to observe the same outcome. To support such replay, TOOLPRO maintains a per-intent- instance log of committedWRITEoutcomes. Specifically, it keeps (i) an ordered history logHcontainingWRITE calls completed in prior executions, and (i) a working log WforWRITEcalls completed in the current execution. Each entry stores(e,a,o)along with a per-re-execution flag used. Both logs are scoped to a single intent instance, ensuring replay does not leak across unrelated tasks. Since replay is only sound when repairs do not attempt to revise already committed effects, TOOLPRO enforces a con- servative replay discipline. If a repaired program changes the arguments or relative order of any committedWRITE prefix already recorded inH, TOOLPRO disables replay and falls back to stepwise calling. This turns a potential silent semantic divergence into an explicit, auditable condition. Under this discipline, replay reduces to a simple matching problem at eachWRITE. On re-execution, when the pro- gram reaches the next dynamicWRITEwith parameters (e,a), TOOLPRO matches it to the earliest unused entry inHwith the same(e,a). If a match exists, the runtime returns the cached outcomeowithout issuing the external call; otherwise, it emits the call, obtainso, and appends (e,a,o)toW. Ordered matching treats repeated writes with identical(e,a)as distinct dynamic calls within a run, while still preventing duplication across re-executions. The log-based replay mechanism is shown in Algorithm 1. Before each re-execution, the runtime archives theWRITE calls completed in the last execution by appendingWtoH, clearsW, and resets allusedflags.READcalls are always emitted, whereasWRITEcalls are either replayed fromH (if matched) or emitted and recorded intoW . Proposition 3.1 (Retry-safeWRITEemissions). Fix an intent instance and a well-formed interface programP. Across repair-driven re-executions that satisfy the replay discipline above, TOOLPRO emits each completed dynamic Algorithm 1 Effect-Aware Replay for Retry-Safe Semantics Require: H: ordered history of completedWRITEcalls across prior executions Require: W: ordered log of completedWRITEcalls in the current execution 1: procedure ONREEXECUTION 2: Hâ Concat(H,W) ⡠Append last execution in order 3: W ââ 4:for each entry xâH do 5:x.usedâ False 6: function HANDLECALL((e,a,eff)) 7:ifeff = READ then 8:return EMIT((e,a)) 9:elseâˇeff = WRITE 10:for each entry xâH in order do 11:if x.(e,a) = (e,a) andÂŹx.used then 12:x.usedâ True 13:return x.o⡠Replay outcome 14:oâ EMIT((e,a)) 15: W.append((e,a,o)) 16:return o WRITEcall to the underlying service at most once, and later re-executions replay its cached outcome. Proof. The only emission of aWRITEoccurs when no unused matching entry exists inH(Lines 9â16), in which case the emitted outcome is recorded and later archived into H. In subsequent re-executions, the same dynamicWRITE must match an unused entry and be replayed (lines 10â13), so it cannot be emitted again.⥠Moreover, practical services often provide idempotency keys or exhibit nondeterminism, which affects replay match- ing. When idempotency keys are available, TOOLPRO in- cludes them in argumenta, strengthening matching and aligning replay with the serviceâs own exactly-once intent. If an endpoint is meaningfully nondeterministic under iden- tical(e,a)and no idempotency is available, TOOLPRO con- servatively falls back to stepwise calling, as replay could otherwise lead to different results compared to stepwise execution. 3.4. Profile-Driven Consolidation Policy The remaining challenge (C3) is when to pay the one-time build cost of program execution. While tool programs can reduce client-server turns, their construction (synthesis, pro- jection, compilation, and possible repair) is nontrivial, so consolidation should be used only when it is predicted to re- duce end-to-end cost. TOOLPRO therefore uses lightweight 5 Beyond Static Endpoints: Tool Programs as an Interface for Flexible Agentic Web Services online profiling and decision rules to choose between the tool program and stepwise calling. To make this choice instance-adaptive, TOOLPRO main- tains moving averages from recent runs forT RTT ,T DEC , and T BUILD . HereT RTT is the clientâservice round-trip time,T DEC is per-step client-side decision overhead, andT BUILD includes program synthesis, projection, compilation, and any repair time. In addition, TOOLPRO estimatesN, the number of dy- namic endpoint invocations in the candidate program, using synthesized structure and loop bounds when available. Given these estimates, the policy follows the cost model in Equation 1. Consolidation primarily saves(Nâ1)additional RTTs and decision rounds, while endpoint execution time largely appears in both modes. TOOLPRO predicts the net benefit of program execution over stepwise calling as âT = (N â 1)¡ (T RTT +T DEC ) âT BUILD .(2) IfâT > 0, TOOLPRO executes the tool program; otherwise it selects stepwise calling. Because profiles may be inaccurate at cold start, TOOLPRO bootstraps with a small number of stepwise runs to initialize T RTT andT DEC , and enables tool program execution only when the synthesized structure is clearly multi-step (e.g., a bounded loop). Once estimates stabilize, Equation 2 is applied to make per-instance decisions. This policy integrates naturally with the end-to-end control flow. Given an intent, TOOLPRO synthesizes a candidate program, estimatesâT, and selects the mode. If program execution is chosen, the server runs projection, compilation, and bounded in-place repair under effect-aware execution. If repair exceeds the attempt budget, violates constraints, or encounters unsupportedWRITEsemantics, TOOLPRO falls back to stepwise calling with diagnostics. As a result, TOOLPRO uses tool programs only when they are predicted to be beneficial in efficiency. 4. Experiments 4.1. Implementation We instantiate TOOLPRO over MCP-style tool-facing ser- vices and implement the service-side runtime using We- bAssembly (Wasm). On the client, an LLM synthesizes a tool programPfrom the intent and tool specifications and applies lightweight interface checks; the consolidation policy selects between program mode and stepwise calling. On the server, TOOLPRO projectsPinto the constrained interface-program surface viaÎ (¡), compiles and executes it in a sandbox with bounded in-place repair, and enforces retry-safeWRITEsemantics by mediating every dynamic CALL and replaying completedWRITEoutcomes across re-executions. If projection/repair violates constraints or ex- ceeds the attempt budget, TOOLPRO falls back to stepwise calling with diagnostics. We use Wasm as the execution substrate because it provides (i) a strong sandbox boundary for untrusted, LLM-generated code with no ambient authority, (i) a capability-style host interface that lets us expose only the unifiedCALL(e,a, eff) stub and mediate all side effects, and (i) portable, low- overhead execution suitable for short-lived procedural work- loads. Additional implementation details appear in Ap- pendix A. 4.2. Experimental Setup Benchmarks. We evaluate TOOLPRO on three widely-used open-source applications (Memos, Directus, and MinIO) from GitHub, following prior studies (Gu et al., 2025). De- tails on these applications are shown in Appendix B.1. Each application is exposed as an MCP-style tool-facing service with fixed endpoints, and we construct procedural work- flows that require loops/conditionals and intermediate bind- ings. For each application, we construct two workflows: a read- only workflow (suffix.r) and a read-write workflow (suffix .w). Each workflow is parameterized byN, which con- trols procedural length (and equals the number of endpoint invocations in stepwise execution). More details on the con- structed workflows are shown in Appendix B.2. We also add supplemental realistic workflows in Appendix B.3 to stress nondeterministic retrieval, branching, coordinated writes, non-idempotent effects, and cross-service execution. Metrics. We report end-to-end latency and client-side traf- fic volume, two widely used metrics (Gu et al., 2025). La- tency measures the time to complete a workflow, including client-side LLM time, client-server communication, and server-side execution. Client-side traffic measures bytes transmitted by the client during workflow execution, includ- ing both client-server payloads and client-to-LLM prompts. For supplemental workflows, we also report task accuracy. Baselines and variants. We compare TOOLPRO against the prevailing stepwise endpoint interface and include two TOOLPRO variants to isolate the effect of consolidation. ⢠Stepwise MCP Web Service (MWS). The prevailing fully stepwise baseline. At each step, the agent replans the next endpoint call(e i ,a i )given the intent, tool specs, and prior observations, leading toNrequests and typi- callyNLLM decision rounds with repeated tool-context transmission. ⢠TOOLPRO-step. A stepwise TOOLPRO variant (no con- solidation) that replaces replanning with intent-structured guidance: it first derives a coarse call skeleton from the intent (e.g., required endpoints and loop/conditional struc- ture), and then per step only instantiates/validates the 6 Beyond Static Endpoints: Tool Programs as an Interface for Flexible Agentic Web Services Memos.rMemos.wDirectus.rDirectus.wMinIO.rMinIO.w 0 5 10 15 20 25 30 35 Time (s) 16.8 20.0 15.5 24.7 14.4 18.1 16.8 19.0 18.6 19.7 17.4 22.9 MWS: E2E MWS: Comm. MWS: LLM TP: E2E TP: Comm. TP: LLM Figure 3. Latency comparison. âTPâ indicates TOOLPRO. âE2Eâ is the end-to-end latency. âComm.â is client-server communication latency. âLLMâ is latency involving client-side LLM inference. next call using current observations (e.g., filling argu- ments from priorREADoutputs), still incurringNre- quests/rounds but with lower per-step decision overhead and less repeated tool context. â˘TOOLPRO-prog. TOOLPRO-prog always executes in pro- gram mode. The agent submits one effect-typed tool pro- gram, which the server projects (Î (¡)), compiles/repairs, and executes under call interception. This isolates the benefits of consolidation (turn reduction) while paying the one-time build cost. ⢠TOOLPRO. Full system with the profile-driven consolida- tion policy, selecting between program mode and stepwise mode per instance. Details on experimental environments are shown in Ap- pendix B.4. 4.3. Overall Efficiency We first evaluate end-to-end efficiency by comparing TOOL- PRO against MWS across workflows with N = 10. Unless specified otherwise, the server is hosted in Sydney and the client in Beijing. Service latency. As shown in Figure 3, TOOLPRO con- sistently reduces end-to-end latency across all workflows. The main source of improvement is turn reduction: pro- gram mode packages a multi-step interaction into a single submission/execution cycle, avoiding the repeated client- side decide-next-call loop in MWS and reducing(N â 1) additional RTTs and reasoning rounds. While TOOLPRO incurs a one-time build cost (program synthesis, projection, compilation, and occasional bounded repair), this overhead is amortized for procedural workflows and higher RTT set- tings, consistent with the proposed policy model. Latency improvements remain consistent for read-write workflows, indicating that enforcing retry-safe semantics does not dom- inate end-to-end cost. Client-side traffic volume. As shown in Figure 4, TOOL- PRO reduces client-side traffic by up to 85.3%. This reduc- tion is primarily driven by fewer client-to-LLM exchanges: MWS repeatedly transmits tool specifications and intermedi- Memos.rMemos.wDirectus.rDirectus.wMinIO.rMinIO.w 0 10 20 30 40 Traffic Volume (KB) 17.8 40.8 5.8 26.6 4.6 31.3 5.5 27.3 4.9 25.3 4.8 27.4 MWS: Comm. MWS: LLM TP: Comm. TP: LLM Figure 4. Client-side traffic volume. âComm.â denotes client-server bytes. âLLMâ denotes client-to-LLM bytes. ate context acrossNrounds, whereas program mode trans- mits a compact tool program once (plus bounded repair prompts when needed). Clientâserver bytes may fluctuate because program mode uploads program source/bytecode, but the reduction in repeated prompting and over/under- fetching dominates for procedural workflows. Realistic workflows and reliability. To test whether the gains go beyond fixed-Nprocedural loops, we add four supplemental complex benchmarks (cbench1âcbench4) that require nondeterministic retrieval, loop/branch logic, coor- dinated multi-record writes, non-idempotent side effects, and cross-service branching. Across cbench1âcbench3 with complex realistic workflows, TOOLPRO reduces end-to-end latency from 30.16s to 17.91s (40.6%), improves task accu- racy from 0.60 to 0.93, and reduces client-side LLM latency from 14.98s to 7.08s (52.8%). On the cross-service bench- mark (cbench4), TOOLPRO reduces latency from 52.68s to 24.54s (53.4%), cuts client-side traffic by 96.1%, and improves accuracy from 0.20 to 0.80. We observe that the program-mode failure rate is relevant to the coding capability of LLMs. On the Rust-based cbench2, qwen3-coder-flash reaches 80% success rate, while gpt- 5.1 and gemini-3-flash-preview each reach 100% success rate with no observed compilation failure or fallback. In addition, replay also matters operationally: over a 15-run no-replay ablation on cbench1âcbench3, disabling replay increases average latency from 17.92s to 21.45s (+19.7%) and fallback from 0/15 to 3/15. Thus TOOLPRO fails closed when replay safety cannot be guaranteed, and fallback does not erase the overall gains over complex realistic workflows. 4.4. Sensitivity We next study how network conditions and workflow com- plexity affect performance, using Memos.w. Impact of network conditions. To vary network conditions, we deploy servers in London, Sydney, and San Francisco with a client in Beijing, and also inject additional one-way delays of 50ms, 100ms, 150ms, and 200ms. We run with N = 10. As shown in Figure 5, TOOLPRO outperforms MWS across 7 Beyond Static Endpoints: Tool Programs as an Interface for Flexible Agentic Web Services 508189100150200 Network Latency (ms) 0 5 10 15 20 25 30 35 40 Time (s) 13.8 23.2 14.9 23.9 15.5 24.7 15.6 24.9 15.9 25.3 16.1 29.4 LONSYDSFO MWS TP E2E LLM Comm. Figure 5. Impact of varying network conditions. 5101520 Complexity (# of API Accesses) 0 10 20 30 40 50 60 Time (s) 12.1 8.6 9.4 15.6 24.7 15.5 15.5 15.6 43.2 15.9 22.1 15.9 45.9 16.5 27.2 16.6 Method: Latency: MWS E2E TP Comm. TP-step LLM TP-prog Figure 6. Impact of workflow complexity on latency. network settings. As RTT increases, the performance gap widens because consolidation saves(N â 1)additional round trips, and the policy increasingly favors program mode when the predicted benefit exceeds build cost. In low- latency conditions, the policy more often selects stepwise mode to avoid paying the one-time build cost, yielding ro- bust performance across conditions. An extended 1â2000ms RTT sweep onMemos.w(N = 8) makes the mode switch explicit. TOOLPRO-step is better at 1â100ms (14.50â15.30s versus 15.51â15.60s for TOOLPRO-prog), while TOOLPRO- prog is better at 1000â2000ms (16.50â17.51s versus 22.48â 30.50s for TOOLPRO-step). The full TOOLPRO policy stays close to the empirically better mode across the sweep, select- ing stepwise execution in low-latency settings and program execution as RTT dominates. Impact of workflow complexity. We vary workflow com- plexity by settingN = 5, 10, 15, 20and compare MWS, TOOLPRO-step, TOOLPRO-prog, and TOOLPRO, with the server hosted in Sydney and the client in Beijing. As shown in Figure 6, MWS scales roughly linearly with Ndue toNrounds of RTT and reasoning. TOOLPRO in stepwise mode improves modestly by reducing per-step de- cision overhead with intent-structured guidance, but still paysNrounds. In contrast, TOOLPRO-prog remains com- paratively stable withNbecause it pays a one-time build cost and executes the interaction logic server-side. The full TOOLPRO achieves the best of both by switching between modes, validating the profile-driven policy. As shown in Figure 7, client-side traffic in MWS grows with 5101520 Complexity (# of API Accesses) 0 10 20 30 40 50 60 Traffic (KB) 13.3 2.62.6 5.3 26.6 5.8 6.0 5.9 39.9 6.7 7.8 6.7 53.2 7.4 10.4 7.5 Method: Traffic: MWSTPTP-stepTP-prog Comm.LLM Figure 7. Impact of workflow complexity on traffic volume. Ndue to repeated prompts and tool-context transmission. TOOLPRO-prog maintains low traffic for largerNby avoid- ing multi-round prompting. By switching between stepwise and program modes, TOOLPRO minimizes client-side traffic across complexity conditions. Moreover, we break down the overhead of TOOLPRO-prog in Appendix C. 5. Related Work Interfaces and representations for agent tool use. LLM- based agents increasingly solve tasks by invoking tools and APIs (Shen et al., 2025a; Liu et al., 2026; Shen et al., 2025b; Du et al., 2024; Song et al., 2025; Schick et al., 2023; Qin et al., 2024). The dominant interface remains stepwise endpoints, where intent is implicit in a sequence of endpoint calls interleaved with multi-round reasoning. This makes control flow and intermediate bindings an emergent property of the agent policy, inflating network turns and reasoning as workflows lengthen. In contrast, TOOLPRO makes intent explicit as an executable tool program with a constrained surface and effect types, enabling compilation, inspection, enforcement, and optimization at the interface boundary. From expressive queries to executable interaction logic. Web APIs evolved from RESTful endpoints (Fielding, 2000) to flexible query interfaces such as GraphQL (GraphQL, 2015), reducing over/under-fetching by letting clients shape responses. However, GraphQL is not designed to encode procedural interaction logic (loops, conditionals, retries) as a single interface object (Stack-Overflow, 2018a; Hartig & P Ě erez, 2018; Stack-Overflow, 2018b). Recent systems exe- cute user-supplied logic near the service; e.g., ORFA (Gu et al., 2025) uses Wasm modules as a Turing-complete query language. TOOLPRO instead focuses on agentic workflows where the core bottlenecks are executability and side effects under re-execution, using LLM-synthesized, repairable tool programs with an effect-typed contract and retry-safe se- mantics under iterative repair. Programmatic agents and in-situ execution. Code-based agent methods such as CodeAct (Wang et al., 2024) use 8 Beyond Static Endpoints: Tool Programs as an Interface for Flexible Agentic Web Services executable code as an agent action space, and workflow- generation methods such as AFlow (Zhang et al., 2025a) search over code-represented agent workflows. TOOLPRO is complementary but targets a different boundary: the submit- ted program is an effect-typed service interface object, not only an internal reasoning/action representation, and the run- time must enforce replay-safeWRITEbehavior across re- pair and re-execution. The design is also analogous to in-situ programmable execution systems such as eBPF (Hoiland- Jorgensen et al., 2018), which move logic closer to the exe- cution boundary to reduce repeated control transfers. Unlike eBPFâs pre-verified kernel packet programs, TOOLPRO han- dles dynamically generated tool programs over web-service endpoints with explicit effect annotations, sandboxed execu- tion, and fail-closed fallback. Wasm sandboxing as a substrate. WebAssembly (Wasm) provides a portable sandbox with near-native perfor- mance (Liu et al., 2025b; Yan et al., 2021; Liu et al., 2025a) and is widely adopted beyond browsers, including server- less and edge settings (Hoque & Harras, 2023; M Ě en Ě etrey et al., 2022; Kjorveziroski & Filiposka, 2023; Gackstatter et al., 2022; Zhang et al., 2025b). TOOLPRO uses Wasm as a supporting substrate to securely execute the constrained tool-program surface. 6. Conclusion We introduced TOOLPRO, which makes tool programs a first-class agent-facing service interface. By compiling effect-typed programs with projection and bounded repair, TOOLPRO consolidates multi-step workflows into fewer turns while ensuring retry-safe execution via effect-aware replay. A profile-driven policy selects program execution only when it is predicted to reduce end-to-end cost. Across complex workflows within realistic applications, TOOLPRO reduces latency and client-side traffic, with gains growing under higher RTT and increased workflow complexity. We believe TOOLPRO is a practical step toward executable and effect-safe representations of tool intent for the agentic web. Acknowledgements This work was supported by National Natural Science Foun- dation of China under the grant number 62595734, the Key Laboratory of High Confidence Software Technolo- gies (Peking University), the Ministry of Education, and the Center for Data Space Technology and System, Peking University. Impact Statement This paper presents work whose goal is to advance the field of Machine Learning. There are many potential societal consequences of our work, none of which we feel must be specifically highlighted here. References Deng, X., Gu, Y., Zheng, B., Chen, S., Stevens, S., Wang, B., Sun, H., and Su, Y. Mind2web: Towards a generalist agent for the web. Proceedings of the Advances in Neu- ral Information Processing Systems (NeurIPS 2023), p. 28091â28114, 2023. Du, Y., Wei, F., and Zhang, H. Anytool: self-reflective, hier- archical agents for large-scale api calls. In Proceedings of the 41st International Conference on Machine Learning (ICML 2024), p. 11812â11829, 2024. Fielding, R. T. Architectural styles and the design of network-based software architectures. University of Cali- fornia, Irvine, 2000. Gackstatter, P., Frangoudis, P. A., and Dustdar, S. Push- ing serverless to the edge with WebAssembly runtimes. In Proceedings of the 22nd IEEE International Sympo- sium on Cluster, Cloud and Internet Computing (CCGrid 2022), p. 140â149, 2022. GraphQL. The query language for modern APIs.https: //graphql.org/, 2015. Accessed: 2025-07-28. Gu, Y., Chen, C., Du, J., Zhang, X., and Zhang, X. ORFA: Exploring WebAssembly as a turing complete query lan- guage for web APIs. In Proceedings of the ACM on Web Conference 2025 (W 2025), p. 1856â1865, 2025. Hartig, O. and P Ě erez, J. Semantics and complexity of graphql. In Proceedings of the 2018 World Wide Web Conference (W 2018), p. 1155â1164, 2018. Hoiland-Jorgensen, T., Brouer, J. D., Borkmann, D., Fastabend, J., Herbert, T., Ahern, D., and Miller, D. The express data path: Fast programmable packet processing in the operating system kernel. In Proceedings of the 14th international conference on emerging networking experiments and technologies, p. 54â66, 2018. Hoque, M. N. and Harras, K. A. WebAssembly for edge computing: Potential and challenges. IEEE Communica- tions Standards Magazine, p. 68â73, 2023. Kjorveziroski, V. and Filiposka, S. WebAssembly as an enabler for next generation serverless computing. Journal of Grid Computing, p. 34, 2023. Liu, M., Shen, H., Zhang, Y., Mei, H., and Ma, Y. We- bassembly for container runtime: Are we there yet? ACM Transactions on Software Engineering and Methodology (TOSEM 2025), p. 22, 2025a. 9 Beyond Static Endpoints: Tool Programs as an Interface for Flexible Agentic Web Services Liu, M., Zhong, S., Yang, Q., Han, Y., Liu, X., and Ma, Y. Webanns: Fast and efficient approximate nearest neigh- bor search in web browsers. In Proceedings of the 48th International ACM SIGIR Conference on Research and Development in Information Retrieval (SIGIR 2025), p. 2483â2492, 2025b. Liu, M., Ma, X., Xie, Y., Chen, Q., Liu, X., and Ma, Y. ROGA: Scaling generalist agents for office productivity tasks via tool generation. In Proceedings of the Four- teenth International Conference on Learning Representa- tions (ICLR 2026), 2026. Liu, X., Yu, H., Zhang, H., Xu, Y., Lei, X., Lai, H., Gu, Y., Ding, H., Men, K., Yang, K., et al. Agentbench: Evalu- ating llms as agents. In Proceedings of the International Conference on Learning Representations (ICLR 2024), p. 52989â53046, 2024. M Ě en Ě etrey, J., Pasin, M., Felber, P., and Schiavoni, V. We- bAssembly as a common layer for the cloud-edge contin- uum. In Proceedings of the 2nd Workshop on Flexible Resource and Application Management on the Edge, p. 3â8, 2022. Qin, Y., Liang, S., Ye, Y., Zhu, K., Yan, L., Lu, Y., Lin, Y., Cong, X., Tang, X., Qian, B., et al. Toolllm: Facilitat- ing large language models to master 16000+ real-world apis. In Proceedings of the International Conference on Learning Representations (ICLR 2024), p. 9695â9717, 2024. Qwen-Team. Qwen3-Max: Just scale it, September 2025. Schick, T., Dwivedi-Yu, J., Dess ` Äą, R., Raileanu, R., Lomeli, M., Hambro, E., Zettlemoyer, L., Cancedda, N., and Scialom, T. Toolformer: Language models can teach themselves to use tools. Proceedings of the Advances in neural information processing systems (NeurIPS 2023), p. 68539â68551, 2023. Shen, H., Li, Y., Meng, D., Cai, D., Qi, S., Zhang, L., Xu, M., and Ma, Y. Shortcutsbench: A large-scale real- world benchmark for api-based agents. In Proceedings of the Thirteenth International Conference on Learning Representations (ICLR 2025), 2025a. Shen, H., Yan, H., Xing, Z., Liu, M., Li, Y., Chen, Z., Wang, Y., Wang, J., and Ma, Y. RAGSynth: Synthetic data for robust and faithful rag component optimization, 2025b. Song, Y., Xu, F. F., Zhou, S., and Neubig, G. Beyond browsing: Api-based web agents. In Findings of the Association for Computational Linguistics: ACL 2025, p. 11066â11085, 2025. Stack-Overflow. GraphQL: can you mutate the results of a query?https://stackoverflow.com/ques tions/52330018/graphql-can-you-mutat e-the-results-of-a-query , 2018a. Accessed: 2025-07-28. Stack-Overflow. Graphql loop through array and get all results. stack overflow.https://stackoverflow. com/questions/48321689/graphql-loop-t hrough-array-and-get-all-results , 2018b. Accessed: 2025-07-28. Wang, X., Chen, Y., Yuan, L., Zhang, Y., Li, Y., Peng, H., and Ji, H. Executable code actions elicit better LLM agents. In Proceedings of the Forty-first International Conference on Machine Learning (ICML 2024), 2024. Yan, Y., Tu, T., Zhao, L., Zhou, Y., and Wang, W. Under- standing the performance of webassembly applications. In Proceedings of the 21st ACM Internet Measurement Conference, p. 533â549, 2021. Yao, S., Chen, H., Yang, J., and Narasimhan, K. Web- shop: Towards scalable real-world web interaction with grounded language agents. Proceedings of the Advances in Neural Information Processing Systems (NeurIPS 2022), p. 20744â20757, 2022. Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., and Cao, Y. React: Synergizing reasoning and acting in language models. In Proceedings of the International Conference on Learning Representations (ICLR 2023), 2023. Zhang, J., Xiang, J., Yu, Z., Teng, F., Chen, X., Chen, J., Zhuge, M., Cheng, X., Hong, S., Wang, J., et al. Aflow: Automating agentic workflow generation. In Proceedings of the International Conference on Learning Representa- tions (ICLR 2025), p. 34040â34077, 2025a. Zhang, Y., Liu, M., Wang, H., Ma, Y., Huang, G., and Liu, X. Research on webassembly runtimes: A survey. ACM Transactions on Software Engineering and Methodology (TOSEM 2025), p. 1â47, 2025b. Zhou, S., Xu, F. F., Zhu, H., Zhou, X., Lo, R., Sridhar, A., Cheng, X., Ou, T., Bisk, Y., Fried, D., et al. Webarena: A realistic web environment for building autonomous agents. In Proceedings of the 2024 International Con- ference on Learning Representations (ICLR 2024), p. 15585â15606, 2024. 10 Beyond Static Endpoints: Tool Programs as an Interface for Flexible Agentic Web Services A. Implementation Details This appendix provides additional details of TOOLPROâs Wasm-based runtime, including the host interface, replay state management, and policy instrumentation. A.1. Runtime Architecture TOOLPRO is a client-server system. The client produces a candidate tool programPin Rust and an intent-instance identifier, and then either (i) submitsPto the server for program-mode execution or (i) performs stepwise call- ing. In program mode, the server executes the following stages. (1) ProjectionÎ (¡)rewritesPinto the constrained interface-program surface. (2) Compilation/repair utilizes Rustc to compile the projected Rust program and performs bounded in-place repair using compiler diagnostics and run- time traces. (3) Sandboxed execution runs the resulting module while intercepting every dynamic CALL to enforce program order and effect-aware replay. If any stage ex- ceeds budgets or violates constraints, the server triggers safe fallback to stepwise calling and returns diagnostics. A.2. Wasm Runtime Configuration and Host Interface The overall Wasm generation pipeline is shown in Figure 8. TOOLPRO compiles the LLM-generated Rust program into a Wasm module and executes it using Wasmtime. The module runs with no ambient authority. It cannot issue network requests, access the filesystem, or load dynamic libraries. All external interaction is mediated through a minimal set of host imports. ClientServer CodeGenerator Wasm Compiler Wasm Executor CodeFormatter Aggregated API Access Debugger APIAccess Agent Intent Confirm Code Code Code MCPServices Rust Projector Figure 8. Wasm generation pipeline of TOOLPRO. Unified call stub. The only capability needed by tool pro- grams is the unified stubCALL(e,a, eff). We implement this as a host-imported function that takes (i) an endpoint identifiere(interned string or integer id), (i) a serialized argument objecta(e.g., JSON bytes), and (i) an effect tag eff âREAD, WRITE. The host returns a serialized result object or a typed error. This import is the enforcement point. The mediator can log calls, enforce program order, check effect labels, and apply replay semantics without requiring the module to embed networking logic. Deterministic projection target. ProjectionÎ (¡)targets a stable surface that compiles deterministically to Wasm. In particular, it rewrites all external interactions to the stub, rejects disallowed constructs (exceptions/threads/dynamic linking/unsafe features), and ensures effect annotations are explicit at each call site. This makes compiler diagnostics and runtime traces comparable across repair iterations. A.3. Effect Mediation and Replay State Effect-aware replay is implemented inside the mediator that handles every dynamic CALL from the Wasm module. For each intent instance, the mediator maintains (i) a history log Hof completedWRITEcalls from prior executions, and (i) a working logWfor completedWRITEcalls in the current execution. Each entry stores(e,a,o)and a per-runused flag. Re-execution protocol.Before each repair-driven re- execution, the mediator archivesWintoH, clearsW, and resets allusedflags. During execution,READcalls are always forwarded to the service. For aWRITEcall with parameters(e,a), the mediator matches it to the earliest unused entry inH; if matched, it returns the cached out- come without emitting the call, otherwise it emits once and appends the outcome toW . Fail-closed conditions. Replay is enabled only under the replay discipline. If a repaired program attempts to revise a committedWRITEprefix (by changing arguments or rela- tive order), replay is disabled, and the system falls back to stepwise calling with diagnostics. B. Experimental Details B.1. Application Benchmarks Details of employed applications are listed below. â˘Memos 2 (56k stars): A lightweight, self-hosted knowl- edge management platform in Go, exposing OpenAPI- compliant REST interfaces. â˘Directus 3 (34k stars): An API layer providing REST and GraphQL endpoints over SQL backends. â˘MinIO 4 (60k stars):An S3-compatible,high- performance object storage system. B.2. Constructed Workflows Table 1 shows the constructed procedural agentic workflows used in our experiments. 2 https://github.com/usememos/memos 3 https://github.com/directus/directus 4 https://github.com/minio/minio 11 Beyond Static Endpoints: Tool Programs as an Interface for Flexible Agentic Web Services Table 1. Composed procedural workflows over fixed endpoints. AppRead-OnlyRead-Write Workflow (.r)Workflow (.w) MemosGet memos of N users (user id=1,2,. . . ,N ). Nis the user number. Change the visibility of N memos. N is the memo number. DirectusGet detailed information of N articles (id=1,2,. . . ,N ). N is the article number. Modify author information of N draft articles. N is the number of articles. MinIODownload N files. N is the file number. Upload N files. N is the file number. B.3. Supplemental Realistic Workflows and Results The supplemental realistic benchmarks were added to mea- sure TOOLPRO under complex situations. They keep the same MCP-style endpoint setting but require runtime bind- ing, branch-dependent control flow, state consistency across multiple records, and cross-service side effects. Table 2. Supplemental realistic workflows. BenchCore challengeRepresentative task cbench1Nondeterministic re- trieval Find customer Mei Pa- tel by ZIP 76165, iden- tify the correct pending or- der at runtime, and update that order to contain only item 1096508426 with to- tal 55.0. cbench2Loop, branching, and coordinated writes Update all pending or- ders and the customerâs primary address; if or- der #W4082615 has not shipped, replace its items and set the total to 25.0. cbench3Non-idempotent side effects Fordeliveredorder #D12345, change status toexchangerequested, replace its items, and create an exchange log recording old and new items. cbench4Cross-service branch- ing Upload five local doc- uments to MinIO, in- spect object text, route objects across prefixes, create follow-up memos when required, then clean up generated files and memos. Supplemental benchmark results.Across cbench1â cbench3, TOOLPRO reduces average latency from 30.16s to 17.91s (40.6%), improves task accuracy from 0.60 to 0.93, and lowers client-side LLM latency from 14.98s to 7.08s. For cbench4, TOOLPRO reduces latency from 52.68s to 24.54s (53.4%), cuts client-side traffic by 96.1%, and improves accuracy from 0.20 to 0.80. The policy selects program mode in 12/15 cold-start runs and in all 12/12 warm-start runs after profiles are available; no fallback is observed once program mode is selected in these measure- ments. Replay and model comparison. In a 15-run no-replay ablation on cbench1âcbench3, disabling replay increases av- erage latency from 17.92s to 21.45s and fallback from 0/15 to 3/15. On cbench2, gpt-5.1 and gemini-3-flash-preview each reach 100% success rate with no observed compila- tion failure or fallback, while qwen3-coder-flash reaches 80%, indicating that compilation failures are primarily a model-capability bottleneck. Table 3. Extended RTT sweep on Memos.w with N=8. RTTTOOLPRO-stepTOOLPRO-progTOOLPRO policy 1ms14.50s15.51s14.54s 10ms14.57s15.52s14.57s 100ms15.30s15.60s15.43s 1000ms22.48s16.50s16.22s 2000ms30.50s17.51s17.64s This sweep makes the profile-driven switch explicit: step- wise execution is preferable at low RTT, while program execution dominates once RTT becomes the main cost. Table 4. Language comparison on cbench2. Rust is an implemen- tation choice rather than a conceptual requirement. LanguageAvg. secondsAccuracyNote Rust19.40520.80Mature direct-to-Wasm frontend in our setting. Go50.21530.40More brittle direct-to-Wasm compilation in our setting. LuaN/AN/ANo practical direct-to-Wasm path for this use case. These results support using Rust in the prototype because it integrates cleanly with Wasmtime and provides actionable compiler diagnostics, while a lighter DSL/IR remains a promising future direction. Generated tool programs remain compact in the supplemen- tal runs: sampled programs have a median of 70 non-empty lines of code, 4 MCP tool calls, and 1 branch/loop keyword hit; the shortest and longest samples are 43 and 102 non- empty lines. The 102-line sample includes 6 tool calls (3 READ, 3WRITE) plus a conditional branch, with explicit effect annotations at call sites. B.4. Environments We run servers on AWSc7i-flex.largeinstances (In- tel Xeon Sapphire Rapids @2.40GHz, 2 vCPUs, 4GB RAM, up to 12.5Gbps). Servers are hosted in Sydney, London, and San Francisco. The client runs in Beijing on a machine with an Intel Core i9-14900HX CPU, 16GB RAM, and a gigabit network connection. TOOLPRO is implemented in 12 Beyond Static Endpoints: Tool Programs as an Interface for Flexible Agentic Web Services Python, utilizing the Wasmtime 5 for WebAssembly execu- tion. TOOLPRO uses Rust 6 as the high-level language for Wasm compilation. We use Qwen3-Max-Instruct (Qwen- Team, 2025) for program synthesis and repair prompting on the client. Unless otherwise specified, results are averaged over five runs. C. Overhead Breakdown Table 5. Breakdown of tool-program build pipeline latency (sec- onds and percentage of total end-to-end latency). AppNProgramCompila-SandboxService SynthesistionExecutionExecution Memos.r 57.31 (41.9%)5.39 (30.9%)2.44 (14.0%)2.06 (11.8%) 107.32 (40.9%)5.43 (30.3%)2.46 (13.7%)2.40 (13.4%) 157.61 (41.9%)5.39 (29.7%)2.45 (13.5%)2.58 (14.2%) 207.61 (41.3%)5.42 (29.4%)2.47 (13.4%)2.81 (15.2%) Memos.w 57.31 (42.4%)5.17 (30.0%)2.47 (14.3%)2.16 (12.5%) 107.51 (42.0%)5.21 (29.2%)2.48 (13.9%)2.20 (12.3%) 157.62 (42.3%)5.37 (29.8%)2.47 (13.7%)2.38 (13.2%) 20 7.86 (41.3%)5.45 (28.6%)2.49 (13.1%)3.09 (16.2%) We break down the overhead of program mode by mea- suring TOOLPRO-prog onMemos.randMemos.wwith N = 5, 10, 15, 20(server in Sydney, client in Beijing). Ta- ble 5 shows that program synthesis dominates the one-time build cost, while compilation and sandbox execution remain stable acrossN. This suggests that model specialization for the constrained interface-program surface (or more efficient synthesis/repair prompting) could further reduce overhead. Importantly, sandbox execution includes effect mediation forWRITEcalls, yet contributes a relatively small frac- tion of end-to-end time, indicating that retry safety can be enforced with modest overhead in practice. 5 https://github.com/bytecodealliance/wasm time 6 https://rust-lang.org/ 13