The M42 Professional MCP server provides a procted access to your data and actions to AI agents through the Model Context Protocol (MCP) — the emerging standard that lets AI assistants read from and act on business systems in a structured, permission-aware way, instead of guessing at screen text.

Two kinds of AI client can use it:

• Neo — M42 Pro's own agents use the MCP server automatically. There is nothing for a customer or consultant to switch on for this path. Same exclusion and permission configurations apply, as explained below.
• External — a separate AI client the customer runs themselves, such as Claude Code, or agents created in Microsoft Copilot Studio, connects to the tenant over OAuth. This requires a one-time Secure Access (previously known as ESA) setup per tenant. See the Connecting External AI Clients to the M42 Professional MCP Server guide for the steps for Claude Code and Microsoft Copilot Studio.

Default tools

Every MCP client — Neo or an external one — sees the same five tools, whatever else has been excluded via the platform settings described further down:

list_templates

Takes no parameters. Returns the code, name, and description of every template the AI can see, after exclusions. This is always the AI's first call — it can't do anything else without first knowing what templates exist.

describe_template

Takes one required parameter: a template code from list_templates. Returns that template's full attribute catalog — every attribute's code, type (text, number, date, reference, static/picklist value, worklog, and a few others), the static value options it can take, what a reference attribute is allowed to point to, whether it's multi-value, and any "enabled if" condition that governs when it applies. It also reports, per attribute, whether the AI may ever write it — a flag is only added to take away permission, so an attribute with no flag is writable — and, at the template level, which folders the AI may create a new record in. The AI is expected to call this before list_datacards (to learn what it can filter, sort, or select by) and before create_datacard (to learn what it's actually allowed to set).

list_datacards

Searches and reads records of one template. Parameters:

• template (required) — the template code.
• filter — an optional query written in Efecte Query Language (EQL), the same query language used elsewhere in M42 Professional's own search, filter, and report screens — e.g. $status$ = 'Open' AND $priority$ >= 3.
• order_by — sort by one or more attributes.
• select — which attributes to include in the result. If omitted, each record comes back with only its ID and name — the AI has to explicitly ask for the fields it actually needs, so a lightweight lookup stays lightweight.
• limit and after — page size (1–200, default 50) and the forward-only cursor for the next page (see Scalability below).
• include_hidden — off by default, so records users don't normally see in M42 Professional's own views (e.g. closed tickets) are excluded unless explicitly asked for. Deleted/trashed records are never returned, regardless of this setting.

Each returned record can carry a readOnly flag when the AI may only view it, not change it — that overrides whatever describe_template said about the individual attributes.

create_datacard

Creates one new record from a template code and a map of attribute values (e.g. {"name": "Broken laptop", "priority": 2}), optionally in a specific folder — otherwise the template's default folder is used. It's all-or-nothing: if any supplied value is invalid, nothing is created, and the AI is told exactly which attribute failed and why (required / unique / validation / permission / unknown), so it can correct and retry without risking a duplicate record. The one exception is a value sent for a field the AI isn't allowed to set at creation — that value is simply dropped (and reported back), rather than blocking the whole creation. What ends up actually stored isn't guaranteed to match exactly what was sent: save-time automation (listeners, workflows, fields that copy values from another record) can still change or clear a value afterwards, the same as it would if a person filled in the same form. One record per call — there's no bulk-create.

update_datacard

Changes one existing record, identified by the ID returned from list_datacards. Only the attributes explicitly supplied are touched — everything else on the record is left exactly as it was. Two behaviors worth knowing:

• For a multi-value field, the list sent replaces the whole set of values, not just adds to it — leaving an existing value out of the list removes it.
• This tool can only set values, never clear them — sending an empty value is rejected rather than blanking the field.

A record flagged readOnly by list_datacards can't be updated at all, and a record someone else is actively editing is refused outright, naming who. As with creation, the same save-time automation can still adjust a value after the fact. One record per call — no bulk-update — and a record can't be moved to a different folder this way.

What the AI can see and change

An MCP client never has more access than the user it's authenticated as. Everything the AI does runs under that user's existing permissions — the same folder, template, and attribute permissions that already apply in the UI:

• Hidden attributes, attributes the admin has explicitly excluded (see Configuration below), and attributes the user has no read permission for are simply invisible to the AI — they never appear in what a tool call returns.
• Before attempting to write anything, the AI is told up front which fields and which records it may change, rather than having to guess and fail. An attribute the user can never write is flagged as read-only; a record the user can only view is flagged the same way at the record level.
• A write still goes through the same permission checks a UI save would — the OAuth scope only bounds what the client is allowed to attempt (read-only vs. also-create vs. also-update); it is never a grant beyond what the authenticated user could already do.
• As of M42 Professional 26.2, a write over MCP also satisfies the same admin-configured validation an interactive UI edit does, including a rule an admin scoped specifically to GUI-style edits.

A few practical exceptions worth knowing before rollout:

