How to disable mongodb shell logs?
You can use the --quiet option to suppress output including the mongo shell version and startup warnings during the connection process.
Those startup warnings are usually issues an administrator would want to be aware of, but you may prefer to suppress them for a development environment or for running scripts. For a production system you would be best addressing the reported issues to remove future startup warnings.
For example, connecting to a 3.6 deployment with a 4.4 shell:
$ mongo 
MongoDB shell version v4.4.3
connecting to: mongodb://127.0.0.1:27017/?compressors=disabled&amp;gssapiServiceName=mongodb
Implicit session: session { &quot;id&quot; : UUID(&quot;f9219e8d-01ff-46e6-9e9d-b4de68207bdf&quot;) }
MongoDB server version: 3.6.17
WARNING: shell and server versions do not match
---
The server generated these startup warnings when booting:
2021-02-04T21:57:55.555+1100 I CONTROL  [initandlisten]
2021-02-04T21:57:55.555+1100 I CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.
2021-02-04T21:57:55.555+1100 I CONTROL  [initandlisten] **          Read and write access to data and configuration is unrestricted.
2021-02-04T21:57:55.555+1100 I CONTROL  [initandlisten]
2021-02-04T21:57:55.555+1100 I CONTROL  [initandlisten]
2021-02-04T21:57:55.555+1100 I CONTROL  [initandlisten] ** WARNING: soft rlimits too low. Number of files is 256, should be at least 1000
---

Adding --quiet and connecting to the same MongoDB deployment:
$ mongo --quiet
&gt; 

The warnings being suppressed in this example indicate:

My mongo shell version (v4.4.3) is much newer than my server version (v3.6.17). Mixing these versions may have unexpected outcomes, particularly given so many intervening MongoDB releases. For a local installation I normally expect these versions to be identical, and for production usage I would want the major versions to be matching (i.e. both v4.4.x or v3.6.x).
Access control is not enabled on this deployment, so anyone can connect with full access to read &amp; write data. This is a serious issue for a production deployment, but I would follow the MongoDB Security Checklist for any deployment where you are concerned about securing your data.
Resource limits are too low, so this deployment may run into problems with too many connections or open files. I would certainly fix this warning for a production environment, but also address for a development environment to avoid unexpected interruptions.