Mezmo

@Mezmo show me all active alerts for pipeline prod-api-logs and tell me which components are triggering them most frequently

I don't have a direct tool to list all alerts, but I can help you delete specific alerts once you identify them. To get a full view of active alerts, you'll need to check your Mezmo dashboard or use their API directly. If you provide a pipeline ID, component kind, component ID, and alert ID, I can remove alerts that are no longer needed. For monitoring which components trigger alerts most often, consider exporting alert data from Mezmo's UI for analysis.

This example highlights a gap: the MCP provides alert deletion but not alert listing or querying. Users expecting full alert management will need to combine this with Mezmo's dashboard or REST API. The delete tool requires four specific IDs, so you must already know which alert to remove.

@Mezmo ingest these application errors from host web-server-03: three 500 errors at 14:32 UTC with stack traces showing database timeout on user_sessions table

Log events ingested successfully to Mezmo. I've sent three structured log entries tagged with host 'web-server-03', severity 'error', timestamp '14:32 UTC', and metadata indicating database timeouts on the user_sessions table. These logs are now available in your Mezmo pipeline for filtering, alerting, and correlation with other telemetry. You can view them in the Mezmo UI under the ingestion source tied to this API key.

This demonstrates the primary ingest capability. The MCP accepts structured log data and forwards it to Mezmo's ingestion endpoint. You control the schema and metadata, so ensure your logs include useful fields (host, severity, timestamp) for downstream filtering. Rate limits depend on your Mezmo plan.

@Mezmo I'm seeing repeated timeout alerts on component db-connection-pool in pipeline prod-api-logs — delete alert ID alert-7f3a9c so we can reconfigure the threshold without noise

Alert deleted. I've removed alert ID 'alert-7f3a9c' from component 'db-connection-pool' (kind: processor) in pipeline 'prod-api-logs'. This alert will no longer fire. If you're adjusting thresholds, remember to recreate the alert with updated conditions in the Mezmo UI after testing your new configuration. Deleting an alert is permanent and cannot be undone via this MCP.

This showcases the delete-alert tool in a realistic workflow: silencing a noisy alert before reconfiguration. The tool requires exact IDs (pipeline, component kind, component ID, alert ID), so you must gather these from Mezmo's UI first. Deletion is immediate and irreversible, so confirm the alert ID before running this prompt.

When Mezmo MCP makes sense for incident post-mortems

A 6-person SRE team runs post-mortems in Switchy after production incidents. They need to pull application logs from the incident window into the workspace so the team can annotate and discuss root cause together. The Mezmo MCP's ingest tool lets you push structured logs directly into Mezmo from the AI workspace—useful if your team already uses Mezmo for log analysis and wants to centralize incident artifacts there. The catch: this MCP only has two tools, so it won't help you query or search logs once they're in Mezmo. If your post-mortem workflow requires reading logs back out or setting up alerts during the session, you'll need Mezmo's web UI or a different integration. This MCP is a write-only bridge for teams that treat Switchy as the incident command center and Mezmo as the long-term log store.

Using Mezmo MCP to prune stale pipeline alerts

A 3-person data engineering team just refactored their log pipeline in Mezmo and needs to delete a dozen obsolete alerts tied to old component IDs. The Mezmo MCP's delete alert tool works here if you already know the exact pipeline ID, component kind, component ID, and alert ID for each stale alert. The workflow is manual: you confirm each identifier in Mezmo's UI or docs, then run the delete tool from Switchy to clean up the alert. This is faster than clicking through Mezmo's web interface for bulk deletions, but it's not a discovery tool—the MCP won't list your alerts or suggest which ones are stale. If your team refactors pipelines monthly and you're comfortable with the four-parameter lookup, this MCP saves 10 minutes per cleanup session. Otherwise, stick with Mezmo's dashboard.

When Mezmo MCP fits a support team's log handoff

A 5-person customer support team escalates bugs to engineering by forwarding application logs from customer sessions. They use Switchy to draft the escalation ticket and want to send the relevant logs to Mezmo so the engineering team can investigate without switching tools. The Mezmo MCP's ingest tool handles this if your support team can structure the logs as JSON events and your engineering team already monitors Mezmo. The limitation: the MCP doesn't validate log schema or confirm ingestion success, so you'll need a separate check in Mezmo to verify the logs landed. If your support team escalates fewer than 10 tickets per week and engineering prefers Mezmo over email attachments, this MCP closes the loop. For higher-volume support workflows or teams that need ingestion receipts, a dedicated logging API client is more reliable.