DMX to GDTF

Identify fixture by DMX channels

match_dmx_channels

Read-onlyIdempotent

Finds the fixtures whose GDTF profile matches a DMX channel list and the matched DMX mode: channel names in DMX order from address 1 (English, Czech, German or Spanish; abbreviations, synonyms and typos are understood), as in a manual, on a console or in a fixture-profile TXT. Give channels (a list) or text (a pasted list, or a TXT with one or more modes; rows such as "Shutter;0;Closed;32;Open" add DMX values as a tie-breaker). Returns up to limit fixtures with score 0-100, the matched GDTF mode (mode.name and mode.channels), links to the fixture page (url) and the .gdtf file (gdtf_url), confidence and same_score_count (several fixtures with the same layout: ask for the manufacturer or DMX values). Same search as https://gdtf-lights.com/dmx-to-gdtf. Limit per IP: 20000 searches a day and 300 a minute, shared with the JSON API of that page; 500 a minute and 10000 an hour for all API and MCP clients together.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "match_dmx_channels"
  }
}

Input Schema

Name	Required	Description
`text`	No	Instead of channels: a pasted channel list (one per line, numbered or comma-separated) or a fixture-profile TXT (*mode:N*, --- Mode: ---, ##Name;N##)
`limit`	No	Maximum number of fixtures to return, best score first (1-10, default 5)
`channels`	No	Channel names in DMX order, address 1 first, e.g. ["Pan", "Pan fine", "Tilt", "Tilt fine", "Dimmer", "Shutter", "Color wheel", "Gobo"]; use "Empty" for an unused address
`include_diff`	No	Add for each match the DMX addresses that differ (your channel vs the fixture channel)
`manufacturer`	No	Only fixtures of this manufacturer; part of the name is enough, e.g. "Robe"

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 8, 2026

addedInput schema / properties / channels / items / description

Added value: +"One channel name as written in the manual or on the console, e.g. \"Dimmer\" or \"Pan fine\""

addedInput schema / properties / limit / description

Added value: +"Maximum number of fixtures to return, best score first (1-10, default 5)"

First observedNov 7, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already cover the read-only/idempotent/non-destructive profile, and the description layers substantial extra behavior on top: score range 0-100, confidence, same_score_count semantics for tied layouts, the DMX-value tie-breaker, include_diff-style address comparison, and concrete rate limits (20k/day, 300/min per IP, shared with the JSON API). That is exactly the operational context an agent needs before calling a rate-limited search endpoint.

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

Conciseness3/5

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

The purpose is front-loaded, but the body is a dense run-on chain of parentheticals mixing input formats, return fields, tie-breaking advice and rate limits in one paragraph. Nearly every clause carries real information, yet the lack of sentence breaks or ordering makes it harder to scan than it needs to be.

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?

With an output schema already present, the description does not need to enumerate return fields, yet it still explains score, confidence and same_score_count, plus how to disambiguate ties. Combined with the input-format guidance and rate limits, an agent has everything required to invoke this correctly and interpret ambiguous results.

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 coverage is 100%, so a 3 would be the baseline, but the description genuinely adds meaning: accepted languages (English, Czech, German, Spanish), tolerance for abbreviations, synonyms and typos, the 'address 1 first / DMX order' convention, 'Empty' for unused addresses, and the row syntax 'Shutter;0;Closed;32;Open' that turns channel text into a tie-breaker. It does not re-explain limit or manufacturer, but those are already well described in the schema.

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 first clause names a specific verb+resource+outcome: 'Finds the fixtures whose GDTF profile matches a DMX channel list and the matched DMX mode.' It is immediately clear what goes in (channel names in DMX order or pasted text) and what comes out (fixture + matched mode), so an agent would not confuse this with a generic search tool.

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 tells the agent which of the two input paths to pick depending on what it has: 'Give channels (a list) or text (a pasted list, or a TXT with one or more modes)'. It also explains how to resolve ambiguity (ask for manufacturer or DMX values) and points to the equivalent web page. It stops short of explicit when-not-to-use or exclusion guidance, so a 4 rather than 5.

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

All DMX to GDTF tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?