From developer concept to buying criterion
"Tools" started as a developer concept: the functions an LLM is allowed to call, described by schemas, invoked during a conversation or task. The Model Context Protocol (MCP) standardized how products expose those tools, so any MCP-capable agent — Claude, IDE agents, custom harnesses — can connect to any MCP server without bespoke integration.
That standardization quietly turned agent tooling into a procurement question. If your team works alongside agents, a platform with no tool surface is a platform your agents can't touch — every workflow dead-ends at a human clicking through a UI. The tool count on a pricing page now matters the way "has an API" mattered in 2015.
What good agent tooling looks like
Four properties separate a real tool surface from a demo. Coverage: the tools span the product's actual operations, not a marketing subset — if a human can do it in the app, an agent can do it through a tool. Composability: tools are granular enough to chain (read segment → draft variant → stage placement → check lift), so the agent can build workflows the vendor never anticipated. Governance: scoped tokens, role gates, and human-review checkpoints, because "agent can act" must not mean "agent acts everywhere, unsupervised." Verifiability: every write has a read the agent can use to confirm what actually happened.
Agent tooling in AXO
AXO exposes 130+ MCP tools covering the full personalization loop: analytics and lift reads, campaign briefs, segment queries, variant drafting, placement changes, trigger management, and profile operations. The server runs as a hosted HTTP endpoint (no local install) or as a package, authenticated with scoped MCP tokens issued from the dashboard. The same operations are available over REST. Your team drives the app; your agents drive the tools; you decide where each is allowed to act without asking.