ITSM Connected to Claude or ChatGPT Through MCP

ITSM connected to Claude, like ChatGPT used for internal IT support, runs through the Model Context Protocol (MCP): the service desk publishes a remote server, the conversational client signs in to it, and the assistant then calls the server’s tools to read or change tickets, requests, workflows and access. Atlassian, Serval, Ravenna and Atomicwork document such servers, and Anthropic and OpenAI document how Claude and ChatGPT connect to them. The label alone settles little, because the MCP specification makes authorization optional. Four published details make a server checkable: where the client connects, which credential authorizes the calls, which tools exist, and how the tools that change data are marked and guarded. Most vendors read here state that the assistant acts with the signed-in user’s permissions; some also accept, or require, a token issued by the vendor. Connecting a client is also separate from the model a vendor’s own agent runs on: these pages document the connection only.

What does an MCP server for a service desk have to publish?

The Model Context Protocol specification’s authorization chapter opens its protocol requirements with the sentence that matters to a buyer: authorization is OPTIONAL for MCP implementations. When it is supported, implementations over an HTTP-based transport should conform to the chapter; implementations over STDIO should not, and should take credentials from the environment instead. The chapter builds on OAuth 2.1, which it cites as an IETF draft (draft-ietf-oauth-v2-1-13).

Registration has moved in the 2026-07-28 revision. A client obtains its identifier through Client ID Metadata Documents, pre-registration, or Dynamic Client Registration; clients and authorization servers should support the first, and the last is deprecated, kept for backwards compatibility.

So the question for a vendor is not whether it “supports MCP” but whether its pages answer four things:

• Where the client connects: the server URL, the transport, and whether there is one URL per tenant or per region.
• What authorizes the calls: a user’s OAuth sign-in, an API key or a token, and whose permissions follow from it.
• Which tools exist: the inventory, and where it is published.
• How tools that change data are marked and guarded: labels, scopes, admin switches, confirmation steps.

Whose permissions does the assistant act with?

Most vendors read here answer: as the person who signed in. They differ on how that person signs in, and on what else can authorize a call.

Serval’s MCP server reference documents OAuth 2.1 over Streamable HTTP: the client opens the browser for approval and manages the tokens. The server has the same capabilities, permissions and rate limits as Serval’s REST API, and workflow runs execute under the user’s identity. Each region runs its own server, with one URL for the United States and one for the European Union.

Ravenna documents its server as a beta feature over Streamable HTTP and states that it enforces the user’s existing Ravenna roles on every tool call. An OAuth connection reaches every workspace the user belongs to, while an API key connection is pinned to the workspace that issued the key.

Atlassian documents OAuth 2.1, with authentication by API token as an option, and states that all actions respect users’ existing access controls and permissions. Its supported tools page adds a condition for service desk teams: the Jira Service Management tools support only API token authentication, are available only if an organization admin enables that method, and cover operations alerts, on-call schedules and operations teams.

Atomicwork’s connection page documents a tenant-specific URL over Streamable HTTP and a bearer token generated under Settings > API Keys in the dashboard, with no per-user OAuth consent step described. Its MCP tools introduction says that agents in the AI Employee runtime inherit the identity and permissions of the AI Employee they belong to, and names an X-Api-Key header for direct access, where the connection page names Authorization.

The common rule, where it is stated, is permission-scoped visibility: the connector reaches what the account behind its credential can reach.

How do Claude and ChatGPT connect to a service desk?

For Claude, Anthropic documents two routes. The Connectors Directory is one catalog of MCP servers for claude.ai, Claude Desktop, mobile, Claude Code and Cowork; it holds verified and community connectors, and Anthropic states that verification isn’t a security audit. The second route is a custom connector: any remote server can be added by its URL, and a connector added this way connects Claude to an unverified service. The user then chooses how Claude identifies itself: Claude’s published identity, which the server reads from a Client ID Metadata Document hosted by Anthropic, described as recommended and requiring server support; automatic registration through Dynamic Client Registration, described as working with most servers; or a client ID the user registered. On Team and Enterprise plans an Owner adds the connector and members connect with their own account.

Among the service desk servers read here, Siit’s MCP page states that its connector is published in Claude’s connector directory, and Atlassian’s get-started page describes installing it from Claude Desktop’s extension settings, both without a server URL. Serval and Atomicwork document Claude Desktop through the mcp-remote bridge, which Serval says requires Node.js v18 or later.

For ChatGPT, OpenAI documents a developer mode that gives full MCP client support for read and write tools, and calls it powerful but dangerous. It is available to Pro, Plus, Business, Enterprise and Education accounts on the web and supports SSE and streaming HTTP. Without static credentials, ChatGPT can use Client ID Metadata Documents when the authorization server advertises them and the app creator chooses them, and Dynamic Client Registration when configured. Write actions require confirmation by default, and tools without a readOnlyHint annotation are treated as writes. Atlassian and Ravenna both name ChatGPT among their supported clients.

Where employees raise requests, rather than where an admin drives the desk, is covered on the Slack and Microsoft Teams page.

Where is the tool inventory, and how are write tools marked?

The service desk vendors read here publish their inventories in different forms. On the same three questions (where the list is, whether it marks the tools that change data, what guards the risky ones), they compare as follows.