• Attachments — the AI can see that a file is attached (its name) but cannot read or download its content.
• A handful of field types are read-only by nature regardless of permissions — worklogs (returned as raw structured data, not formatted text), generated IDs, timestamps, SLA calculations, and similar system-maintained values.
• Reading a field backed by a live search or a computed count re-runs that search/count on every single record returned — worth keeping in mind on templates that use those field types heavily, since it directly affects how expensive a listing is (see Scalability below).

Scalability — it cannot fetch your entire ticket history

A common early question is whether an AI agent could accidentally run an expensive, unbounded query against a large M42 Professional instance — for example "summarize every ticket ever raised." It can't, by construction:

• The tool that lists records (list_datacards) returns at most 200 records per call (50 by default unless the caller asks for more), and further pages are fetched one at a time with a forward-only cursor — there's no cheap way to jump deep into a large result set.
• Every one of those calls is bounded by a 30-second query timeout, specifically because the filter the AI writes is free-form search syntax generated by an LLM — this stops a poorly-formed filter from running unbounded.
• At most 6 AI tool calls run at the same time across the whole tenant (this is a tunable platform setting), so an AI agent cannot saturate the shared database connection pool the way a runaway integration could.
• There is no "count" or "group by" tool exposed to the AI today — it cannot ask the server to aggregate over the whole ticket table in one shot. This was deliberately left out for performance reasons.
• It is still possible to perform searches against a larger data set, from which only the matching subset will be returned.

In short: the MCP server can retrieve a bounded page of matching records per call and nothing more — it has no tool that could scan or aggregate hundreds of thousands of tickets in one request.

Configuring MCP for a customer

Two things determine how well the AI performs once MCP is switched on, and both should be considered before go-live, not discovered afterwards.

1. Template and attribute descriptions are what the AI actually reads

The wording of the MCP tools themselves (e.g. what "list templates" or "create a datacard" means) is fixed and identical on every tenant — it is not meant to be customized per customer, and Matrix42 may change that wording in future releases without notice. It is not the place to make the AI understand your business.

What the AI actually reads to decide which template and which fields are relevant to a request is the description and help text you already maintain on templates and attributes in the admin UI. A template with a clear description and well-described attributes gives the AI the context it needs to search for and act on the right data; a template with blank or unclear descriptions leaves the AI guessing.

Before relying on this, confirm two platform settings are enabled — if either is switched off, the AI receives none of that attribute's description or help text at all, no matter how well it's written:

• mcp.attribute.description.enabled
• mcp.attribute.help.enabled

If instance-specific AI behavior is needed beyond what template/attribute descriptions can express, that's an aicore agent system-prompt change on the AI Core side — not something to solve via MCP tool descriptions.

2. Decide what's off-limits before turning MCP on

Four platform settings let an admin exclude specific templates, classes, attributes, or modules from the AI's reach entirely, regardless of the requesting user's own permissions:

• mcp.excluded.template.codes — list here template codes of those templates that AI should not have access to over MCP
• mcp.excluded.class.codes — list here class codes of those templates that AI should not have access to over MCP
• mcp.excluded.attribute.codes — list here attribute codes of those templates that AI should not have access to over MCP. File attachments cannot be served over MCP. Include any file attachment attributes to avoid undesired behavior.
• mcp.excluded.module.codes

Work through these as part of initial setup for a customer — deciding what an AI agent should never see or touch is a much easier conversation before rollout than after something unwanted has already been exposed.

Other settings worth knowing

• mcp.enabled — master on/off switch for the MCP server on a tenant (on by default).
• mcp.concurrency.limit — the concurrent-call cap mentioned above (default 6); can be retuned live, without a restart, if a customer's usage pattern needs more or less headroom.

One operational note: tool descriptions and server instructions are only read once, when the server starts. If a tool-description property is changed, M42 Professional needs a restart, and in aicore the MCP server entry under Configuration → MCP Servers needs to be re-saved to pick up the new tool catalog — otherwise aicore keeps handing the AI the old description.

Setting up Claude Code

To connect Claude Code to the MCP server, follow the Claude Code section of the Connecting External AI Clients to the M42 Professional MCP Server guide. The guide covers the Secure Access setup that all external clients need, and the Claude Code steps, including the callback URL registration.

Known limitations

• Comments and worklogs cannot be accessed via MCP
• File attachment content cannot be read, downloaded, or uploaded via MCP — the AI can see that a file is attached (its filename) but nothing else.
• Embedded references are not supported
• A few configuration-dependent write paths (fields that copy values from a referenced record, and fields driven by an expression) can behave in ways that are correct but not obvious — e.g. a saved value coming back different from what was sent, because an expression recalculated it.
• IP address values written via MCP are not validated against subnet or reservation rules the way the UI's picker guides a user to a free address — an AI agent has no equivalent guardrail today.

Platform settings reference

All settings below live under the "MCP server" property group in M42 Professional's platform settings. Default values are omitted here — they're visible directly in the admin UI, and can change between releases.

Where to go next

For setting up an external client such as Claude Code or Microsoft Copilot Studio, see the Connecting External AI Clients to the M42 Professional MCP Server guide.