MCP 2025-06-18 Spec Update: What Elicitation, Structured Output, and Tool Behavior Change

MCP (Model Context Protocol) is evolving fast. The spec has seen multiple revisions since its initial release, and each update changes what MCP servers can do and how clients interact with them.

The 2025-06-18 update introduces three features that fundamentally expand the interaction model: Elicitation (tools can ask users questions), Structured Output (type-safe tool responses), and Tool Behavior Annotations (safety metadata). If you're building or maintaining MCP servers, these aren't optional — they're the new baseline.

Before this update, MCP tools were one-directional: the client sends input, the tool returns output. No back-and-forth.

Elicitation changes this. A tool can now pause execution and ask the user a structured question. The user responds with one of three actions: accept (submit the form), decline (explicitly say no), or cancel (dismiss without choosing).

Practical impact: A flight booking tool can now ask "Where to? When? How many travelers?" mid-execution instead of requiring all parameters upfront. Approval workflows become possible — "This will deploy to production. Confirm?" with structured accept/decline.

The constraint: only flat objects with primitive types (string, number, boolean). No nested objects, no arrays. This keeps the interaction simple and predictable.

// Elicitation request example
const response = await client.request({
  method: "elicitation/create",
  params: {
    message: "Please confirm deployment details",
    requestedSchema: {
      type: "object",
      properties: {
        environment: { type: "string", description: "Target environment" },
        confirmed: { type: "boolean", description: "Proceed with deploy?" }
      },
      required: ["environment", "confirmed"]
    }
  }
});
// response.action: "accept" | "decline" | "cancel"

Previously, tool responses were text-based content arrays. Clients had to parse text to extract structured data — fragile, error-prone, and format-dependent.

Now tools can declare an outputSchema and return structuredContent alongside the human-readable content[]. The SDK validates structuredContent against the schema at runtime, failing fast on violations.

Practical impact: Downstream systems can consume tool results programmatically without parsing. A weather tool returns {temperature: 22, unit: "celsius"} as typed data, not "It's 22°C" as text. Pipeline integrations become reliable instead of regex-based.

Key rule: when outputSchema is defined, structuredContent is mandatory. But content[] is also still required — humans need readable output too.

// Tool with structured output
server.tool("get-metrics", {
  outputSchema: {
    type: "object",
    properties: {
      activeUsers: { type: "number" },
      errorRate: { type: "number" },
      status: { type: "string", enum: ["healthy", "degraded", "down"] }
    },
    required: ["activeUsers", "errorRate", "status"]
  }
}, async () => ({
  content: [{ type: "text", text: "System healthy: 1,234 active users, 0.2% errors" }],
  structuredContent: { activeUsers: 1234, errorRate: 0.002, status: "healthy" }
}));

This is the simplest but potentially most impactful change. Tools can now declare four behavior attributes:

- readOnlyHint: Does this tool just read data, or does it modify state? - destructiveHint: Can this tool irreversibly destroy data? - idempotentHint: Is it safe to retry this tool on failure? - openWorldHint: Does this tool have external side effects (sending emails, calling APIs)?

Clients use these annotations to adjust their UI. A destructive tool gets a confirmation dialog. A read-only tool might auto-execute without asking. An idempotent tool can be safely retried on network errors.

Practical impact: Better UX with zero client-side logic changes. The server declares intent, the client adapts. This is especially important for safety — a delete-database tool should never auto-execute.

If you maintain an existing MCP server:

1. Add behavior annotations to all your tools. Start with readOnlyHint and destructiveHint — they have the most immediate UX impact. 2. Identify tools that would benefit from structured output. Any tool whose results feed into other systems is a candidate. 3. Consider where elicitation could replace awkward multi-step tool chains. If a tool currently requires 5 parameters upfront, maybe it should ask for them interactively.

If you're building a new MCP server:

- Use the MCP Elicitation Form Builder skill to generate elicitation schemas - Use the MCP Structured Output Validator skill to define outputSchemas - Use the MCP Tool Behavior Declarator skill to annotate all tools

All three skills are available in our catalog with copy-paste CLAUDE.md code.

These three features signal a clear direction: MCP is moving from "tools as functions" to "tools as interactive services." Elicitation adds conversation. Structured output adds contracts. Behavior annotations add safety semantics.

The next frontier is likely tool composition — tools that call other tools, with elicitation and structured output flowing through the chain. The A2A (Agent-to-Agent) protocol discussions are already pointing in this direction.

For now, adopting these three features puts your MCP server ahead of the curve and ready for what comes next.