Atlassian publishes a supported tools page. Tools are grouped into read, write, search, delete and manage sets, each with the scope it requires; the Jira delete and manage sets are disabled by default until an admin enables them, and separate read, write and destructive execute tools are used to apply agent-level confirmation.

Serval states that every endpoint of its public API is available as an MCP tool. Its reference lists the tools employees use most (tickets, access requests, workflows, identity) and points to the MCP tools/list method for the rest. It labels no tool read or write; users without the permission to run published workflows do not see the workflow-run tools.

Ravenna publishes an Available tools page organized by domain. It labels no tool read or write, but says clients treat every call to its attachments tool as a write. It states that calls with unknown parameters are rejected before anything runs, that the vault credentials tool returns metadata only, and that deleting a whole form is not exposed over MCP.

Atomicwork documents each tool on its own page, with a parameter table, under an MCP tools section whose introduction lists nine categories, from tickets for requests, incidents, problems and service requests to identity governance and integrations. Neither that introduction nor the connection page marks write tools or names a guard on them.

Freshworks lists its tools in a table by resource on its Freshservice MCP article (fetchTickets, createTicket, updateTicket and so on). The names say whether a tool fetches, creates or updates, but no tool carries a read or write label. The guard it describes sits in the client: per-tool permission levels such as Always allow, Needs approval or Blocked, set in the connector settings.

Siit puts its inventory on the setup page itself, in tables by family with a read or write label on each tool. The credential of a custom integration is write-only: no tool returns it, and a new custom action is created disabled. Its bulk tools are not atomic, so a request can be skipped, and custom integration tools return an error until a workspace has them enabled.

None of these forms is a ranking. A label, a scope group or a parameter table describes the server; what a connection may do still depends on its credential and on the client’s confirmation settings.

Can a general-purpose assistant act on a service desk?

Yes, once a connector is authorized: the vendors’ own examples are actions. Atlassian shows “Move PROJ-456 to ‘In Review’ and add a comment that the PR is up”. Serval documents starting a workflow run; workflows with approval requirements still go through their normal approval process. Ravenna lists creating, updating and triaging tickets, and bulk updates to close out an incident. Atomicwork’s tools introduction includes firing request automations on tickets. The definition of an AI service desk agent is in what an AI service desk agent is, and how far an agent may act before a person approves is taken apart in what autonomy means for an IT agent.

The controls sit in three places. The server decides which tools exist for a credential, as with Atlassian’s admin-enabled sets. The client decides when to ask: ChatGPT lets a user remember an approval for the rest of a conversation, which OpenAI advises only for an application the user trusts. The organization decides how to watch: Atlassian advises least privilege, reviewing high-impact changes before confirming, and monitoring audit logs.

• 01

  Whose credential is it?

  Serval, Ravenna and Atlassian document that the assistant acts with the signed-in user's permissions. Ravenna and Atlassian also accept an API key or token, and Atomicwork's connection page documents a dashboard token. The review question is which account a connection uses.

• 02

  Authorization is optional in the protocol

  The specification marks authorization OPTIONAL and asks only HTTP implementations to follow its chapter. Support for MCP settles nothing about how a given server checks who is calling.

• 03

  Client registration is moving

  The current specification marks Dynamic Client Registration deprecated and asks clients and servers to support Client ID Metadata Documents. Claude and ChatGPT both document both options.

• 04

  Inventories take different forms

  Atlassian groups its tools by scope, Siit labels each tool read or write, Ravenna and Atomicwork document parameters tool by tool, and Serval derives its tools from its public API. None of these forms ranks the servers.

Where do the limits sit?

Three locations of data are also separate: where the organization is hosted, which Serval maps to a region with its own server URL; where the model processes the tool results, in the client chosen; and where calls are logged, which Atlassian’s get-started page does not say while advising to monitor audit logs. The evidence a reviewer collects is listed in what a security review of an IT agent looks at.

Last, a listing is a snapshot. Atlassian’s get-started page announces that on March 1, 2027 existing use of its v1 server will automatically start to expose v2 tools, and that incompatible clients will need to clear cached client IDs or credentials; that date is announced by Atlassian and subject to change. A directory entry, a beta label or a migration notice describes a page as read in October 2026.

Which vendors document an MCP server for IT service management?

Listed here: vendors whose public documentation, read for this guide, publishes an MCP server for service desk work and states where a client connects, how calls are authorized and which tools it exposes.

• Atlassian: its get-started page gives the server URL https://mcp.atlassian.com/v2/mcp and OAuth 2.1 with an optional API token, and its supported tools page groups the tools by scope.
• Freshworks: its Freshservice MCP page gives the server URL https://<subdomain>.freshservice.com/mcp, API key and OAuth authentication, a table of tools by resource, and per-minute rate limits and included MCP actions by plan, which the article’s introduction calls monthly and its table annual.
• Ravenna: its overview documents a beta server with OAuth sign-in or a workspace-pinned API key, and its Available tools page groups the tools by domain.
• Serval: its MCP server reference gives a US and an EU server URL and OAuth 2.1 with approval in the browser, and states that every public API endpoint is available as a tool.
• Siit: its MCP page gives the server URL https://mcp.siit.io/mcp and OAuth 2.1 with dynamic client registration, and lists its tools in tables with a read or write label on each.