Two design principles matter more than anything else in step 2. First, return structured data, not raw text. If your tool dumps 50 MB of raw logs into the agent’s context, you have built an expensive way to confuse it. Pre-filter, aggregate, and attach severity levels and stable identifiers so the agent can reason over findings. Second, keep every tool read-only. The agent forms hypotheses; humans approve actions. Your MCP layer should make the wrong thing impossible, not just discouraged.<\/p>\n
What DevOps Agent requires from your server<\/h2>\n
Before writing code, check your server against the connection requirements, because two of them catch people out:<\/p>\n
- \n
- Transport:<\/strong> only the Streamable HTTP transport is supported. A stdio-based local server that works fine with your IDE will not connect here.<\/li>\n
- Authentication:<\/strong> the server must support OAuth 2.0 (client credentials or 3LO), API key\/token auth, or AWS SigV4.<\/li>\n
- Tool naming:<\/strong> tool names are capped at 64 characters, and there is a per-Agent-Space quota on total MCP tools.<\/li>\n<\/ul>\n
A minimal tool definition for an ALB log query looks like this (Python, FastMCP style):<\/p>\n
@mcp.tool()
\ndef query_alb_access_logs(
\nlb_name: str,
\nstart_time: str,
\nend_time: str,
\nstatus_code_filter: str = “5xx”
\n) -> dict:
\n“””Query ALB access logs in S3 via Athena for a time window.
\nReturns aggregated counts by target, status code and
\nelb_status_code vs target_status_code mismatches.”””
\n…<\/p><\/blockquote>\nNote what the tool returns: aggregations and mismatch flags, not log lines. The docstring matters too, because it is the primary signal the agent uses to decide when this tool is relevant.<\/p>\n
Hosting on Amazon Bedrock AgentCore<\/h2>\n
You can host an MCP server anywhere that speaks Streamable HTTP, but Bedrock AgentCore Runtime is the path of least resistance for AWS-heavy environments. You get serverless deployment of the MCP server, session isolation, IAM\/SigV4 auth without building an auth layer yourself, and an endpoint that DevOps Agent can reach without you managing load balancers or certificates. AWS’s own reference implementations, including the packet-capture MCP server for network investigations, deploy exactly this way.<\/p>\n
The deployment flow in short: package the server, deploy it to AgentCore Runtime (the starter toolkit or CDK both work), note the endpoint ARN\/URL, then register it in the DevOps Agent console under your Agent Space’s integrations with the matching auth method.<\/p>\n
![\"Add](\"https:\/\/www.tothenew.com\/blog\/wp-ttn-blog\/uploads\/2026\/09\/image-38-1024x562.png\")
Add MCP server to an Agent space<\/p><\/div>\n
<\/h2>\n
Permissions: allowlist narrow, grant read-only<\/h2>\n
This is the part regulated environments care about, and AWS’s guidance here is blunt for good reason. Custom MCP servers widen the agent’s reach, which also widens the prompt-injection surface: log lines and ticket text are untrusted input that flows into the agent’s context.<\/p>\n
Three controls keep this sane:<\/p>\n
- \n
- Allowlist specific tools<\/strong>, not the whole server. If your server exposes twelve tools and an investigation class needs three, grant three.<\/li>\n
- Read-only credentials end to end.<\/strong> The IAM role or API token behind the MCP server should be incapable of mutation, so even a successfully injected instruction has nothing destructive to execute.<\/li>\n
- Scope by Agent Space.<\/strong> Separate spaces for prod and non-prod, each with its own MCP connections and credential sets, mirroring the account boundaries you already run.<\/li>\n<\/ul>\n
Skills: teaching the agent when to use your tools<\/h2>\n
Connecting tools gets you capability. Agent Skills get you consistency. A skill is a folder with a SKILL.md file (plus optional references and assets) that encodes an investigation playbook, and the agent loads it on demand when the task matches.<\/p>\n
The highest-value use of skills is pairing them with your custom MCP tools. Our 502-investigation skill, for example, tells the agent: when an ALB 5xx alarm fires and targets are healthy, call
query_alb_access_logs<\/code> first, compareelb_status_code<\/code> againsttarget_status_code<\/code>, and if they diverge, check idle-timeout configuration on both sides before considering application-level causes. Without the skill, the agent may still find its way there. With it, the investigation follows the same path a senior engineer would take, every time, including at 2 AM.<\/p>\nSkills are managed from the Knowledge page of the Operator Web App, where you can upload them as zip files or edit them inline.<\/p>\n
What changes in practice<\/h2>\n
With the MCP server and skill in place, the same 502 scenario plays out differently. The alarm fires, the agent runs its native checks, then calls the custom log-query tool, spots the status-code mismatch, pulls the timeout values, and posts a hypothesis to the incident channel with the supporting evidence attached, before the on-call engineer has finished reading the page. The engineer’s job shifts from data collection to decision-making: approve the fix or dig further.<\/p>\n
That is the honest promise of this architecture. Not autonomous remediation, but an investigation that arrives at your desk already 80% done, grounded in data sources that no out-of-the-box agent could reach.<\/p>\n
Conclusion<\/h2>\n
AWS DevOps Agent is only as good as its visibility, and MCP is how you extend that visibility into the systems that actually hold your root causes. The recipe is repeatable: wrap the data source in a read-only MCP server, host it on Bedrock AgentCore, allowlist narrowly, and encode your runbooks as skills so the agent investigates the way your best engineers do. Start with the one data source your team greps manually during every incident. That is where the payback is fastest.<\/p>\n
Don’t just read about technology \u2013 experience it firsthand. Schedule a call with us today!<\/a><\/strong><\/p>\n
- Read-only credentials end to end.<\/strong> The IAM role or API token behind the MCP server should be incapable of mutation, so even a successfully injected instruction has nothing destructive to execute.<\/li>\n
- Authentication:<\/strong> the server must support OAuth 2.0 (client credentials or 3LO), API key\/token auth, or AWS SigV4.<\/li>\n