𝗗𝗲𝘃 𝗟𝗼𝗴: 𝗠𝗖𝗣, 𝗘𝗺𝗮𝗶𝗹 𝗧𝗿𝗮𝗰𝗸𝗶𝗻𝗴, 𝗮𝗻𝗱 𝗠𝗲𝗻𝘂 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲
I spent the day building MCP servers, automated email tracking, and scalable admin menus.
Here are the core lessons from the work.
𝗠𝗖𝗣 𝗦𝗲𝗿𝘃𝗲𝗿 𝗦𝗮𝗳𝗲𝘁𝘆
I shipped a generic MCP toolbox and deployed servers across several enterprise apps. When building agents that can interact with your systems, follow these rules:
- Give agents read tools freely.
- Give write tools sparingly.
- Force every write action through a human-gated runbook.
- Hash passwords in your create-user tools. Never store plaintext.
- Use public UUIDs for audit logs. Never leak internal database IDs.
- Use a fallback for user context. An agent might use HTTP or STDIO. Ensure your code handles both.
𝗘𝗺𝗮𝗶𝗹 𝗧𝗿𝗮𝗰𝗸𝗶𝗻𝗴 𝗪𝗶𝘁𝗵𝗼𝘂𝘁 𝗠𝗮𝗻𝘂𝗮𝗹 𝗪𝗼𝗿𝗸
I built a system that tracks email opens and clicks automatically. Do not make developers add tracking pixels to every email. Instead, use a mail-sending listener.
- The listener intercepts the message.
- It injects the tracking pixel into the HTML.
- It wraps all links for click tracking.
- It adds a metadata hash for easy correlation.
Two important notes:
- Avoid Mail::raw(). It skips the HTML rewriting path. Use proper HTML Mailables to ensure tracking works.
- Set tracking to "on" by default. If users have to enable it, they will forget.
𝗦𝗰𝗮𝗹𝗮𝗯𝗹𝗲 𝗔𝗱𝗺𝗶𝗻 𝗠𝗲𝗻𝘂𝘀
When you manage menus across multiple apps, do not use one giant file. Use small builder classes for each group.
- Create one class per group (e.g., Settings, User Management).
- Each class declares its own items and required permissions.
- This keeps your navigation declarative.
- Truncate long labels inside the component, not on a per-item basis.
- Gate tools behind two checks: user permissions and the specific app edition.
𝗧𝗵𝗲 𝗕𝗶𝗴𝗴𝗲𝗿 𝗣𝗶𝗰𝘁𝘂𝗿𝗲
The goal is to make the safety net automatic.
If a diagnostic tool is useful, turn it on by default. If you have to remember to turn it on, you will not have it when a system fails at 2 AM. Encode your lessons into your tools so you do not have to relearn them.