Tools
Expose functions as executable capabilities for your MCP client.
Tools are the core building blocks that allow your LLM to interact with external systems, execute code, and access data that isn’t in its training data. In FastMCP, tools are Python functions exposed to LLMs through the MCP protocol.
What Are Tools?
Tools in FastMCP transform regular Python functions into capabilities that LLMs can invoke during conversations. When an LLM decides to use a tool:
- It sends a request with parameters based on the tool’s schema.
- FastMCP validates these parameters against your function’s signature.
- Your function executes with the validated inputs.
- The result is returned to the LLM, which can use it in its response.
This allows LLMs to perform tasks like querying databases, calling APIs, making calculations, or accessing files—extending their capabilities beyond what’s in their training data.
Tools
The @tool
Decorator
Creating a tool is as simple as decorating a Python function with @mcp.tool()
:
When this tool is registered, FastMCP automatically:
- Uses the function name (
add
) as the tool name. - Uses the function’s docstring (
Adds two integer numbers...
) as the tool description. - Generates an input schema based on the function’s parameters and type annotations.
- Handles parameter validation and error reporting.
The way you define your Python function dictates how the tool appears and behaves for the LLM client.
Functions with *args
or **kwargs
are not supported as tools. This restriction exists because FastMCP needs to generate a complete parameter schema for the MCP protocol, which isn’t possible with variable argument lists.
Parameters
Annotations
Type annotations for parameters are essential for proper tool functionality. They:
- Inform the LLM about the expected data types for each parameter
- Enable FastMCP to validate input data from clients
- Generate accurate JSON schemas for the MCP protocol
Use standard Python type annotations for parameters:
Parameter Metadata
You can provide additional metadata about parameters using Pydantic’s Field
class with Annotated
. This approach is preferred as it’s more modern and keeps type hints separate from validation rules:
You can also use the Field as a default value, though the Annotated approach is preferred:
Field provides several validation and documentation features:
description
: Human-readable explanation of the parameter (shown to LLMs)ge
/gt
/le
/lt
: Greater/less than (or equal) constraintsmin_length
/max_length
: String or collection length constraintspattern
: Regex pattern for string validationdefault
: Default value if parameter is omitted
Supported Types
FastMCP supports a wide range of type annotations, including all Pydantic types:
Type Annotation | Example | Description |
---|---|---|
Basic types | int , float , str , bool | Simple scalar values - see Built-in Types |
Binary data | bytes | Binary content - see Binary Data |
Date and Time | datetime , date , timedelta | Date and time objects - see Date and Time Types |
Collection types | list[str] , dict[str, int] , set[int] | Collections of items - see Collection Types |
Optional types | float | None , Optional[float] | Parameters that may be null/omitted - see Union and Optional Types |
Union types | str | int , Union[str, int] | Parameters accepting multiple types - see Union and Optional Types |
Constrained types | Literal["A", "B"] , Enum | Parameters with specific allowed values - see Constrained Types |
Paths | Path | File system paths - see Paths |
UUIDs | UUID | Universally unique identifiers - see UUIDs |
Pydantic models | UserData | Complex structured data - see Pydantic Models |
For additional type annotations not listed here, see the Parameter Types section below for more detailed information and examples.
Optional Arguments
FastMCP follows Python’s standard function parameter conventions. Parameters without default values are required, while those with default values are optional.
In this example, the LLM must provide a query
parameter, while max_results
, sort_by
, and category
will use their default values if not explicitly provided.
Metadata
While FastMCP infers the name and description from your function, you can override these and add tags using arguments to the @mcp.tool
decorator:
name
: Sets the explicit tool name exposed via MCP.description
: Provides the description exposed via MCP. If set, the function’s docstring is ignored for this purpose.tags
: A set of strings used to categorize the tool. Clients might use tags to filter or group available tools.
Async Tools
FastMCP seamlessly supports both standard (def
) and asynchronous (async def
) functions as tools.
Use async def
when your tool needs to perform operations that might wait for external systems (network requests, database queries, file access) to keep your server responsive.
Return Values
FastMCP automatically converts the value returned by your function into the appropriate MCP content format for the client:
str
: Sent asTextContent
.dict
,list
, PydanticBaseModel
: Serialized to a JSON string and sent asTextContent
.bytes
: Base64 encoded and sent asBlobResourceContents
(often within anEmbeddedResource
).fastmcp.Image
: A helper class for easily returning image data. Sent asImageContent
.None
: Results in an empty response (no content is sent back to the client).
FastMCP will attempt to serialize other types to a string if possible.
At this time, FastMCP responds only to your tool’s return value, not its return annotation.
Error Handling
New in version: 2.3.4
If your tool encounters an error, you can raise a standard Python exception (ValueError
, TypeError
, FileNotFoundError
, custom exceptions, etc.) or a FastMCP ToolError
.
In all cases, the exception is logged and converted into an MCP error response to be sent back to the client LLM. For security reasons, the error message is not included in the response by default. However, if you raise a ToolError
, the contents of the exception are included in the response. This allows you to provide informative error messages to the client LLM on an opt-in basis, which can help the LLM understand failures and react appropriately.
Annotations
New in version: 2.2.7
FastMCP allows you to add specialized metadata to your tools through annotations. These annotations communicate how tools behave to client applications without consuming token context in LLM prompts.
Annotations serve several purposes in client applications:
- Adding user-friendly titles for display purposes
- Indicating whether tools modify data or systems
- Describing the safety profile of tools (destructive vs. non-destructive)
- Signaling if tools interact with external systems
You can add annotations to a tool using the annotations
parameter in the @mcp.tool()
decorator:
FastMCP supports these standard annotations:
Annotation | Type | Default | Purpose |
---|---|---|---|
title | string | - | Display name for user interfaces |
readOnlyHint | boolean | false | Indicates if the tool only reads without making changes |
destructiveHint | boolean | true | For non-readonly tools, signals if changes are destructive |
idempotentHint | boolean | false | Indicates if repeated identical calls have the same effect as a single call |
openWorldHint | boolean | true | Specifies if the tool interacts with external systems |
Remember that annotations help make better user experiences but should be treated as advisory hints. They help client applications present appropriate UI elements and safety controls, but won’t enforce security boundaries on their own. Always focus on making your annotations accurately represent what your tool actually does.
MCP Context
Tools can access MCP features like logging, reading resources, or reporting progress through the Context
object. To use it, add a parameter to your tool function with the type hint Context
.
The Context object provides access to:
- Logging:
ctx.debug()
,ctx.info()
,ctx.warning()
,ctx.error()
- Progress Reporting:
ctx.report_progress(progress, total)
- Resource Access:
ctx.read_resource(uri)
- LLM Sampling:
ctx.sample(...)
- Request Information:
ctx.request_id
,ctx.client_id
For full documentation on the Context object and all its capabilities, see the Context documentation.
Parameter Types
FastMCP supports a wide variety of parameter types to give you flexibility when designing your tools.
FastMCP generally supports all types that Pydantic supports as fields, including all Pydantic custom types. This means you can use any type that can be validated and parsed by Pydantic in your tool parameters.
FastMCP supports type coercion when possible. This means that if a client sends data that doesn’t match the expected type, FastMCP will attempt to convert it to the appropriate type. For example, if a client sends a string for a parameter annotated as int
, FastMCP will attempt to convert it to an integer. If the conversion is not possible, FastMCP will return a validation error.
Built-in Types
The most common parameter types are Python’s built-in scalar types:
These types provide clear expectations to the LLM about what values are acceptable and allow FastMCP to validate inputs properly. Even if a client provides a string like “42”, it will be coerced to an integer for parameters annotated as int
.
Date and Time Types
FastMCP supports various date and time types from the datetime
module:
datetime
- Accepts ISO format strings (e.g., “2023-04-15T14:30:00”)date
- Accepts ISO format date strings (e.g., “2023-04-15”)timedelta
- Accepts integer seconds or timedelta objects
Collection Types
FastMCP supports all standard Python collection types:
All collection types can be used as parameter annotations:
list[T]
- Ordered sequence of itemsdict[K, V]
- Key-value mappingset[T]
- Unordered collection of unique itemstuple[T1, T2, ...]
- Fixed-length sequence with potentially different types
Collection types can be nested and combined to represent complex data structures. JSON strings that match the expected structure will be automatically parsed and converted to the appropriate Python collection type.
Union and Optional Types
For parameters that can accept multiple types or may be omitted:
Modern Python syntax (str | int
) is preferred over older Union[str, int]
forms. Similarly, str | None
is preferred over Optional[str]
.
Constrained Types
When a parameter must be one of a predefined set of values, you can use either Literal types or Enums:
Literals
Literals constrain parameters to a specific set of values:
Literal types:
- Specify exact allowable values directly in the type annotation
- Help LLMs understand exactly which values are acceptable
- Provide input validation (errors for invalid values)
- Create clear schemas for clients
Enums
For more structured sets of constrained values, use Python’s Enum class:
When using Enum types:
- Clients should provide the enum’s value (e.g., “red”), not the enum member name (e.g., “RED”)
- FastMCP automatically coerces the string value into the appropriate Enum object
- Your function receives the actual Enum member (e.g.,
Color.RED
) - Validation errors are raised for values not in the enum
Binary Data
There are two approaches to handling binary data in tool parameters:
Bytes
When you annotate a parameter as bytes
, FastMCP will:
- Convert raw strings directly to bytes
- Validate that the input can be properly represented as bytes
FastMCP does not automatically decode base64-encoded strings for bytes parameters. If you need to accept base64-encoded data, you should handle the decoding manually as shown below.
Base64-encoded strings
This approach is recommended when you expect to receive base64-encoded binary data from clients.
Paths
The Path
type from the pathlib
module can be used for file system paths:
When a client sends a string path, FastMCP automatically converts it to a Path
object.
UUIDs
The UUID
type from the uuid
module can be used for unique identifiers:
When a client sends a string UUID (e.g., “123e4567-e89b-12d3-a456-426614174000”), FastMCP automatically converts it to a UUID
object.
Pydantic Models
For complex, structured data with nested fields and validation, use Pydantic models:
Using Pydantic models provides:
- Clear, self-documenting structure for complex inputs
- Built-in data validation
- Automatic generation of detailed JSON schemas for the LLM
- Automatic conversion from dict/JSON input
Clients can provide data for Pydantic model parameters as either:
- A JSON object (string)
- A dictionary with the appropriate structure
- Nested parameters in the appropriate format
Pydantic Fields
FastMCP supports robust parameter validation through Pydantic’s Field
class. This is especially useful to ensure that input values meet specific requirements beyond just their type.
Note that fields can be used outside Pydantic models to provide metadata and validation constraints. The preferred approach is using Annotated
with Field
:
You can also use Field
as a default value, though the Annotated
approach is preferred:
Common validation options include:
Validation | Type | Description |
---|---|---|
ge , gt | Number | Greater than (or equal) constraint |
le , lt | Number | Less than (or equal) constraint |
multiple_of | Number | Value must be a multiple of this number |
min_length , max_length | String, List, etc. | Length constraints |
pattern | String | Regular expression pattern constraint |
description | Any | Human-readable description (appears in schema) |
When a client sends invalid data, FastMCP will return a validation error explaining why the parameter failed validation.
Server Behavior
Duplicate Tools
New in version: 2.1.0
You can control how the FastMCP server behaves if you try to register multiple tools with the same name. This is configured using the on_duplicate_tools
argument when creating the FastMCP
instance.
The duplicate behavior options are:
"warn"
(default): Logs a warning and the new tool replaces the old one."error"
: Raises aValueError
, preventing the duplicate registration."replace"
: Silently replaces the existing tool with the new one."ignore"
: Keeps the original tool and ignores the new registration attempt.
Removing Tools
New in version: 2.3.4
You can dynamically remove tools from a server using the remove_tool
method:
Legacy JSON Parsing
New in version: 2.2.10
FastMCP 1.0 and < 2.2.10 relied on a crutch that attempted to work around LLM limitations by automatically parsing stringified JSON in tool arguments (e.g., converting "[1,2,3]"
to [1,2,3]
). As of FastMCP 2.2.10, this behavior is disabled by default because it circumvents type validation and can lead to unexpected type coercion issues (e.g. parsing “true” as a bool and attempting to call a tool that expected a string, which would fail type validation).
Most modern LLMs correctly format JSON, but if working with models that unnecessarily stringify JSON (as was the case with Claude Desktop in late 2024), you can re-enable this behavior on your server by setting the environment variable FASTMCP_TOOL_ATTEMPT_PARSE_JSON_ARGS=1
.
We strongly recommend leaving this disabled unless necessary.