A Shared MCP Tool Layer in Foundry: Ownership, Versions and Access

Prerequisites

Before changing a shared tool layer, identify the Foundry project or environment in scope, the agents that currently depend on it, and the business systems those tools can affect. This guide assumes your team is considering a shared toolbox as a controlled way to reuse integrations, rather than letting every agent team create a separate connection to each system.

You will also need named people who can make decisions about tool behavior and access: an integration owner, a representative of each consuming application or agent team, and the people responsible for the relevant Azure identity and network configuration. They do not need to be the same people. They do need enough authority to resolve a failed release without treating a model response as permission to change a production system.

Agree on the environment boundary before designing reuse. “Shared” should mean that more than one approved consumer can use a deliberately managed tool contract. It should not mean that every agent can see or invoke every operation merely because the integration exists. Record the systems, data types and actions in scope, and identify which actions can change external state.

Finally, establish where the existing implementation lives and who can change it. If you are still selecting an agent platform or planning the foundational architecture, first compare the relevant platform choices in this enterprise agent platform guide. This article starts at a narrower point: how to govern and reuse a tool layer in Foundry.

Working rule: Do not migrate a tool into a shared layer until you can name its owner, consumers, supported contract version, access boundary and rollback decision-maker.

Why a shared tool layer needs an operating model

A tool is a callable capability that lets an agent request information or an action outside its own model context. For example, a support agent might retrieve an order status; a finance agent might request a payment hold. Those operations may reach the same business system, but their consequences and permitted inputs are different. Reuse should preserve those distinctions instead of hiding them behind a single broad “business system” connection.

In Microsoft Foundry, Toolbox exposes curated tools through an MCP-compatible endpoint. That makes it possible to present a managed set of tools for agent use; it does not decide which team owns an operation, which version a consumer depends on, or which callers should be allowed to invoke it. Those decisions belong in the operating model your organization builds around the tool layer. Microsoft’s Toolbox overview describes the product boundary; the ownership and release practices below are design recommendations.

MCP separates the host, client and server roles, while transport and authorization are distinct from the meaning of an individual tool. In practical terms, an agent application can participate in an MCP interaction without that fact alone establishing whether a particular operation is appropriate, authorized or safe to execute. Keep tool semantics, connection mechanics and caller access as separate design questions. The MCP architecture specification provides the protocol context.

A shared layer changes the economics of maintenance as well as the risk. One integration can reduce duplicated implementation and make contract changes visible in one place. But the same reuse can increase the number of dependent applications affected by a mistake. The right objective is not maximal centralization. It is to centralize stable, well-understood operations while keeping genuinely different business decisions and access needs explicit.

Treat the toolbox as a product with a service boundary. Its consumers need a discoverable contract, a way to request changes, predictable version behavior and a clear response when an operation is unavailable. Its owners need a supported release path, a way to identify callers and a decision process for retiring old behavior. Without these, “shared” becomes an informal dependency that may be copied, relied on and changed without anyone recognizing the full impact.

Step 1: Inventory the tools and choose what belongs in the shared layer

Start with an inventory of the operations teams want to reuse. Do not begin with a list of backend systems. A connection to a ticketing platform, for instance, may expose both “read ticket summary” and “close ticket.” They reach the same platform but have different effects, review needs and consumer suitability. Record operations at the level where a caller can understand what will happen.

For each candidate, capture its business purpose, owner, consumers, input fields, returned information, side effects and failure behavior. Include whether it reads, creates, updates or deletes external data; whether repeated requests could produce repeated effects; and what a human or downstream system must do to verify completion. If the team cannot describe an operation’s effect in ordinary business language, it is not ready to be a shared contract.

Then classify candidates into three practical groups. A stable, narrow read operation may be suitable for shared reuse. An operation whose behavior varies by business unit may need separate contracts or remain application-specific. A high-impact write operation may still be reusable, but only after the team defines its caller boundary, approval point, exact request shape and recovery procedure. This classification is a design choice, not a claim that a platform automatically enforces those controls.

