This feature implements the MCP Tools specification. FrontMCP handles all protocol details automatically.
Why Tools?
In the Model Context Protocol, tools serve a distinct purpose from resources and prompts:| Aspect | Tool | Resource | Prompt |
|---|---|---|---|
| Purpose | Execute actions | Provide data | Provide templated instructions |
| Direction | Model triggers execution | Model pulls data | Model uses messages |
| Side effects | Yes (mutations, API calls) | No (read-only) | No (message generation) |
| Use case | Actions, calculations, integrations | Context loading | Conversation templates |
- API integrations — call external services, webhooks, third-party APIs
- Data mutations — create, update, delete records
- Calculations — perform computations, transformations
- System operations — file operations, process management
- Workflows — trigger multi-step processes, orchestration
Creating Tools
Class Style
Use class decorators for tools that need dependency injection, lifecycle hooks, or complex logic:Function Style
For simpler tools, use the functional builder:Registering Tools
Add tools to your app via thetools array:
Input Schemas
Tools use Zod schemas for type-safe input validation. The schema is automatically converted to JSON Schema for MCP protocol compatibility.Basic Types
With Descriptions
Optional and Default Values
Complex Types
Output Schemas
Optionally define an output schema for response validation:Return Values
Tools support multiple return formats. The SDK automatically converts your return value to the MCPCallToolResult format.
Simple Returns
Full MCP Format
For complete control over the response, return the fullCallToolResult structure:
Multiple Content Items
Return an array to include multiple content blocks:Tool Metadata
| Field | Description |
|---|---|
name | Programmatic identifier used internally and in MCP responses |
description | Helps the model understand when and how to use this tool |
inputSchema | Zod schema defining expected input parameters |
outputSchema | Zod schema for validating and documenting output |
title | Human-friendly name for UI display |
icons | Array of icons for visual representation in clients |
tags | Categorization for organization and filtering |
annotations | MCP-defined hints about tool behavior |
examples | Usage examples for discovery and LLM understanding |
ui | Visual widget configuration (template, display mode, etc.) |
hideFromDiscovery | When true, tool is callable but not listed in tools/list |
Tool Examples
Provide examples to improve discoverability and help LLMs understand how to use your tools effectively.CodeCall Discovery
Examples are indexed for semantic search with 2x weight, helping users find the right tools faster.
LLM Understanding
The
codecall:describe tool returns up to 5 examples per tool to help LLMs understand usage patterns.Tool Annotations
Annotations provide hints to clients about tool behavior:| Annotation | Description |
|---|---|
title | Display title for the tool |
readOnlyHint | Tool doesn’t modify state (like a resource, but returns computed data) |
destructiveHint | Tool performs irreversible operations (delete, overwrite) |
idempotentHint | Multiple identical calls produce the same result |
openWorldHint | Tool interacts with external systems (APIs, services) |
Tool Context
Class-based tools have access to a rich execution context viathis:
Using Providers
Inject services via theget() method:
Request Context
Class-based tools have access to the full request context including tracing, timing, and authentication:Progress Notifications
Send real-time updates to clients during long-running operations using MCP notifications.Sending Messages
Usethis.notify() to send log messages to the client:
'debug', 'info', 'warning', 'error'
Sending Progress
Usethis.progress() for progress bar updates. This only works when the client includes a progressToken in the request:
Progress notifications are only sent if the client includes a
progressToken in the request’s _meta field.
If no token is provided, this.progress() returns false and silently succeeds.Progress Token Access
TheprogressToken is automatically extracted from the request’s _meta field and made available via the ToolCallExtra type for advanced use cases:
this.progress() which handles the token automatically.
Real-World Examples
Calculator Tool
API Integration Tool
Database Mutation Tool
File Operation Tool
MCP Protocol Integration
Tools integrate with the MCP protocol via two flows:| Flow | Description |
|---|---|
tools/list | Returns all available tools with their metadata and input schemas |
tools/call | Executes a specific tool with provided arguments |
tools/call with a name and arguments:
- The SDK locates the tool by name
- Arguments are validated against the tool’s
inputSchema - The
execute()method is called with the validated arguments - The return value is validated against
outputSchema(if provided) and converted to MCPCallToolResultformat
Capabilities
FrontMCP automatically advertises tool capabilities during MCP initialization:| Capability | Description |
|---|---|
listChanged | When true, the server will send notifications/tools/list_changed when tools are added or removed |
listChanged: true when you have any tools registered, enabling clients to receive real-time notifications when tools are dynamically added or removed.
Change Notifications
When tools change dynamically (e.g., via adapters or plugins), FrontMCP automatically sendsnotifications/tools/list_changed to connected clients. Clients that support this notification will refresh their tool list.
Tool UI
Tools can render visual widgets alongside their responses. This enables rich, interactive presentations of tool outputs—weather cards, order summaries, data tables, and more.Basic UI Configuration
Add aui property to attach a visual template:
Template Types
FrontMCP auto-detects your template type:UI Configuration Options
| Option | Description |
|---|---|
template | HTML function, React component, or MDX string |
displayMode | 'inline' (default), 'fullscreen', or 'pip' |
widgetDescription | Human-readable description shown to users |
widgetAccessible | Allow widget to call tools via MCP Bridge |
csp | Content Security Policy (allowed domains) |
servingMode | How HTML is delivered: 'auto' (default), 'inline', 'static', 'hybrid', etc. |
htmlResponsePrefix | Text prefix for Claude dual-payload HTML block (default: 'Here is the visual result') |
mdxComponents | Custom components for MDX templates |
hydrate | Enable client-side React hydration for interactivity |
Using @frontmcp/ui Components
Combine Tool UI with the@frontmcp/ui component library:
Testing Tool UI
Use@frontmcp/testing for E2E validation of rendered widgets:
Tool UI Guide
Complete configuration options and examples
UI Components
Pre-built components from @frontmcp/ui
Templates
HTML, React, and MDX template patterns
Testing UI
E2E testing with @frontmcp/testing
Best Practices
Do:- Use descriptive
nameanddescriptionfields to help models understand tool purpose - Define clear input schemas with
.describe()on each field - Use appropriate annotations (
destructiveHint,idempotentHint, etc.) to guide client behavior - Validate inputs thoroughly and return meaningful error messages
- Keep tools focused on a single action or operation
- Create tools for read-only data retrieval (use resources instead)
- Skip input validation—always define a proper
inputSchema - Ignore error handling—wrap external calls in try/catch
- Create overly complex tools—split into multiple tools if needed
- Expose sensitive operations without proper authentication checks