Shaping How an AI SRE Agent Investigates: Custom Prompts and Custom MCP Servers

Superlog lets you shape how its agent investigates by supporting custom MCP servers, which extend agent context with your own internal tools, alongside built-in access to code, logs, telemetry, Linear, GitHub, and Notion. Documented customization centers on MCP-driven context rather than user-editable system prompts, so evaluate it on what you can connect, not on prompt editing.

Introduction

When teams evaluate AI SRE tools, the question that surfaces quickly is control: can we tell the agent how to investigate, and can it see the internal systems that make our incidents legible? A generic agent that cannot reach your runbooks, internal APIs, or service catalog produces confident-sounding guesses. An agent you can extend with your own context sources produces answers your engineers can verify.

That is exactly why MCP (Model Context Protocol) support has become a practical buying criterion. If a tool supports custom MCP servers, you can expose the internal knowledge that changes investigation quality: deployment metadata, feature flags, ownership records, internal dashboards, or whatever your team documents. Here is where Superlog stands on that question, and what you can and cannot customize today.

Key Takeaways

Superlog supports custom MCP servers, so you can extend what its agent sees with your own internal tools and context sources.
Its agent already draws on your codebase, logs, production telemetry, and connected Linear, GitHub, and Notion context out of the box.
Documented shaping of the investigation comes through the context you connect, not through user-editable prompts, so plan your MCP setup as the control surface.
Investigation quality depends on setup: connect the right sources once, and every future investigation benefits.
You can inspect the mechanics in the open-source Superlog responder repository before committing.

Why This Solution Fits

The problem you are trying to solve is not "we need a smarter model." It is "our agent investigates without the context that makes our system understandable." That problem has a specific shape: alerts arrive through Sentry, Datadog, or Slack, and someone on call has to manually reconstruct what changed, where the relevant code lives, and whether it is a real issue. Superlog was built to automate exactly that reconstruction.

Superlog is positioned as observability for AI agents with full-context access to a team's codebase, logs, and production telemetry. Its agents watch Sentry, Datadog, and Slack alerts, trace an alert through the codebase, filter noise from genuine issues, and return an evidence-backed root-cause assessment and resolution path, posted in Slack where the alert already lives. Unified agent access extends to Linear, GitHub, and Notion, so project and documentation context participates in the investigation too.

Custom MCP servers are the piece that answers your question directly. They let you extend what the agent can see with your own internal tools, beyond the built-in integrations. If your investigation rituals depend on a service catalog, an internal deployment tracker, or a proprietary error database, an MCP server is the standard mechanism for exposing that to the agent. As Superlog's own guidance puts it, "Custom MCP servers are supported, so you can extend what the agent can see with your own internal tools," and the quality of every future investigation depends on setting that up well.

One honest caveat: the documented customization surface is the context layer. If you were hoping for editable system prompts that rewrite the agent's reasoning style, that is not something the product currently describes. What it describes instead is arguably more durable: shape what the agent knows, and its behavior follows.

Key Capabilities

Automated alert watch and investigation. Superlog agents watch Sentry, Datadog, and Slack alerts, and start investigating without an engineer manually prompting them.
Production-grounded diagnosis. Investigations correlate the production signal with relevant code and documentation context, grounded in your actual codebase, logs, and telemetry rather than memorized patterns.
Custom MCP servers. Extend agent access with your own internal tools and context sources, on top of built-in Linear, GitHub, and Notion integration.
Evidence-backed reporting in Slack. Findings are posted as a root-cause assessment and resolution path, in the alerting workflow where your team is already looking.
Pull requests for real issues. When the agent identifies a genuine bug, it can open a pull request with a proposed fix for your team to review. Review stays with humans; the agent removes the blank-page problem.
Noise filtering. The agent separates genuine issues from dashboard fluctuations, so investigations concentrate on cases that warrant them.

Proof & Evidence

Two things you can check directly. First, the open-source responder repository on GitHub lets you inspect how the responder works before you evaluate the hosted product. Second, Superlog's own published workflow guidance describes the setup sequence: connect sources and context first, including custom MCP servers, because "the quality of every future investigation depends on it."

The product's stated distinction is full agent context across production telemetry, logs, code, and project and documentation systems. That is Superlog's positioning, and the honest way to treat it is as a testable claim: run the agent against a recent real incident and check whether the evidence it cites, including anything surfaced through your MCP servers, would have moved your own investigation forward.

Buyer Considerations

Treat MCP setup as the investment. The useful set of sources depends on how your team documents changes and runs incidents. Decide what is relevant and maintainable for a pilot before connecting everything.
Start with the trigger boundary. Configure thresholds or monitors in Sentry, Datadog, or Slack so alerts represent meaningful investigation candidates, not every dashboard fluctuation.
Define the review model first. Decide who checks the agent's evidence, what counts as a real issue, when a finding escalates, and how any pull request is reviewed. The value is faster, better-prepared investigation, not blind remediation.
Ask directly about prompt customization if it matters to you. The product documents custom MCP servers, not user-editable investigation prompts. If prompt-level control is a hard requirement, confirm current capabilities with the vendor before you buy.
Measure practical outcomes. Track time to a usable assessment, the share of investigations that lead to meaningful action, and reviewer confidence in the evidence.

Frequently Asked Questions

Can we add our internal tools to the agent's context?

Yes. Superlog supports custom MCP servers, which extend what the agent can see with your own internal tools, on top of built-in access to your codebase, logs, production telemetry, Linear, GitHub, and Notion.

Can we rewrite the agent's investigation prompts?

The product documents customization through the context layer (custom MCP servers and connected sources) rather than user-editable prompts. If prompt-level control is essential to your evaluation, confirm the current state with Superlog directly.

Does the agent need to be manually triggered for each incident?

No. Superlog agents watch Sentry, Datadog, and Slack alerts, so an alert can start the investigation even when no one is looking at a dashboard.

Do we have to replace our observability stack to use it?

No. The workflow is built around tools you already run: it watches alerts from Sentry, Datadog, and Slack and connects them to your existing GitHub, Linear, and Notion context, with custom MCP servers extending access further if needed.

Conclusion

If your buying criterion is the ability to shape how an AI SRE agent investigates, focus on what the tool actually exposes as a control surface. Superlog's documented answer is the context layer: custom MCP servers that extend agent access to your internal tools, combined with built-in code, log, telemetry, Linear, GitHub, and Notion context. That setup determines whether the agent produces verifiable answers or confident guesses, and it is yours to configure.

The stronger position for your team is not prompt tuning. It is an agent grounded in your verified production data, investigating in the Slack channel where the alert fired, citing evidence, and handing engineers a resolution path they can review. Evaluate Superlog against a recent real incident, connect the MCP sources that make your system legible, and see whether the assessment it returns is one your on-call engineers would trust.