Assess whether the proposed common operation is actually common. Suppose two agent teams both request “update customer.” One means changing a mailing preference after a verified request; the other means changing a billing contact after a finance review. Sharing a low-level system connection could be reasonable, but presenting the same unconstrained update action to both teams would erase meaningful differences. Prefer separate, purpose-specific operations or distinct consumer-facing contracts over one broad operation with undocumented assumptions.

A candidate should also have a real owner with capacity to maintain it. That owner is responsible for the tool’s meaning and compatibility decisions, not necessarily for every identity or network component through which it is reached. If no team accepts responsibility for explaining a field, deciding whether a behavior change is breaking, and communicating a retirement, keep the capability outside the shared layer until ownership is settled.

Pro tip: Inventory consumer journeys, not just existing tool names. A tool called update_record may conceal several business operations. Naming each intended outcome first often reveals that the proposed reuse is too broad.

Step 2: Assign owners and write a bounded contract

For every accepted candidate, name a tool owner and distinguish that role from the owner of the connected business system. The tool owner decides what the interface promises to callers and coordinates its changes. The system owner decides whether the underlying business operation is valid. A consuming application team owns how its agent uses the contract in a particular workflow. One person may hold more than one role in a smaller organization, but the decisions should still be recorded separately.

Write a short contract before implementation or migration. Include the tool’s purpose; the situations in which it should be called; required and optional inputs; allowed value ranges or formats; returned fields; known side effects; expected business errors; and the outcome that counts as success. Add examples with representative but non-sensitive values. Explain fields that look similar but have different meanings, such as an internal record identifier versus a customer-visible reference.

Make the contract conservative. Prefer specific inputs such as case_id and requested_status to a free-form instruction like “change the case as needed.” Enumerate allowable status transitions if the business system supports only certain transitions. Avoid returning more personal or commercially sensitive data than the consumer needs. These are interface design recommendations; they do not substitute for an organization’s data handling rules or identity controls.

Distinguish a request being accepted from a business result being achieved. A response that says an operation was submitted is not proof that the intended record now has the intended state. Define what the caller can verify, which source is authoritative, and what to do when the response is ambiguous. For an update, that may mean retrieving the resulting record and checking a specific field. For a request that enters a human review queue, success may mean “review requested,” not “change completed.”

Specify error behavior in language an agent and its application can use. Examples include invalid input, caller not authorized, record not found, downstream system unavailable, and outcome unknown after a timeout. Avoid collapsing every failure into a generic success-shaped message. In particular, an uncertain result after a write should not prompt an automatic retry unless the operation has a safe, defined way to handle repeats.

A contract should also identify exclusions. State which related work the tool does not perform, and which decisions remain with the calling workflow or a human. This keeps a concise tool from gradually becoming a vague back door to a system. If the operation depends on a policy decision, put that decision in an explicitly owned workflow instead of implying that the shared tool can infer it from an incomplete prompt.

Step 3: Set version and change rules before reuse expands

Choose a versioning policy consumers can follow. The practical purpose is to let a team understand whether its agent is calling the contract it implemented against, and to give the owner a controlled way to introduce a changed contract. A version label without a compatibility policy is only a label; define which changes preserve existing expectations and which require a consumer update.

A change that adds an optional response field may be compatible for consumers that ignore unknown fields, but it might not be harmless if a consumer validates an exact response shape. A change that alters the meaning of an existing field, makes an optional input mandatory, changes a side effect, or narrows accepted values can break a consumer even if the tool name stays the same. Assess impact from the consumer’s perspective, not from the size of the code change.

Keep a registry entry for each supported contract version. At minimum, record its owner, purpose, consumers, release status, change notes, known limitations and retirement date or review point. The registry can be a platform catalog, an engineering-owned repository or another maintained internal record. The essential property is that teams can find the current contract and determine whether an older dependency is still intentionally supported.

