MCP or GUI: choosing an interface for a corporate operation

An agent conversation is useful for finding a ticket by meaning and preparing a change. Before a write, a form that shows the old and new values is often better. MCP connects an application to tools; your system remains responsible for deciding who may change a ticket.

This is a teaching scenario for an internal service desk. An employee reads a ticket, proposes a new assignee and sends that change for confirmation. It is not a ready integration for any named product. The tool and field names are illustrative: implement and test them in the system you choose.

Split the operation into reading, proposing and writing

In the MCP architecture, a host application works with servers through clients, and servers expose tools and other capabilities. A suitably named tool does not itself grant a user business permission.

Action	Useful starting interface	Admission condition
Find a ticket the user may access	MCP and conversation	The server limits results by that user’s permissions
Propose a new assignee	MCP for the draft; a form for comparison	The proposal does not alter the record
Confirm the change	GUI or a tested MCP Apps form	Exact fields are visible; the server rechecks permissions and freshness

This is a design recommendation for this scenario. An ordinary GUI can also hide material values or call an inadequately protected backend. Evaluate the actual write path and its evidence.

Assume training ticket REQ-204 has assignee team-a and the user wants team-b. Conversation can find the object, but before saving show its ID, old value, new value and consequences: notification, access change, or an external action. Matching titles are not enough to select an object.

Make confirmation apply to the exact change

An internal confirmation object could be:

{
  "ticket_id": "REQ-204",
  "expected_revision": "r17",
  "changes": {
    "assignee": {"from": "team-a", "to": "team-b"}
  },
  "mode": "proposal"
}

This is an application schema, not an MCP standard. On save, the server must compare the revision and permissions. If the ticket changed, show the proposal again. A Confirm button must not silently apply a different diff.

The MCP Tools specification covers visible calls, a person’s ability to reject an action, and server-side validation of input and access. The protocol does not prescribe one confirmation interface. Access to an MCP server is therefore not permission for every corporate operation.

Define backend behavior for a timeout before it happens. When a response is lost, first query the operation result by its retained identifier. Blind retry can send a notification twice or repeat an external effect. Restoring the old assignee does not make every consequence reversible.

When MCP Apps fits

MCP Apps lets a server tool provide an interactive UI inside a client that supports it. The host renders it in a sandboxed iframe. It can provide a field-comparison form in the conversation if the chosen client and server versions support the extension.

For this scenario, the form can show the ticket, the proposed diff, and explicit Apply and Cancel buttons. Server authorization, revision validation and a result log are still required. A sandboxed iframe neither replaces service-desk permissions nor makes an arbitrary server trusted.

Keep a separate GUI when the current client cannot reliably show a diff, complete corporate confirmation or provide the required accessibility. If the model is unavailable, a person must still be able to open the ticket by ID and inspect its actual state. A model failure must not leave them guessing whether the change was saved.

Build a pilot: BetterToken for the model, MCP for tickets

For a pilot, use Claude Desktop as the client and connect a Claude model through BetterToken with the API setup guide. Use your own API Key with access to the Claude provider and Gateway Base URL https://bettertoken.ai; verify exact fields and conditions for your version in the guide. First obtain a response to an ordinary short message to test the model connection independently.

Then connect a test service-desk MCP server through the selected client and test access to one non-secret ticket. BetterToken supplies the model API layer; service-desk credentials, user permissions and write confirmation are configured separately. A model connection does not prove MCP Apps support in a particular client mode, so test that separately before choosing an embedded form. If the form is unavailable, keep confirmation in the GUI.

Connect the model through BetterToken for the test scenario, then complete the checks below. Use fictional data: MCP response content passed to the model can enter an API request. Authorization to work with real corporate data must follow your organization’s rules.

Test the choice under failures

Run the exercise in a test environment with two roles and non-secret tickets. One role may change an assignee; the other may only read records available to it. Record the actual result for every check. This table is expected criteria, not a test report.

Check	Expected result
A user requests an unavailable ticket belonging to someone else	The server refuses without exposing its contents
A read-only role confirms an assignee change	The server rejects the write
The user cancels a proposed diff	The ticket is unchanged
Revision changes after viewing	Saving stops; a new view is required
The response after save is lost	Determine status before deciding to retry
The model is unavailable	The GUI can read the actual state
The form is used with keyboard and screen reader	A person can understand, confirm or cancel the change

If a check fails, keep that kind of write in the existing tested interface until the cause is fixed. Reading through MCP can be assessed separately; reads also require permissions and result limits.

Leave an audit trail

For this scenario, record the user, ticket ID, agreed diff, source revision, time, operation ID and backend result. Do not log tokens or full contents of restricted tickets without need. Retention and access rules for the log must follow your organization’s policy.

After the pilot, record a decision for each action: reading in conversation, preparation as a draft, and writing in the selected tested form. Attach failure-test results and an owner for remaining issues. Then expand MCP only for operations whose permissions, confirmation and recovery after failure are understood.