An agent is not a magic loop that you let run until it feels finished. It is an application workflow in which a model may choose from a small set of capabilities, receive tool results, and propose the next bounded step. The product team still owns identities, authorization, validation, timeouts, and side effects.
Model Context Protocol can make external capabilities easier to connect, but it does not remove those responsibilities. This lesson helps you design a tool allowlist, a turn budget, and an approval boundary before connecting anything that can read private data or make changes.
Start by naming the outcome, not the tools. A support copilot may need order status and approved policy retrieval; it does not need broad database access, a shell, or a payment endpoint. The smallest useful tool set is easier to evaluate and harder to misuse.
Describe each tool with a strict input schema, a narrow response, an authorization rule, and an owner.
MCP is a protocol for connecting model applications to tools and data sources. Treat each MCP server as a dependency with its own trust boundary. Review what it exposes, which identities it uses, where data travels, and how it is monitored before enabling it for users.
A discovered tool is not automatically an approved tool. Apply your application allowlist after discovery.
The agent loop needs a budget just like any other workflow. Limit maximum turns, tool calls, elapsed time, token usage, and retries. Stop with a useful review state when the assistant cannot complete the task inside its defined boundary.
Record a redacted event trail: proposed tool, validated arguments, authorization decision, result summary, and final state.
Model output never authorizes a write. For consequential actions, display the proposed change, collect explicit confirmation from an authorized person, and run the action through normal application validation. The model may prepare a draft, but it should not become the approval channel.
Evaluate prompt injection attempts that appear inside retrieved or tool-returned content.
An agent is a workflow with model-driven choices, not a reason to abandon ordinary system design. Before connecting more tools, define the task state, the maximum number of steps, the human approval points, and the exact data each capability may return. The model can decide which allowed tool to request; code still owns execution and authorization.
MCP can standardize how external capabilities are described and connected, but it does not make a remote system trustworthy. Start with a small tool set, authenticate the connection, validate every result, and treat tool descriptions, fetched content, and remote errors as untrusted inputs to your application.
The model may propose a name, but your server chooses whether that capability is available for this request.
ALLOWED_TOOLS = {"get_order_status", "search_policy"}
def may_call_tool(name: str, user_role: str) -> bool:
return name in ALLOWED_TOOLS and user_role == "support_agent"
print(may_call_tool("get_order_status", "support_agent"))
print(may_call_tool("issue_refund", "support_agent"))True
FalseA budget produces an auditable review state instead of an unbounded agent session.
def final_state(turns_used: int, max_turns: int) -> str:
if turns_used >= max_turns:
return "needs_human_review"
return "may_continue"
print(final_state(3, 3))needs_human_reviewThe workflow selects from capabilities your application explicitly approved for this task type.
CAPABILITIES = {
"support_lookup": {"get_order_status", "search_policy"},
"support_write": {"draft_reply"},
}
def tools_for(task_type: str) -> set[str]:
return CAPABILITIES.get(task_type, set())
print(sorted(tools_for("support_lookup")))['get_order_status', 'search_policy']A loop budget turns an endless or unexpectedly expensive sequence into a visible escalation path.
def next_state(step_count: int, max_steps: int) -> str:
return "continue" if step_count < max_steps else "needs_review"
print(next_state(2, 4))
print(next_state(4, 4))continue
needs_reviewA capability and trust exercise
0 of 2 completed
Only if the application has a deliberate, authorized workflow for that action; consequential changes should normally include confirmation and ordinary validation.
No. It standardizes connections. Your application still owns identity, access control, approval, and audit.
Explore 500+ free tutorials across 20+ languages and frameworks.