Skip to main content
Tools are where reasoning touches the world. Their design decides more about safety and reliability than any prompt — and their sprawl is the most common self-inflicted wound in agent engineering.

​
3.1 Fewer, better tools

The most instructive published lesson in the category comes from Microsoft’s Azure SRE Agent team, who have written candidly that they began with more than a hundred tools across dozens of narrowly specialized agents — and shipped with a handful of core tools and more generalist agents. Every tool added is context the model must carry, a decision surface it can get wrong, and an interface you must version and test. Design rules that hold up:
  1. Tools are capabilities, not API endpoints. Wrap intent (“get recent deploys for service S”, “top slow queries on database D”), not raw verbs. One good capability replaces five thin wrappers and removes argument-guessing errors.
  2. Descriptions are prompts. The model chooses tools by their descriptions. Write them like documentation for a sharp new hire: when to use, when not to use, what the result contains, cost and latency notes for expensive probes.
  3. Read and write are different species. Separate read tools (freely usable inside the loop) from write tools (policy-gated, Chapter 6) at the interface level, not by convention. The agent should be structurally unable to mutate through a read path.
  4. Results are context — shape them. Return structured, pre-summarized, size-capped results with pointers to full data. A tool that returns 80,000 raw log lines is an attack on your own context budget.
  5. Idempotency and dry-run on every write. Every mutating tool supports plan/preview, executes idempotently, and returns a machine-checkable result. This is what makes verification (Chapter 1) and rollback (Chapter 6) engineering rather than hope.

​
3.2 Skills and runbooks: operational knowledge as code

Above atomic tools sits the layer that encodes procedure: skills — parameterized, versioned units of operational capability (“rotate credentials for X”, “drain and recycle node pool Y”, “collect the evidence bundle for incident class Z”). Skills are where the determinism boundary from Chapter 1 becomes reusable: the model selects and parameterizes; the skill executes as tested code with its own pre-flight checks, timeouts, and rollback hooks. Engineering implications: skills live in version control with owners, tests, and changelogs; they declare their blast radius and reversibility so policy (Chapter 6) can classify them automatically; and their execution telemetry feeds evaluation (Chapter 7). A platform’s skill catalog — how rich, how tested, how declarative about risk — is a better maturity signal than its demo.
IN PRACTICE — A CATALOG WITH DECLARED RISKCloudThinker ships 325+ CloudSkills spanning cloud, Kubernetes, database, security, and cost surfaces; each declares its access class (read/write), reversibility, and required policy level, which is what lets the Action Engine auto-classify it into the approval model instead of relying on a human to remember which script is dangerous. When evaluating any platform, ask to see the skill metadata, not the skill list.

​
3.3 MCP in production

The Model Context Protocol has become the de facto standard for connecting agents to tools and data — the reason a platform can integrate an observability stack or a ticketing system without bespoke glue, and the one technical standard that matters across every group of the 2026 AI-SRE landscape: if a platform speaks MCP, agents and tools from different vendors compose; if it does not, you are buying an ecosystem. Production use, however, is not plug-and-play. The engineering checklist:
  • Server trust is supply-chain trust. An MCP server is code with credentials. Pin versions, review before upgrade, allowlist which servers each agent may load, and prefer first-party or audited servers for anything touching production. Tool descriptions themselves are injectable surfaces (Chapter 5) — treat third-party tool metadata as untrusted input.
  • Auth follows the agent, not the server. Credentials scoped per agent identity and per environment, short-lived, brokered — never a shared service account behind a popular server.
  • Version the contract. Tool schemas drift. Contract-test the tools your runbooks depend on so a server upgrade cannot silently change argument semantics under a working skill.
  • Egress-map every server. Know which servers can reach the internet and which are perimeter-only; this is the difference between a data-exfiltration path and a contained integration (Chapter 5).
One clarification worth engineering into your mental model: integration is not sensing. Connecting tools so agents can act on systems (the MCP layer) and pushing events from systems into the platform so agents notice (the sensing pipeline, Chapter 4) are different mechanisms with different reliability and security profiles. Platforms — and diagrams — that blur them usually have a gap in one.
KEY TAKEAWAYDesign few, intent-shaped tools with structurally separated read/write paths; encode procedure as versioned, risk-declaring skills; and treat MCP as production supply chain — pinned, allowlisted, contract-tested, egress-mapped. The tool layer is where “the agent did something weird” is either impossible or inevitable.