Dev Log: MCP, Email Tracking, and Menu Structure
I spent the day building MCP servers, automated email tracking, and scalable admin menus.
Here are the core lessons from the work.
MCP Server Safety
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.
Email Tracking Without Manual Work
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.
Scalable Admin Menus
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 Bigger Picture
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.