update why_mesc.md

sslivkoff · sslivkoff · commit bdcb4429b390 · 2024-01-28T20:10:49.000-08:00
diff --git a/docs/src/why_mesc.md b/docs/src/why_mesc.md
@@ -14,3 +14,13 @@ Instead it would be desirable to have a solution that:
 - is backwards compatible with previous solutions
 
 MESC aims to satisfy all of these constraints.
+
+
+## As a developer, why should I integrate MESC into my tools?
+
+- **Easier Onboarding**. As soon as a user installs your tool, they will be able to use your tool with all of their configured networks. This eliminates one of the major setup steps for most RPC consuming tools.
+- **Interoperability**. If you maintain multiple tools, or your tool has components in multiple languages, MESC will create a single, shared source of truth across all of these tool components.
+- **Safety and Robustness**. MESC is thoroughly tested against a large number of config-related edge cases. In many cases it will be safer to user MESC than to create a configuration system from scratch.
+- **Minimize maintenance burden**. Leaning on MESC to handle configuration means there is one less thing you need to maintain. You can spend your time on other things.
+- **Developer Features**. If you need to develop or test your tool with multiple endpoints, the `mesc` CLI tools contains many useful developer features for managing endpoints.
+- **Go config-free**. In some cases, adopting MESC means that your tool no longer needs its own config. You can store your tool's config data in MESC's metadata and then just use MESC for all config IO.
