TypeScript Functions Are Live on MCPWorks

MCPWorks Functions now supports TypeScript. Your AI assistants can create, execute, and manage TypeScript functions alongside Python, using the same MCP interface, the same secure sandbox, and the same namespace infrastructure. No configuration change. No separate server. Add language: "typescript" to make_function and it works.

This matters because roughly half the developers building with AI assistants work in TypeScript-dominant stacks. Next.js, tRPC, Cloudflare Workers, Deno. Forcing Python on everyone excluded a large portion of the people who would otherwise use this platform. That's fixed now.

How does it work?

When your AI calls make_function with language: "typescript", three things happen:

1. Your TypeScript source is transpiled on our infrastructure using esbuild (the same transpiler used by Vite, Remix, and most modern JS toolchains). Type annotations, interfaces, enums, and generics are all supported. Transpilation typically completes in under 10 milliseconds.

2. The resulting JavaScript executes inside an nsjail sandbox running Node.js 22 LTS. The same Linux namespace isolation, cgroup resource limits, and seccomp syscall filtering that protect Python functions protect TypeScript functions. The security model is identical.

3. Results come back in the same format as Python functions. Success, output, stdout, stderr, error type. Your AI doesn't need to handle TypeScript results differently than Python results.

The practical effect: an AI assistant working on a TypeScript project can write functions in the language it's already thinking in, instead of context-switching to Python.

What does a TypeScript function look like?

Here's a function that generates a Fibonacci sequence, created by Claude in a real MCPWorks session:

interface FibResult {
  sequence: number[];
  count: number;
  sum: number;
}

export default function main(input: Record<string, any>): FibResult {
  const n: number = Math.min(input.n || 10, 50);
  const sequence: number[] = [];

  let a = 0, b = 1;
  for (let i = 0; i < n; i++) {
    sequence.push(a);
    [a, b] = [b, a + b];
  }

  return {
    sequence,
    count: sequence.length,
    sum: sequence.reduce((acc, val) => acc + val, 0),
  };
}

The AI creates this with a single MCP tool call:

make_function(
  service="math",
  name="fibonacci",
  backend="code_sandbox",
  language="typescript",
  code="...",
  input_schema={"type": "object", "properties": {"n": {"type": "integer"}}}
)

Execution returns:

{"sequence": [0, 1, 1, 2, 3, 5, 8, 13, 21, 34], "count": 10, "sum": 88}

Full type annotations, interfaces, generics. esbuild strips the types at transpilation time, and Node.js executes the clean JavaScript.

What entry points does TypeScript support?

TypeScript functions on MCPWorks support four patterns, matching the Python conventions:

// Pattern 1: Default export (preferred)
export default function main(input: Record<string, any>) {
  return { greeting: `Hello, ${input.name}!` };
}

// Pattern 2: With context (for agent orchestration)
export default function handler(input: Record<string, any>, context: any) {
  return { state: context.state.someKey };
}

// Pattern 3: CommonJS
module.exports.main = function(input) { return { ok: true }; };

// Pattern 4: Simple assignment
const result = { computed: 42 };
module.exports.result = result;

Async functions are fully supported. If your entry point returns a Promise, the sandbox awaits it automatically:

export default async function main(input: Record<string, any>) {
  const response = await fetch(input.url);
  return { status: response.status, body: await response.text() };
}

What about npm packages?

TypeScript functions have access to 16 pre-installed npm packages covering the most common use cases. The approach is identical to Python: all packages are pre-installed in the sandbox image. No npm install at runtime, no supply chain risk, no cold start penalty.

Available packages include lodash, zod, axios, cheerio, marked, date-fns, jsonwebtoken, bcryptjs, ajv, uuid, yaml, xml2js, csv-parse, csv-stringify, and both the OpenAI and Anthropic SDK clients.

Node.js built-ins are always available without declaring them: crypto, url, path, buffer, util, fs, http, https, querystring, stream, zlib.

Your AI can check what's available at any time:

list_packages(language="typescript")

We'll expand the package list based on what developers actually need. If there's a package you want, let us know.

Can TypeScript functions call Python functions?

Yes. Both directions work.

MCPWorks includes a cross-language bridge that lets functions call each other across the language boundary. From Python code-mode, you can call a TypeScript function as naturally as a Python one:

from functions import fibonacci
result = fibonacci(n=10)
# Returns: {"sequence": [0, 1, 1, 2, 3, 5, 8, 13, 21, 34], ...}

From TypeScript code-mode, you can call a Python function the same way:

