Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.simplefunctions.dev/llms.txt

Use this file to discover all available pages before exploring further.

This page is the current public status map for SimpleFunctions developer surfaces. The SDK and Agent SDK are now published as alpha packages, while the CLI and HTTP API remain separate surfaces with their own contracts.

​
Current state

SurfaceCurrent statusUse it for
HTTP APIPublic raw network surfaceLanguage-neutral access to SimpleFunctions endpoints
CLIPublished operator and automation surfaceTerminal workflows, local agent loop, headless mode, daemon/runtime controls
/api/contracts/toolsStrict SDK/Agent contract truthCanonical tool names, auth, access, sideEffect, costEffect, replay metadata
/api/toolsBroad hosted compatibility inventoryHTTP-native and MCP compatibility discovery
@spfunctions/sdkPublished alpha, 0.1.0-alpha.0Typed data and contract client for TypeScript
@spfunctions/agent v0Published alpha, 0.1.0-alpha.0Governed direct tool runner for TypeScript
@spfunctions/agent/v1Published alpha, 0.1.0-alpha.0Model loop, watch primitives, sessions, hooks, and Cursor-style compatibility

​
Which surface should I use?

Use the HTTP API if:
  • you are not writing TypeScript
  • you need direct control over requests and response handling
  • you are integrating from a service that already owns auth, retries, and error mapping
Use the CLI if:
  • a human, shell script, CI job, or coding agent is operating from a terminal
  • you want the richer sf agent local loop
  • you need headless NDJSON tooling
  • you need local runtime controls such as sf runtime
Use the SDK if:
  • you are writing TypeScript
  • you want typed reads and stable resource objects
  • you want API-key-first client behavior
  • you want strict manifest inspection through sf.manifest.*
Use Agent SDK v0 if:
  • you already have an application, worker, or agent harness
  • you want canonical direct tool calls from code
  • you need policy gates for sideEffect and costEffect
  • you need local trace/replay
  • you do not need a model-backed planner

​
What is not shipped

These are not shipped as stable SDK/Agent capabilities:
  • GA semver compatibility
  • browser runtime or long-lived browser API keys
  • MCP runtime inside the Agent SDK
  • live trading through SDK or Agent SDK
  • events.*
  • market.related semantic graph
  • auth.status
  • investigations.create
  • intents.propose
  • webhooks.create
  • live_trade

​
Tool truth hierarchy

For SDK and Agent SDK work, use this hierarchy:
SourceMeaning
GET /api/contracts/toolsStrict SDK/Agent contract truth
sf describe --all --jsonLocal installed CLI command manifest
GET /api/toolsBroad hosted compatibility inventory
MCP toolsAdapter inventory for MCP-compatible clients
Do not treat /api/tools or MCP names as SDK/Agent canonical names. For example: 
world.read       canonical SDK/Agent tool
get_world_state  broad compatibility name, not SDK/Agent truth

​
Roadmap

The current sequence is:
  1. Keep 0.1.0-alpha.0 pinned in examples and customer projects.
  2. Expand contract coverage only through /api/contracts/tools.
  3. Harden v1 watch/model-loop examples against real production workloads.
  4. Add public support, rate-limit, and error-handling commitments before GA.
  5. Move toward 0.1.x alphas without breaking v0 direct-runner behavior.
No live trading, browser runtime, MCP runtime, or broad /api/tools aliasing is part of the current alpha roadmap.