description: Default Tools - 115 ready-to-call JavaScript tools across 6 source bundles, exposed through the built-in MCP server, OS-agnostic by design.

Default Tools

Where: top navigation → Tool Studio - the default tools ship pre-loaded; tune the exposed subset in the Built-in MCP Server Native Tools drawer.

Spring AI Playground ships with 115 default tools spread across six JSON source bundles. They are ready to call the moment a model provider is connected - you do not need to author anything yourself to see agentic workflows work end-to-end. They also serve as editable references when you start writing your own tools.

Tools that reach an external API read their keys from environment variables - each tool's card below lists the variables it needs. How to supply env vars (desktop launcher, Docker -e, or a source run) is covered once in the Configuration reference.

Every tool is Local-Passed (published to the built-in MCP server) out of the box - except any that are still missing a required ${ENV_VAR}, which stay as drafts until you supply it. A preset decides something separate: which of the Local-Passed tools the server actually exposes to agents at boot (the default is Starter 5), with per-tool include / exclude rules layering on top. That preference lives in <home>/spring-ai-playground/tool/save/default-tools-preference.json and is chosen at setup - the desktop launcher's Default MCP Tools card, or CLI / yaml (full breakdown in Tool Studio → Where preset choices live). Tool Studio's Built-in MCP Server Native Tools drawer then selects which Local-Passed tools the MCP server exposes. Applying a chat-side prompt preset that declares tools writes this same preference, resetting the exposed set to that preset's key-less tools - so it persists across restarts and the chat, Tool Studio, and the server stay in agreement.

!!! info "Two presets, one exposed set" The built-in MCP server publishes a single exposed-tool set (default-tools-preference.json). Three places write it, and the last write wins and persists across restarts:

1. **Startup tool preset** (`Starter 5`, `Everything`, ...) - establishes the initial exposed set, chosen once at setup. It is the baseline the server shows to external MCP clients and before any chat role is applied.
2. **Applying a chat prompt preset** (`Data wrangler`, `Log detective`, ...) - re-exposes exactly that role's tools, because the chat agent calls them through this same built-in server. The new set sticks until the next change, and a confirmation dialog lists it first.
3. **Tool Studio's Native Tools drawer** - manual per-tool edits.

So the *tool* preset and the *prompt* preset are not two competing systems: they are entry points to the **same** setting at different moments (once at setup vs each time you pick a chat role). Because they share one set, applying a chat role also changes what external MCP clients see - which is why the confirmation dialog spells out the new exposure before you commit.