For a breaking change, create a new supported version or a parallel contract where the platform and implementation design allow it. Do not assume that an existing Foundry-hosted endpoint can split traffic for a canary: the available design facts do not establish such routing. If a gradual rollout requires traffic separation, propose and validate an external routing design appropriate to your environment, or use a consumer-by-consumer migration plan that does not depend on endpoint behavior you have not confirmed.

A migration plan should name affected consumers, the change each must make, a validation condition, an owner for each action and a retirement decision. It should set a review date, but not treat the date alone as evidence that migration is complete. A consumer is ready to leave the old contract when its owner confirms the new request and response behavior, its important failure paths are considered, and the old dependency can be removed without an untracked fallback.

Warning: Avoid silent semantic changes. A tool that still accepts the same input but now interprets it differently can be more dangerous than a clear failure, especially when it changes external records.

Step 4: Separate caller access from tool meaning

Design access around the specific caller and operation. A team’s need to invoke a read operation does not automatically justify access to a write operation exposed by the same integration. Likewise, an agent’s presence in an environment should not be treated as proof that every tool in that environment is an appropriate capability for that agent. Maintain a mapping from consumer to contract version and allowed operations, and ensure the responsible identity design can express the intended boundary.

The purpose of this step is not to repeat a full identity architecture. It is to make access a release condition for each shared tool. Identify the caller context, the resource or operation being protected, and the owner who confirms that the intended consumer can reach only what its workflow requires. For a deeper treatment of identity questions and responsibility boundaries, see the guide to agent identity and authorization.

Keep authentication and authorization distinct in the design record. Authentication concerns which caller is presenting itself; authorization concerns what that caller may do. Neither by itself explains whether the tool’s business inputs are valid or whether the resulting action should proceed. These questions may be implemented in different components, so document which component is responsible for each decision and how a failure is surfaced to the consumer.

Network reachability is another separate responsibility. A service that can be reached is not thereby authorized for every caller, and an authorized caller may still be unable to reach a service because of network configuration. Draw the actual path from agent application to the MCP-facing endpoint and onward to the business system, then assign an owner to each boundary. For inbound and outbound considerations specific to Foundry, use the private networking design guide; do not assume the toolbox contract settles connectivity.

Step 5: Define an approval boundary for consequential actions

Not every tool call needs human approval. A narrowly scoped read operation may not change the underlying business record. For a consequential write, however, define whether an approval is required, who can provide it, and what exactly the approval authorizes. Approval should precede execution, bind the exact payload that will be sent, and expire. If the payload changes after review, treat the prior approval as no longer authorizing the altered request.

Record the approval reference, approver, payload or a stable representation of it, and expiry in the application’s appropriate audit trail. The tool owner should specify the contract and decision boundary; the consuming workflow owner should specify when to request review; the business process owner should determine who can approve the action. This does not mean every organization needs an elaborate approval system. It means that where approval is required, a general instruction such as “approved for this customer” should not silently authorize materially different operations.

Plan for a delay between approval and execution. A record can change while a request waits. At execution time, re-check the conditions that make the exact action valid, such as whether the target record still exists and whether the requested transition remains allowed. If those conditions no longer hold, stop and return a clear failure for renewed review rather than altering the request to make it pass.

Avoid claiming exactly-once external effects. A network interruption can leave the caller uncertain whether a write completed. Design the operation and its consumer to recognize that uncertainty, check the business system’s resulting state where possible, and avoid issuing an unexamined duplicate. If the underlying system offers a suitable way to identify repeated requests, document its limitations rather than assuming every integration supports the same mechanism.

Step 6: Map Azure responsibilities and validate the path

Draw the architecture before assigning production ownership. The diagram below is a planning model, not a claim that every component is automatically created or configured by Foundry. Replace the labels with the names of your actual applications, environments and owner teams. The sequence illustrates that a request must pass contract, ownership, access and approval decisions before execution, and that the result must be checked afterward.

