Each tool should do exactly one thing with a clear input schema, predictable output, and idempotent behavior when possible. 'update_ticket' is a good tool. 'handle_ticket' (which might update, delete, or escalate depending on context) is a bad tool — the agent cannot reason about its effects.

Follow read-before-write patterns: give the agent a 'get_ticket' before 'update_ticket' so it always sees current state before making changes. Destructive tools (delete, send external email, charge payment) should require explicit confirmation or a separate approval step.

Write tool descriptions for the model, not for developers. 'Search the knowledge base for articles matching a query. Returns title, snippet, and URL for each match. Use this before answering product questions.' beats 'Calls /api/v2/kb/search with query param.' The model chooses tools based on descriptions — vague descriptions lead to wrong tool selection.

Model Context Protocol (MCP) standardizes how agents connect to external systems — Slack, GitHub, databases, CRMs, and internal APIs. Instead of building custom integrations for every tool, MCP provides a universal connector format.

For agent products, MCP matters in two ways: as a consumer (your agent connects to MCP servers for Slack, Google Drive, etc.) and as a provider (you expose your agent's capabilities as an MCP server that other tools can call). Start by consuming — ship MCP connectors for the 2-3 integrations your ideal customer profile uses daily.

Do not try to support every MCP server on day one. Pick the integrations that appear in 80% of your design partner workflows. Deep, reliable connectors for HubSpot + Gmail + Slack beat shallow connectors for 20 tools.

Agents that act on user data are security liabilities if not designed carefully. Three non-negotiable rules: scope OAuth tokens per customer (never share credentials across tenants), require confirmation for destructive actions, and log every tool call with inputs and outputs for audit.

Implement least-privilege access: the agent's Slack token should post messages, not admin the workspace. Its CRM token should read and update records, not delete accounts. Its email token should draft, not send without approval (at least initially).

Build a permission model that customers can configure: 'Allow auto-send for internal emails, require approval for external emails.' 'Allow read access to all tickets, write access only to assigned tickets.' Enterprise buyers will ask about this in the first sales call — having a clear answer accelerates deals.