MCP and Tool Layers for B2B AI Agents

What a tool layer is (and is not)

A tool layer is the contract between the agent and your systems: named operations, typed inputs/outputs, auth context, rate limits, and side-effect policy. MCP and similar protocols standardize how hosts discover and invoke those tools; they do not replace product design. It is not a pass-through to every internal microservice. Discovery of fifty write endpoints is how agents invent creative disasters. Treat tools like a public API for a semi-trusted caller (the model): least privilege, validation, idempotency, and audit by default.

• Protocol choice ≠ security model
• Catalog should be curated per agent and persona
• Side-effecting tools need stronger gates than read tools
• Human approval sits above tools, not inside every connector

Narrow tools vs god-mode APIs

Prefer `get_order_status(order_id)`, `create_draft_ticket(...)`, `propose_price_change(...)` over `run_sql`, `call_http`, or `erp_proxy(any)`. Narrow tools encode intent and make allowlists, tests, and UX evidence cards tractable. If you must wrap a wide backend, put a facade in front: allowlisted routes, field masks, and max blast radius (e.g. single record updates). Never hand the model a bearer token with admin ERP scope. Composition belongs in the graph (multiple narrow calls), not in one mega-tool that 'figures it out'.

• One business intent per tool when practical
• Ban arbitrary code execution and raw shell in production agents
• Separate read catalogs from write catalogs
• Review new tools like API additions in CAB or design review

Permissions and the authenticated principal

Every tool invocation runs as a user (or tightly scoped service identity) with tenant and role. Inherit rights from SSO and identity; do not escalate to a shared god account to 'make the demo work'. Check authorization before the outbound call. Log denials. Partner and plant-scoped roles must survive into tool filters the same way as UI routes. Align with enterprise AI security for prompt injection and tool exfiltration risks: untrusted ticket text is data, not an instruction to widen scope.

Schemas, validation, and idempotency

Publish JSON schemas (or equivalent) for every tool. Validate enums, ranges, IDs, and required fields at the boundary. Reject unknown properties when they enable smuggling. Side-effecting tools take idempotency keys and return stable result shapes so retries from agent graphs do not double-post. Keep error messages actionable for the graph (retryable vs fatal vs needs human) without leaking stack traces or secrets to the model context.

ERP, CRM, and ticket connectors

Connectors are productized integrations, not weekend scripts. Map to systems of record with clear ownership per data readiness. Prefer draft/propose tools plus human-in-the-loop before irreversible ERP posts. Ticket and CRM tools should field-mask PII and respect record-level ACL. Bulk operations need hard caps and confirmation gates. Sandbox credentials, contract tests, and replay fixtures belong in delivery acceptance—see ERP integration practices.

• Draft then commit patterns for money-moving systems
• Stable external IDs in tool results for audit and UI
• Circuit breakers when ERP latency or error rates spike
• Never invent record IDs in the model—lookup tools only

RAG and search as tools

Expose retrieval as an explicit tool with tenant filters and confidence—not ambient context stuffing. Follow production RAG for ACL and evaluation. Return chunk IDs and citations the UI and HITL cards can render. Cap result size so agents cannot drown themselves in tokens. Keep write tools and retrieval tools in separate permission sets.

Versioning and compatibility

Tool names and schemas are contracts. Version breaking changes (`create_ticket` → `create_ticket_v2`) and keep old versions until graphs and prompts migrate. Apply the same discipline as API design and versioning. Pin agents to a tool catalog version in production. Silent schema drift mid-flight causes mysterious failures and unsafe retries. Document deprecation windows for contractors and internal teams alike.

Observability for tool calls

Trace tool name, latency, success/failure class, tenant, correlation ID, and whether a human gate followed. Feed observability dashboards and alerts on error spikes and unusual write volumes. Redact sensitive fields in traces. Retain enough to debug 'why did we post this order' without storing full PII payloads forever. Pair with testing strategy: contract tests per tool, chaos for dependency outages, and golden agent scenarios that assert which tools may be called.

• Alert on novel tool sequences that bypass expected graphs
• Budget max tool calls per run
• Sample production traces for permission anomalies
• Include tool metrics in go-live readiness reviews

MVP delivery and contractor gates

Ship a minimal catalog for one journey: a few reads, one draft write, one commit-after-approval. Non-goals: open MCP to the whole enterprise API surface on day one. Acceptance: schema validation, ACL tests, idempotent writes, audit of tool args/results IDs, runbooks for connector outage. Tie to contractor hiring, AI acceptance criteria, and production readiness. Cost the tool layer in estimates—connectors and safety rails dominate model fees for real B2B agents.

Next steps

List every tool your agent would need for one vertical journey. Cross out any that are wider than a single business intent. What remains is your v1 catalog. Then review agentic AI, human-in-the-loop UX, other resources, case studies, book a call, or contact before connecting agents to ERP or CRM with broad credentials.

FAQ