MCP for Infrastructure: Give Agents Tools Without Leaking Keys

MCP is becoming the default language for connecting AI agents to tools.

The Model Context Protocol docs describe MCP as an open standard for connecting AI applications to external systems such as local files, databases, tools, and workflows. Anthropic's announcement framed MCP as a way to connect assistants to the systems where data lives.

That is exactly the right abstraction for infrastructure work.

It is also easy to get wrong.

The goal is not "give the model every tool." The goal is to give the agent the smallest useful tool surface, keep credentials local, gather evidence, and stop before high-impact actions run without review.

The MCP Infrastructure Use Case

Infrastructure questions are rarely isolated.

A useful agent needs to ask things like:

• Which Kubernetes deployment changed before the 502s started?
• Which cloud resources are public and untagged?
• What did the last GitHub Actions deploy change?
• Which database is driving this week's cost increase?
• Which Sentry errors map to the last rollout?
• What is the rollback path for this service?

Without tools, the model guesses.

With raw credentials, the model becomes too dangerous.

With a controlled MCP surface, the model can request evidence through local tools and produce a reviewable answer.

Connector Sprawl Is Not a Control Plane

The easiest MCP mistake is building one server per system with broad permissions:

• One for AWS.
• One for Kubernetes.
• One for GitHub.
• One for Datadog.
• One for Sentry.
• One for Terraform.
• One for Slack.
• One for Supabase.

That gives the agent reach, but not judgment. It also creates inconsistent permissions, logging, schemas, and approval logic.

Production infrastructure needs a control plane, not a pile of connectors.

Clanker Cloud's role is to sit in that middle layer: connect the existing stack, expose useful local context to MCP-capable agents, and preserve review-before-apply behavior.

A Good MCP Tool Is Narrow

Good tools answer specific operational questions.

Examples:

• list_kubernetes_workloads
• inspect_deployment_rollout
• find_recent_error_spikes
• summarize_cloud_cost_delta
• scan_public_exposure
• get_recent_deploys
• generate_reviewed_change_plan

Bad default:

• run_any_shell_command
• use_aws_admin
• kubectl_arbitrary
• terraform_apply
• delete_resource

Those broad tools may be useful for a human operator. They should not be the first interface an agent gets.

Keep Credentials Local

For cloud operations, the credential boundary matters more than the model choice.

The model does not need your AWS secret key. It needs the result of a constrained query.

The safer shape:

Agent
  -> MCP request
  -> Local Clanker Cloud or Clanker CLI tool
  -> Provider API using local credentials
  -> Evidence returned to agent
  -> Reviewed plan returned to human

The agent receives context. The credentials stay where they belong.

That pattern also works with BYOK models, local inference endpoints, Claude Code, Codex-style agents, and custom agent frameworks.

Design MCP Tools Around Risk

Classify tools into four tiers.

Read-Only Evidence

Safe default:

• Inventory.
• Status.
• Logs.
• Cost summaries.
• Security findings.
• Recent deploy metadata.

These tools should still log calls, but they can usually be available broadly.

Drafting and Planning

Useful but not destructive:

• Generate rollback plan.
• Draft Terraform patch.
• Create incident summary.
• Write remediation ticket.
• Compare config to policy.

These tools should include provenance: which data was used, which assumptions were made, and what needs human review.

Low-Risk Actions

Needs policy:

• Create ticket.
• Post summary.
• Tag non-production resource.
• Start read-only scan.

The action is not destructive, but it still affects systems.

High-Impact Actions

Require explicit review:

• Deploy.
• Rollback.
• Delete.
• Scale production.
• Change IAM.
• Rotate secrets.
• Apply Terraform.
• Modify database schema.

This is where Clanker Cloud's review-before-apply model matters most.

Add Observability to MCP Itself

OpenTelemetry now has semantic conventions for generative AI systems, including agent spans and MCP-related conventions.

That matters because an MCP call is an operational event.

Track:

• Agent identity.
• Tool name.
• Arguments.
• Result size.
• Duration.
• Error.
• Approval state.
• User who approved.
• Related incident or PR.

If an agent touched production context, there should be an audit trail.

The Takeaway

MCP makes agents useful because it connects them to tools. Infrastructure makes MCP risky because tools can change real systems.

The answer is not to avoid MCP. The answer is to put MCP behind a local, narrow, reviewable infrastructure workspace.

That is the Clanker Cloud pattern:

• Existing stack first.
• Local credentials.
• Purpose-built tools.
• Evidence before action.
• Reviewed deploy and remediation plans.
• Agentic-native cloud workflows next.

Agents need tools. They do not need unmanaged power.

Sources

• Model Context Protocol docs
• Anthropic: Introducing the Model Context Protocol
• OpenTelemetry GenAI semantic conventions
• Clanker Cloud MCP
• Clanker Cloud local credentials