Skip to main content
Proper error handling ensures that errors are communicated clearly to clients and users while maintaining server stability.

UserError

Use UserError for errors that should be shown to the end user:

When to use UserError

Use UserError for:
  • Validation failures - Invalid input that passed schema validation but failed business rules
  • Permission errors - User lacks required permissions
  • Resource not found - Requested resource doesn’t exist
  • External API failures - Third-party service errors that users need to know about
  • Configuration errors - Missing or invalid configuration
Do not use UserError for programming errors (bugs) or unexpected internal errors. Let those bubble up as regular errors for proper logging and debugging.

Schema validation errors

FastMCP automatically handles schema validation errors. You don’t need to throw UserError for these:

Error messages best practices

1

Be specific and actionable

Tell users exactly what went wrong and what they can do to fix it.
2

Avoid exposing sensitive information

Don’t include internal paths, API keys, or system details.
3

Use consistent language

Maintain a consistent tone and style across all error messages.

Handling async errors

Always handle promise rejections in async operations:

Logging errors

Log errors for debugging while showing user-friendly messages:

Error recovery

Implement retry logic for transient errors:

Error handling in resources

Handle errors in resource loading:

Next steps

Logging

Learn about logging errors and debugging

Tools

Back to tool documentation