Your agent can reach the service desk. The asset register is harder. The internal purchasing portal has no usable MCP server, and that's where the replacement request has to go.
You can connect an AI agent to an internal application without a ready-made MCP server. First establish a permitted way to perform the required operation, using an existing API, service, script, or application interface.
Then expose that operation through an interface your agent supports. MCP is one option.
The useful starting point is the work someone needs done. “Connect the purchasing portal” leaves almost every important decision open. “Prepare an equipment replacement request, obtain approval, record it, and link it to the original case” gives the team something it can implement and test.
Find the missing operation
A server might be missing entirely. It might also exist but lack the write operation, custom field, or account access your workflow needs. Those are different implementation problems.
Before building anything, have the application owner walk through the operation with the account the automation would use. Identify the records involved, required fields, validation rules, and evidence that the change succeeded. A demonstration under an administrator's account doesn't establish what a restricted automation account can do.
Then inspect the access routes already available. A maintained internal service or scheduled script may contain years of useful application knowledge. If it performs the operation correctly and can be invoked safely, keep it.
| What you have | Practical next step | What still needs checking |
|---|---|---|
| A supported API covering the operation | Reuse it behind a narrow action | Account permissions, required fields, and result verification |
| A maintained internal service or script | Make that existing operation callable | Inputs, execution identity, ownership, and failure reporting |
| An approved import or batch process | Use its established submission and reconciliation path | Processing delay, rejected records, and evidence of completion |
| A web application with no usable published API | Assess authorised private web operations or UI interaction | Actual coverage, session handling, permissions, and change sensitivity |
| No approved route for the required change | Keep that step with a person while resolving access | Who performs it and how the workflow records the handoff |
Private web operations require an application-specific assessment. A request observed in a browser isn't automatically a stable integration contract or permission to automate it. A desktop-only application also needs a different assessment from a web portal.
The legacy application access guide goes deeper on those routes. Here, the question is what to build once you've established that the required operation is available.
Give the agent a business operation it can understand
For an equipment replacement, a generic “send HTTP request” tool gives the agent too much work to reconstruct. It has to choose the destination, understand the fields, and decide whether the response means anything useful happened.
Design a narrower operation around the task. Its contract should identify the service case, employee, and asset using authoritative records; specify the permitted change; and state the evidence it will return. Missing identity, denied access, and an unresolved result should be explicit outcomes.
Implement input validation, access checks, and allowed transitions in the code that runs the operation. A sentence telling the model to be careful won't enforce them.
MCP can expose an operation built this way. Its tools specification defines named tools with input schemas and optional output schemas, and requires server-side input validation and access controls.
A schema helps describe the call; your implementation still has to establish whether the requested business change is allowed.
The operation can contain tested workflow logic. There's no requirement to give the model a separate tool for every click or API request.
Build the replacement workflow around an explicit stopping point
Consider a hypothetical employee equipment request spanning a service desk, an asset register, and a purchasing portal.
The service case says the employee's laptop is failing. The asset register identifies the assigned device. The purchasing portal records replacement requests, but no available MCP server exposes the required operation.
Start by joining the case to the employee and device. If the case names one serial number and the asset register shows another, the workflow should return the discrepancy for review. Finding two plausible records isn't enough to select one silently.
The organisation supplies its replacement criteria, approval authority, and required supporting evidence. Application discovery might reveal a mandatory approval field; it can't establish that this employee is entitled to a replacement or that the person requesting it can approve the spend.
Use the verified records and that policy to prepare a proposal. The reviewer should see the employee, device, reason, and intended purchasing action before approving it. Tie approval to that proposal; material changes require another review.
After approval, the workflow creates the request in the purchasing portal and records its reference on the service case. It reads back the request and the case link to establish that both changes took effect against the intended records.
Success here means an approved replacement request exists and is linked to the correct case. It doesn't mean a laptop was purchased, shipped, or delivered. Those later events need their own process and completion evidence.
That stopping point makes the automation useful without pretending it owns the entire equipment lifecycle.
Decide how the agent will call it
Once the underlying operation works, choose its agent-facing interface.
If several approved agent clients need the operation and support MCP, an MCP server can provide a shared interface. If one existing agent application already calls internal functions through its framework, a direct tool integration may be sufficient. Check the actual client's supported interfaces before adding another component to operate.
The MCP architecture documentation describes local and remote servers and explicitly leaves model use and context management to the AI application. It doesn't require a fresh model decision for each internal step of your replacement workflow.
For a private application, draw the network path too: where the agent runs, where the callable operation executes, and which component can reach the purchasing portal. A server on an internal network is useful only if the intended client has an approved way to reach it.
Check protocol-version compatibility, transport support, and authentication against the deployed client and server. “Supports MCP” is a starting point for that check.
Keep application authority explicit
Authorising an agent client to reach a server and authorising a purchasing action are separate decisions.
The MCP authorization specification addresses access to restricted MCP servers over HTTP. The application behind the server still needs an appropriate execution identity and controls over the records and changes that identity can access.
For the replacement workflow, decide whether execution uses a delegated employee identity or an approved service account. If a service account can access several departments, the operation must enforce the caller's permitted scope. It can't infer authority from a department name supplied in the prompt.
Record who requested the action, who approved it, which identity executed it, and which records changed. That makes an unexpected replacement request something the team can investigate.
These decisions apply to US and Australian deployments alike. Locate the execution service, application credentials, model requests, and logs before choosing a deployment. An application hosted in one country doesn't establish where every component handling its data runs.
Plan for the run that stops halfway
Suppose the purchasing request is created, but updating the service case fails. Repeating the whole workflow could create a second request.
Keep the confirmed purchasing reference and report the unfinished case update. Recovery should complete that remaining step after checking the current state.
If the original submission times out and its result is unknown, first try to establish whether a matching request was created. Where the application supports a unique submission reference or duplicate prevention, use it; otherwise stop for reconciliation when the result can't be established safely.
Don't treat every error as permission to retry. A denied account, rejected approval, or changed asset assignment needs a different response from a temporary connection failure.
Someone also needs to own changes to the operation. When the portal adds a required field, that owner updates the implementation and reruns the acceptance cases.
When replacement policy changes, the business owner updates the rule and approval path. Those responsibilities can sit with different people.
Prove the operation before expanding agent access
Run the underlying operation directly with controlled cases before asking an agent to choose it. This separates application-access failures from problems in the agent's interpretation of the request.
For the equipment example, the first acceptance set should include:
- A valid, approved request that creates exactly one purchasing record and the correct case link.
- A mismatched employee or device that stops before submission.
- A caller outside the permitted department who cannot use broader service-account access.
- A missing or changed approval that prevents the write.
- A repeated request or interrupted run that is reconciled without blindly creating another purchasing request.
Then test through the intended agent client. Check that it selects the right operation, supplies the correct records, presents approval accurately, and reports incomplete work honestly. A successful direct call proves application execution; it doesn't prove the agent will choose or describe that call correctly.
The integration platform guide offers a broader comparison when several tools could supply the access and execution components.
Where Monarch fits
Monarch is the orchestration layer between agents and enterprise applications. Its Product Graph maps accessible application operations and their prerequisites so workflows can use captured, verified behaviour. That can include public APIs, private web operations, and UI paths within the connected account's scope.
For the replacement example, the work would be to establish the required portal operations, carry the right records between applications, and capture repeatable steps in deterministic code. The organisation still defines replacement policy, approval authority, and what counts as completion.
A working internal service may already solve the access problem. Keep it. Evaluate Monarch where understanding the applications and making the cross-system work repeatable remain substantial jobs.
Bring one workflow, the accounts it can use, and the operation your current tools can't perform. That's enough to start a scoped evaluation of the access, approvals, and recovery it will need.
Discuss your internal app workflow