This paper is a summary of the implemented OASIS3-MCT coupling interface implemented in WRF. The design of the interface is introduced in detail with two examples demonstrating the implemented framework. This work is very useful for modelers to develop coupled models. It is also important for scientists to understand the ocean-atmosphere interactions. I did not read or test all the code provided by the authors, but the code is written and documented in a good manner. The code is very clear and self-explanatory. The paper is also very well written. I only have a few minor concerns before publishing this work:

1. For the implementations described in Section 2, the implemented interface is specifically developed for WRF v4.6.0. If so, are there any plans to maintain this interface for higher or lower versions of WRF? Would it be easy to implement this interface for other WRF versions?
2. Line 155 is confusing to me. Do the authors separate the WRF code into three subroutines (init, run, finalize)? Or do the authors put functions in“frame/module_cpl_oasis3.F” used in these processes?
3. Are the authors using the existing WRF I/O streams (auxinput or auxhist) when getting the input or output? Why don’t use the existing ones? 
4. Line 236, when in the coupled experiment. I feel it is challenging to use WRF IO quilting when using the same processors for both Ocean and Atmosphere models. How should the ocean model set these processors for IO quilting? Have the authors tested this?
5. Section 3.3. Are the users free to add more variables for the coupling processes?
6. Section 4.1.3 is a very interesting example. Has anyone tested the nested domains in a realistic application? In addition, in Fig. 19 the filled color and the color of the boxes are very close. It would be better if the author could use a different colormap for the masks.
7. In Appendix 2, there is a typo in https://github.com/massonseb/WRF/blob/GMD_wrf_coupling/run/namecouple_example. It should be https://github.com/massonseb/WRF/blob/GMD_wrf_coupling/run/namcouple_example.

This technical paper describes the interface between WRF and the OASIS coupler (although the interface is conceived for use with any other coupler). It is clear, well-written, and interesting for the WRF and regional climate modeling community. I recommend it for publication after a few very minor issues are addressed.

1. The mention of the “most popular model” regarding WRF appears subjective (Short summary, and beginning); unless this is proven, suggest rephrasing L38: “among the most popular…” in both occurrences.
2. L38: not convinced that “numerical performances” are among the main reasons for the success of WRF. Unless the latest versions have changed this, WRF is known for limited scalability.
3. L61 please introduce the acronym C-Coupler used later
4. L83 the sentence “The de facto” needs to be rephrased for clarity
5. Section 2.3 refers to the standard OASIS functionalities. This needs to be stated clearly; also, the associated schemes (fig3) and text do not consider any delay (LAG) in the time-stepping to exchange fields and avoid deadlock communication. I recommend adding a discussion on that, which could be useful for many users.
6. L200 decision -> strategy
7. In Table 2, every interpolation method is given also with the “F” (BICUBIC and BICUBICF) without explaining the meaning
8. L281 as shown in Figure 9.
9. It is not clear why the use of relative wind is implemented only in two PBL schemes, and not in all; is there a specific reason? Can the authors at least say how to do it for the other schemes?
10. The same applies to the Charnock coefficient in the Revised MM5 Monin-Obukhov surface scheme, which could be discussed in more detail. What about other schemes?
11. L631 “other kinds”
12. In general, the technical paper will be very useful if associated with realistic examples collected by the authors and the community (in terms of masks, grids, namelists). The example provided in the github is quite limited (exchanges of only SST and TAUX); having at least two complete configuration examples (e.g., one with no nested domains and one with), complete as in realistic applications of all domain and grid files, the scripts to generate them and the associated namelists to run, could be very useful to guide users in their implementations.