Skip to main content
Glama
sus-tech-gmbh

matrix42-mcp

by sus-tech-gmbh
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Remote

Matrix42 web service discovery

webservice_discovery
Read-only

Explore the Matrix42 REST API by reviewing conventions, listing web services, searching operations, and retrieving detailed operation contracts with parameters and return types.

Instructions

Discover the Matrix42 REST API of the connected instance (read-only metadata). action='api_overview' returns general Matrix42 API conventions (token exchange, the Explicit-Language header, Public vs Product API) — useful for reasoning about the API or writing standalone integration code. action='list_operations' returns operations as {id,name,method,path,service,documentation}; pass 'search' to filter by name/documentation/service or 'service_id' to limit to one service. action='list_services' lists every web service with its documentation. action='describe_operation' with 'operation_id' returns that operation's full contract: HTTP method, path, parameters with types, and return type. Typical flow: api_overview (once) → list_operations(search) → describe_operation(id).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of operations to return (default 200, 0 = no limit). Only used with action='list_operations'.
actionYesWhich discovery step to perform.
searchNoCase-insensitive filter over operation name, documentation, and service name. Only used with action='list_operations'.
service_idNoLimit results to a single web service (id from action='list_services'). Only used with action='list_operations'.
operation_idNoOperation id to describe. Required for action='describe_operation'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.5

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description details per-action behavior, including return shapes for list_operations, the nature of api_overview content, and the required inputs for describe_operation. It also clarifies that the tool is metadata-only and references authentication conventions as discoverable content, providing meaningful behavioral context.

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?

The description is dense but well-structured, front-loading the core purpose and then systematically covering each action, its parameters, and the typical flow. Every sentence carries actionable information without repetition or 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 multi-action discovery tool with no output schema, the description is exceptionally complete: it defines all actions, their return content, parameter usage, and a recommended call sequence. An agent has enough information to select the right action and parameters for a discovery task.

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?

The input schema already documents all five parameters with a high coverage level, so the baseline is 3. The description adds value by mapping each parameter to the action it affects, explaining search and service_id filtering semantics, and noting operation_id's requirement for describe_operation.

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 clearly identifies a specific verb ('Discover'), a specific resource ('Matrix42 REST API of the connected instance'), and its read-only metadata nature. It enumerates four distinct actions with concrete outputs, so an agent can understand the tool's scope and distinguish it from data-query or schema-related siblings.

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

Usage Guidelines4/5

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

The description gives clear context for when this tool is useful: reasoning about the API or writing standalone integration code. It also provides a typical discovery flow, but it does not explicitly name sibling tools or state when not to use it, so it stops short of a full when/when-not comparison.

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

Install Server

Other Tools