flowchart TD
    accTitle: Shared tool request and control path
    accDescr: An agent request passes contract, ownership, access and approval checks before execution. The outcome is recorded or stopped, and business results are verified after execution.
    A["Agent application"] --> B["Versioned tool contract"]
    B --> C["Owner and version gate"]
    C --> D["Identity and network gate"]
    D --> E["Exact-payload approval gate"]
    E --> F["MCP endpoint and operation"]
    F --> G["Verify result or record stop"]
    C --> G
    D --> G
    E --> G

Read the diagram as a control sequence, not merely a connectivity picture. If the owner cannot confirm the selected contract version, the request stops before access is considered. If identity or network checks fail, it stops before the tool is invoked. If an approval is required but missing, expired or bound to a different payload, the write does not proceed. The final node represents two distinct outcomes: recording a reason for stopping at a gate, or checking the business result after execution. It does not suggest that a model’s report is authoritative proof of a change.

Use the responsibility matrix to make Azure-specific ownership explicit. The component labels are logical roles; map them to the services and controls actually present in your design rather than assuming a particular deployment pattern.

Area	Accountable role	Design evidence to record	Failure owner
Foundry toolbox and contract	Tool owner	Contract version, purpose, consumers and release state	Tool owner
Agent application and invocation	Consumer team	Caller-to-tool mapping and expected outcomes	Consumer team
Identity configuration	Identity owner	Caller identity, protected resource and allowed operation	Identity owner
Network path	Network/platform owner	Inbound and outbound path, boundaries and dependencies	Network/platform owner
Business-system operation	System or process owner	Valid inputs, side effects and authoritative result	Business-system owner
Approval decision	Process owner	Approver, exact authorized payload and expiry	Approval owner
Release and retirement	Tool and consumer owners	Migration, validation and old-version removal decision	Named release coordinator

Validate the path with representative requests before onboarding consumers. Include a valid read, invalid input, denied caller, unreachable dependency, expired approval and ambiguous outcome after a write. These are proposed acceptance cases, not a claim that any test has been run. For each case, define what the application should show, which team receives the actionable failure, and whether any external effect may already have occurred.

Keep the responsibility boundary useful during incidents. If an agent cannot call a tool, the consumer team should be able to supply the contract version and request context; the identity owner should be able to check the caller boundary; and the network owner should be able to assess the path. Avoid making the tool owner the default fixer for every failure merely because the tool is shared. A short escalation map with a first diagnostic owner for each failure class can save time without blurring accountability.

Step 7: Onboard consumers and manage operational change

Onboard one consumer at a time when practical. Give its team the contract, the supported version, example inputs, expected outputs, failure meanings and a named change contact. Ask the team to describe which workflow invokes the tool and what it will do with the response. That conversation can expose assumptions that a schema review will not: for example, whether an agent treats “request received” as “request completed.”

Require consumer teams to pin or otherwise record the version they depend on according to the implementation’s supported mechanisms. The exact method is specific to the architecture and should not be guessed from the existence of an MCP-compatible endpoint. Whatever mechanism is used, keep enough information to identify affected consumers when a version changes and to reproduce a report of unexpected behavior.

Monitor operational signals that answer management questions, not just whether a request reached an endpoint. Useful categories include request volume by consumer and contract version, success and failure categories, latency or timeouts where available, and the status of unresolved outcomes for consequential writes. Ensure the monitoring design does not unnecessarily retain sensitive input values. Agree on who reviews those signals and how unusual patterns become a tool, consumer or access review.

A rise in failures should first be classified. A change in invalid-input errors could indicate a consumer using an outdated contract or a tool change that was not communicated. Access denials may indicate an expected boundary working correctly or a caller configuration that needs review. Timeouts can leave a write’s result unknown. These conditions call for different responses; a single “retry everything” policy risks repeating an action whose outcome is already uncertain.

