ftl-cli-0.0.23 is not a library.

`ftl`

Fast tools for AI agents

Docs | Contributing | Security | Releases

FTL is an open source framework and edge hosting platform for tools that extend the abilities of AI agents. It builds on the WebAssembly Component Model via Spin to provide a just works DX for the entire lifecycle of building and running secure, high performance Model Context Protocol tools authored in a variety of source languages, accessible over the network with low latency.

Why?

MCP is minimal. Tools are straightforward. Writing and running them should be too. Performance and security should be a given.

FTL tools run on any host compatible with Spin/Wasmtime, including your development machine.

The FTL Platform aims to be the best way to host and manage remote tools that are fast and distributed enough be used by agents deployed anywhere, including real-time voice and multimodal systems. FTL runs on Fermyon Wasm Functions and Akamai's globally distributed edge cloud. Latency and compute overhead for remote tool calls should not be something you have to design around.

Workers automatically scale horizontally to meet demand, can cold start in < 1ms, and scale down to zero.
The FTL gateway components handle protocol complexity, auth, tool argument validation, and tool component routing.

The FTL Platform is optional. Opt in via the ftl login command, which enables ftl deploy.

See ftl-mcp if you want to directly use, contribute to, or fork individual FTL components.

Tools run as individual WebAssembly components to provide sandboxed tool executions on a provably airtight security model. MCP endpoints are secured by protocol-compliant authorization. Plug in your own OIDC provider via simple configuration, or use FTL's by default.

Write your MCP tools in Rust, TypeScript, Python, Go, C, and more. If you can implement a basic HTTP route as a Wasm component, you can run it as an MCP tool with FTL.

Tools are compiled to self-contained Wasm binaries that are often < 1MB. They can be pushed and pulled directly from OCI-compliant registries like Docker Hub, GitHub Container Registry, Amazon Elastic Container Registry, and more.

Tools are built on and compatible with the WebAssembly Component Model via Spin.

Quick Start

Install ftl

cargo install ftl-cli

Set up templates

ftl setup templates

Create a new project

ftl init my-tools
cd my-tools

Develop new tools

ftl add

Serve your tools locally

ftl up --build

Try them out with your MCP client

{
  "mcpServers": {
    "my-tools": {
      "url": "http://127.0.0.1:3000/mcp",
      "transport": "http"
    }
  }
}

Authenticate with FTL

ftl login

Deploy

ftl deploy

Plug it in

{
  "mcpServers": {
    "my-tools": {
      "url": "https://d2c85b78-6487-4bee-a98c-5fa32f1598af.aka.fermyon.tech/mcp",
      "transport": "https"
    }
  }
}

Developing tools

use ftl_sdk::{tool, ToolResponse};
use serde::Deserialize;
use schemars::JsonSchema;

#[derive(Deserialize, JsonSchema)]
struct MyToolInput {
    /// The message to process
    message: String,
}

/// A simple MCP tool
#[tool]
fn my_tool(input: MyToolInput) -> ToolResponse {
    ToolResponse::text(format!("Processed: {}", input.message))
}

import { createTool, ToolResponse } from 'ftl-sdk'
import { z } from 'zod'

// Define the schema using Zod
const ToolSchema = z.object({
  message: z.string().describe('The message to process')
})

type ToolInput = z.infer<typeof ToolSchema>

const tool = createTool<ToolInput>({
  metadata: {
    name: 'my_tool',
    title: 'My Tool',
    description: 'A simple MCP tool',
    inputSchema: z.toJSONSchema(ToolSchema)
  },
  handler: async (input) => {
    return ToolResponse.text(`Processed: ${input.message}`)
  }
})

//@ts-ignore
addEventListener('fetch', (event: FetchEvent) => {
  event.respondWith(tool(event.request))
})

Architecture

graph TB
    subgraph "MCP Clients"
        Desktops["Cursor, Claude"]
        Agents["LangGraph, Mastra, ADK, OpenAI Responses API"]
        Realtime["11.ai, LiveKit, Pipecat"]
    end
    
    MCP["Model Context Protocol<br/>(Streamable HTTP)"]
    
    subgraph "Akamai Edge Worker"
        subgraph "Fermyon Wasm Function"
            subgraph "Spin/Wasmtime Runtime"
                subgraph "FTL Application"
                    subgraph "FTL Gateway Components"
                        AuthGateway["Auth Gateway<br/>(Authentication, Authorization)"]
                        MCPGateway["MCP Gateway<br/>(Protocol, Routing, Validation)"]
                    end
                    
                    subgraph "User Tool Components"
                        Weather["Weather Tool<br/>(TypeScript)"]
                        GitHub["GitHub Tool<br/>(Rust)"]
                        Database["Database Tool<br/>(JavaScript)"]
                        Custom["Custom Tool<br/>(Another Language)"]
                    end
                end
            end
        end
    end
    
    Desktops -.->| | MCP
    Agents -.->| | MCP
    Realtime -.->| | MCP
    MCP -.->| | AuthGateway
    AuthGateway -.->|"Authorized requests (in-memory call)"| MCPGateway
    MCPGateway -.->|"In-memory call"| Weather
    MCPGateway -.->|"In-memory call"| GitHub
    MCPGateway -.->|"In-memory call"| Database
    MCPGateway -.->|"In-memory call"| Custom

Each tool runs as a separate WebAssembly component in its own sandbox.
The FTL gateway components handle protocol complexity, auth, tool argument validation, and tool component routing.
Individual components are composed onto a single worker that exposes a secure, protocol-compliant MCP server.
Workers automatically scale horizontally to meet demand, can cold start in < 1ms, and scale down to zero.
Cross-component calls happen in memory with no network latency, while maintaining security boundaries.

Contributing

We welcome contributions and discussion. Please see our Contributing Guide for details.

License

Apache-2.0 - see LICENSE for details.

Acknowledgments

FTL is built on top of these excellent projects:

ftl-cli 0.0.23

ftl