diff --git a/src/docs/asciidoc/tcp-client.adoc b/src/docs/asciidoc/tcp-client.adoc
index a5ee1ff7df..f635726192 100644
--- a/src/docs/asciidoc/tcp-client.adoc
+++ b/src/docs/asciidoc/tcp-client.adoc
@@ -302,15 +302,15 @@ public class Application {
 
 == Connection Pool
 
-By default, the `TCP` client uses a "`fixed`" connection pool with `500` as a maximum number of the channels and
-`45s` as acquisition timeout.
+By default, the `TCP` client uses a "`fixed`" connection pool with `500` as the maximum number of the channels and
+`45s` as the acquisition timeout.
 This means that the implementation creates a new channel if someone tries to acquire a channel but none is in the pool.
-When the maximum number of the channels in the pool is reached, new tries to acquire a channel will be delayed
+When the maximum number of the channels in the pool is reached, new tries to acquire a channel are delayed
 until a channel is returned to the pool again.
 The implementation uses `FIFO` order for channels in the pool regardless of whether it is "`elastic`" or "`fixed`".
-By default there is no idle time specified for the channels in the pool
+By default, there is no idle time specified for the channels in the pool.
 
-If you need a "`elastic`" connection pool, you can apply the following configuration by using
+If you need an "`elastic`" connection pool, you can apply the following configuration by using
 {javadoc}/reactor/netty/resources/ConnectionProvider.html[`ConnectionProvider`].
 The following example shows how to do so:
 
@@ -389,7 +389,7 @@ public class Application {
 ----
 ====
 
-NOTE: Be cautious with "`elastic`" connection pool when you expect a high load. You might experience
+NOTE: Be cautious with an "`elastic`" connection pool when you expect a high load. You might experience
 `reactor.netty.http.client.PrematureCloseException` exception with a root cause "Connect Timeout" due
 to too many concurrent connections opened/acquired.