matrix42-mcp

Matrix42 service desk

service_desk

Read-only

Search any ticket kind in Matrix42, fetch ticket summaries and SLA details, and browse or find related business objects such as assets, contracts, and catalog services.

Instructions

Read the service desk and the business objects around it. action='data_model' explains how Matrix42's modules map onto a handful of base classes — read it first if you are unsure where something lives. action='search_tickets' searches ANY ticket kind (incident, problem, change, task, service request, generic ticket, knowledge article) through one uniform contract. Only subject, category_name and states actually filter — Matrix42 accepts the other parameters and ignores them, so they are refused rather than returning every ticket. To filter on a person, ticket number or asset, use data_query with an ASQL where clause. action='get_ticket' returns one ticket's summary (it takes the OBJECT id — a fragment id answers null), action='sla_for_ticket' the service levels that apply to it, and action='sla_times' applies a service-level duration between two points in time. action='browse' lists a curated domain: assets (SPSAssetClassBase), stock_units (SPSStockKeepingUnitClassBase), contracts (SPSContractClassBase), slas (SVCServiceLevelAgreementClassBase), catalog_services (SPSArticleClassBase), bookings (SVCServiceBookingClassBase), kb_articles (SVMKBArticleClassBase), approvals (SVCApprovalTaskClassBase), imports (GDIEImportClassBase), import_runs (GDIEImportLogClassBase), workflow_instances (PLSLProcessInstanceClassBase), workflow_definitions (PLSLComponentClassBase), applications (SPSApplicationClassBase). action='find' searches ALL of those domains at once for a name — reach for it when you do not know where something lives. It does not cover tickets; search those with search_tickets. Columns are resolved against this instance every time, so fields a module does not install are reported as unavailable rather than failing the call.

Input Schema

TableJSON Schema

Name	Required	Description
`end`	No	ISO end of the window, for action='sla_times'.
`kind`	No	Ticket kind to search. Required for action='search_tickets'.
`begin`	No	ISO start of the window, for action='sla_times'.
`limit`	No	Maximum rows to return (default 25).
`where`	No	Additional ASQL filter for browse. Use attribute names from schema_discovery(describe_data_definition).
`action`	Yes	What to do.
`domain`	No	Which curated domain to list. Required for action='browse'.
`search`	No	Free-text filter, matched against a domain's searchable fields. Required for action='find'.
`states`	No	Comma-separated state ids to include. Read valid ids with schema_discovery(get_pickup_values).
`domains`	No	Restrict action='find' to these domains. Defaults to all of them.
`subject`	No	Filter by subject text.
`user_id`	No	User fragment id for only_mine — server_info reports the authenticated account's.
`asset_id`	No	NOT APPLIED by Matrix42 — passing it is refused.
`duration`	No	Duration in minutes to apply. Required by action='sla_times'.
`only_mine`	No	Restrict to items related to the user given in user_id.
`service_id`	No	NOT APPLIED by Matrix42 — passing it is refused.
`category_name`	No	Filter by category NAME (no id needed). One of the three filters that works.
`ticket_number`	No	NOT APPLIED by Matrix42 — passing it is refused. Filter on TicketNumber with data_query instead.
`initiator_name`	No	NOT APPLIED by Matrix42 — passing it is refused. Filter on the initiator with data_query instead.
`recipient_name`	No	NOT APPLIED by Matrix42 — passing it is refused.
`ticket_object_id`	No	Ticket OBJECT id, for get_ticket, sla_for_ticket and sla_times.
`recipient_role_name`	No	NOT APPLIED by Matrix42 — passing it is refused.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.5Sep 2, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark the tool as readOnly and openWorld, and the description reinforces this ('Read the service desk'). It adds substantial operational nuance beyond the annotations: Matrix42 silently ignores certain filter parameters and the tool refuses them, get_ticket answers null for fragment ids, fields absent from a module are reported as unavailable rather than failing, and search_tickets covers all ticket kinds through one contract.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Long but justifiably dense: seven actions, thirteen browse domains, and multiple caveats are packed into a well-organized, front-loaded description. Each sentence carries operational value, from 'read it first if you are unsure' to the closing note about per-instance column resolution. There is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a polymorphic read-only tool with 22 parameters and no output schema, the description is remarkably complete. It covers every action, the domain list for browse, the relationship to data_query, the exact filter caveat, id-type semantics for get_ticket, and instance-specific schema resolution. The sibling tools are addressed where relevant, and the absence of an output schema is mitigated by explaining what each action returns or how failures surface.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3; the description builds on that by clarifying which parameters actually do something ('Only subject, category_name and states actually filter'), which parameters are refused, and how action-specific parameters map to actions like sla_times or get_ticket. It does not exhaustively walk through all 22 parameters, but the schema already describes each one, so this is appropriately complementary.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear 'Read the service desk and the business objects around it' and then enumerates each action with a specific verb and resource: search_tickets, get_ticket, sla_for_ticket, sla_times, browse, find. It explicitly distinguishes find from search_tickets ('It does not cover tickets') and points to data_query for person/ticket-number/asset filtering, so an agent can tell it apart from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives direct routing guidance: read data_model first if unsure where something lives, use find when you do not know where something lives, use search_tickets for tickets, and use data_query with an ASQL where clause to filter on person, ticket number, or asset. It also warns which parameters are ignored/refused, preventing wasted calls.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Matrix42 service desk

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools