tool use<\/a>, schemas should distinguish read, create, update, and destructive operations so the model can select a capability without confusing operations that have very different side effects.<\/p>\nWhen server tools change, re-run discovery and verify that configured allowlist names still match exactly. A renamed or removed tool should fail visibly instead of silently widening access.<\/p>\n
The allowlist should be versioned with the agent configuration. If a server later publishes a new destructive tool, the agent should not automatically inherit it simply because the endpoint stayed the same. Explicit tool selection turns server expansion into a reviewed change rather than an invisible privilege increase.<\/p>\n
Approval policy belongs at consequential action boundaries<\/h3>\n Foundry MCP integrations can require approval for every call, no calls, or selected tools depending on configuration. The default can be conservative, but the useful policy depends on effect. High-risk write operations should usually require explicit review unless another trusted control provides equivalent authorization.<\/p>\n
An approval request should expose the proposed tool and arguments so the reviewer can understand the effect. A prompt that merely asks ‘allow tool?’ creates click fatigue without meaningful control. Keep routine low-risk lookups separate from actions that publish, delete, change permissions, or trigger costly work.<\/p>\n
Microsoft also notes that runtime enforcement matters: a tool’s metadata alone does not guarantee that an arbitrary agent runtime will stop for approval. Verify the consuming runtime actually implements the pause-and-resume behavior.<\/p>\n
Approval design should reflect reversibility. Reading a public issue, listing repository metadata, or fetching a status may be safe to automate, while sending messages, changing tickets, creating infrastructure, or writing to business systems deserves stronger review. Classify tools by consequence and data sensitivity instead of using one global approval switch.<\/p>\n
Treat server output as untrusted model input<\/h3>\n Remote MCP servers can return content that includes malicious or misleading instructions. An agent should treat tool descriptions, annotations, and results as data, not higher-priority policy. This is an indirect prompt-injection boundary as well as a conventional integration boundary.<\/p>\n
Prefer servers operated by trusted providers or by your own organization, pin versions where feasible, and review data retention and geographic implications for third-party endpoints. Sensitive prompt content or repository data may leave Microsoft infrastructure when it is sent to an external server.<\/p>\n
Filter or validate tool results before they drive privileged actions. A compromised read-only source should not be able to cause a second tool to perform an irreversible operation simply by returning persuasive text.<\/p>\n
Build error handling around protocol states<\/h3>\n MCP workflows can produce authentication errors, consent requests, approval requests, unavailable tools, invalid arguments, timeouts, and downstream application failures. Model each state distinctly. A consent requirement should be returned to the signed-in user; a 403 should not be retried as if it were a transient network failure.<\/p>\n
Long-running tool operations can also exceed ordinary request expectations. Where Foundry supports task-style MCP operations, surface progress and final status rather than making the language model guess whether the work completed.<\/p>\n
Include stable correlation identifiers through the agent response, MCP call, server logs, and downstream system. That evidence is essential when a tool appears to have executed twice or returned stale state.<\/p>\n
When a tool fails after a partial side effect, the agent needs enough state to avoid blindly repeating it. Idempotency keys, operation identifiers, or a follow-up read can help determine whether the action actually completed. This is particularly important for ticket creation, workflow starts, and other calls where a retry could duplicate work.<\/p>\n
When a tool may create a side effect before returning an error, recovery should verify state before retrying. A ticket may have been created even if the response timed out; a workflow may have started even if the client lost the connection. Operation identifiers, idempotency keys, or a follow-up read keep the agent from duplicating actions during ambiguous failures.<\/p>\n
Govern the endpoint like a production API<\/h3>\n A mature MCP server has an owner, authentication model, authorization policy, allowlist strategy, approval classification, change process, logging standard, and incident plan. The protocol is only the transport contract. Microsoft<\/a> Foundry provides the integration machinery, but organizations remain responsible for server trust and data handling. Contract changes should be versioned and tested against existing agents before rollout. Renaming a tool, tightening a schema, or changing an error shape can alter model behavior even when the backend still works, so compatibility and rollback need the same discipline as any production API change.<\/p>\nReview the server whenever its operator, exposed tools, or downstream permissions change. A previously safe read-only endpoint can become materially different after a new write tool is added.<\/p>\n
The practical success criterion is that an auditor can reconstruct why the agent had access to a tool, who approved a consequential call, what arguments were sent, what the server returned, and what downstream effect occurred.<\/p>\n
Contract changes deserve compatibility discipline. Renaming a parameter, changing a result shape, or altering tool semantics can break agent behavior even when the server remains reachable. Publish stable schemas, deprecate deliberately, and test representative agent calls before rolling a new MCP server version into production.<\/p>\n
Rate limits and timeouts should be set with the downstream system in mind. An agent can call tools faster than a human interface ever did, so an integration that was safe for manual use may overload an internal API when exposed through automation. Capacity and abuse controls belong at the MCP boundary as well as in the underlying service.<\/p>\n
Keep human ownership visible<\/h3>\n Every production MCP integration should have a named owner who can answer what the tools do, which data they expose, and what changes are expected. Agents make integration paths easier to compose, but they should not make ownership ambiguous. Clear ownership is what allows permission reviews, incident response, and deprecation to happen on schedule.<\/p>\n
Ownership also matters when an agent spans several servers. Define which team owns the end-to-end workflow versus each server, and decide who can disable a tool quickly during an incident. A kill switch is only useful when someone is authorized and prepared to use it.<\/p>\n
Every production MCP path should have a named service owner, a data owner for sensitive sources, and an incident contact who can disable the integration quickly. Composability makes it easy to connect tools, but it must not make accountability diffuse. Ownership is what turns approvals, access reviews, deprecation, and emergency shutdown from policy statements into executable operating procedures.<\/p>\n","protected":false},"excerpt":{"rendered":"
Remote MCP servers make agent capabilities portable Microsoft Foundry agents can connect to remote Model Context Protocol servers and use the tools those servers expose. The agent is configured with a server URL and label, and the integration can be authenticated through a project connection. For Microsoft AI-103, this turns tool integration into an architecture […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1029],"tags":[],"class_list":["post-22485","post","type-post","status-publish","format-standard","hentry","category-technology"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t