Security engineers using Cloud SIEM spend their day-to-day investigating signals, tuning detection rules, managing suppressions, running historical jobs across interconnected workflows, and more. Agents are becoming a practical way to navigate that complexity, and we built a set of security tools for the Datadog MCP Server to support them.
Cloud SIEM is only one part of a broader cloud security ecosystem, so the Security MCP toolset has to grow across many teams and products. That growth comes with a constraint. The tools share a single context window, so every new tool consumes more of that window. Add enough tools and the agent can lose track of which one fits the task in front of it.
We built these tools under that constraint, and we’ll cover what we learned in this post. We’ll show how we scoped tools around what users already do and managed the shared context window with progressive disclosure. We’ll also cover how we tested non-deterministic agent behavior with a custom eval framework and governed a growing multi-team toolset.
Scope MCP tools around what users already do
Deciding what to build first is challenging for a product as broad as Cloud SIEM. Assumptions about what an agent should do can send you in the wrong direction and waste time and resources on developing tools that may prove unhelpful.
