AI Docs
Chat & Streaming
Transports
Tools
Middleware
Chat UI Recipes
Interrupts
MCP
Resumable Streams
Persistence
Persistence (Advanced)
Media
Embeddings
Reranking
Evaluate
Code Mode
Computer Use
Harness
- Build your first harness
- Host options
- Send and show media
- Connect clients
- Write a client in any language
- Access and tenants
- Run in the terminal
- Deploy a harness
- Send inputs safely
- Run a tool without a model
- Durable sessions
- Run background work on workers
- List, rename, and fork sessions
- Lifecycle and retention
- Run side effects once
- Wait for a person
- Build on the session log
- Control how a turn ends
- Store settings per thread
- Compact a long session
- Fork and reset a thread
- One log for a session tree
- Write a plugin
- Track usage and cost
- Ask before risky tool calls
- Give your agent coding tools
- Sandbox and extend the coding tools
- Run the coding tools for many threads
- Undo a turn
- Build a coding agent
- Delegate to coding agents
- Switch between agent profiles
- Auth and connectors
- Share a thread between people
- Connect model providers
- Build your own UI
- Code mode in a harness
- Work until a goal is met
- Run agents from a harness
- Hand off a conversation
- Add skills
- Use MCP servers
- Give your agent a computer
- Use from any MCP client
- Use a harness from an editor (ACP)
Sandboxes
- Overview
- Quick Start
- ProvidersUpdated
- Harnesses
- Harness Auth
- Workspace
- Tools
- Policy
- Lifecycle & Snapshots
- Portable Snapshots
- Keep Files After Reload
- Save a Named Version
- Branch From a Version
- Send a Frozen File
- Let the Agent Save and Fork
- Pick Which Files to Keep
- What a Snapshot Stores
- Instance Durability
- Durable Runs
- Events
Sandboxes (Advanced)
Advanced
- Runtime Context
- Bring Your Own Key
- Keep Keys on the Server
- Debug Logging
- Multimodal Content
- Files API
- Per-Model Type Safety
- Runtime Adapter Switching
- Tree-Shaking
- Extend Adapter
- Extend Adapter: Advanced
- Typed Pre-Configured Options
- Test with a Fake Model
- Prompt Caching
- Mid-Conversation Changes
- Approval Flow Processing
AI/LLM: This documentation page is available in plain markdown format at/ai/latest/docs/mcp/server-input.md
MCP
Ask for Input
An MCP tool can stop and ask the user before it runs. Use that when the tool deletes a file or sends data.
Call ctx.context.requestInput inside the tool. The host shows your message to the user, and the call returns the answer.
Quick setup#
You need an MCP server first. If you do not have one, start with Serve Tools over HTTP.
- Give .server() the type MCPToolContext, so ctx.context.requestInput type-checks.
- Call requestInput with the message for the user.
- Act on the answer.
ts
import { toolDefinition } from '@tanstack/ai'
import { createMCPServer } from '@tanstack/ai-mcp/server'
import type { MCPToolContext } from '@tanstack/ai-mcp/server'
import { z } from 'zod'
const deleteFile = toolDefinition({
name: 'delete_file',
description: 'Delete a file after the user says yes',
inputSchema: z.object({
path: z.string(),
}),
}).server<MCPToolContext>(async ({ path }, ctx) => {
const answer = await ctx.context.requestInput({
message: `Delete ${path}? Type yes to continue.`,
})
if (answer !== 'yes') {
return `Kept ${path}.`
}
return `Deleted ${path}.`
})
const server = createMCPServer({
name: 'files',
version: '1.0.0',
tools: [deleteFile],
})
export function fetch(request: Request) {
return server.fetch(request)
}If the user sends yes, the tool returns Deleted plus the file path. Any other answer returns Kept plus the path.
How it works#
- ctx is the second argument of the function that you pass to .server().
- requestInput returns the string that the user sends.
- If the user declines or cancels, requestInput throws an Error. The tool call then ends with a tool error.
A TanStack chat() host pauses on the request and shows it to the user. MCP Client Input shows how the user answers.
Advanced#
Spec 2025 and spec 2026#
The two MCP spec versions ask for input in different ways.
On spec 2025:
- requestInput needs sessions: 'memory'. Without a session, it throws. See MCP Server Sessions.
- requestInput waits on the open session. The same tool call then continues with the answer.
On spec 2026:
- The handler returns input_required. Then the client runs the tool again with the answer.
- The code before requestInput runs on each call, so it can run more than once. If work must run once, put it after requestInput returns.
- A tool asks one question per call. A second requestInput in the same call throws an Error. To ask two questions, use two tools.
Task tools#
requestInput does not work in an execution: 'task' tool. MCP Server Tasks has the details.