Changes to the business system can require contract changes even when the toolbox code is untouched. If a downstream system changes a valid status, identifier format or response meaning, have the system owner notify the tool owner and affected consumers. Treat a change to business semantics as a compatibility question, not merely an implementation detail. A maintained dependency record helps establish which consumers need assessment before release.

If your organization needs to establish these ownership, release and operating practices across multiple teams, enterprise platform engineering is a relevant next step. Keep that work focused on the platform operating model and delivery boundaries; it does not replace decisions about a particular business operation’s meaning or approval.

Step 8: Work through a hypothetical shared-tool release

Consider a hypothetical organization with two internal agent applications. One helps service staff find open cases. The other prepares a draft response and may request a case status change. Both teams want to reuse a shared case integration. The example is illustrative; it does not describe a PADISO client or a tested Foundry deployment.

The inventory identifies two candidate operations: get_case_summary and request_case_status_change. The first returns a limited set of fields needed to answer staff questions. The second can affect a business record. The teams initially propose one generic manage_case tool. The tool owner rejects that shape because it hides distinct purposes and would make it harder to give the service lookup agent a narrower capability than the workflow that requests a change.

The owner writes separate contracts. The read contract accepts a case reference and returns a defined summary, with a not-found response that is distinguishable from an unavailable system. The change contract accepts a case reference, a specific requested status and a reason code from an agreed set. It reports whether the request was accepted, rejected or left with an unknown outcome. The business-system owner specifies which transitions are valid; the consumer team defines how its workflow handles each result.

The release record names the tool owner, both consumers, the contract versions, the identity owner and the network owner. The read-only consumer is mapped only to the read operation in the proposed access design. The status-change workflow is treated as a separate caller context. The identity owner confirms the intended access configuration; the network owner validates the designed path. This is an allocation of responsibility in the scenario, not an assertion that a specific Azure service automatically supplies the policy.

For the status change, the process owner decides that a designated staff member must review consequential requests. The approval is tied to the case reference, requested status and reason code, and expires after the organization’s chosen review window. Before execution, the workflow checks whether the approval remains valid and whether the case still supports the requested transition. If the case has changed in the meantime, the request stops for reassessment rather than silently substituting another status.

The team then defines acceptance cases. A valid read must return only the contracted fields. A read for an unknown case must not be represented as an empty successful result. A caller without the intended access must be denied before the operation changes data. An expired approval must not proceed. A timeout after submitting a status change must produce an “outcome unknown” path that prompts a state check, not an automatic duplicate write. The business owner identifies the authoritative field to inspect when verifying the final case status.

Suppose, illustratively, that three consumer teams later need the read contract and one needs the write contract. The number of consumers alone is not a reason to grant all four the same operations. The owner checks the use cases, version dependencies and access mapping as each team joins. If a fourth team needs a new kind of status transition, it may require a contract change and business-owner review rather than an undocumented extension to the existing tool.

The scenario also exposes a counterexample. If the integration owner instead publishes a broad manage_case operation that accepts free-form instructions, returns a generic success message and is available to every consumer, reuse has reduced duplicated connections but weakened the ability to reason about behavior. A tool layer is not well governed simply because it is centralized. It is well governed when consumers can predict the contract, owners can assess change impact, and consequential operations retain explicit boundaries.

Step 9: Handle failures and retire old contracts deliberately

Plan for partial failure across the whole call, not only a clean rejection from the tool. The agent application might send a request but fail to receive a response. The endpoint might report a transport problem while the business system has already acted. The business system might accept a request but later reject it during processing. The consumer needs distinct states for “not submitted,” “rejected,” “accepted but pending,” and “outcome unknown” wherever the implementation can distinguish them.

When the outcome is unknown, preserve the request context needed for investigation and avoid an automatic repeat unless the operation’s design makes that safe. Check the system of record or use a business-approved reconciliation process. Record whether the intended state was reached, whether a duplicate effect may have occurred, and which owner will resolve the discrepancy. Do not infer completion from a model’s confident wording or from the absence of an error message.