const { check_api } = require("./functions");
const result = await check_api({ url: "https://api.mcpworks.io/v1/health" });
// Returns: {"status_code": 200, "healthy": true, ...}

Under the hood, cross-language calls route through the MCP run server. Each call is a full sandbox execution with its own isolation, billing, and call tracking. The bridge is transparent to the AI and to the function code. You call the function, you get the result. The language it was written in is an implementation detail.

Cross-language calls require network access (Builder tier or above), since the bridge uses HTTP to route between sandboxes.

What about code-mode execution?

Code-mode is the pattern where your AI writes ad-hoc code that calls multiple functions in a single sandbox execution, keeping intermediate data out of the context window. MCPWorks now provides two code-mode tools:

• execute_python runs Python code with access to all namespace functions via from functions import ...
• execute_typescript runs TypeScript/JavaScript code with access to all namespace functions via require("./functions")

Both tools can call functions written in either language. Your AI picks the tool that matches the code it's writing, and the cross-language bridge handles the rest.

What templates are available?

Three TypeScript templates are available for quick-start:

• hello-world-ts is the TypeScript equivalent of our Python hello-world. Proves the sandbox works, shows the entry point pattern, returns a greeting.

• api-connector-ts demonstrates calling external APIs using Node.js built-in fetch. Takes a URL, method, headers, and body. Returns status code, headers, and response body.

• json-transformer-ts shows data transformation with pick, rename, and filter operations on JSON objects and arrays.

Clone any template with a single tool call:

make_function(service="utils", name="greet", template="hello-world-ts")

The template sets the language, code, schemas, and requirements automatically.

How does TypeScript sandbox security compare to Python?

The isolation is identical. Both languages run inside the same nsjail sandbox with:

• Linux PID namespace preventing process visibility across executions
• Network namespace with no connectivity on the free tier, and filtered egress on paid tiers
• Mount namespace with a read-only root filesystem (only /tmp and /sandbox are writable)
• User namespace running as nobody (UID 65534) with no capabilities
• cgroup v2 memory, CPU, and process limits enforced per tier
• seccomp-bpf syscall allowlist blocking dangerous kernel operations

The one difference: Node.js's V8 JIT compiler requires writable+executable memory mappings (mmap with PROT_WRITE|PROT_EXEC), which Python's interpreter does not. This is an accepted trade-off, the same one made by every cloud sandbox provider that supports JavaScript (Cloudflare Workers, AWS Lambda, Deno Deploy). The other five isolation layers prevent exploitation of the JIT surface.

What are the resource limits?

TypeScript functions share the same tier-based limits as Python:

Tier	Timeout	Memory	Network
Free	10s	128 MB	Blocked
Builder	30s	256 MB	Available
Pro	90s	512 MB	Available
Enterprise	300s	2 GB	Available

The --max-old-space-size V8 flag is set automatically to match your tier's memory limit, so the V8 heap respects the same boundary as the cgroup.

How do I get started?

If you already have a MCPWorks account, TypeScript works right now. No upgrade needed. No configuration change.

1. Connect your AI to your namespace's create endpoint (same as before)
2. Call make_function with language: "typescript"
3. Execute via the run endpoint or use execute_typescript for code-mode

If you don't have an account yet, sign up for the Developer Preview. Free Builder access for up to 90 days, no credit card required.

Frequently asked questions

Can I mix Python and TypeScript functions in the same namespace?

Yes. Each function declares its language at creation time, and both languages coexist in the same namespace and services. The language is stored per function version and cannot be changed after creation (if you want to rewrite a function in a different language, create a new function).

Does TypeScript support type checking?

MCPWorks uses esbuild for transpilation, which strips types without checking them. This is intentional. Full tsc type checking would add 1-5 seconds to every function creation, and LLM-authored code rarely benefits from strict type checking at creation time. Runtime errors catch type mismatches effectively, and TypeScript's type system still helps the AI reason about the code it's writing.

Can I use JavaScript instead of TypeScript?

Yes. TypeScript is a superset of JavaScript. If you set language: "typescript" and submit plain JavaScript, it works fine. esbuild passes it through unchanged.

What Node.js version is used?

Node.js 22 LTS (currently v22.22.1). This includes stable fetch, structuredClone, top-level await support, and all Node.js 22 built-in modules.

Is there a cold start penalty for TypeScript?

TypeScript functions have a slightly higher cold start than Python (~150-200ms vs ~50-100ms) due to V8 initialization. For most use cases this is imperceptible. If TypeScript usage grows significantly, we'll add pre-warmed Node.js sandbox pools to match Python's ~5-10ms warm execution overhead.