CallScript

Say you have two GitHub tools mounted - listIssues, which returns the first 100 issues of a repo, and closeIssue, which closes one issue by number - and you prompt the agent: "close stale issues".

With plain tool calling, every listIssues call lands all 100 issues in the agent's context. To pick the stale ones it has to read them; to close them it has to generate tokens for each closeIssue call - and so on, one round-trip at a time.

That is slow, costs tokens, no way to see the full set of calls ahead of time, judgments like "stale" are made mid-run and so on..

Code Mode - or, in Anthropic's writing, code execution with MCP - solves this by giving the model type definitions for the tools and letting it write a TypeScript program against them: models are better at writing programs than at emitting tool-call chains, and results flow between calls without going back through the model. But code mode introduces its own complexity - from Anthropic's:

Note that code execution introduces its own complexity. Running agent-generated code requires a secure execution environment with appropriate sandboxing, resource limits, and monitoring. These infrastructure requirements add operational overhead and security considerations that direct tool calls avoid. The benefits of code execution—reduced token costs, lower latency, and improved tool composition—should be weighed against these implementation costs.

But calling tools and APIs shouldn't need a Turing-complete language. By the rule of least power, the unused power is what forces the sandbox and keeps the code from being validated, bounded, or paused.

CallScript keeps the parts of JavaScript the job needs - calls, dataflow, branches, bounded fan-outs - and compiles them to inert data before anything executes. The benefits stay and the infrastructure goes: a plan and its state are plain data, so a run stores anywhere, resumes later, and takes new input when it does.

The agent answers the same prompt by writing one small JavaScript program:

// close stale issues
const issues = await github.listIssues({ repo: "api" });
const stale = issues.filter(i => i.stale);
const closed = await Promise.all(
  stale.slice(0, 10).map(i => github.closeIssue({ repo: "api", number: i.number })));

callscript never executes it - each statement compiles into one step of an inert JSON plan:

{
	"intent": "close stale issues",
	"steps": [
		{ "id": "issues", "call": "github.listIssues", "args": { "repo": "api" } },
		{ "id": "stale", "let": "issues.filter(i => i.stale)" },
		{
			"id": "closed",
			"call": "github.closeIssue",
			"each": "stale.map(i => ({ repo: 'api', number: i.number }))",
			"max": 10
		}
	]
}

Steps reference each other by id, and those references are the schedule: independent steps run concurrently, dependent ones wait. Awaited calls keep statement order, and Promise.all runs calls in parallel.

npm install callscript

Mount your tools on callscript and hand the model the ready-made tools - execute, search, and describe:

import { generateText } from "ai";
import { callscript } from "callscript";
import { toAISDKTools, fromAISDKTools } from "callscript/ai-sdk";

const cs = callscript({
	tools: fromAISDKTools(tools, { namespace: "github" }),
});

await generateText({
	model: "anthropic/claude-sonnet-5",
	prompt: "Close every stale open issue in the 'api' repo.",
	tools: toAISDKTools(cs), // execute + search + describe
});

In callscript, a tool is anything an executor can evaluate. Executors come from adapters - the AI SDK, MCP, and others - and the default executor evaluates a plain object: { name, execute } plus an optional schema and description:

import { callscript, tool } from "callscript";

const closeIssue = tool({
	name: "github.closeIssue",
	description: "close an issue by number",
	inputSchema: { /* zod, any standard schema, or json schema */ },
	execute: ({ number }) => ({ closed: number }),
});

const cs = callscript({ tools: [closeIssue] });

import { toAISDKTools, fromAISDKTools } from "callscript/ai-sdk";

const cs = callscript({
	tools: fromAISDKTools(github, { namespace: "github" }),
});

// hand the model callscript's tools: execute + search + describe
await generateText({ model, prompt, tools: toAISDKTools(cs) });

import { fromMCP } from "callscript/mcp";

// any MCP client with listTools/callTool fits
const cs = callscript({
	tools: await fromMCP(client, { namespace: "github" }),
});

function signatures

callscript turns each tool definition into a function signature: one card with the signature line, the description, and any declared error codes.

github.closeIssue({ repo: string, number: number }) -> { closed: number }
  close an issue by number
  errors: not_found

search

Tools are meant to be discovered: search finds mounted tools by keyword and returns names with one-line summaries, and describe returns the full signature cards for the names a script will use. You pick the exposure. Append every card into the prompt when the toolset is small; or list only names and short descriptions and let the agent describe the ones it needs - no searching to discover - or expose nothing inline and let it search first, so the prompt stays the same size however many tools you mount. execute is the third tool of the pair - the one that acts, running the script the model authored.

const { execute, search, describe } = cs.tools({ scope });

An execution of a callscript is data all the way down: the plan, every settled step, and the point where it stopped all serialize into one plain record. You can flag a risky call for approval, park a run on an external event, or leave a long job running and join it from a later script:

// the agent flags the risky call - the run pauses right there
const closed = await github.closeIssue({ number: 42 }, { suspend: true });

which compiles to the plan step:

{ "id": "closed", "call": "github.closeIssue", "args": { "number": 42 }, "suspend": true }

The paused run comes back as a plain state record that can be stored in memory or as a KV entry; when the answer arrives, execution continues from the serialized record - settled steps reused, not re-run.

cs.script({...}) and cs.tool(...) are typed against the mounted tools: call autocompletes to mounted tool names and args to that tool's input, so a typo'd name is a type error before it is a validation error. Every expression position takes the string form or a real JS arrow, transpiled - never executed - into the string at the door:

cs.script({
	steps: [
		{ id: "issues", call: "github.listIssues", args: { repo: "api" } },
		{ id: "stale", let: ({ issues }) => issues.filter((i) => i.stale) },
	],
});

The arrow's parameter names everything the body reads; a free name - including a captured outer variable, the thing a native closure could smuggle in - is rejected at the door. What's stored, hashed, and re-executed is always the string form, so the script stays inert data.

Each step of a plan is one of three verbs:

• call - const x = await tool.name({...}) - invokes a mounted tool; its args validate against the tool's schema before it fires. A second argument carries per-call options: { reason, suspend, onError }.
• let - const x = expr - derives a value from earlier steps with a pure expression.
• return - if (cond) return value - is a guard clause: when it fires the run ends right there with that value; otherwise the run continues.

And a step can carry modifiers:

• if skips the step unless a condition holds.
• each fans a call out over a list, one dispatch per element, bounded by a hard max.
• after orders a step behind earlier ones when no data flows between them - close the issues, then post the summary.
• suspend flags a call for confirmation: the run pauses there until a human approves it.

A few more things the language gives you:

• Globals. Expressions read earlier steps by id, input (data passed to this execution), variables published by earlier runs in the session, $errors.stepId for recorded failures, and safe built-ins like Math, JSON, and Date.
• Promises. Every call is async; await only decides whether the run blocks on it. A call without await (const job = svc.export({...})) detaches and keeps running in the background, and a later script joins it with const r = await job.
• Expressions. A side-effect-free subset of JS: arrows, template literals, ternaries, optional chaining - no I/O, no imports, no reaching outside the script's scope.
• Output. output projects the run's final result from any settled step; by default it is the last step's value.
• Validation. The whole plan is checked before anything runs - unknown tools, misshaped args, unbound references, all reported at once - and hard limits cap steps, total calls, and concurrency.