When a consumer reports a mismatch, compare the exact contract version, input shape, caller identity context and observed business result. That narrows the investigation to contract, consumer, access, network or downstream behavior. Do not immediately “fix” a tool by changing its semantics for all consumers. If a correction changes the contract, assess compatibility and follow the release process; if the issue is specific to a consumer’s interpretation, correct that integration without changing other teams’ expectations.

Retire a version only after consumers have been identified and their migration status is known. Communicate what changes, when support is expected to end, the replacement contract, and where to report a blocker. A retirement record should capture the owner’s decision and evidence that listed consumers no longer depend on the old behavior. If a consumer cannot be identified, that is a discoverability problem to resolve before a risky shutdown, not a reason to assume the consumer does not exist.

If a release causes a material incident, pause further migration, preserve the current contract behavior where feasible, and use the designated release owner to decide whether to roll back, disable a consumer path or issue a correction. A rollback itself can have side effects if data has already changed, so separate restoring the interface from repairing business records. Have the business-system owner determine any required data reconciliation; do not promise that reverting tool code reverses external effects.

Printable decision worksheet

Use this worksheet in a design review or release review. A blank answer is a decision still to make, not an approval by default. Keep the completed record with the tool’s maintained contract or catalog entry so a future consumer can discover the same boundaries.

Tool and ownership

• Business purpose: State the operation in one sentence that describes the intended business outcome, not the name of a backend system.
• Tool owner: Name the person or team accountable for contract meaning, compatibility decisions and change communication.
• System or process owner: Identify who confirms that the underlying business operation and its side effects are valid.
• Consumers: List each agent application and the workflow in which it will use the operation.
• Exclusions: Record adjacent actions or decisions that the tool does not perform.

Contract and version

• Inputs: List required and optional fields, formats, accepted values and validation behavior.
• Outputs: Define returned information and distinguish accepted, completed, pending and unknown outcomes where relevant.
• Side effects: State what can change externally and how a result is checked against an authoritative source.
• Supported version: Record the consumer’s intended contract version and the owner’s compatibility policy.
• Change path: Identify affected consumers, validation conditions, migration owner and retirement review point.

Access, network and approval

• Caller boundary: Record which caller context may invoke which operation, with an identity owner assigned.
• Network path: Map the intended inbound and outbound path and assign an owner to each relevant boundary.
• Approval rule: For consequential actions, say whether review is required, who may approve, what exact payload is covered and when that approval expires.
• Execution re-check: Specify which business conditions must still hold when an approved request is executed.
• Failure routing: Name the first diagnostic owner for contract, identity, network, approval and downstream failures.

Release and operations

• Acceptance cases: Include valid input, invalid input, denied caller, dependency unavailable and any ambiguous write outcome.
• Consumer handling: State what each application shows or does for success, rejection, pending status and unknown outcome.
• Signals and review: Identify operational signals, who reviews them and how sensitive inputs are minimized in records.
• Recovery: Record whether a request can be checked before retry and who decides how to reconcile an external effect.
• Retirement evidence: Define how the owner will know no supported consumer still depends on the version.

Summary: make reuse explicit, bounded and reversible

A shared Foundry tool layer is useful when it gives multiple approved consumers a stable, understandable contract without erasing differences in purpose or authority. Begin with business operations, assign owners, describe inputs and effects, and decide what constitutes a breaking change before reuse spreads.

Keep versioning, caller access, network responsibility and approval as related but distinct decisions. Validate the path and its failure outcomes, especially when a write may have completed despite a timeout. Onboard consumers deliberately, track their contract dependencies, and retire old behavior only when the affected applications and recovery implications are understood.

The practical test is straightforward: can a consumer identify what the operation means and which version it uses; can an owner explain who may invoke it and how it changes; and can the team stop, investigate or recover when the result is uncertain? If not, improve the contract or boundary before adding another consumer.