Risk Level { #risk-level }

Every tool carries a Risk Level (L0-L5) - the sandbox posture the Safe Tool Specification computes from the tool's declared capabilities (sandboxOverrides). Lower = more sandboxed. Each tool's reference card shows its level; the same chip appears in Tool Studio's Sandbox & Capabilities pane.

!!! note "Two L0-L5 scales" This is the sandbox rubric (how far a JavaScript tool widens the local sandbox). External MCP servers reuse the same enum for a different question - see MCP Server Safety. The two never mix.

Levels are derived from each tool's declared sandboxOverrides (by SandboxPostureCalculator); the full bullet-by-bullet rule set is in AI Agent Tool Safety → Risk Level decision matrix. Across the 115 default tools: 50 are L0, 58 are L3 (allowlisted-host fetch or file read/search), 4 are L4 (file write / append / edit / copy), and 3 are L5 (the destructive move / delete / deleteDir tools). Every L4 and L5 filesystem tool is additionally gated by human-in-the-loop approval, which lowers its effective chip by one band (L4 → L3, L5 → L4) while the inherent level shown here still drives sandbox permissions and the audit log.

!!! question "Why no L1 or L2 here?" The sandbox rubric only ever produces L0 / L3 / L4 / L5 - the calculator jumps from the L0 baseline straight to L3 the moment a tool declares any widening (network, file, or class change), so a tool is never L1 or L2. L1 (Safe) and L2 (Low) exist only in the MCP server rubric, which scores a different thing (connecting to an external server) on the same L0-L5 enum.

Browse all 115 tools { #browse-all-tools }

Click a card to jump to its full reference (with the JS source pre-expanded) on the right sub-page - same UX as the Built-in MCP Server Native Tools drawer in Tool Studio. Six reference pages organise the catalog by source bundle and concern: Examples · Utilities · Filesystem · Global · Korea · Visualization.

Filter modes: pick a Preset for an exclusive view (just the tools in that preset, all other filters cleared); or combine a search keyword with one or more Tag / Category chips - search is AND, tag and category are OR (a card is shown when it matches any selected tag OR category and also matches the search keyword).

Two ways to use these tools

Expose and call

The simplest mode - pick a preset (or layer rules on top) and the built-in MCP server publishes that subset. The same tool inventory ends up reachable, but the two transports the server can run with serve different audiences:

• Streamable HTTP at http://localhost:8282/mcp - always on. The in-app MCP Inspector (MCP Server tab) and the in-app Agentic Chat use this transport exclusively, and so do external Streamable HTTP MCP clients (Claude Code, Cursor, Claude Desktop via mcp-remote).
• STDIO - opt-in, only useful when an external MCP client wants to host the process itself. Launch with the mcp-stdio Spring profile (Docker -e SPRING_PROFILES_INCLUDE=mcp-stdio, or java -jar with the same env var); the client then spawns the playground as its child process and talks JSON-RPC over its stdin/stdout. The server's lifetime is tied to that client process - when the client exits, the server exits with it. This is how Claude Desktop / Claude Code can host the built-in server with no HTTP at all. The in-app surfaces are unaffected - they keep talking Streamable HTTP whether or not the STDIO profile is layered in.

Before exposing to an external client, the in-app MCP Inspector is the practical place to verify each tool's contract - run the tool, look at its schema, prompts, and resources, all isolated from chat.

No JS authoring is required for any of this mode - pick a preset, expose, call.

• → Tool Studio: Key Tool Studio Capabilities - Built-in MCP Server Native Tools drawer overview
• → Tool Studio: Connect to the Built-in MCP Server - wiring external clients over Streamable HTTP
• → Alternative Runtimes: distribution channels and MCP transports - Docker container and fat-JAR launchers for STDIO mode
• → MCP Server: MCP Inspector - exercise tools, resources, prompts before exposing externally
• → Agentic Chat - call them from a model conversation

Author and compose

The deeper mode - each default tool's JS source is a working reference for the cross-bridged helpers (fetch, safety.fs.*, safety.parser.*, crypto.subtle, console.log). Open one in Tool Studio, use Copy And New Tool to fork it, tweak the action, hit Test & Publish. The moment Local Pass succeeds, your tweaked tool joins the same built-in MCP server - Agentic Chat and external clients see it without a restart.

• → Tool Studio: Built-in JavaScript Helpers - the full helper surface
• → Tool Studio: Local Pass - Test Before Publish - the publish gate
• → Tutorial 1: Author a Tool - first walkthrough

End-to-end flow

[ Default tool · Custom tool ]
            │
            ▼
   [ Author in Tool Studio ]
            │
            ▼
   [ Local Pass test  ✅ ] ──── No pass, no run - the gate
            │
            ▼
   [ Built-in MCP server ]
            │
            ├── Streamable HTTP  ·  http://localhost:8282/mcp
            │   server runs independently; clients connect by URL
            │       │
            │       ├──▶  [ MCP Inspector ]  (in-app - verify the contract)
            │       ├──▶  [ Agentic Chat ]   (in-app)
            │       └──▶  External HTTP clients - Claude Code · Cursor ·
            │             Claude Desktop (via mcp-remote) · any Streamable HTTP MCP client
            │
            └── STDIO  ·  process stdin/stdout JSON-RPC
                client spawns the playground as its child process;
                its lifetime is tied to the client - when the client exits, the server exits with it
                (opt-in: mcp-stdio profile - Docker -e SPRING_PROFILES_INCLUDE=mcp-stdio,
                 or java -jar with the same env var)
                     │
                     └──▶  External STDIO clients - Claude Desktop · Claude Code
                           configured to spawn the process · any other STDIO MCP client

The two transports differ in who owns the server's lifetime: in Streamable HTTP mode the playground is a long-running daemon and clients come and go by URL; in STDIO mode the MCP client launches the playground as a child process and the server dies with the client. The in-app Inspector and Agentic Chat always reach the server over Streamable HTTP - STDIO is purely for external clients that want to host the process themselves. The same flow applies whether you expose a default tool unchanged or compose new tools from default-tool patterns, and the Inspector is where you exercise each tool against its schema before pointing an external client at it.

Why these are different from other MCP tools

Most MCP server implementations ship one native binary per OS (Python wheels, Node binaries, Go / Rust executables) and require the user to install a platform-matching build, often plus a toolchain (Python, Node, Cargo) to author new tools.

Spring AI Playground's tool runtime is OS-agnostic by design. One JVM artifact - distributed as a JAR, a Docker image, or an Electron-packaged desktop launcher - runs identically on macOS, Windows, and Linux. All 115 default tools are pure JavaScript executed through GraalVM Polyglot, and so is every tool you author. There is no per-OS build step, no native dependency, no toolchain on the user's machine.

Full mechanics - including how every cross-bridged helper rides on JVM stdlib so / vs \, TLS, parsers, and crypto behave identically across OSes - in Tool Studio → Cross-platform by design.

Composition recipes

The reference pages list what's available; composition recipes show how to chain them into a useful new tool. Three walk-throughs are in Tutorial 8: Default Tool Recipes:

• Filesystem pipeline - listDir → grepFile → sliceFile → writeTextFile, ending in a custom tool that summarises a chunked log directory.
• GitHub release → AI summary - getGithubLatestRelease → openaiResponseGenerator, ending in a tool that posts release-notes digests.
• City name → hourly forecast - geocodeAddress → getOpenMeteoForecast, ending in a tool that answers "is it raining tomorrow in city?" without hard-coded coordinates.

Environment variables - short list

Some default tools depend on environment-backed secrets and stay inert until those are set. The full per-tool breakdown lives on each reference page; the most common are:

Secrets are masked from console.log output by substring replacement when the full resolved value appears, and they are not committed to the tool spec - they resolve at runtime from the JVM environment.

→ Tool Studio: Key Tool Studio Capabilities - Static Variables, secret masking, and how env-backed values reach the JS action.